Oracle disponibiliza shapes E4.Flex para DB System

Em constante evolução a Oracle disponibilizou esta semana a utilização de shapes E4.Flex, para a criação de DB Systems. Possibilitando desta forma uma maior personalização na criação de ambientes de banco de dados Oracle.

Os shapes flexíveis permitem uma maior personalização no número de OCPUs alocadas para uma instância de banco de dados, otimizando assim o desempenho e reduzindo os custos. 

A quantidade de memória, rede e IO são determinados pelo número de OCPUs selecionadas, sendo que, para cada OCPU (limitando a 64 OCPUs) são alocados 16GB de memória (limitado a 1024GB), 1Gbps de network (limitado a 40 Gbps) e 16K de IOPS (limitado a 640K).

Os shapes estão disponíveis para utilização com o Oracle Database 21c, 19c, 12.2 e 12.1 com Patch de abril de 2022.



Além da maior flexibilidade que o shape E4.flex vai permitir, vale destacar que ele é composto por processadores  EPYC 7J13 'Milan' que comparados aos X7 apresentam um ganho de performance de aproximadamente 15%, conforme destacado no artigo shapes E4.Flex


https://docs.oracle.com/en-us/iaas/dbcs/doc/virtual-machine-db-systems.html#DBSCB-GUID-3452CF5F-0245-4F5C-8C96-378F2A41D5A1

https://www.eximioti.com.br/post/oracle-disponibiliza-shapes-e4-para-db-systems

Oracle KVM disponível para Oracle Linux 8


O Oracle Linux KVM fornece uma solução de virtualização open source, moderna, de alta performance e alternativa, sem custos de licenciamento.

Lançado com a versão Oracle Linux 7.5 de 17 de abril de 2018 o Oracle Linux KVM foi aprimorado para oferecer desempenho e segurança para implementação de virtualizações. Além de facilitar a migração das cargas de trabalho para a Oracle Cloud. 

O Oracle Linux KVM pode ser utilizado para otimizar e reduzir os custos de licenciamentos do Oracle Enterprise Edition através da fixação de cores a maquinas virtual onde roda o banco de dados (hard partitioning technology),  que permite que os núcleos físicos possam ser fixados em um servidor virtual específico.

Oracle Linux KVM passou a ser a nova opção para virtualização disponibilizada pela Oracle.

Final de abril deste ano a Oracle finalmente anunciou o Oracle Linux Virtualization Manager 4.4 que além de vários aprimoramentos e correções de Bugs, passa a suportar o Oracle Linux 8.

Para mais detalhes: 

https://blogs.oracle.com/virtualization/post/oracle-expands-oracle-linux-kvm-server-virtualization-solution-with-oracle-linux-8-support

https://www.eximioti.com.br/post/oracle-kvm-dispon%C3%ADvel-para-oracle-linux-8

Alta disponibilidade no Oracle Standard Edition 19c – Oracle SEHA (Standard Edition High Availability)


Uma das grandes mudanças relacionadas ao Oracle 19c Standard Edition 2 (SE2), foi a remoção do Oracle Real Application Cluster. Com isso, todo ambiente RAC Standard Edition que for atualizar para o Oracle 19c, precisa remover o RAC antes de iniciar o processo de upgrade. Este processo de remoção é detalhado na Doc ID (2504078.1).

Alguma das alternativas disponíveis até a versão 19.7 eram:

* Migrar para a versão Enterprise Edition (EE) e adquirir a feature RAC, 

* Migrar para uma single instance;

* Permanecer na versão 18c;

* Buscar soluções na Oracle cloud

A partir da versão 19.7 a Oracle introduziu Standard Edition High Availability (SEHA), uma nova feature de alta disponibilidade para tentar preencher a lacuna criada com a remoção do Real Application Cluster (RAC). 

O SEHA utiliza os benefícios da arquitetura de cluster disponível no Oracle Grid Infrastructure, como o Oracle Clusteware, Oracle Automatica Storage Management (ASM) e Oracle ASM Cluster File System (ACFS). Desta forma permite que o processo de failover do SEHA seja muito mais rápido do que qualquer outra solução disponível.

Atualmente é disponibilizado para as arquiteturas Linux x86-64, Oracle Solaris on SPARC (64-bit) e Microsoft Windows, substituindo o Oracle Fail Safe que passou a ser depreciado também a partir da versão 19c.

Vale destacar que diferentemente do Oracle RAC no qual ambos os nodes possuem uma instância ativa, o SEHA trabalha em modo failover, ou seja, a instância fica ativa no servidor principal e será ativado no servidor secundário em caso de problemas com o primário. Desta forma o tempo de indisponibilidade para os usuários comparado com um ambiente RAC também é significativamente maior.
 

