Jag håller på att byta ut hårdvara för ett befintligt RAC-kluster med 3 noder. Detta system är också en primär för en 2-nods RAC standby-databas. För att ersätta hårdvaran är min plan att tillfälligt utöka klustret till en 6-nodskonfiguration, 3 gamla servrar och 3 nya servrar. När jag har kört instanserna på den nya hårdvaran och har mina applikationer anslutna till de nya instanserna kommer jag att ta ner de gamla instanserna och ta bort de gamla servrarna och återgå till en 3-nodskonfiguration.
Efter att ha utökat klustret till alla sex noderna startade jag den gångna helgen upp de nya instanserna på de nya noderna. För att göra mitt liv enklare använde jag bara DBCA för detta arbete. Efter att ha startat upp DBCA valde jag att arbeta på en RAC-databas och valde sedan Instance Management och sedan Add New Instance. När jag gick igenom guiden lät jag DBCA ta hand om alla detaljer åt mig. Låter enkelt.
I morse fick jag min vanliga arkivfördröjningsrapport. Det ser ut som följande:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Jag skickar detta till min inkorg två gånger om dagen. En snabb blick hjälper mig att avgöra om mitt vänteläge tar emot och tillämpar transaktioner från den primära. Jag har ställt in alla mina standby-databaser på fyra timmars appliceringsfördröjning. Och min primära har ARCHIVE_LAG_TARGET inställt på en timme. Detta innebär att ansökningsfördröjningen kommer att vara minst 4 timmar men bör inte vara mer än 5 timmar. Som vi kan se ovan har vi två standby-databaser som kraftigt har överskridit 5 timmars max appliceringsfördröjning. Ovan har jag standby med en appliceringsfördröjning på 1 dag 21 timmar! Så jag visste direkt att något var fel. Och det behövdes inte en raketforskare för att veta att det troligen bidrog till problemet att lägga till den nya instansen till den primära.
Som jag sa i början av det här inlägget har jag ett RAC-standbysystem med 2 noder. En instans är "apply-instansen" och den andra instansen sitter där relativt inaktiv. I min varningslogg för tillämpningsinstanser såg jag följande felmeddelanden:
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)
Eftersom jag har min standby-databas inställd på STANDBY_FILE_MANAGEMENT=AUTO, är den första delen av meddelandena vettig. När du lägger till en ny instans till en RAC-databas måste du tillhandahålla ett Ångra tabellutrymme bara för den instansen och du måste också tillhandahålla online-redo-logggrupper dedikerade till den instansens tråd. DBCA ställde mig specifikt frågor angående ångra och gör om filstrukturer. I varningsloggens innehåll ovan kan vi se att vänteläget lyckades lägga till datafil 342, vilket är mitt Ångra tabellutrymme. Men vänteläget kunde inte lägga till online redo-loggarna. Om du vill att standby ska kunna lägga till online redo-loggarna automatiskt måste du ange OMF-parametrar, vilket jag är ovillig att göra. Eftersom tillägget av online-redo-loggfilen resulterade i ett fel, stoppade vänteläget medieåterställning. Vänteläget tar fortfarande emot loggar.
Jag hittade inte mycket på Metalink eller genom att göra Google-sökningar om hur jag löser det här problemet, men här är stegen som jag tog för att få igång Media Recovery igen. I standby-databasen (jag gjorde detta på appliceringsinstansen men det borde vara genomförbart på alla instanser i RAC-standbydatabasen):
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
Detta borde inte vara en chock eftersom vi vet att Managed Recovery avbröts. Men för fullständighetens skull inkluderade jag detta steg. Om du måste lägga till redo-loggar i ett standby-läge som för närvarande tillämpar transaktioner, behöver du det här steget.
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.
Ovanstående är exakt vad som kördes på primären. Behöver lägga till redo-loggen i vänteläge exakt som gjort på den primära. Upprepa för varje redo-logggrupp som lagts till på den primära. Eftersom jag lade till 3 instanser till min primära RAC-databas måste jag lägga till tre trådar här.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Starta hanterad återställning. Allt borde vara bra nu och vi kan verifiera i appliceringsinstansens varningslogg:
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
Vi kan också kontrollera att ansökningsfördröjningen blir kortare. I vänteläge, utfärda följande:
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';
För bakgrundsinformation om hur du hanterar omloggar online för din fysiska standby-databas, se Metalink note 740675.1 Online Redo-loggar i standby.