Olá a todos,

Como muitos ainda não devem saber, entrei para a Oracle como Strategic Customer Service Manager e me tornei um ACE Alumni.

O Programa Oracle ACE é destinado a Clientes e Parceiros, não a funcionários.

Fiquei no programa por 6 anos e vou continuar dando suporte ao programa, agora do lado da Oracle.

Sou muito grato pelo programa, especialmente para Jennifer Nicholson, Oana-Aurelia Bonu e Cassandra Call, que o administra com paixão e me apoia todos esses anos.

Continuarei escrevendo blogs e ajudando dentro do possível a comunidade como sempre foi desde 2010.

Obrigado a todos pelo carinho e respeito que sempre a comunidade e o programa teve comigo.

Até logo
Andre Ontalba

This is the system:

• 2 Oracle Database Appliances
• Databases running as a single instance
• DataGuard between ODA-1 and ODA-2 for mission-critical databases
• Databases,  12.2 and 19.8
• Currently running ODA 19.8.0.0

The mission is to upgrade one of these 12.2 databases to 19.8. So the basic steps are as follows:

1. Validate Oracle Home for version 19.8
2. Disable DataGuard configuration
3. Stop DataGuard Broker processes
4. Stop Standby database
5. Upgrade Primary database
6. Start Standby database from new home

On an ODA this is quite simple to do. First list Oracle Home an both ODAs:

root@oda-duts-01 ~ # odacli list-dbhomes

ID                                       Name                 DB Version                               Home Location                                 Status

---------------------------------------- -------------------- ---------------------------------------- --------------------------------------------- ----------

7c724f57-a495-4db9-a88a-48323f3632c6     OraDB12201_home1     11.2.0.4.200414                          /u01/app/oracle/product/12.2.0.1/dbhome_1     CONFIGURED

7c525f55-a494-4db7-a70a-45356f3562c6     OraDB1908_home1     11.2.0.4.200414                          /u01/app/oracle/product/19.8.0.0/dbhome_1     CONFIGURED

Next step is disabling the DataGuard configuration:

oracle@oda-duts-02~#  dgmgrl
DGMGRL> connect sys/****@primary

Connected.

DGMGRL> disable configuration

Disabled.

Now stop the DataGuard Broker processes on both, primary and standby:

oracle@oda-duts-02 ~ # sqlplus / as sysdba

SQL> alter system set dg_broker_start=false scope=both;

System altered.

Stop the Standby database:

root@oda-duts-02# srvctl stop database -d DUTSDB

Now do the upgrade of the Primary to the Oracle Home 19c.

root@oda-duts-01# odacli upgrade-database -i d1c80b77-1e74-4643-8b3b-3cac65041340 -to 7c525f55-a494-4db7-a70a-45356f3562c6    

That’s it for the Primary. Now modify the Standby to use the new 19c Database Home. Copy the password file to the new Oracle Home, and, if it is not in a shared location, the SPfile too.

root@oda-duts-02# cp /u01/app/oracle/product/12.2.0.0/dbhome_1/dbs/orapwDUTSDB /u01/app/oracle/product/19.8.0.0/dbhome_1/dbs/

root@oda-duts-02# cp /u01/app/oracle/product/12.2.0.0/dbhome_1/dbs/orapwDUTSDB /dbs/spfileDUTSDB.ora /u01/app/oracle/product/19.8.0.0/dbhome_1/dbs/

The database resource needs to be modified in order to use the new Oracle Home. That is the last time that “srvctl” is run from the old Oracle Home:

root@oda-duts-02# srvctl config database -d DUTSDB

root@oda-duts-02# srvctl modify database -d DUTSDB -o /u01/app/oracle/product/19.8.0.0/dbhome_1

If required, change the SPfile location too:

root@oda-duts-02# srvctl modify database -d DUTSDB -p /u01/app/oracle/product/19.8.0.0/dbhome_1/dbs/spfileDUTSDB.ora

Now the Standby can be started again:

root@oda-duts-02# srvctl start database -d DUTSDB

Last step is to start the DataGuard Broker processes and re-enable the configuration.

oracle@oda-duts-02 ~ # sqlplus / as sysdba

SQL> alter system set dg_broker_start=true scope=both;

System altered.

oracle@oda-duts-02~#  dgmgrl

DGMGRL> connect sys/****@primary

Connected.

DGMGRL> enable configuration

Enabled.

After a few minutes show the configuration of Data Guard.

DGMGRL> show configuration

Configuration - DUTSDG

  Protection Mode: MaxPerformance

  Members:

  DUTSDB   - Primary database

    DUTSDB_DG - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

Hope this helps you!!!

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful

During the duplicate process I got this error

RMAN-06402: Oracle instance shut down
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 14/11/2022 14:08:33
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '+RECO/DUTS/ARCHIVELOG/2022_11_14/thread_2_seq_45.4262.1023037434'
ORA-10877: error signaled in parallel recovery slave

In alert.log

2022-11-14T14:07:52.556223-06:00
kcrf_decrypt_redokey: wallet is not opened..(err 28365) <<<< wallet is not open
Errors with log +RECO/DUTS/ARCHIVELOG/2022_11_14/thread_2_seq_45.4262.1023037434
2022-11-14T14:07:52.673668-06:00
Media Recovery failed with error 28365
Recovery interrupted!
2022-11-14T14:07:52.851222-06:00
Errors in file /u01/app/oracle/diag/rdbms/duts/DUTS/trace/DUTS_pr00_24026.trc:
ORA-00283: recovery session canceled due to errors
ORA-28365: wallet is not open

Solution

• Copy the wallet file (ewallet.p12) from source database server to clone database server. You can check the wallet file location on source database from sqlnet.ora file of the source database ORACLE_HOME scp oracle@duts1:/u01/app/oracle/admin/DUTS/wallet/ewallet.p12 .

• Modify sqlnet.ora file in clone database ORACLE_HOME to reflect the location of the wallet file:

ENCRYPTION_WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /u01/app/oracle/admin/DUTS/wallet)
)
)

• Invoke orapki utility on the clone database server to make the wallet auto-login:

orapki wallet create -wallet /u01/app/oracle/admin/DUTS/wallet -pwd "oracle" -auto_login

• If above step is successful, you should find a new file is created in the same directory: cwallet.sso

[oracle@duts2 wallet]$ ll *.sso

-rw-rw-r-- 10 oracle oinstall 2048 Nov 14 16:11 cwallet.sso

• STARTUP NOMOUNT the auxiliary instance and try the duplicate command.

After few minutes the problem fixed.

starting media recovery
media recovery complete, elapsed time: 00:50:00
Finished recover at 14-NOV-22

RMAN>

Hope this helps you!!!

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful

How Burstable Instances Work

Burstable instances are able to sustain workloads running at a fraction of CPUs most of the time, and can burst up to the full CPUs for a limited amount of time.

When you create a burstable instance, you specify the total OCPU count (or CPU cores) and the baseline CPU utilization. The baseline utilization is a fraction of each CPU core, either 12.5% or 50%. The baseline provides the minimum CPUs that can be used constantly.

When needed, the instance can use more than the baseline CPU, all the way up the total OCPUs that you provision. This usage above the baseline is called bursting, because it happens automatically and for short periods of time.

The ability to burst depends on the instance’s CPU usage pattern and the underlying server resource usage. If the instance’s average CPU utilization over the past 24 hours is below the baseline, the system will allow it to burst above the baseline.

After the burst is finished by the system, the instance is limited to the baseline CPU.

Limitations and Considerations

• For critical or production workloads that require full OCPU utilization, you should use a regular instance instead. Because the physical VM host is oversubscribed, there is no guarantee that an instance will be able to burst.  
• Network bandwidth is oversubscribed, so there is no guarantee that the instance can use the maximum bandwidth.
• Memory does not burst.
• Custom images are supported if the baseline OCPU meets the minimum requirements for the image.
• Each burstable instance can have one ephemeral public IP address. If you need additional public IPs, assign reserved public IPs to the instance.
• You can attach four block volumes for each 12.5% baseline OCPU, up to the maximum limit.
• Burstable instances must use paravirtualized networking.
• Burstable instances are not supported on dedicated virtual machine hosts, capacity reservations, or preemptible capacity.
• Burstable instances and regular instances share the same service limits and compartment quotas based on the instance’s shape.

OCPU, Memory, Network Bandwidth, and VNICs

Because burstable instances use flexible shapes, you can customize the number of OCPUs and the amount of memory that are allocated to a burstable instance.

• OCPUs: You can select the same range of OCPUs for a burstable instance as you can select for a regular instance that uses the same shape.
• Memory: The amount of memory is based on the total number of OCPUs. For each OCPU, you can select the same ratio of memory for a burstable instance as you can select for a regular instance that uses the same shape, regardless of which baseline OCPU you configure.
• Network bandwidth: The maximum network bandwidth is defined in relation to the baseline OCPU. Network bandwidth does burst.
• VNICs: The minimum number of VNICs, maximum number of VNICs, and ratio of VNICs to OCPUs for a burstable instance are the same as those for a regular instance that uses the same shape.

Supported Shapes

You can use the following shapes to create burstable instances:

• VM.Standard3.Flex
• VM.Standard.E3.Flex
• VM.Standard.E4.Flex

I will prepare a post on how to implement this feature.

Hope this helps you!!!

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful

• Continuidade da solução e dependências codificadas
• Gerenciamento de pool de IP
• Reputação de IP

A Oracle executa um processo de validação em blocos CIDR importados e, após a validação, você é notificado de que o bloco CIDR está disponível para uso.

Limites e Quotas

• A CIDR block that is /24 or smaller is required for addresses to be advertised to the Internet.
• You can’t bring more than 10 IPv4 address ranges to your OCI account.
• You can create up to 10 pools.
• BYOIP is not available to Oracle Cloud Infrastructure Free Tier or Pay As You Go services.
• Your addresses can only be imported to a specific Oracle region.
• You can use BYOIP with a CIDR block that is a minimum of /24 and a maximum of /8.
• You can’t bring the same address range to more than one compartment at a time.

Requisitos e preparação

Você deve ter a propriedade do bloco CIDR IPv4 público que deseja importar para o Oracle Cloud Infrastructure e a propriedade deve ser registrada em um Regional Internet Registry (RIR) compatível.

A Oracle valida a propriedade de seus endereços. Apenas os seguintes registros são suportados, e os endereços devem ter um tipo ou status especificado:

• American Registry for Internet Numbers (ARIN) – “Direct Allocation” and “Direct Assignment” network types
• Réseaux IP Européens Network Coordination Centre (RIPE NCC) – “ALLOCATED PA,” “LEGACY,” “ASSIGNED PI,” and “ALLOCATED-BY-RIR” allocation statuses
• Asia-Pacific Network Information Centre (APNIC) – “ALLOCATED PORTABLE” and “ASSIGNED PORTABLE” allocation statuses

Os endereços no intervalo de endereços IP devem ter um histórico limpo. A Oracle pode investigar a reputação do intervalo de endereços IP e podem rejeitar um intervalo de endereços IP que contenha um endereço IP associado a comportamento malicioso.

As etapas necessárias para BYOIP no Oracle Cloud Infrastructure requerem um tempo significativo, portanto, planeje com antecedência para realizar essa importação.

Espero que isso ajude você!!!

Andre Luiz Dutra Ontalba

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”

Link do canal: https://lnkd.in/dMukKNq.

Link da Live: https://lnkd.in/em6jckN

Muito Obrigado ORAWORLD, pela publicação do artigo.

Link do artigo: https://lnkd.in/dUwuxfg

 Logue no Oracle Cloud e clique em “Create an ATP database”.

Preencha as informações e selecione as opções para criar a instância ATP.

Choose a compartment: dbadutra(root)

Display name: DBCLONE

Database name: DBCLONE

Choose a workload type: Transaction Processing

Choose a deployment type: Shared Infrastructure

Configure the database:  Neste  caso como usamos Always Free não podemos alterar o tamanho da CPU e do armazenamento.

Create administrator credentials: OracleATP2020        

Choose a license type: Neste caso selecione License Included

Depois de preencher tudo, clique em “Create Autonomous Database”

Espere alguns minutos pela criação da ATP

Agora selecione o menu “Autonomous Transaction Processing”

Clique em “DBCLONE”

No menu “Actions” clique em “Create Clone”

Agora vamos criar um clone do nosso ATP, preenchendo as informações abaixo.

Clone Type:  Nesta opção, podemos escolher um clone completo ou apenas a estrutura sem dados.  Neste  caso, vamos selecionar O Clone Completo.

Configure clone source: Nesta opção podemos escolher um clone da Instância do Banco de Dados ou usar um Backup para executar este clone e podemos realizar um point in time Clone.

Neste  caso,  usaremos o clone da Instância do Banco de Dados.

Create In Compartment: dbadutra (root)

Display name: Clone of DBCLONE

Database name: DBCLONE2

Configure the database:   Neste  caso como usamos Always Free, não podemos alterar o tamanho da CPU e armazenamento.

Create administrator credentials: OracleATP2020        

Choose a license type: Neste caso selecione o License Included

Agora clique em “Create Autonomous Database Clone”

Espere alguns minutos pela criação do ATP clone

Pronto seu clone está criado e disponível para uso.

Para aprender mais sobre o Autonomous Database Clone clique aqui

Esperamos ter ajudado com este grande novo recurso.

André Ontalba / Rodrigo Mufalani

Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community.”