O SEHA pode ser licenciado utilizando a regra dos 10 dias, que permite executar ambiente licenciados em um ambiente sobressalente não licenciado em um ambiente de failover, por um período total de 10 dias ao longo de qualquer ano. 
Para mais detalhes sobre este licenciamento, pode-se consultar o link abaixo.

link da regra: https://www.oracle.com/assets/data-recovery-licensing-070587.pdf

#DICA - Alterando o timezone no Oracle Linux 7


Através do comando timedatectl, que interage com o gerenciador de serviços responsável ela configuração da zona de fuso horário no linux é possível consultar o timezone atual. Para isso, basta executar o comando sem passar parâmetros.

[root@prd-app-tasy01 ~]# timedatectl Local time: Tue 2022-03-22 13:09:08 EDT Universal time: Tue 2022-03-22 17:09:08 UTC RTC time: Tue 2022-03-22 17:09:08 Time zone: America/New_York (EDT, -0400) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2022-03-13 01:59:59 EST Sun 2022-03-13 03:00:00 EDT Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2022-11-06 01:59:59 EDT Sun 2022-11-06 01:00:00 EST

Para consultar os timezones existentes:

[root@prd-app-tasy01 ~]# timedatectl list-timezones | grep Paulo America/Sao_Paulo [root@prd-app-tasy01 ~]# timedatectl list-timezones | grep Arg America/Argentina/Buenos_Aires America/Argentina/Catamarca America/Argentina/Cordoba America/Argentina/Jujuy America/Argentina/La_Rioja America/Argentina/Mendoza America/Argentina/Rio_Gallegos America/Argentina/Salta America/Argentina/San_Juan America/Argentina/San_Luis America/Argentina/Tucuman America/Argentina/Ushuaia [root@prd-app-tasy01 ~]#

Para alterar o fuso horario, basta utilizar a opção "set-timezone" seguido do nome da zone desejada. Posteriormente, reiniciar o serviço.

[root@prd-app-tasy01 ~]# timedatectl set-timezone America/Manaus [root@prd-app-tasy01 ~]# timedatectl Local time: Tue 2022-03-22 13:09:32 -04 Universal time: Tue 2022-03-22 17:09:32 UTC RTC time: Tue 2022-03-22 17:09:32 Time zone: America/Manaus (-04, -0400) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: n/a [root@prd-app-tasy01 ~]# date Tue Mar 22 13:09:38 -04 2022 [root@prd-app-tasy01 ~]#

[root@prd-app-tasy01 ~]#


[INS-08101] Unexpected error while executing the action at state: 'supportedOSCheck'

Durante a instalação do Oracle database 19c em um ambiente Oracle Linux 8.5, estava ocorrendo o erro abaixo.


[root@serverdbtasy ~]# cat /etc/oracle-release Oracle Linux Server release 8.5 [root@serverdbtasy ~]#

Conforme consta na matriz de certificação do Oracle Database 19c, o mesmo é homologado para o Oracle Linux 8.x, e não deveríamos ter erro durante a sua instalação.

Esse erro ocorre devido a instalação que esta sendo utilizada estar sendo a release base 19.3.0.0. Para evitar o erro é possível aplicar o workaround abaixo ou aplicar o último PSU disponível antes de instalar o produto.
  • Exportar a variável CV_ASSUME_DISTD='OL7' antes de executar o instalador.

Uma alternativa melhor é aplicar o último PSU disponível para a instalação. Desta forma o erro não será apresentado. Neste exemplo, apliquei o PSU 19.14.

[oracle@serverdbtasy ContentsXML]$ cd /orabin01/app/oracle/product/19.0.0.0/dbhome_1/ [oracle@serverdbtasy dbhome_1]$ [oracle@serverdbtasy dbhome_1]$ ./runInstaller -silent -applyRU /orabackup/33509923/33515361 Preparing the home to patch... Applying the patch /orabackup/33509923/33515361... Successfully applied the patch. The log can be found at: /orabin01/app/oraInventory/logs/InstallActions2022-03-11_01-52-35PM/installerPatchActions_2022-03-11_01-52-35PM.log Launching Oracle Database Setup Wizard...


#DICA - Apos criar um novo pdb no OCI - ORA-28361: master key not yet set


Após a criação de um novo pdb em um ambiente Oracle database cloud service tivemos o erro abaixo ao criar uma nova tablespace.

SQL> create tablespace teste;
create tablespace teste
*
ERROR at line 1:
ORA-28361: master key not yet set


