Configurar o Banco de Dados Secundário Futuro

Depois de estabelecer o primeiro stand-by físico no Oracle Cloud Infrastructure (OCI), você criará um segundo em outra região. Esse segundo banco de dados é o banco de dados em seu ambiente de recuperação de desastres baseado na nuvem.

A funcionalidade stand-by em cascata do Oracle Data Guard , na qual o segundo stand-by recebe seu redo do primeiro stand-by, e não diretamente do principal local, reduz o tráfego de rede do site do host local. Ele também estabelecerá qual será, em última análise, a principal rota de propagação redo.

Neste momento, há restrições que nos impedem de usar as ferramentas da OCI para estabelecer e gerenciar totalmente nosso futuro banco de dados de recuperação de desastres. No momento, o serviço de nuvem de Associação do Oracle Data Guard não pode registrar um relacionamento de banco de dados stand-by existente e não poderá gerenciar a configuração do banco de dados stand-by. Portanto, por exemplo, o Oracle Managed Disaster Recovery Cloud Service não pode ser usado.

Como ambos os bancos de dados stand-by são estabelecidos com um banco de dados placeholder baseado na OCI, o plano de controle da OCI pode gerenciar patches e outras atividades do ciclo de vida para cada um deles.

Criar Banco de Dados de Placeholder

Use a Console do OCI para criar um novo banco de dados de placeholder em outra região (recomendado) ou em outro domínio de disponibilidade na mesma região.

Siga as etapas aqui. NÃO exclua o banco de dados de placeholder usando ferramentas como OCI ou dbaascli.
  1. Selecione Exadata no Oracle Public Cloud. Escolha o serviço Oracle Exadata Database Service on Dedicated Infrastructure no qual você deseja implantar o banco de dados.

    Siga estas restrições:

    • O home do banco de dados deve estar no mesmo nível de versão, release e patch do software da origem.
    • O DB_NAME deve ser igual ao do banco de dados principal e do primeiro stand-by.
    • O DB_UNIQUE_NAME pode ser deixado em branco ou especificado, mas deve ser diferente do banco de dados principal local e do primeiro banco de dados stand-by físico.
    • Não configure backups automáticos ao provisionar este banco de dados.
    • Não especifique um nome de PDB ao provisionar este banco de dados.
  2. Capture os dados de configuração stand-by em cascata.
    1. Faça log-in como o usuário do SO oracle em um dos nós de banco de dados que hospedam o banco de dados de placeholder recém-criado.
    2. Crie o ambiente para este banco de dados.
    3. Execute o seguinte comando usando seu DB_UNIQUE_NAME:
    $ srvctl config database -db DB_UNIQUE_NAME
    Salve esses dados de configuração, você os usará em várias etapas abaixo.
  3. Desative o banco de dados de placeholder.
    $ srvctl stop database -db cascade standby placeholder database -stopoption immediate
  4. Faça log-in como usuário do sistema operacional da grade. Usando o comando asmcmd, esvazie os arquivos nos diretórios em +DATAC1/DB_UNIQUE_NAME:
    1. DATAFILE
    2. ONLINELOG
    3. Todos PDB GUID/DATAFILE
    4. Todos os arquivos de controle em +DATAC1/DB_UNIQUE_NAME/CONTROLFILE
    5. O arquivo de senha conforme especificado nos dados de configuração capturados na Etapa 1
  5. Em +RECOC1/DB_UNIQUE_NAME, remova os arquivos nos diretórios ARCHIVELOG, AUTOBACKUP e FLASHBACKLOG.
  6. Não remova o spfile.

Preparar para Restauração do Banco de Dados

Configure o novo Oracle home na preparação para a restauração do banco de dados.

  • Ajuste o arquivo tnsnames.ora em cada ambiente para estar ciente de cada um dos outros bancos de dados. Verificar comunicações entre ambientes.
  • Copie o arquivo de senha do primeiro banco de dados stand-by.
  • Copie a wallet de Criptografia Transparente de Dados (TDE) do primeiro banco de dados stand-by.
  • Ajuste os parâmetros de banco de dados para o banco de dados stand-by em cascata.

