Ik ben bezig met het vervangen van hardware voor een bestaande RAC-cluster met 3 knooppunten. Dit systeem is ook een primaire naar een 2-node RAC-standbydatabase. Om de hardware te vervangen, is mijn plan om het cluster tijdelijk uit te breiden naar een configuratie met 6 knooppunten, 3 oude servers en 3 nieuwe servers. Zodra de instances op de nieuwe hardware draaien en mijn applicaties verbinding maken met de nieuwe instances, zal ik de oude instances verwijderen en de oude servers buiten gebruik stellen, om terug te keren naar een configuratie met 3 knooppunten.
Nadat ik het cluster had uitgebreid naar alle zes knooppunten, heb ik afgelopen weekend de nieuwe instanties op de nieuwe knooppunten opgestart. Om mijn leven gemakkelijker te maken, heb ik zojuist de DBCA voor dit werk gebruikt. Nadat ik de DBCA had opgestart, koos ik ervoor om aan een RAC-database te werken en koos vervolgens voor Instance Management en vervolgens voor Add New Instance. Terwijl ik door de wizard loop, laat ik de DBCA alle details voor mij regelen. Klinkt eenvoudig.
Vanmorgen kreeg ik mijn gebruikelijke archiefvertragingsrapport. Het ziet er ongeveer als volgt uit:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- ----------- --------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Ik stuur dit twee keer per dag naar mijn inbox. Een snelle blik helpt me te bepalen of mijn stand-by transacties van de primaire ontvangt en toepast. Ik heb al mijn reservedatabases ingesteld op een toepassingsvertraging van vier uur. En mijn primaire heeft ARCHIVE_LAG_TARGET ingesteld op één uur. Dit betekent dat de aanvraagvertraging minimaal 4 uur maar niet meer dan 5 uur mag zijn. Zoals we hierboven kunnen zien, hebben we twee standby-databases die de maximale toepassingsvertraging van 5 uur ruimschoots hebben overschreden. Hierboven heb ik de stand-by met een toepassingsvertraging van 1 dag 21 uur! Dus ik wist meteen dat er iets niet klopte. En er was geen raketgeleerde voor nodig om te weten dat het toevoegen van de nieuwe instantie aan de primaire waarschijnlijk tot het probleem heeft bijgedragen.
Zoals ik aan het begin van dit bericht al zei, heb ik een RAC-standbysysteem met 2 knooppunten. Eén instantie is de "apply-instantie" en de andere instantie zit daar relatief inactief. In het waarschuwingslogboek van mijn toepassingsinstantie zag ik de volgende foutmeldingen:
Zat 01 Dec 14:25:40 2012
Herstel gemaakt bestand /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Succesvol databestand 342 toegevoegd aan mediaherstel
Gegevensbestand #342:'/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
Geen OMF-bestemming opgegeven, kan geen logs maken
Fouten met log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0:Achtergrond Media Recovery beëindigd met fout 1264
Fouten in bestand /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264:Kan logbestand bestandsnaam niet aanmaken
Herstel onderbroken!
Zat 01 Dec 14:25:51 2012
Herstelde gegevensbestanden in een consistente staat bij wijziging 192271576009
Zat 01 Dec 14:25:51 2012
MRP0:Achtergrond Media Recovery-proces afgesloten (orcs2)
Aangezien ik mijn reservedatabase heb ingesteld op STANDBY_FILE_MANAGEMENT=AUTO, is het eerste deel van de berichten logisch. Wanneer u een nieuwe instantie aan een RAC-database toevoegt, moet u alleen voor die instantie een Undo-tabelruimte opgeven en moet u ook online loggroepen voor opnieuw uitvoeren opgeven die zijn toegewezen aan de thread van die instantie. De DBCA heeft mij specifiek vragen gesteld over de bestandsstructuren voor ongedaan maken en opnieuw uitvoeren. In de inhoud van het waarschuwingslogboek hierboven kunnen we zien dat het standby-gegevensbestand 342 met succes is toegevoegd, wat mijn Undo-tabelruimte is. Maar de stand-by kon de online redo-logboeken niet toevoegen. Als je wilt dat de stand-by automatisch de online redo-logs kan toevoegen, moet je OMF-parameters opgeven, wat ik niet graag doe. Omdat de toevoeging van het online logbestand opnieuw tot een fout leidde, stopte de standby-mediaherstel. De standby ontvangt nog steeds logs.
Ik heb niet veel gevonden op Metalink of door Google-zoekopdrachten uit te voeren om dit probleem op te lossen, maar hier zijn de stappen die ik heb genomen om Media Recovery weer aan de gang te krijgen. Op de standby-database (ik deed dit op de toepassingsinstantie, maar het zou haalbaar moeten zijn op elke instantie in de RAC-reservedatabase):
1. database wijzigen herstel beheerde standby-database annuleren;
database wijzigen beheerde standby-database herstellen annuleren
*
FOUT op regel 1:
ORA-16136:Beheerd stand-by herstel niet actief
Dit zou geen schok moeten zijn, omdat we weten dat Managed Recovery is afgebroken. Maar voor de volledigheid heb ik deze stap opgenomen. Als u opnieuw logboeken moet toevoegen aan een stand-by die momenteel transacties toepast, heeft u deze stap nodig.
2. verander systeem set standby_file_management='MANUAL' scope=memory;
Systeem gewijzigd.
3. database wijzigen logbestand thread 4 toevoegen groep 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database gewijzigd.
Het bovenstaande is precies wat er op de primaire werd uitgevoerd. Noodzaak om het opnieuw logboek toe te voegen aan de stand-by, precies zoals gedaan op de primaire. Herhaal dit voor elke herhalingslogboekgroep die is toegevoegd aan de primaire. Aangezien ik 3 instanties aan mijn primaire RAC-database heb toegevoegd, moet ik hier drie threads toevoegen.
Systeem gewijzigd.
Database gewijzigd.
Beheerd herstel starten. Alles zou nu goed moeten zijn en we kunnen controleren in het waarschuwingslogboek van de toepassingsinstantie:
database wijzigen beheerde stand-by database herstellen loskoppelen van sessie
Poging om op de achtergrond beheerd stand-by-herstelproces (orcs2) te starten
Ma 03 dec 13:32:38 2012
MRP0 begon met pid=47, OS id=13232
MRP0:Achtergrond beheerd stand-by herstelproces gestart (orcs2)
begonnen logmerger proces
Ma 03 dec 13:32:44 2012
Managed Standby Recovery zonder Realtime Toepassen
Ma 03 dec 13:32:49 2012
Parallel mediaherstel begon met 4 slaves
Wachten tot alle niet-huidige ORL's zijn gearchiveerd...
Alle niet-huidige ORL's zijn gearchiveerd.
Ma 03 dec 13:32:49 2012
Voltooid:database wijzigen herstellen beheerde stand-by database loskoppelen van sessie
Ma 03 dec 13:32:50 2012
Logboek voor mediaherstel /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Logboek voor mediaherstel /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Logboek voor mediaherstel /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Logboek voor mediaherstel /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
We kunnen ook controleren of de aanvraagvertraging korter wordt. Voer in de stand-by het volgende uit:
selecteer i.instance_name,d.value als apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') als curr_time
van v$instance i,v$dataguard_stats d
waar d.name='apply lag';
Voor achtergrondinformatie over het beheren van online redo-logs voor uw fysieke standby-database, zie Metalink-opmerking 740675.1 Online Redo-logs in een stand-by.