ALERTLOG
2022-03-10T08:27:35.587135-03:00
PIRA2011(5):create tablespace teste
2022-03-10T08:27:35.587301-03:00
PIRA2011(5):Force tablespace TESTE to be encrypted
PIRA2011(5):Master key not set for this container (5). Please ensure that wallet is configured and master key is set.
PIRA2011(5):ORA-28361 signalled during: create tablespace teste...
Status do wallet no PDB.

SQL> set lines 210
SQL> col WRL_PARAMETER for a45
SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
WRL_PARAMETER STATUS WALLET_TYPE
--------------------------------------------- ------------------------------ --------------------
OPEN_NO_MASTER_KEY AUTOLOGIN
SQL> SQL>



O erro ocorre pois após a criação de um novo PDB é esperado que a master key seja criada e ativada. Para a criação e ativação da master key, basta seguir os passos abaixo.

Desabilitar a opção de auto-login movendo o arquivo de wallet para um diretório de backup. Confirmar que não existam arquivos .sso no diretório do wallet.

mv /opt/oracle/dcs/commonstore/wallets/tde/cdbprd01/cwallet.sso /opt/oracle/dcs/commonstore/wallets/tde/cdbprd01_bkp

Fechar e reabrir a wallet usando a senha, no cdb.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE close;

keystore altered.

SQL> set lines 210
SQL> col wrl_parameter for a60
SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

WRL_PARAMETER                                                STATUS                         WALLET_TYPE
------------------------------------------------------------ ------------------------------ --------------------
/opt/oracle/dcs/commonstore/wallets/tde/cdbprd01/            CLOSED                         UNKNOWN
                                                             CLOSED                         UNKNOWN
                                                             CLOSED                         UNKNOWN
                                                             CLOSED                         UNKNOWN
                                                             CLOSED                         UNKNOWN

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open IDENTIFIED BY "SENHA";

keystore altered.

SQL> show pdns;
SP2-0158: unknown SHOW option "pdns"
SQL> show pdbs;

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PRD01                          READ WRITE NO
         4 ANS2011                        READ WRITE NO
         5 PIRA2011                       READ WRITE NO

Conectar no PDB que estava apresentando erro execute os passos abaixo.

SQL> alter session set container=PIRA2011;

Session altered.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open IDENTIFIED BY "pzlv##qZv43fED";

keystore altered.

SQL> administer key management set key identified by  "pzlv##qZv43fED" with backup;

keystore altered.

SQL>  set lines 210
col wrl_parameter for a60
SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;SQL> SQL>

WRL_PARAMETER                                                STATUS                         WALLET_TYPE
------------------------------------------------------------ ------------------------------ --------------------
                                                             OPEN                           PASSWORD

Apos o processo feito no PDB criado, é necessário conectar no CDB, executar o comando para ativar o auto-login e então realizar um restart da base.

No comando abaixo é passado o caminho do wallet (/opt/oracle/dcs/commonstore/wallets/tde/cdbprd01) e a senha.

SQL> alter session set container=CDB$ROOT;

Session altered.

SQL>  administer key management create AUTO_LOGIN keystore from keystore '/opt/oracle/dcs/commonstore/wallets/tde/cdbprd01' identified by  "SENHA;
keystore altered. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> SQL> startup; ORACLE instance started. Total System Global Area 1.4361E+10 bytes Fixed Size 9151448 bytes Variable Size 6710886400 bytes Database Buffers 7616856064 bytes Redo Buffers 24399872 bytes Database mounted. Database opened. SQL>

Assim que o banco iniciar novamente, podemos validar que o status da wallet está open e com autologin.

SQL> set lines 210
SQL> col wrl_parameter for a60
SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

WRL_PARAMETER                                                STATUS                         WALLET_TYPE
------------------------------------------------------------ ------------------------------ --------------------
/opt/oracle/dcs/commonstore/wallets/tde/cdbprd01/            OPEN                           AUTOLOGIN
                                                             OPEN                           AUTOLOGIN
                                                             OPEN                           AUTOLOGIN
                                                             OPEN                           AUTOLOGIN
                                                             OPEN                           AUTOLOGIN

SQL> show pdbs;

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PRD01                          READ WRITE NO
         4 ANS2011                        READ WRITE NO
         5 PIRA2011                       READ WRITE NO
SQL> alter session set container=PIRA2011;

Session altered.

SQL> create tablespace teste;

Tablespace created.

SQL> drop tablespace teste;

Tablespace dropped.

Provided in [OCI-C, OCI]: Newly Created PDB Inside The Container Database Shows Wallet Error "OPEN_NO_MASTER_KEY" Note 2443398.1

OCI : Create Create Tablespace in-PDB Fails with 'ORA-28374: Typed Master Key Not Found In Wallet' (Doc ID 2496205.1)