Procedimento para resolver o problema de replicação ou sincronização do banco de dados no Prime Network

Introduction

Este documento descreve um procedimento passo a passo para resolver problemas de replicação ou sincronização de bancos de dados no Prime Network quando o banco de dados standby do banco de dados principal é recriado.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Use este procedimento para reconstruir o banco de dados secundário somente se SWITCHOVER_STATUS do banco de dados principal estiver em UNRESOLVABLE GAP.
• Certifique-se de que o banco de dados principal esteja no modo LEITURA GRAVAÇÃO e o banco de dados secundário esteja no modo SOMENTE LEITURA ou LEITURA APENAS COM APLICATIVO.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Prime Network versão 3.9 e superior
• Versão do Oracle Database 11G

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informações de Apoio

1. Use este comando para saber switchover_status do banco de dados principal:

SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
UNRESOLVABLE GAP 

Note: O switchover do Prime Central Geo HA falha abruptamente, deixando o sistema Prime Central GEO HA e/ou o status da função do banco de dados corrompido (em primeiro lugar ou em ambos em standby) e você precisará reconstruir o principal ou o secundário, dependendo do último status ativo/em standby.

Note: Para todos os outros casos, abra o SR com o Cisco TAC para resolver o problema de replicação de banco de dados.

2. Use este comando para saber o modo atual do banco de dados principal e secundário:

 SQL> select open_mode from v$database;  

Problema

Falha na replicação do banco de dados de rede Prime.

O aplicativo Prime Network cria eventos do sistema que notificam tais falhas, que estão disponíveis no cliente da GUI do Event Vision.

Troubleshoot

Antes da solução, execute etapas básicas de solução de problemas como:

1. Verifique a conectividade da rede e/ou os problemas relacionados à latência entre o Prime Network Gateway primário e secundário.

2. Verifique estes logs de banco de dados no Principal para encontrar erros de ORA relacionados ao banco de dados:

<database_home_directory>/diag/rdbms/anadb/anadb/trace/alert_anadb.log

3. Verifique o status open_mode, current_scn e switchover no banco de dados Principal e Secundário.

SQL> select open_mode from v$database;
SQL> select current_scn from v$database;
SQL> select switchover_status from v$database;

4. A causa raiz da replicação do banco de dados pode ser o problema de comunicação de rede entre o Prime Network Gateway primário e secundário, o banco de dados corrompido ou erros semelhantes relacionados ao banco de dados.

Solução

Execute o procedimento de restauração do banco de dados no Prime Network Gateway primário e secundário:

Etapa 1. Os trabalhos de backup agendados atuais mantêm vários dias de arquivos de log no sistema de arquivos. Para evitar que os arquivos de log do arquivo sejam removidos, esta linha em backup_daily.sh, backup_high_daily.sh, backup_week.sh e backup_high_week.sh é comentada:

Altere delete noprompt archivelog até a hora ... para #excluir o log de arquivamento do noprompt até a hora ...

Note: Esses scripts '.sh' pertencem ao usuário oracle e podem ser encontrados no diretório $ORACLE_HOME/ana_scripts.

Etapa 2. No banco de dados principal, faça login como sysdba e localize o número de arquivos redo no sistema e execute este comando:

SQL> select member from v$logfile;

Para cada log, execute este comando. Portanto, se o comando anterior retornou 6 linhas, execute o próximo comando 6 vezes.

SQL>alter system switch logfile;

Etapa 3. No banco de dados em standby, faça login como sysdba e crie um arquivo a partir do spfile:

SQL>create pfile='$ORACLE_HOME/dbs/ana_sb_init.ora' from spfile;

Etapa 4. No banco de dados em standby, faça login como sysdba e localize o caminho do diretório para o arquivo de dados, pedaços de backup, redo logs e arquivos de log. Isso pode ser feito com estes comandos:

Para localizar os arquivos de dados:

SQL> select name from v$datafile;

Para localizar os arquivos de backup:

rman target /
RMAN> list backup;

Para localizar os arquivos de redo log:

 SQL> select member from v$logfile;

Para localizar o archiveLog:

SQL> show parameter log_archive_dest_1;

Desligar o banco de dados:

sqlplus / as sysdba
SQL> shutdown immediate;

Etapa 5. Exclua todos os arquivos de arquivo, pedaços de backup, arquivos de redo log e arquivos de log dos diretórios correspondentes (o caminho foi encontrado na Etapa 4).

Em seguida, reinicie o nomontcom o arquivo criado na Etapa 3:

sqlplus / as sysdba
SQL>startup nomount pfile='$ORACLE_HOME/dbs/ana_sb_init.ora;

Etapa 6. No banco de dados principal, faça uma cópia de todos os pedaços de backup originais na pasta de backup e armazene-os em outro local.

Passo 7. No banco de dados principal, conecte-se ao RMAN e use excluir backup para remover todos os pedaços de backup físicos do sistema de arquivos.

#rman target /
RMAN>delete backup;

Etapa 8. No banco de dados principal, conecte-se ao RMAN e faça um backup completo do banco de dados, arquivo de controle em standby e arquivo de arquivamento nessa ordem. Execute estes comandos:

