Po nedávném výpadku proudu na našem webu DR jsem zjistil, že tam pohotovostní režim přestal používat protokoly. V archivovaných redo logech byla zjevně transakce, která vytvořila datový soubor, ale disk v pohotovostním režimu neměl dostatek místa na disku, aby umožnil dokončení transakce. Takže pohotovostní režim ukončil řízenou obnovu, jak by měl.
Archivované redo logy běžně uchováváme po dobu 7 dnů. Bohužel, než jsem tuto situaci objevil, uplynulo 15 dní a archivované redo logy „chyběly“. Bez použití archivovaných redo logů bylo jediným řešením přestavět databázi od nuly. Tato databáze má velikost přibližně 7 TB, takže přestavba od nuly není triviální záležitost.
Primární je 3-uzlová databáze RAC 11.2.0.2 běžící na Linuxu. Pohotovostní režim je dvouuzlová databáze RAC, samozřejmě stejné verze Oracle a OS.
Zde je návod, jak jsme dosáhli přestavby pohotovostního režimu:
- Primární část jsme přepnuli do režimu horké zálohy a pořídili jsme diskový snímek databáze.
- Snímek byl zkopírován na externí médium. Poznámka:Přeprava přes WAN byla příliš časově náročná.
- Externí média byla ručně přenesena na web DR.
- LOG_ARCHIVE_DEST_STATE_n pro pohotovostní režim byl nastaven na DEFER.
- Pohotovostní databáze byla zrušena z konfigurace DG Broker: ODEBRAT DATABÁZI pohotovostní režim ZACHOVAT CÍLE;
- Připojovací body pohotovostní databáze byly vymazány. Koneckonců, databáze byla v tuto chvíli v podstatě k ničemu.
- Byly vytvořeny nové přípojné body a snímek byl zapsán na disk v místě DR.
- Po dokončení přenosu souborů (asi 5 dní) jsme řekli našemu úložišti, aby aktualizovalo snímek na webu DR o aktuálnější snímek. To bylo provedeno přes WAN, protože byly odeslány pouze změny, které byly mnohem, mnohem menší než databáze.
- Byl vytvořen záložní kontrolní soubor: ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/dir/path’;
- Aby to bylo jednoduché, chtěli jsme používat jednoinstanční pohotovostní režim, dokud jej nezprovozníme. Vytvořili jsme tedy PFILE z pohotovostního RAC SPFILE a poté pomocí textového editoru upravili soubor parametrů tak, aby byly odstraněny všechny parametry podporující RAC. Odstranili jsme CLUSTER_DATABASE, nastavili parametr UNDO_TABLESPACE specifický pro instanci pro použití pro všechny instance „*.“, odstranili parametry THREAD atd. Naše normální pohotovostní databáze má dvě instance, STANDBY1 a STANDBY2. V uzlu 1 jsme umístili pfile do $ORACLE_HOME/dbs/initstandby.ora místo do initstandby1.ora, aby databáze s jednou instancí mohla najít svůj soubor parametrů. Něco podobného jsme udělali pro soubor s hesly.
- Pohotovostní kontrolní soubor z kroku 9 jsme zkopírovali přes kontrolní soubory ve snímku databáze.
- Se soubory pfile a pswd pro databázi jedné instance jsme provedli STARTUP MOUNT.
- Vytvořili jsme všechny pohotovostní protokoly opakování, které bychom potřebovali. V našem případě má primární také pohotovostní redo protokoly pro usnadnění operací přepínání a pohotovostní redo protokoly z primárního zdroje nebyly součástí snímku. Takže jsme museli odstranit SRL, která cestu nezvládla.
- V primárním nastavení nastavte LOG_ARCHIVE_DEST_STATE_n na ENABLE.
- V primárních instancích bylo provedeno ALTER SYSTEM SWITCH LOGFILE;
- Ověřeno v protokolech výstrah primárního i pohotovostního režimu, že pohotovostní režim přijímá protokoly, tj. ověřeno, že přenos protokolu funguje.
- Zapnuto spravovaného pohotovostního režimu:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE ODPOJENÍ OD REZE;
- V pohotovostním protokolu výstrah bylo ověřeno, že protokoly byly aplikovány, tj. ověřené použití nyní funguje.
V tuto chvíli jsme měli záložní databázi zálohovanou a spuštěnou. V primáru jsme vytvořili jednoduchou tabulku a vložili do ní jeden řádek dat, provedli znovu přepínače protokolů a poté v režimu READ ONLY otevřeli pohotovostní režim, abychom ověřili, že se transakce v pohotovostním režimu přehrála tak, jak má. Jakmile jsme spokojeni, že záložní databáze funguje, musíme z ní udělat databázi RAC. Všechno je již připraveno, aby to byla databáze RAC, protože kdysi byla. Abychom dokončili práci, prostě jsme vypnuli jednoinstanční pohotovostní databázi (SHUTDOWN ABORT) v SQL*Plus a poté pomocí srvctl spustili pohotovostní režim jako RAC databázi:
srvctl start databáze -d pohotovostní režim -o připojení
Jediné, co v tomto okamžiku zbývalo, bylo přidat pohotovostní režim zpět do konfigurace DG Broker (v DGMGRL): ADD DATABASE standby
Když se to stalo poprvé, byl jsem nervózní, jak to půjde, když je to tak velká databáze. Žádná z výše uvedených operací není závislá na velikosti kromě kopírování souborů na az média. Ale všechno šlo dobře.
Abychom zajistili, že se do této situace v budoucnu nedostaneme, přidali jsme upozornění do našeho řízení sítě Oracle Enterprise Manager. Nyní obdržím upozornění VAROVÁNÍ, když je odeslání protokolu nebo použití protokolu 12 hodin pozadu, a KRITICKÉ upozornění, když je zpoždění 24 hodin. To by nám mělo poskytnout dostatek času na vyřešení případných problémů, než budou archivované opakované protokoly po 7 dnech automaticky odstraněny, nebo přinejmenším změnit proces tak, aby archivované opakované protokoly uchovával více dní, dokud situaci nenapravíme.