Cenário:
Oracle EE 11.2.0.4 Linux 6
AMBIENTE DE PRODUÇÃO COM GAP NO STADNBY DATABASE (BACKUP é FEITO NO FÍSICO
STANDBY)
Checando a consulta abaixo, foi verificado que último archive aplicado foi do
dia 06/04, mas que em compensação foram recebidos todos os archives. ( O que
aconceteceu nesse caso, é que existiu a adição de uma nova tablespace na
produção e o parâmetro standby_file_management estava como MANUAL,
consequentemente o standby nao criou a tablespace e o standby parou de aplicar,
mas continou recebendo os archives da produção, realizando os backups e
apagando os archives em disco)
LOGS TIME---------------- ------------------Last applied :
06-APR-17:01:07:31Last received : 14-APR-17:03:01:57
Thread Last Sequence Received **Last Sequence Applied**
Difference---------- ---------------------- --------------------- ----------
1 323820 **320312** 3508 2
1711 1711 0
Alguns archives estão em backup na fita e outros estão em disco, conforme
abaixo:
+FLASH/STANDBY/ARCHIVELOG2017_04_11/2017_04_12/2017_04_13/2017_04_14/ RMAN>
LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 320312; BS Key Size Device
Type Elapsed Time Completion Time------- ---------- ----------- ------------
-------------------14253 7.50G SBT_TAPE 00:23:24 06/04/2017
15:12:10 BP Key: 14253 Status: AVAILABLE Compressed: NO Tag:
TAG20170406T123644 Handle: RMAN_AL__14446_1_940603726 Media: @aaab6
List of Archived Logs in backup set 14253 Thrd Seq Low SCN Low Time
Next SCN Next Time ---- ------- ---------- -------------------
---------- --------- 1 320312 3940054443061 06/04/2017 01:07:31
3940054530795 06/04/2017 01:10:45 1 320313 3940054530795 06/04/2017
01:10:45 3940054578516 06/04/2017 01:12:21 1 320314 3940054578516
06/04/2017 01:12:21 3940054584627 06/04/2017 01:12:44 1 320315
3940054584627 06/04/2017 01:12:44 3940054590378 06/04/2017 01:13:12 1
320316 3940054590378 06/04/2017 01:13:12 3940054595869 06/04/2017 01:13:44 1
320317 3940054595869 06/04/2017 01:13:44 3940054600753 06/04/2017 01:14:10
.........
BS Key Size Device Type Elapsed Time Completion Time------- ----------
----------- ------------ -------------------14778 9.29G SBT_TAPE
00:29:59 14/04/2017 01:39:40 BP Key: 14778 Status: AVAILABLE
Compressed: NO Tag: TAG20170414T010940 Handle:
RMAN_AL_14985_1_941245781 Media: @aaab6
List of Archived Logs in backup set 14778 Thrd Seq Low SCN Low Time
Next SCN Next Time ---- ------- ---------- -------------------
---------- --------- 1 323773 3940814732761 14/04/2017 00:09:23
3940814946818 14/04/2017 00:10:45 1 323774 3940814946818 14/04/2017
00:10:45 3940815012259 14/04/2017 00:11:57 1 323775 3940815012259
14/04/2017 00:11:57 3940815090888 14/04/2017 00:13:13 1 323776
3940815090888 14/04/2017 00:13:13 3940815186248 14/04/2017 00:14:32 1
323777 3940815186248 14/04/2017 00:14:32 3940815247715 14/04/2017 00:15:44 1
323778 3940815247715 14/04/2017 00:15:44 3940815377351 14/04/2017 00:16:59
1 323779 3940815377351 14/04/2017 00:16:59 3940815446649 14/04/2017
00:18:08 1 323780 3940815446649 14/04/2017 00:18:08 3940815485204
14/04/2017 00:19:06 1 323781 3940815485204 14/04/2017 00:19:06
3940815550196 14/04/2017 00:20:03 1 323782 3940815550196 14/04/2017
00:20:03 3940815626653 14/04/2017 00:20:55 1 323783 3940815626653
14/04/2017 00:20:55 3940815670450 14/04/2017 00:21:49 1 323784
3940815670450 14/04/2017 00:21:49 3940815699775 14/04/2017 00:22:37 1
323785 3940815699775 14/04/2017 00:22:37 3940815766143 14/04/2017 00:23:32 1
323786 3940815766143 14/04/2017 00:23:32 3940815804012 14/04/2017 00:24:29
1 323787 3940815804012 14/04/2017 00:24:29 3940815853125 14/04/2017
00:25:14 1 323788 3940815853125 14/04/2017 00:25:14 3940815908048
14/04/2017 00:25:56 1 323789 3940815908048 14/04/2017 00:25:56
3940815947781 14/04/2017 00:26:39 1 323790 3940815947781 14/04/2017
00:26:39 3940815977518 14/04/2017 00:27:12 1 323791 3940815977518
14/04/2017 00:27:12 3940816005791 14/04/2017 00:27:51 1 323792
3940816005791 14/04/2017 00:27:51 3940816057310 14/04/2017 00:28:33 Percendo
a lista de archives acima, percebe-se que a sequence **320312** (que foi a
ultima aplicada pelo standby) foi gerada no dia 06/04, que foi o dia que o
standby parou de aplicar os archives.
Para resolver o GAP, eu quis fazer o restore de todos os archives a partir da
sequence 320312 para o disco,realizar o catalog, para o standby começar o
recovery, porém não seguiu como planejado: run{set archivelog destination to
'/backup/arch';CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS
'ENV=(NB_ORA_SERV=xxx, NB_ORA_CLIENT=xxx)';restore archivelog from sequence
320312 until sequence 323820;}
executing command: SET ARCHIVELOG DESTINATIONusing target database control file
instead of recovery catalog
old RMAN configuration parameters:CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS 'ENV=(NB_ORA_SERV=xxx, NB_ORA_CLIENT=xxx)';new RMAN configuration
parameters:CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS
'ENV=(NB_ORA_SERV=xxx, NB_ORA_CLIENT=xxx)';new RMAN configuration parameters
are successfully stored
Starting restore at 14/04/2017 03:55:16allocated channel: ORA_DISK_1channel
ORA_DISK_1: SID=3 device type=DISKallocated channel: ORA_SBT_TAPE_1channel
ORA_SBT_TAPE_1: SID=318 device type=SBT_TAPEchannel ORA_SBT_TAPE_1: Veritas
NetBackup for Oracle - Release 7.6 (2014070701)
archived log for thread 1 with sequence 320312 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320312.1307.941213433archived log
for thread 1 with sequence 320313 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320313.2090.941213433archived log
for thread 1 with sequence 320314 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320314.2732.941213433archived log
for thread 1 with sequence 320315 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320315.2890.941214229archived log
for thread 1 with sequence 320316 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320316.3357.941214231archived log
for thread 1 with sequence 320317 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320317.3709.941213449archived log
for thread 1 with sequence 320318 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320318.4592.941214591archived log
for thread 1 with sequence 320319 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320319.4593.941214591archived log
for thread 1 with sequence 320320 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320320.3989.941214249archived log
for thread 1 with sequence 320321 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320321.4595.941214605archived log
for thread 1 with sequence 320322 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320322.4596.941214605archived log
for thread 1 with sequence 320323 is already on disk as file
+FLASH/xxx/archivelog/2017_04_13/thread_1_seq_320323.2779.941214257....archived
log for thread 1 with sequence 323820 is already on disk as file
+FLASH/xxx/archivelog/2017_04_14/thread_1_seq_323820.3718.941252435RMAN-00571:
===========================================================RMAN-00569:
=============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571:
===========================================================RMAN-03002: failure
of restore command at 04/14/2017 04:14:27
Até o momento não consegui resolver essa questão, estou pensando em fazer um
incremental from scn no primary, mas gostaria de entender o motivo de não ter
conseguido restaurar os meus archives que estão no backup.
a) Porque não consegui gerar os archives a partir da sequence 320312? A
mensagem acima do RMAN, me diz que já existe no disco para o dia 2017_04_13,
porém no "LIST BACKUP OF ARCHIVELOG..." nós vimos que a sequence é do dia
06/04, e não da mensagem acima do RMAN.
b) Como devo proceder para restaurar esses archives no disco para catalogar e o
database começar a realizar a recuperação?