#rman target /
RMAN>backup database;
RMAN>backup format '$BACKUP_DIR/Control%U' current controlfile for Standby;
RMAN>backup archivelog all;

Note: O $BACKUP_DIR é a pasta de backup atual encontrada com o backup de lista anteriormente e o arquivo será chamado de Control%U no futuro. Não é uma variável.

Etapa 9. No banco de dados principal, conecte-se ao RMAN e use o backup de lista para descobrir a verificação de ckp para o campo de controle Standby que foi criado na Etapa 8. Procure o arquivo com o formato de nome $BACKUP_DIR/Control%U.

Tipo de chave BS Tipo de dispositivo Tamanho LV Tempo decorrido Conclusão

— — — — — —

2358 DISCO Full 1,09M 00:00:04 21-JAN-14

Chave BP: 2358 Status: DISPONÍVEL compactado: SIM Tag: TAG20140121T162311

Nome da peça: /export/home/oracle/backup/Control9nouks3f_1_1

Arquivo de controle de standby incluído: SCN Ckp: 164541747 Hora Ckp: 21-JAN-14

Note: Neste exemplo, o backup do arquivo de controle em standby é /export/home/oracle/backup/Control9nouks3f_1_1. Na linha abaixo deste nome de arquivo, você vê "Ckp SCN: 164541747". Usaremos o número "164541747" no bloco de execução de duplicação na Etapa 13.

Etapa 10. No banco de dados principal, ative todas as partes de backup criadas na Etapa 8. Como o usuário raiz SCP, o arquivo tar para a pasta de backup no banco de dados Standby.

Etapa 11. No login do banco de dados em standby como usuário raiz e use chown para alterar a propriedade do arquivo tar para oracle:dba. Em seguida, mude o usuário de volta para oracle(su - oracle) e descompacte o arquivo tar.

Etapa 12. No login do gateway principal como usuário de rede principal e cd para ~/Main diretory, execute este comando para obter a senha do sistema:

./runRegTool.sh –gs 127.0.0.1 get 127.0.0.1 persistency/general/EmbeddedDBSystemPass

Note: A senha sys retornada é usada na próxima etapa para se conectar ao banco de dados Standby do banco de dados Principal.

Etapa 13. No banco de dados principal, conecte-se ao banco de dados de destino (principal) e, em seguida, ao banco de dados auxiliar (standby). Em seguida, execute o bloco de execução duplicado para criar o banco de dados Standby:

#rman target /
RMAN>connect auxiliary sys/$sys_pwd@ANADB_SB
RMAN>run {
set until scn $SCN_NUMBER;
duplicate target database
for Standby
dorecover
spfile
set "db_unique_name"="anadb_sb"
set LOG_ARCHIVE_DEST_2="Service=anadb ASYNC LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
database_unique_name=anadb"
set FAL_CLIENT="anadb_sb"
set FAL_SERVER="anadb"
set log_file_name_convert="$REDO","$REDO"
nofilenamecheck;
}

Note: $sys_pwd é a senha do sistema que você obteve na Etapa 12. O $SCN_NUMBER no bloco de execução é obtido na Etapa 9. como um exemplo. $REDO é o local do redo log seguido por /.

Etapa 14. Depois que o bloco de execução for executado na Etapa 13. completa, depois no login do banco de dados em standby como sysdba e execute estes comandos para ativar o banco de dados em standby no modo somente leitura seguido por somente leitura com o modo de aplicação:

sqlplus / as sysdba
SQL>shutdown immediate;
SQL>startup nomount;
SQL>alter database mount Standby database;
SQL>recover managed Standby database using current logfile disconnect from session;
SQL>recover managed Standby database cancel;
SQL>alter database open read only;
SQL>recover managed Standby database using current logfile disconnect from session;

Etapa 15. Após a verificação no banco de dados principal, descomente esta linha em backup_daily.sh,backup_high_daily.sh, backup_week.sh e backup_high_week.sh:

Alterar #delete noprompt archivelog até a hora ... para excluir um log de arquivo de prompt até a hora ...

Verificar

Verificação de banco de dados no gateway de rede Prime primária e secundária:

1. Verifique se o número e os nomes dos arquivos de redo log são os mesmos no banco de dados Principal e Standby.

2. Verifique se o número e o tamanho dos arquivos de dados nos bancos de dados Principal e Standby são iguais.

3. Use este comando nos bancos de dados Primbary e Standby para mostrar que a SCN atual no banco de dados Standby pode acompanhar a SCN no banco de dados Primário:

sqlplus / as sysdba
SQL>select current_scn from v$database;

4. Verifique se o open_mode do banco de dados Primário é READ WRITE e READ ONLY WITH APPLY on Standby database.

sqlplus / as sysdba
SQL>select open_mode from v$database;

5. Verifique se o switchover_status do primary é TO STANDBY e NOT ALLOWED no banco de dados de standby:

sqlplus / as sysdba 
SQL>select switchover_status from v$database;

6. Validar se os registros de arquivo estão sendo transferidos

No banco de dados principal:

SQL> alter system switch logfile;

No banco de dados secundário:

Verifique se um novo arquivo foi criado em ~/arch.

7. Verifique se você não verá a falha de replicação do banco de dados na GUI do Event Vision a partir de agora (nos próximos 20 minutos).