ORACLE e MAA – Parte III – Reinstate
Após fazer o failover no artigo anterior você precisa recuperar o seu ambiente, presiamos fazer o reinstate do antigo primary. De forma resumida o resintate é recuperar o banco para que assuma a nova função.
No mundo real as falhas que podem deixar seu ambiente primary fora e forçar o failover para o standby são diversas. Muitas vezes perde-se o ambiente por completo e precisamos recriar o primary, quando acontece isso a solução é recriar o ambiente e adicionar o banco ao DG. Aqui, o antigo primary teve a sua falha corrigida e ele foi religado. Se no caso você perdeu completamente o antigo primary não há o que fazer, você precisará recriar ele através de um backup do novo primary.
TERCEIRO ARTIGO
Neste artigo irei demonstrar como fazer o reinstate manual do antigo primary. Além disso, também demonstrarei como adicionar este banco como standby ao ambiente para que possamos a ter um ambiente MAA. Como este artigo é uma sequência dos anteriores eu recomendo a leitura dos anteriores para ficar familiarizado, não é obrigatório mas pode ajudar.
AMBIENTE
Neste artigo temos um banco primary rodando em Oracle RAC que sofreu uma falha e sofreu failover para seu standby que também roda em Oracle RAC. Com isso o antigo standby foi elevado a função de primary, e esta troca de papeis ocorreu sem qualquer perda de dados.
Aqui, o antigo primary foi recuperado e está novamente operacional. Como estamos em um ambiente Oracle RAC automaticamente ao servidor ligar o CRS irá iniciar o banco, recomendo que todas as suas instâncias paradas.
Lembra-se que até o momento não temos o Broker habilitado no ambiente. Tudo o que fizemos até agora foi manual, configuração, failover e agora o reinstate.
REINSTATE
O reinstate é um procedimento simples, mas para isso você tem que ter seguido alguns passos. No primeiro artigo fui categórico ao afirmar que habilitar o flashback do banco de dados traria benefícios, e é aqui que veremos isso. Se você tiver o flashback habilitado com um simples comando você deixa tudo pronto, caso contrário se prepare e tenha backup do banco de dados – você precisaria.
SCN
A primeira coisa a fazer é identificar qual foi SCN em que o standby se tornou primary, o comando abaixo mostra como fazer isso:
SQL> SELECT instance_name FROM v$instance;
INSTANCE_NAME
----------------
maastb1
SQL> SELECT standby_became_primary_scn FROM v$database;
STANDBY_BECAME_PRIMARY_SCN
--------------------------
2596056
SQL>Se você notar e comparar com o artigo anterior verá que o SCN foi o mesmo que apareceu no alertlog do standby quando ele se tornou primary. Este SCN é fundamental para fazer o resintate do antigo primary, com ele fazemos o flashback do banco. Volto ao ponto da importância do flashback, com um único comando você volta o banco sem precisar de qualquer restore de backup.
Antigo Primary
Depois de verificar o scn nós precisamos iniciar um instância do antigo primary. Não se preocupe se quando você ligou o servidor o seu antigo primary entrou em modo open. Desta forma, iniciamos uma única instância em modo mount:
SQL> STARTUP MOUNT;
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2235208 bytes
Variable Size 511706296 bytes
Database Buffers 549453824 bytes
Redo Buffers 5541888 bytes
Database mounted.
SQL> SELECT instance_name FROM v$instance;
INSTANCE_NAME
----------------
maa1
SQL>Um detalhe interessante, se você fizer um select para saber a role do banco ele ainda acredita que é um banco primary. Observe:
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
PRIMARY
SQL>Flashback
Até o momento nós temos o scn que o houve a troca de papeis, um banco standby que se tornou primary. Além disso, temos o antigo primary que foi aberto em modo mount em uma única instância, confuso?
Agora, com o SCN que foi resgatado acima podemos fazer o flashback do antigo primary para ele. Com um simples comando iremos deixar o antigo primary pronto para se tornar o novo standby. Observe:
SQL> FLASHBACK DATABASE TO SCN 2596056;
Flashback complete.
SQL>Convert to Standby
Como você viu acima este banco ainda acredita que é o banco primary, nós precisamos alterar isso. O procedimento é simples e deixa o banco pronto para se tornar o standby, observe:
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
Database altered.
SQL>
No alert da antiga primary:
Flashback Media Recovery Complete
Completed: FLASHBACK DATABASE TO SCN 2596056
Sun Apr 13 11:12:38 2014
ALTER DATABASE CONVERT TO PHYSICAL STANDBY
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (maa1)
Flush standby redo logfile failed:1649
Clearing standby activation ID 722049028 (0x2b099804)
The primary database controlfile was created using the
'MAXLOGFILES 192' clause.
There is space for up to 188 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 52428800;
Shutting down archive processes
Archiving is disabled
Completed: ALTER DATABASE CONVERT TO PHYSICAL STANDBY
Sun Apr 13 11:12:44 2014
SUCCESS: diskgroup FRA was dismounted
SUCCESS: diskgroup DATA was dismounted
NOTE: Database dismounted; ASMB process exiting
Stopping background process RBAL
Stopping background process MARK
Sun Apr 13 11:12:46 2014
NOTE: Shutting down MARK background processDeixei em negrito no alertlog acima, mas se você notar no irá ver que o banco agora passou a ser o standby. Depois, você eu recomendo fazer um shutdown e um startup mount do novo standby:
SQL> SHUTDOWN IMMEDIATE;
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2235208 bytes
Variable Size 511706296 bytes
Database Buffers 549453824 bytes
Redo Buffers 5541888 bytes
Database mounted.
SQL>Observe no resultado do comando acima que a informação de que o banco não estava montado (mas iniciamos o processo com o banco em estado mount!?). Não se preocupe, o processo de conversão para standby fez isso.
Standby redo log files
Agora temos um banco primary e um banco standby pronto para receber o dados/archives do primary. Antes disso vamos dar uma olhada nos standby redo logs:
SQL> COL member FORMAT a50
SQL> SELECT group#, type, member FROM v$logfile;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------
1 ONLINE +DATA/maa/onlinelog/group_1.272.843488553
1 ONLINE +FRA/maa/onlinelog/group_1.286.843488555
2 ONLINE +DATA/maa/onlinelog/group_2.271.843488555
2 ONLINE +FRA/maa/onlinelog/group_2.285.843488555
3 ONLINE +DATA/maa/onlinelog/group_3.257.843489101
3 ONLINE +FRA/maa/onlinelog/group_3.284.843489101
4 ONLINE +DATA/maa/onlinelog/group_4.262.843489103
4 ONLINE +FRA/maa/onlinelog/group_4.283.843489103
5 STANDBY +DATA/maa/onlinelog/group_5.263.843615365
5 STANDBY +FRA/maa/onlinelog/group_5.289.843615367
6 STANDBY +DATA/maa/onlinelog/group_6.261.843615373
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------
6 STANDBY +FRA/maa/onlinelog/group_6.670.843615373
7 STANDBY +DATA/maa/onlinelog/group_7.260.843615379
7 STANDBY +FRA/maa/onlinelog/group_7.263.843615379
8 STANDBY +DATA/maa/onlinelog/group_8.259.843615383
8 STANDBY +FRA/maa/onlinelog/group_8.703.843615385
9 STANDBY +DATA/maa/onlinelog/group_9.256.843615389
9 STANDBY +FRA/maa/onlinelog/group_9.504.843615389
10 STANDBY +DATA/maa/onlinelog/group_10.274.843615393
10 STANDBY +FRA/maa/onlinelog/group_10.496.843615393
20 rows selected.
SQL>Você deve estar se perguntando o porquê disso, mas explico. Quando fizemos o convert acima para physical standby apareceu no alerlog informação referentes a adição de standby logfiles. Como destaquei no primeiro artigo, eles são importantes e não custa nada averiguar algumas informações antes de prosseguir. Aqui, tudo permaneceu correto, aço o seu fique/esteja errado após o reinstate, basta remover e adicionar novos.
log_archive_dest_state_XX
No artigo anterior você viu que que deixamos desligado o envio de redo do primary para o standby. Fizemos isso até que o novo standby estivesse disponível, como agora ele está nós podemos ir na primary e religar o envio.
SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'ENABLE' SCOPE = BOTH SID = '*';
System altered.
SQL>
No alert da standby:
[oracle@rac11pri01 ~]$ tail -f /u01/app/oracle/diag/rdbms/maa/maa1/trace/alert_maa1.log
ARC2: Becoming the active heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Completed: ALTER DATABASE MOUNT
Sun Apr 13 11:32:40 2014
db_recovery_file_dest_size of 10240 MB is 11.88% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Sun Apr 13 11:40:14 2014
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Sun Apr 13 11:40:16 2014
RFS[1]: Assigned to RFS process 9651
RFS[1]: Opened log for thread 1 sequence 77 dbid 722024964 branch 843466948
Archived Log entry 192 added for thread 1 sequence 77 rlc 843466948 ID 0x2b099804 dest 2:
Sun Apr 13 11:40:19 2014
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Standby controlfile consistent with primary
RFS[2]: Assigned to RFS process 9655
RFS[2]: Selected log 5 for thread 1 sequence 6 dbid 722024964 branch 844762805
Sun Apr 13 11:40:22 2014
RFS[3]: Assigned to RFS process 9666
RFS[3]: Opened log for thread 1 sequence 2 dbid 722024964 branch 844762805
Sun Apr 13 11:40:22 2014
RFS[4]: Assigned to RFS process 9664
RFS[4]: Opened log for thread 1 sequence 1 dbid 722024964 branch 844762805
RFS[3]: New Archival REDO Branch(resetlogs_id): 844762805 Prior: 843466948
RFS[3]: Archival Activation ID: 0x2b1c0c3f Current: 0x0
RFS[3]: Effect of primary database OPEN RESETLOGS
RFS[3]: Incarnation entry added for Branch(resetlogs_id): 844762805 (maa1)
Sun Apr 13 11:40:23 2014
Setting recovery target incarnation to 2
...
...
...
Changing standby controlfile to MAXIMUM AVAILABILITY level
RFS[2]: Selected log 5 for thread 1 sequence 9 dbid 722024964 branch 844762805
Archived Log entry 208 added for thread 1 sequence 8 ID 0x2b1c0c3f dest 1:
Sun Apr 13 12:24:26 2014
Standby controlfile consistent with primary
RFS[1]: Selected log 9 for thread 2 sequence 9 dbid 722024964 branch 844762805
Sun Apr 13 12:24:26 2014
Archived Log entry 209 added for thread 2 sequence 8 ID 0x2b1c0c3f dest 1:Vamos analisar com calma o alertlog acima. Se você notar, no mesmo momento em que executamos comando na primary, o alertlog da standby já detectou que o recebimento destes arquivos já que a base precisava de RESYNCRONIZATION.
Se estivéssemos olhando o alertlog da primary iríamos ver as informações de início de envio de archivelogs para a standby. Observe no alertlog acima que os archives estão sendo recebido e que a primary se “tornou primary” devido a um OPEN RESETLOGS. Os redo começam a ser enviados para o standby e os bancos ficam em MAXIMUM AVAILABILITY, observe o resultado do select na primary:
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
PRIMARY
SQL>
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
SQL>Database Recover
Isso não quer dizer que tudo está correto, os archives do primary foram recebidos pelo standby mas ainda não foram aplicados. Além do mais, você ainda precisa religar o real-time apply para que o redo do primary seja aplicado diretamente pelo standby. Corrigimos tudo isso com o comando abaixo na standby:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
Database altered.
SQL>
No alert da standby:
Sun Apr 13 12:31:35 2014
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Attempt to start background Managed Standby Recovery process (maa1)
Sun Apr 13 12:31:35 2014
MRP0 started with pid=48, OS id=11062
MRP0: Background Managed Standby Recovery process started (maa1)
started logmerger process
Sun Apr 13 12:31:41 2014
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Sun Apr 13 12:31:41 2014
Media Recovery start incarnation depth : 1, target inc# : 2, irscn : 2596059
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Clearing online redo logfile 1 +DATA/maa/onlinelog/group_1.272.843488553
Clearing online log 1 of thread 1 sequence number 9
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 +DATA/maa/onlinelog/group_2.271.843488555
Clearing online log 2 of thread 1 sequence number 9
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 +DATA/maa/onlinelog/group_3.257.843489101
Clearing online log 3 of thread 2 sequence number 53
Clearing online redo logfile 3 complete
Clearing online redo logfile 4 +DATA/maa/onlinelog/group_4.262.843489103
Clearing online log 4 of thread 2 sequence number 54
Sun Apr 13 12:31:46 2014
Clearing online redo logfile 4 complete
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_54.585.844799057
Identified End-Of-Redo (failover) for thread 2 sequence 54 at SCN 0x0.279cdb
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_77.557.844796415
Identified End-Of-Redo (failover) for thread 1 sequence 77 at SCN 0x0.279cdb
Resetting standby activation ID 722049028 (0x2b099804)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_1.573.844799061
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_1.582.844796423
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_2.560.844796423
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_3.568.844796425
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_2.564.844799061
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_3.578.844799061
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_4.491.844796425
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_4.581.844799061
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_5.580.844796425
Sun Apr 13 12:31:52 2014
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_6.587.844799057
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_5.598.844799061
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_6.596.844799061
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_7.579.844799057
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_7.591.844799057
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_8.595.844799067
Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_8.593.844799065
Media Recovery Waiting for thread 1 sequence 9 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 9 Reading mem 0
Mem# 0: +DATA/maa/onlinelog/group_5.263.843615365
Mem# 1: +FRA/maa/onlinelog/group_5.289.843615367
Media Recovery Waiting for thread 2 sequence 9 (in transit)
Recovery of Online Redo Log: Thread 2 Group 9 Seq 9 Reading mem 0
Mem# 0: +DATA/maa/onlinelog/group_9.256.843615389
Mem# 1: +FRA/maa/onlinelog/group_9.504.843615389No alertlog da standby temos algumas informações importantes. Primeiro o banco iniciou o recover (RECOVER) para ser standby (MANAGED STANDBY DATABASE) e com real-time apply (USING CURRENT LOGFILE). No alertlog vimos que ele detectou o “End-Of-Redo” nas duas threads de redo e aplicou os archives recebidos previamente. Observe que os redologs fora reiniciados (ele é standby e não necessita deles agora).
CRS
Para finalizar, ajuste o CRS do novo standby, assim ele ficará correto irá iniciar tudo corretamente (inicie as outras instâncias do standby se desejar).
[oracle@rac11pri01 ~]$ srvctl config database -d maa -v
Database unique name: maa
Database name: maa
Oracle home: /u01/app/oracle/product/11.2.0.3/db_1
Oracle user: oracle
Spfile: +DATA/maa/spfilemaa.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: maa
Database instances: maa1,maa2
Disk Groups: DATA,FRA
Mount point paths:
Services:
Type: RAC
Database is administrator managed
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$ srvctl modify database -d maa -s MOUNT -r PHYSICAL_STANDBY
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$ srvctl config database -d maa -v
Database unique name: maa
Database name: maa
Oracle home: /u01/app/oracle/product/11.2.0.3/db_1
Oracle user: oracle
Spfile: +DATA/maa/spfilemaa.ora
Domain:
Start options: mount
Stop options: immediate
Database role: PHYSICAL_STANDBY
Management policy: AUTOMATIC
Server pools: maa
Database instances: maa1,maa2
Disk Groups: DATA,FRA
Mount point paths:
Services:
Type: RAC
Database is administrator managed
[oracle@rac11pri01 ~]$Acima modificamos a antiga primary no crs e deixamos ela como standby e que somente inicie ela em modo mount.
AMBIENTE FINAL
Chegamos ao final com um ambiente onde o antigo primary sofreu o failover para o standby e aqui vimos como fazer o reinstate manual do antigo primary. Além disso, fizemos com que o antigo primary passase a agir como o novo standby. Observe abaixo:
Na primary:
SQL> SELECT protection_mode, protection_level, database_role FROM v$database;
PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE
-------------------- -------------------- ----------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PRIMARY
SQL>
Na standby:
SQL> SELECT protection_mode, protection_level, database_role FROM v$database;
PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE
-------------------- -------------------- ----------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PHYSICAL STANDBY
SQL>Pronto, agora você fez um reinstate do antigo primary e tornou ele o banco standby. Acredito que você percebeu como fica mais fácil quando trabalhamos com FLASHBACK, não precisamos voltar nenhum backup e tudo foi mais rápido. Claro que isso só pode ocorrer pois o seu antigo primary voltou sem perder dados. Caso você tivesse perdido completamente ele precisaria utilizar um backup para criar o standby, basicamente os mesmos passos do clone que fizemos no primeiro artigo. No próximo artigo vamos ver como fazer o swicthover manual dos bancos.
Este artigo também foi publicado em meu blog pessoal.
