Jeg er i gang med at udskifte hardware til en eksisterende 3-node RAC-klynge. Dette system er også en primær til en 2-node RAC standby database. For at erstatte hardwaren er min plan midlertidigt at udvide klyngen til en 6-node konfiguration, 3 gamle servere og 3 nye servere. Når jeg har forekomsterne kørende på den nye hardware og har fået mine applikationer til at forbinde til de nye forekomster, vil jeg fjerne de gamle forekomster og trække de gamle servere tilbage, så jeg vender tilbage til en 3-node konfiguration.
Efter at have udvidet klyngen til alle seks noder, startede jeg i sidste weekend de nye forekomster op på de nye noder. For at gøre mit liv lettere, har jeg netop udnyttet DBCA til dette arbejde. Efter at have tændt for DBCA'en, valgte jeg at arbejde på en RAC-database og valgte derefter Instance Management og derefter Add New Instance. Da jeg gik gennem guiden, lod jeg DBCA tage sig af alle detaljerne for mig. Lyder enkelt.
I morges fik jeg min sædvanlige arkivforsinkelsesrapport. Det ligner følgende:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Jeg sender dette til min indbakke to gange om dagen. Et hurtigt blik hjælper mig med at afgøre, om min standby modtager og anvender transaktioner fra den primære. Jeg har indstillet alle mine standby-databaser til en forsinkelse på fire timer. Og min primære har ARCHIVE_LAG_TARGET indstillet til en time. Det betyder, at ansøgningsforsinkelsen vil være på mindst 4 timer, men ikke bør være mere end 5 timer. Som vi kan se ovenfor, har vi to standby-databaser, der i høj grad har overskredet de 5 timers maksimale forsinkelse. Ovenfor har jeg standby med en appliceringsforsinkelse på 1 dag og 21 timer! Så jeg vidste med det samme, at der var noget galt. Og det krævede ikke en raketforsker at vide, at tilføjelsen af den nye instans til den primære sandsynligvis har bidraget til problemet.
Som jeg sagde i begyndelsen af dette indlæg, har jeg et 2-node RAC standby system. Den ene instans er "anvend instansen", og den anden instans sidder der relativt inaktiv. I min underretningslog for anvend forekomster så jeg følgende fejlmeddelelser:
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)
Da jeg har min standby-database sat til STANDBY_FILE_MANAGEMENT=AUTO, giver den første del af beskederne mening. Når du tilføjer en ny instans til en RAC-database, skal du give et Fortryd Tablespace kun for den instans, og du skal også levere online-redo-loggrupper dedikeret til den instans’ tråd. DBCA stillede mig specifikt spørgsmål vedrørende fortryd og gentag filstrukturer. I advarselsloggens indhold ovenfor kan vi se, at standbyen med succes tilføjede datafil 342, som er mit Fortryd tablespace. Men standbyen var ikke i stand til at tilføje online-redo-logfilerne. Hvis du ønsker, at standbyen automatisk skal kunne tilføje online-redo-logs, skal du angive OMF-parametre, hvilket jeg er tilbageholdende med. Da tilføjelsen af online-redo-logfilen resulterede i en fejl, stoppede standby mediegendannelse. Standbyen modtager stadig logfiler.
Jeg fandt ikke meget på Metalink eller ved at lave Google-søgninger om, hvordan jeg løser dette problem, men her er de trin, jeg tog for at få Media Recovery op at køre igen. På standby-databasen (jeg gjorde dette på application-forekomsten, men det burde være levedygtigt på enhver forekomst i RAC standby-databasen):
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
Dette burde ikke være et chok, fordi vi ved, at Managed Recovery blev afbrudt. Men for fuldstændighedens skyld inkluderede jeg dette trin. Hvis du skal tilføje gentag-logfiler til en standby, der i øjeblikket anvender transaktioner, skal du bruge dette trin.
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.
Ovenstående er præcis, hvad der blev kørt på den primære. Skal tilføje gentag-loggen på standby nøjagtigt som gjort på den primære. Gentag for hver gentag-loggruppe tilføjet på den primære. Da jeg tilføjede 3 forekomster til min primære RAC-database, er jeg nødt til at tilføje tre tråde her.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Start administreret gendannelse. Alt burde være i orden nu, og vi kan bekræfte i appliceringsinstansens advarselslog:
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 også bekræfte, at ansøgningsforsinkelsen bliver kortere. I standby skal du udsende følgende:
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';
For baggrundsoplysninger om, hvordan du administrerer online-redo-logfiler for din fysiske standby-database, se Metalink note 740675.1 Online Redo-logs i en standby.