Configurar TNS para Stand-by em Cascata

Ajuste o arquivo tnsnames.ora em cada ambiente para estar ciente de cada um dos outros bancos de dados. Verificar comunicações entre ambientes.

O Data Guard Broker deve ser capaz de se comunicar com cada banco de dados na configuração, independentemente da instância à qual ele esteja conectado. O Oracle Zero Downtime Migration fez essa configuração para o relacionamento stand-by inicial. Você deve adicionar o banco de dados stand-by em cascata à configuração:
  • Adicione a string de conexão TNS do banco de dados stand-by em cascata aos arquivos tnsnames.ora usados por todas as instâncias do Oracle Real Application Clusters (Oracle RAC) dos bancos de dados principal e stand-by locais
  • Adicione as strings de conexão TNS do banco de dados principal local e dos primeiros bancos de dados stand-by do OCI aos arquivos tnsnames.ora usados por todas as instâncias do Oracle RAC do banco de dados stand-by em cascata.
Essas entradas do TNS devem usar endereços SCAN IP, não o nome SCAN. Veja a seguir um exemplo de entrada TNS compatível que o Oracle Zero Downtime Migration criou para nosso primeiro banco de dados stand-by:
CDBHCM_iad1dx =
          (DESCRIPTION =
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  1>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  2>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  3>)) (PORT = 1521))
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = CDBHCM_iad1dx)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
              (UR=A)
             )
          )

Faça log-in em cada servidor de banco de dados como o usuário do oracle OS, gere seu ambiente e altere o diretório para $TNS_ADMIN.

  1. Para cada instância do Oracle RAC do principal local e do primeiro stand-by do OCI, edite o arquivo tnsnames.ora e adicione a string de conexão TNS do banco de dados stand-by em cascata.
  2. Para cada instância do Oracle RAC do stand-by em cascata do OCI, edite o arquivo tnsnames.ora e adicione strings de conexão TNS para os bancos de dados principal e principal do OCI.
  3. Teste se você pode fazer ping no primeiro banco de dados stand-by do stand-by em cascata, usando o utilitário tnsping com o alias da string de conexão adicionado.
    $ tnsping CDBHCM_iad1dx
    Isso deve retornar OK com tempo de latência em milissegundos. Se OK não for retornado, verifique se há erros e o endereço corretamente.
  4. Teste a conexão de cada um dos servidores de banco de dados que hospedarão o banco de dados stand-by em cascata para o primeiro banco de dados stand-by (CDBHCM_iad1dx) usando o SQL*Plus. Você precisará da senha SYS para o principal.
    $ sqlplus sys/<password>@CDBHCM_iad1dx as sysdba
    Corrija os erros e repita até conseguir se conectar com êxito.

Copiar o Arquivo de Senha

