Sto sostituendo l'hardware per un cluster RAC a 3 nodi esistente. Questo sistema è anche un database di standby RAC principale a 2 nodi. Per sostituire l'hardware, il mio piano è di estendere temporaneamente il cluster in una configurazione a 6 nodi, 3 vecchi server e 3 nuovi server. Dopo aver eseguito le istanze sul nuovo hardware e aver connesso le mie applicazioni alle nuove istanze, rimuoverò le vecchie istanze e ritirerò i vecchi server, tornando a una configurazione a 3 nodi.
Dopo aver esteso il cluster a tutti e sei i nodi, lo scorso fine settimana ho avviato le nuove istanze sui nuovi nodi. Per semplificarmi la vita, ho semplicemente sfruttato il DBCA per questo lavoro. Dopo aver attivato il DBCA, ho scelto di lavorare su un database RAC, quindi ho scelto Gestione istanza e quindi Aggiungi nuova istanza. Passando attraverso la procedura guidata lascio che il DBCA si occupi di tutti i dettagli per me. Sembra semplice.
Questa mattina, ho ricevuto il mio solito rapporto sul ritardo dell'archivio. È simile al seguente:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- ----------- --------
orcs1 +01 21:40:47 03-12-2012 08:00:01
Lo mando alla mia Posta in arrivo due volte al giorno. Una rapida occhiata mi aiuta a determinare se il mio standby sta ricevendo e applicando transazioni dal principale. Ho impostato tutti i miei database di standby su un ritardo di applicazione di quattro ore. E il mio primario ha ARCHIVE_LAG_TARGET impostato su un'ora. Ciò significa che il ritardo di applicazione sarà di almeno 4 ore ma non dovrebbe essere superiore a 5 ore. Come possiamo vedere sopra, abbiamo due database in standby che hanno ampiamente superato il ritardo di applicazione massimo di 5 ore. Sopra, ho lo standby con un ritardo di applicazione di 1 giorno e 21 ore! Quindi ho subito capito che qualcosa non andava. E non ci voleva uno scienziato missilistico per sapere che l'aggiunta della nuova istanza alla primaria probabilmente ha contribuito al problema.
Come ho detto all'inizio di questo post, ho un sistema di standby RAC a 2 nodi. Un'istanza è "applica istanza" e l'altra istanza è relativamente inattiva. Nel registro degli avvisi dell'istanza di applicazione ho visualizzato i seguenti messaggi di errore:
Sab 01 dicembre 14:25:40 2012
Recupero del file creato /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
File di dati 342 aggiunto con successo al ripristino del supporto
File dati n. 342:'/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
Nessuna destinazione OMF specificata, impossibile creare log
Errori con il log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0:Ripristino supporto in background terminato con errore 1264
Errori nel file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264:impossibile creare il nome del file di registro
Recupero interrotto!
Sab 01 dicembre 14:25:51 2012
File di dati ripristinati in uno stato coerente alla modifica 192271576009
Sab 01 dicembre 14:25:51 2012
MRP0:Arresto del processo di ripristino del supporto in background (orcs2)
Dato che il mio database di standby è impostato su STANDBY_FILE_MANAGEMENT=AUTO, la prima parte dei messaggi ha un senso. Quando aggiungi una nuova istanza a un database RAC, devi fornire uno spazio tabella Annulla solo per quell'istanza e devi anche fornire gruppi di log di ripristino online dedicati al thread di quell'istanza. Il DBCA mi ha posto in particolare domande relative alle strutture dei file di annullamento e ripristino. Nel contenuto del registro degli avvisi sopra, possiamo vedere che lo standby ha aggiunto correttamente il file di dati 342, che è il mio spazio tabella Annulla. Ma lo standby non è stato in grado di aggiungere i registri di ripristino online. Se si desidera che lo standby sia in grado di aggiungere automaticamente i registri di ripristino online, è necessario specificare i parametri OMF, cosa che sono riluttante a fare. Poiché l'aggiunta del file di registro di ripristino in linea ha provocato un errore, lo standby ha interrotto il ripristino del supporto. Lo standby sta ancora ricevendo i log.
Non ho trovato molto su Metalink o facendo ricerche su Google su come risolvere questo problema, ma ecco i passaggi che ho seguito per ripristinare l'operatività di Media Recovery. Sul database di standby (l'ho fatto sull'istanza apply ma dovrebbe essere fattibile su qualsiasi istanza nel database di standby RAC):
alterazione database ripristino database standby gestito annullamento
*
ERRORE alla riga 1:
ORA-16136:Managed Standby Recovery non attivo
Questo non dovrebbe essere uno shock perché sappiamo che il ripristino gestito è stato interrotto. Ma per completezza, ho incluso questo passaggio. Se devi aggiungere registri di ripristino a uno standby che sta attualmente applicando transazioni, avrai bisogno di questo passaggio.
Sistema alterato.
3. altera il database aggiungi logfile thread 4 gruppo 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Banca dati modificata.
Quanto sopra è esattamente ciò che è stato eseguito sul primario. È necessario aggiungere il registro di ripristino in standby esattamente come fatto sul primario. Ripetere per ogni gruppo di log di ripristino aggiunto al database primario. Poiché ho aggiunto 3 istanze al mio database RAC principale, devo aggiungere tre thread qui.
Sistema alterato.
Banca dati modificata.
Avvia il ripristino gestito. Tutto dovrebbe andare bene ora e possiamo verificare nel registro degli avvisi dell'istanza di applicazione:
alter database recovery database in standby gestito disconnessione dalla sessione
Tentativo di avviare il processo di ripristino in background gestito in standby (orcs2)
lun 03 dic 13:32:38 2012
MRP0 è iniziato con pid=47, OS id=13232
MRP0:processo di ripristino in background gestito in standby avviato (orcs2)
ha avviato il processo di logmerger
lun 03 dic 13:32:44 2012
Recupero in standby gestito che non utilizza l'applicazione in tempo reale
lun 03 dic 13:32:49 2012
Parallel Media Recovery è iniziato con 4 slave
In attesa dell'archiviazione di tutti gli ORL non correnti...
Tutti gli ORL non correnti sono stati archiviati.
lun 03 dic 13:32:49 2012
Completato:alter database recovery database in standby gestito disconnessione dalla sessione
lun 03 dic 13:32:50 2012
Registro recupero supporti /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Registro recupero supporti /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Registro recupero supporti /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Registro recupero supporti /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Possiamo anche verificare che il ritardo dell'applicazione si stia accorciando. In standby, emetti quanto segue:
seleziona i.instance_name,d.value come apply_lag,
to_char(sysdate,'AAAA-MM-GG HH24:MI:SS') come curr_time
da v$instance i,v$dataguard_stats d
dove d.name='apply lag';
Per informazioni di base su come gestire i registri di ripristino online per il database di standby fisico, vedere la nota di Metalink 740675.1 Registri di ripristino online in standby.
