Estou substituindo o hardware de um cluster RAC de 3 nós existente. Esse sistema também é primário para um banco de dados de espera RAC de 2 nós. Para substituir o hardware, meu plano é estender temporariamente o cluster para uma configuração de 6 nós, 3 servidores antigos e 3 novos servidores. Assim que tiver as instâncias em execução no novo hardware e meus aplicativos se conectarem às novas instâncias, desativarei as instâncias antigas e aposentarei os servidores antigos, voltando para uma configuração de 3 nós.
Depois de estender o cluster para todos os seis nós, no fim de semana passado, iniciei as novas instâncias nos novos nós. Para facilitar minha vida, apenas aproveitei o DBCA para este trabalho. Depois de iniciar o DBCA, optei por trabalhar em um banco de dados RAC e, em seguida, escolhi Gerenciamento de instância e, em seguida, Adicionar nova instância. Percorrendo o assistente, deixei o DBCA cuidar de todos os detalhes para mim. Parece simples.
Esta manhã, recebi meu relatório de atraso de arquivo habitual. Parece semelhante ao seguinte:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Eu envio isso para minha caixa de entrada duas vezes por dia. Uma rápida olhada me ajuda a determinar se meu standby está recebendo e aplicando transações do primário. Configurei todos os meus bancos de dados de espera para um atraso de aplicação de quatro horas. E meu principal tem ARCHIVE_LAG_TARGET definido como uma hora. Isso significa que o atraso de aplicação será de pelo menos 4 horas, mas não deve ser superior a 5 horas. Como podemos ver acima, temos dois bancos de dados de espera que excederam muito o atraso de aplicação máximo de 5 horas. Acima, tenho o standby com um apply lag de 1 dia 21 horas! Então eu imediatamente soube que algo estava errado. E não foi preciso ser um cientista de foguetes para saber que adicionar a nova instância à primária provavelmente contribuiu para o problema.
Como eu disse no início deste post, tenho um sistema standby RAC de 2 nós. Uma instância é a “instância de aplicação” e a outra instância fica relativamente ociosa. No meu log de alerta de instância de aplicação, vi as seguintes mensagens de erro:
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
Como tenho meu banco de dados de espera definido como STANDBY_FILE_MANAGEMENT=AUTO, a primeira parte das mensagens faz sentido. Ao adicionar uma nova instância a um banco de dados RAC, você precisa fornecer um Undo Tablespace apenas para essa instância e também fornecer grupos de redo logs online dedicados ao thread dessa instância. O DBCA me perguntou especificamente sobre as estruturas de arquivos de desfazer e refazer. No conteúdo do log de alertas acima, podemos ver que o standby adicionou com sucesso o arquivo de dados 342, que é meu tablespace Undo. Mas o modo de espera não conseguiu adicionar os logs de redo online. Se você quiser que o standby possa adicionar automaticamente os redo logs online, você precisa especificar os parâmetros OMF, o que estou relutante em fazer. Como a adição do arquivo de redo log online resultou em um erro, o modo de espera interrompeu a recuperação de mídia. A espera ainda está recebendo logs.
Não encontrei muito no Metalink ou fazendo pesquisas no Google sobre como resolver esse problema, mas aqui estão as etapas que fiz para que o Media Recovery voltasse a funcionar. No banco de dados em espera (eu fiz isso na instância de aplicação, mas deve ser viável em qualquer instância no banco de dados em espera do RAC):
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
Isso não deve ser um choque porque sabemos que o Managed Recovery foi abortado. Mas para completar, incluí este passo. Se você precisar adicionar logs de redo a uma espera que esteja aplicando transações no momento, precisará desta etapa.
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
O acima é exatamente o que foi executado no primário. Precisa adicionar o redo log no standby exatamente como feito no primário. Repita para cada grupo de redo logs adicionado ao primário. Como adicionei 3 instâncias ao meu banco de dados RAC primário, preciso adicionar três threads aqui.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Inicie a recuperação gerenciada. Tudo deve estar bem agora e podemos verificar no log de alerta da instância de aplicação:
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Também podemos verificar que o atraso de aplicação está diminuindo. No modo de espera, emita o seguinte:
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d
where d.name='apply lag';
Para obter informações básicas sobre como gerenciar redo logs online para seu banco de dados em standby físico, consulte a nota Metalink 740675.1 Online Redo Logs in a Standby.