Copie o arquivo de senha do primeiro banco de dados stand-by.

  1. Faça log-in em um dos servidores que hospedam seu primeiro banco de dados stand-by (CDBHCM_iad1dx) como usuário do oracle OS.
  2. Use srvctl para determinar onde o arquivo de senha deste banco de dados está localizado e copie-o para o diretório /tmp.
    Para determinar o local raiz da wallet, execute o seguinte como sysdba:
    $ srvctl config database -db first standby db name
  3. Procure a linha que diz "Arquivo de senha:" e registre sua localização (caminho do Oracle Automatic Storage Management (Oracle ASM)).
  4. Torne-se o usuário do sistema operacional grid e use o comando asmcmd para copiar o arquivo de senha para o diretório /tmp:
    $ asmcmd -p
    asmcmd> cd +DATAC1/path from step 3
    asmcmd> cp <password file name> /tmp/password file name
  5. Transfira o arquivo de senha para um local temporário em um dos servidores de banco de dados stand-by em cascata usando scp ou por qualquer meio que você use para transferir arquivos no OCI.
  6. Faça log-in no servidor de banco de dados stand-by em cascata no qual o arquivo de senha foi colocado, como usuário do sistema operacional da grade. Copie o arquivo de senha para o Oracle ASM, usando o local especificado nos dados de configuração stand-by em cascata acima.
    $ asmcmd -p --privilege sysdba
    asmcmd> pwcopy –dbuniquename cascade standby db unique name /tmp/password-file-name +ASM Diskgroup/path/password-file-name -f
    Por exemplo,
    asmcmd> pwcopy –dbuniquename CDBHCM_phx5s   /tmp/password file name +DATAC1/CDBHCM_phx5s/PASSWORD/orapwCDBHCM_phx5s -f 
  7. Certifique-se de que todas as strings de conexão TNS estejam configuradas corretamente, validando que cada banco de dados possa se conectar a todos os outros bancos de dados. Corrija os erros de conexão das seguintes tentativas de conexão.
    1. No banco de dados local (principal):
      $ sqlplus sys/password@first standby db as sysdba
      $ sqlplus sys/password@cascade standby db as sysdba
    2. Do primeiro stand-by físico:
      $ sqlplus sys/password@on-prem primary as sysdba
      $ sqlplus sys/password@cascade standby db as sysdba
    3. Do stand-by físico em cascata:
      $ sqlplus sys/password@on-prem primary as sysdba
      $ sqlplus sys/password@first standby db as sysdba
    Não prossiga até que todas as tentativas de conexão sejam bem-sucedidas.

Copiar a Wallet de TDE

Copie a wallet de Criptografia Transparente de Dados (TDE) do primeiro banco de dados stand-by. No Oracle Exadata Database Service on Dedicated Infrastructure, o local que as ferramentas de nuvem usam para armazenar as wallets de TDE está no Oracle Advanced Cluster File System (Oracle ACFS), que todos os servidores de banco de dados no cluster compartilham.
  1. Faça log-in em um dos servidores que hospedam seu primeiro banco de dados stand-by (CDBHCM_iad1dx) como usuário do SO oracle e altere o diretório para o local raiz da wallet.
    Para determinar o local raiz da wallet, execute o seguinte como sysdba:
    $ sqlplus / as sysdba
    SQL> show wallet_root
    $ cd wallet root location from “show wallet_root” above
  2. Vá para o local raiz da wallet e compacte o diretório tde.
    O diretório tde está sob o diretório fornecido na etapa 1, que geralmente é /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root.
    $ zip -r CDBHDM_tde_wallet.zip  tde
  3. Transfira esse arquivo ZIP para um dos servidores de banco de dados que hospedarão o banco de dados em cascata (CDBHCM_phx5s) para um local temporário (por exemplo, /tmp).
    Use scp ou por qualquer meio que você use para transferir arquivos no OCI.
  4. Faça log-in nos servidores de banco de dados que hospedarão o banco de dados em cascata (CDBHCM_phx5s) e no qual o arquivo zip foi colocado, como o usuário do SO oracle e altere o diretório para o local raiz da wallet.

    O local deve ser igual ao anterior, pois DB_NAME é o mesmo (CDBHCM).

    $ cd /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root
  5. Mova o diretório TDE existente para outro nome.
    $ mv tde tde_date
  6. Mova o arquivo ZIP que contém a wallet de TDE (CDBHDM_tde_wallet.zip) criada na Etapa 2 para o seguinte caminho:/var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root.
    Substitua DB_NAME pelo nome do seu banco de dados.
  7. Deszipar o arquivo CDBHDM_tde_wallet.zip.
    $ unzip CDBHDM_tde_wallet.zip

Isso cria um novo subdiretório tde com os arquivos da wallet do primeiro banco de dados stand-by físico.

Ajustar os Parâmetros de Banco de Dados para Stand-by em Cascata

