Efter en nylig strømafbrydelse på vores DR-side opdagede jeg, at en standby der var holdt op med at anvende logs. Tilsyneladende var der i de arkiverede redologs en transaktion, der voksede til en datafil, men disken på standby-stedet havde ikke nok diskplads til at lade transaktionen fuldføre. Så standbyen afsluttede den administrerede gendannelse, som den burde.
Vi opbevarer normalt de arkiverede genoptagelogfiler i 7 dage. Desværre, da jeg opdagede denne situation, var der gået 15 dage, og de arkiverede gentag-logfiler "manglede". Uden nogen arkiverede redo-logfiler at anvende, var den eneste løsning at genopbygge databasen fra bunden. Denne database er cirka 7 TB i størrelse, så det er ingen triviel affære at genopbygge fra bunden.
Den primære er en 3-node RAC 11.2.0.2-database, der kører på Linux. Standbyen er en RAC-database med to noder, åbenbart de samme Oracle- og OS-versioner.
Her er, hvordan vi fik genopbygget standbyen:
- Vi satte den primære i hot backup-tilstand og tog et diskbaseret snapshot af databasen.
- Snapshottet blev kopieret til eksterne medier. Bemærk:Forsendelse på tværs af WAN var for tidskrævende.
- De eksterne medier blev håndbåret til DR-siden.
- LOG_ARCHIVE_DEST_STATE_n for standby var indstillet til DEFER.
- Standbydatabasen blev slettet fra DG Broker-konfigurationen: FJERN DATABASE-standby BEVAR DESTINATIONER;
- Standbydatabasens monteringspunkter blev slettet. Når alt kommer til alt, var databasen stort set ubrugelig på dette tidspunkt.
- Nye monteringspunkter blev oprettet, og snapshottet blev skrevet til disken på DR-webstedet.
- Efter filoverførslen var gennemført (ca. 5 dage), bad vi vores lager om at opdatere øjebliksbilledet på DR-webstedet med et mere aktuelt øjebliksbillede. Dette blev udført over WAN, da kun ændringerne blev sendt, som var meget, meget mindre end databasen.
- Der blev oprettet en standby-kontrolfil: ALTER DATABASE OPRET STANDBY-KONTROLFIL SOM '/dir/sti';
- For at gøre tingene enkle, ønskede vi at bruge en standby med en enkelt forekomst, indtil vi fik den op at køre. Så vi oprettede en PFILE fra standbyens RAC SPFILE og brugte derefter en teksteditor til at ændre parameterfilen for at fjerne eventuelle RAC-bevidste parametre. Vi fjernede CLUSTER_DATABASE, satte en instansspecifik UNDO_TABLESPACE-parameter til at blive brugt til alle instanser “*.”, fjernede THREAD-parametre osv. Vores normale standby-database har to instanser, STANDBY1 og STANDBY2. I node 1 satte vi pfilen i $ORACLE_HOME/dbs/initstandby.ora i stedet for initstandby1.ora, så databasen med enkelt instans kunne finde sin parameterfil. Vi gjorde noget lignende for adgangskodefilen.
- Vi kopierede standby-kontrolfilen fra trin 9 over kontrolfilerne i database-øjebliksbilledet.
- Med pfile- og pswd-filen på plads for en enkelt forekomstdatabase, foretog vi STARTUP MOUNT.
- Vi har oprettet alle standby-redo-logfiler, vi skulle bruge. I vores tilfælde har den primære også standby-redo-logs for at lette overgangsoperationer, og standby-redo-logs fra den primære var ikke en del af snapshotet. Så vi var nødt til at fjerne de SRL'er, der ikke nåede turen.
- I den primære skal du indstille LOG_ARCHIVE_DEST_STATE_n til ENABLE.
- I de primære tilfælde udførte ALTER SYSTEM SWITCH LOGFILE;
- Bekræftet i både den primære og standbys advarselslog, at standbyen modtog logs, dvs. bekræftet, at logtransporten fungerede.
- Aktiveret administreret standby:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE AFBRYD FRA SESSION;
- Bekræftet i standbys advarselslog, at logfilerne blev anvendt, dvs. bekræftet anvendelse virkede nu.
På dette tidspunkt havde vi en standby-database op at køre. Vi oprettede en simpel tabel i den primære og indsatte en række data i den, udførte log-skiftene igen og åbnede derefter standbyen i READ ONLY-tilstand for at bekræfte, at transaktionen blev afspillet i standby-tilstand, som den skulle. Når vi var overbeviste om, at standby-databasen virkede, er vi nødt til at gøre den til en RAC-database. Alt er allerede på plads for, at dette kan være en RAC-database, fordi det var engang. For at afslutte jobbet lukker vi bare standby-databasen med en enkelt forekomst (SHUTDOWN ABORT) i SQL*Plus og brugte derefter srvctl til at starte standbyen som en RAC-database:
srvctl start database -d standby -o mount
Det eneste, der var tilbage på dette tidspunkt, var at tilføje standbyen tilbage til DG Broker-konfigurationen (i DGMGRL): ADD DATABASE standby
Da dette skete første gang, var jeg nervøs for, hvordan det ville gå at være så stor en database. Ingen af ovenstående handlinger er størrelsesafhængige udover at kopiere filerne til og fra medier. Men det hele gik godt.
For at sikre, at vi ikke løber ind i denne situation i fremtiden, har vi tilføjet alarmer til vores Oracle Enterprise Manager Grid Control. Jeg vil nu modtage en ADVARSEL, når logforsendelse eller logansøgning er 12 timer bagud og en KRITISK advarsel, når der er 24 timer bagud. Det burde give os masser af tid til at løse eventuelle problemer, før de arkiverede fortrydelseslogfiler automatisk fjernes efter 7 dage, eller i det mindste ændre processen, så den opbevarer flere dages arkiverede genoptagelogfiler, indtil vi retter op på situationen.