Efter ett strömavbrott nyligen på vår DR-webbplats upptäckte jag att en standby där hade slutat använda loggar. Tydligen fanns i de arkiverade redo-loggarna en transaktion som växte fram en datafil men disken på standbyplatsen hade inte tillräckligt med diskutrymme för att transaktionen skulle slutföras. Så vänteläget avslutade hanterad återställning, som det borde.
Vi behåller normalt de arkiverade redo-loggarna i 7 dagar. Tyvärr, när jag upptäckte denna situation, hade 15 dagar gått och de arkiverade redo-loggarna "saknas". Utan några arkiverade redo-loggar att tillämpa var den enda lösningen att bygga om databasen från början. Den här databasen är cirka 7 TB stor, så att bygga om från grunden är ingen trivial affär.
Den primära är en 3-nods RAC 11.2.0.2-databas som körs på Linux. Standby är en RAC-databas med två noder, uppenbarligen samma Oracle- och OS-versioner.
Så här återuppbyggde vi standbyläget:
- Vi satte den primära i hot backup-läge och tog en diskbaserad ögonblicksbild av databasen.
- Önblicksbilden kopierades till extern media. Obs:frakt över WAN var för tidskrävande.
- Det externa mediet bars för hand till DR-webbplatsen.
- LOG_ARCHIVE_DEST_STATE_n för vänteläge var inställt på DEFER.
- Standbydatabasen togs bort från DG Broker-konfigurationen: REMOVE DATABASE standby PRESERVE DESTINATIONS;
- Väntedatabasens monteringspunkter raderades. När allt kommer omkring var databasen i princip värdelös vid det här laget.
- Nya monteringspunkter skapades och ögonblicksbilden skrevs till disken på DR-platsen.
- Efter att filöverföringarna var klara (cirka 5 dagar), bad vi vårt lagringsutrymme att uppdatera ögonblicksbilden på DR-webbplatsen med en mer aktuell ögonblicksbild. Detta utfördes över WAN eftersom endast ändringarna skickades, vilket var mycket, mycket mindre än databasen.
- En standby-kontrollfil skapades: ALTER DATABASE SKAPA STANDBY-KONTROLLFIL SOM '/dir/sökväg';
- För att göra det enkelt ville vi använda ett standbyläge för en instans tills vi fick det igång. Så vi skapade en PFILE från standbyens RAC SPFILE och använde sedan en textredigerare för att modifiera parameterfilen för att ta bort eventuella RAC-medvetna parametrar. Vi tog bort CLUSTER_DATABASE, ställde in en instansspecifik UNDO_TABLESPACE-parameter som ska användas för alla instanser “*.”, tog bort THREAD-parametrar, etc. Vår normala standby-databas har två instanser, STANDBY1 och STANDBY2. I nod 1 lägger vi p-filen i $ORACLE_HOME/dbs/initstandby.ora istället för initstandby1.ora så att en-instansdatabasen kunde hitta sin parameterfil. Vi gjorde något liknande för lösenordsfilen.
- Vi kopierade väntelägeskontrollfilen från steg 9 över kontrollfilerna i databasens ögonblicksbild.
- Med pfile- och pswd-filen på plats för en databas med en enda instans, gjorde vi STARTUPMONTERING.
- Vi skapade alla redo-loggar som vi skulle behöva. I vårt fall har den primära också redo-loggar i beredskapsläge för att underlätta övergångsoperationer och loggarna för omställning i beredskapsläge från den primära var inte en del av ögonblicksbilden. Så vi var tvungna att ta bort de SRL som inte gjorde resan.
- I den primära, ställ in LOG_ARCHIVE_DEST_STATE_n på ENABLE.
- I de primära fallen utfördes ALTER SYSTEM SWITCH LOGFILE;
- Verifierade i både primär- och standby-varningsloggarna att standby-enheten tog emot loggar, dvs. verifierade att loggtransporten fungerade.
- Aktiverat hanterat standbyläge:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE KOPPLA FRÅN SESSION;
- Verifierade i väntelägets varningslogg att loggarna tillämpades, dvs. verifierad tillämpning fungerar nu.
Vid det här laget hade vi en standby-databas igång igen. Vi skapade en enkel tabell i den primära och infogade en rad med data i den, utförde loggväxlingarna igen och öppnade sedan standby-läget i READ ONLY-läge för att verifiera att transaktionen spelades om i standby-läge som den skulle. När vi väl var övertygade om att standbydatabasen fungerade måste vi göra den till en RAC-databas. Allt är redan på plats för att detta ska vara en RAC-databas eftersom det en gång var det. För att avsluta jobbet stängde vi bara av standby-databasen för en instans (SHUTDOWN ABORT) i SQL*Plus och använde sedan srvctl för att starta standby-läget som en RAC-databas:
srvctl start databasen -d standby -o mount
Det enda som återstod vid denna tidpunkt var att lägga till vänteläget tillbaka till DG Broker-konfigurationen (i DGMGRL): ADD DATABASE standby
När detta först hände var jag nervös hur det skulle gå att vara en så stor databas. Ingen av operationerna ovan är storleksberoende förutom att kopiera filerna till och från media. Men allt gick bra.
För att säkerställa att vi inte hamnar i den här situationen i framtiden har vi lagt till varningar i vår Oracle Enterprise Manager Grid Control. Jag kommer nu att få en VARNING när loggsändning eller logga gäller är 12 timmar efter och en KRITISK varning när 24 timmar efter. Det borde ge oss gott om tid att åtgärda eventuella problem innan de arkiverade redo-loggarna tas bort automatiskt efter 7 dagar, eller åtminstone ändra processen så att den lagrar fler dagars arkiverade redo-loggar tills vi rättar till situationen.