Finalize a configuração do banco de dados stand-by em cascata.

  1. Faça log-in em um dos servidores que hospedam o primeiro banco de dados stand-by (CDBHCM_iad1dx) como o usuário oracle OS e origine o ambiente.
    $ . ./CDBHCM.env
  2. Crie um pfile com base no primeiro banco de dados stand-by a ser usado como referência para ajustar os parâmetros no banco de dados stand-by em cascata.
    $ cd $ORACLE_HOME/dbs
    $ sqlplus / as sysdba
    SQL> create pfile=’tmp_CDBHCM_iad1dx_init.ora’ from spfile;
  3. Faça log-in em um dos servidores de banco de dados que hospedarão o banco de dados stand-by em cascata (CDBHCM_phx5s) e origine o ambiente:
    $ . ./CDBHCM.env
  4. Inicialize NOMOUNT em uma instância.
    $ sqlplus / as sysdba
    SQL> startup nomount
  5. Faça os seguintes ajustes nos parâmetros do banco de dados para o banco de dados em cascata, referenciando a lista de parâmetros do banco de dados da Etapa 2 acima:
    SQL> alter system set control_files=’’ sid=’*’ scope=spfile;
    SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 1>’ scope=spfile;
    SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 2>’ scope=spfile;
    SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance N>’ scope=spfile;
    SQL> alter system set sga_target=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
    SQL> alter system set log_buffer=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
  6. Ajuste os parâmetros específicos para PeopleSoft.
    SQL> alter system set “_gby_hash_aggregation_enabled”=false sid=’*’ scope=spfile;
    SQL> alter system set “_ignore_desc_in_index”=true sid=’*’ scope=spfile;
    SQL> alter system set “_unnest_subquery”=true sid=’*’ scope=spfile;
    SQL> alter system set nls_length_semantics='CHAR' sid=’*’ scope=spfile;

    Observação:

    Não altere os seguintes parâmetros:
    • DB_NAME
    • DB_UNIQUE_NAME
    • WALLET_ROOT
  7. Faça shutdown e reinicie NOMOUNT na instância para implementar as alterações.
    $ sqlplus / as sysdba
    SQL> shutdown immediate
    SQL> startup nomount

Restaurar o Banco de Dados para o Stand-by em Cascata

Restaure o banco de dados na pegada stand-by em cascata do primeiro banco de dados stand-by físico. Use o comando RESTORE FROM SERVICE do Oracle Recovery Manager (RMAN) para restaurar o arquivo de controle e os arquivos de dados.

  1. Se a instância do stand-by em cascata não for iniciada, inicie-a em NOMOUNT:
    $ sqlplus / as sysdba 
    $ SQL> startup nomount
  2. Use RMAN para restaurar o arquivo de controle e os arquivos de dados do primeiro stand-by para o stand-by em cascata.

    Observação:

    Pode ser necessário ajustar o número de canais RMAN para "disco do tipo de dispositivo" para não saturar a rede. Se for necessária uma alteração, faça isso antes de executar o comando "restaurar banco de dados do serviço". Você pode fazer isso com o seguinte comando, substituindo N conforme apropriado:
    RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM N; 
    $ rman target / nocatalog
    RMAN> restore standby controlfile from service ‘first standby db name’;
    RMAN> alter database mount;
    RMAN> restore database from service ‘first standby db name’ section size 8G;
    RMAN> shutdown immediate;
    RMAN> exit
  3. Reinicie todas as instâncias e monte o banco de dados stand-by em cascata usando srvctl.
    $ srvctl start database -db cascade standby db unique name -startoption mount
  4. Crie e limpe todos os arquivos de log on-line e stand-by usando o script a seguir.
    $ sqlplus “/ as sysdba”
    SQL> set pagesize 0 feedback off linesize 120 trimspool on
    SQL> spool /tmp/clearlogs.sql
    SQL> select distinct 'alter database clear logfile group '||group#||';' from v$logfile;
    SQL> spool off
  5. Inspecione o script clearlogs.sql gerado antes de executá-lo. Isso fará com que a instância do banco de dados crie e limpe arquivos de logs on-line e stand-by para todos os threads. Em seguida, execute o script.
    SQL> @/tmp/clearlogs.sql

Configurar o Data Guard Broker para o Stand-by em Cascata

Você já configurou o Data Guard Broker entre o banco de dados principal local e o primeiro stand-by do OCI pelo Oracle Zero Downtime Migration. Agora você adicionará o stand-by em cascata à configuração.

