Na een recente stroomstoring op onze DR-site, ontdekte ik dat een stand-by daar gestopt was met het toepassen van logs. Blijkbaar was in de gearchiveerde redo-logs een transactie die een databestand groeide, maar de schijf op de standby-site had niet genoeg schijfruimte om die transactie te voltooien. Dus de standby beëindigde het beheerde herstel, zoals het hoort.
Normaal gesproken bewaren we de gearchiveerde logs voor opnieuw uitvoeren 7 dagen. Helaas waren er tegen de tijd dat ik deze situatie ontdekte 15 dagen verstreken en waren de gearchiveerde redo-logboeken "ontbrekend". Omdat er geen gearchiveerde herhalingslogboeken waren om toe te passen, was de enige oplossing om de database helemaal opnieuw op te bouwen. Deze database is ongeveer 7 TB groot, dus helemaal opnieuw opbouwen is geen sinecure.
De primaire is een RAC 11.2.0.2-database met 3 knooppunten die op Linux draait. De stand-by is een RAC-database met twee knooppunten, uiteraard dezelfde Oracle- en OS-versies.
Hier is hoe we de stand-by hebben herbouwd:
- We hebben de primaire in de hot-back-upmodus gezet en een schijfgebaseerde momentopname van de database gemaakt.
- De momentopname is gekopieerd naar externe media. Opmerking:verzending via het WAN kostte te veel tijd.
- De externe media werden met de hand naar de DR-site gebracht.
- De LOG_ARCHIVE_DEST_STATE_n voor de stand-by is ingesteld op DEFER.
- De standby-database is verwijderd uit de configuratie van DG Broker: REMOVE DATABASE standby PRESERVE DESTINATIONS;
- De aankoppelpunten van de standby-database zijn gewist. De database was op dat moment immers in wezen nutteloos.
- Er zijn nieuwe koppelpunten gemaakt en de momentopname is naar de schijf op de DR-site geschreven.
- Nadat de bestandsoverdrachten waren voltooid (ongeveer 5 dagen), hebben we onze opslag verteld om de momentopname op de DR-site bij te werken met een meer actuele momentopname. Dit werd uitgevoerd via het WAN omdat alleen de wijzigingen werden verzonden, wat veel, veel kleiner was dan de database.
- Er is een stand-by-controlebestand gemaakt: ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/dir/path';
- Om het simpel te houden, wilden we een stand-by voor één instantie gebruiken totdat we deze in gebruik hadden genomen. We hebben dus een PFILE gemaakt van de RAC SPFILE van de stand-by en vervolgens een teksteditor gebruikt om het parameterbestand te wijzigen om alle RAC-bewuste parameters te verwijderen. We hebben CLUSTER_DATABASE verwijderd, een instantiespecifieke UNDO_TABLESPACE-parameter ingesteld die moet worden gebruikt voor alle instanties "*.", THREAD-parameters verwijderd, enz. Onze normale standby-database heeft twee instanties, STANDBY1 en STANDBY2. In knooppunt 1 hebben we het pfile in $ORACLE_HOME/dbs/initstandby.ora geplaatst in plaats van initstandby1.ora, zodat de database met één instantie zijn parameterbestand zou kunnen vinden. We hebben iets soortgelijks gedaan voor het wachtwoordbestand.
- We hebben het stand-by controlebestand van stap 9 gekopieerd over de controlebestanden in de database-snapshot.
- Met het pfile- en pswd-bestand voor een enkele instantiedatabase hebben we STARTUP MOUNT uitgevoerd.
- We hebben alle standby-logboeken voor opnieuw uitvoeren gemaakt die we nodig zouden hebben. In ons geval heeft de primaire ook stand-by redo-logs om overschakelingsbewerkingen te vergemakkelijken en de stand-by redo-logs van de primaire maakten geen deel uit van de momentopname. Dus moesten we de SRL's verwijderen die de reis niet hebben gemaakt.
- Stel in de primaire LOG_ARCHIVE_DEST_STATE_n in op ENABLE.
- In de primaire gevallen, ALTER SYSTEM SWITCH LOGFILE uitgevoerd;
- Geverifieerd in zowel de primaire als de standby-waarschuwingslogboeken dat de standby-logboeken werden ontvangen, d.w.z. geverifieerd dat het transport van logs werkte.
- Ingeschakeld op beheerde stand-by:ALTER DATABASE HERSTEL BEHEERDE STANDBY DATABASE ONTKOPPEL VAN SESSIE;
- Geverifieerd in het waarschuwingslogboek van de stand-by dat de logboeken werden toegepast, d.w.z. geverifieerd toepassen werkte nu.
Op dit moment hadden we een standby-database die weer actief was. We hebben een eenvoudige tabel in de primaire tabel gemaakt en er één rij gegevens in ingevoegd, de logwisselingen opnieuw uitgevoerd en vervolgens de stand-by geopend in de modus ALLEEN LEZEN om te controleren of de transactie in de stand-by is afgespeeld zoals het hoort. Zodra we er zeker van waren dat de standby-database werkte, moeten we er een RAC-database van maken. Nou, alles is al aanwezig om dit een RAC-database te laten zijn, want dat was het ooit. Om de klus te klaren, hebben we gewoon de stand-bydatabase met één instantie (SHUTDOWN ABORT) in SQL*Plus afgesloten en vervolgens srvctl gebruikt om de stand-by als een RAC-database op te starten:
srvctl start database -d standby -o mount
Het enige dat op dit punt overbleef, was om de stand-by weer toe te voegen aan de DG Broker-configuratie (in DGMGRL): ADD DATABASE stand-by
Toen dit voor het eerst gebeurde, was ik nerveus hoe het zou gaan als zo'n grote database. Geen van de bovenstaande bewerkingen is afhankelijk van de grootte, behalve het kopiëren van de bestanden van en naar media. Maar het ging allemaal goed.
Om ervoor te zorgen dat we deze situatie in de toekomst niet meer tegenkomen, hebben we alerting toegevoegd aan onze Oracle Enterprise Manager Grid Control. Ik ontvang nu een WAARSCHUWING-waarschuwing wanneer de verzending van het log of het toepassen van log 12 uur achterloopt en een KRITIEKE waarschuwing wanneer er 24 uur achterloopt. Dat zou ons voldoende tijd moeten geven om eventuele problemen op te lossen voordat de gearchiveerde logboeken voor opnieuw uitvoeren automatisch worden verwijderd na 7 dagen, of op zijn minst het proces wijzigen om meer dagen aan gearchiveerde logboeken voor opnieuw uitvoeren vast te houden totdat we de situatie hebben verholpen.