Os bancos de dados stand-by em cascata e on-premises não se comunicam diretamente entre si. Quando necessário, seu redo é enviado por meio do primeiro banco de dados stand-by local:

  • Quando o banco de dados local é principal, redo é enviado do principal local para ou por meio do primeiro stand-by e, em seguida, para o stand-by em cascata:
    • Principal local para o primeiro stand-by do OCI
    • Primeiro stand-by do OCI para stand-by em cascata do OCI
  • Quando o primeiro stand-by está na atribuição principal, redo é enviado desse banco de dados diretamente para os bancos de dados stand-by locais e em cascata:
    • OCI principal para o stand-by local
    • OCI principal para stand-by em cascata do OCI
  • Se o stand-by em cascata se tornar principal nessa configuração, o redo será enviado desse banco de dados para ou por meio do primeiro stand-by do OCI e, em seguida, para o banco de dados local:
    • Primeiro stand-by do OCI para o stand-by local
    • Principal em cascata do OCI para o primeiro stand-by do OCI
  1. Configure o Data Guard Broker no servidor de banco de dados que hospeda o stand-by em cascata. Faça log-in em um dos servidores de banco de dados que hospedam o banco de dados stand-by em cascata como o usuário do oracle OS e origine o ambiente.
    $ sqlplus / as sysdba
    SQL> alter system set dg_broker_config_file1=’+DTAC1/cascade standby db/DG/dr1 cascade standby db.dat’ sid=’*’ scope=both;
    SQL> alter system set dg_broker_config_file2=’+RECOC1/cascade standby db/DG/dr2 cascade standby db.dat’ sid=’*’ scope=both;
    SQL> alter system set dg_broker_start=TRUE sid=’*’ scope=both;
  2. Faça log-in no banco de dados stand-by principal ou no primeiro banco de dados stand-by físico e origine o ambiente. Adicione o novo stand-by em cascata à configuração existente do Data Guard Broker.
    $ dgmgrl 
    DGMGRL>  connect sys/password
    DGMGRL> show configuration
    DGMGRL> add database 'cascade standby db’
     as connect identifier is cascade standby db;
  3. Adicione redo routes.
    DGMGRL> edit database on-premises db set property redoroutes='(LOCAL : first standby db ASYNC)';
    DGMGRL> edit database first standby db set property redoroutes='(LOCAL : on-premises db ASYNC, cascade standby db ASYNC)(on-premises db : cascade standby db ASYNC)(cascade standby db : on-premises db ASYNC)';
    DGMGRL> edit database cascade standby db set property redoroutes='(LOCAL : first standby db ASYNC)';
  4. Ative o novo banco de dados stand-by em cascata.
    DGMGRL> enable database cascade standby db;
  5. Depois que o banco de dados em cascata for ativado, ele começará a receber redo gerado pelo banco de dados principal local por meio do primeiro banco de dados stand-by. No Data Guard Broker, mostre a configuração:
    DGMGRL> show configuration lag
    Configuration - zdm_psfthcm_dg
      Protection Mode: MaxPerformance
      Members:
      CDBHCM_sca6dp  - Primary database
        CDBHCM_iad1dx - Physical standby database 
                          Transport Lag:      0 seconds (computed 0 seconds ago)
                          Apply Lag:          0 seconds (computed 1 second ago)
          CDBHCM_phx5s - Physical standby database (receiving current redo)
                            Transport Lag:      1 second (computed 1 second ago)
                            Apply Lag:          2 seconds (computed 1 second ago)
    
    Fast-Start Failover:  Disabled
    
    Configuration Status:
    SUCCESS   (status updated 47 seconds ago)

Definir os Serviços de Banco de Dados Baseados em Atribuição para o Futuro Stand-by

Adicione serviços de banco de dados baseados em atribuição que o aplicativo PeopleSoft usará quando o banco de dados secundário do OCI estiver preenchendo a atribuição PRIMÁRIA.

  1. Adicione serviços de banco de dados baseados em atribuição para o process scheduler.
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_BATCH -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3
  2. Adicione serviços de banco de dados baseados em atribuição para os usuários on-line.
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_ONLINE -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3