След скорошно прекъсване на захранването на нашия сайт за DR, открих, че режим на готовност там е спрял да прилага регистрационни файлове. Очевидно в архивираните регистрационни файлове за повторно изпълнение е имало транзакция, която е увеличила файл с данни, но дискът в резервния сайт няма достатъчно дисково пространство, за да позволи тази транзакция да завърши. Така че режимът на готовност прекрати управляваното възстановяване, както трябва.
Обикновено съхраняваме архивираните регистрационни файлове за повторно изпълнение в продължение на 7 дни. За съжаление, когато открих тази ситуация, изминаха 15 дни и архивираните регистрационни файлове за повторно изпълнение „липсват“. Без да се прилагат архивирани регистрационни файлове за повторно изпълнение, единственото решение беше възстановяването на базата данни от нулата. Тази база данни е с размер приблизително 7TB, така че възстановяването от нулата не е тривиално.
Основната е база данни RAC 11.2.0.2 с 3 възли, работеща под Linux. Резервният режим е RAC база данни с два възела, очевидно едни и същи версии на Oracle и OS.
Ето как постигнахме възстановяването на режима на готовност:
- Поставихме основното в режим на горещо архивиране и направихме базирана на диск моментна снимка на базата данни.
- Моментната снимка беше копирана на външен носител. Забележка:доставката през WAN отнема твърде много време.
- Външният носител беше пренесен на ръка до сайта на DR.
- LOG_ARCHIVE_DEST_STATE_n за режим на готовност е зададен на ОТЛОЖЕНИЕ.
- Базата данни в режим на готовност беше премахната от конфигурацията на DG Broker: ОТХВЪРХАЙТЕ БАЗА ДАННИ в готовност за запазване на ДЕСТИНАЦИИ;
- Точките за монтиране на базата данни в режим на готовност бяха изтрити. В крайна сметка базата данни беше по същество безполезна в този момент.
- Бяха създадени нови точки за монтиране и моментната снимка беше записана на диска в сайта на DR.
- След като прехвърлянето на файлове приключи (около 5 дни), казахме на хранилището си да актуализира моментната снимка на сайта за DR с по-актуална моментна снимка. Това беше извършено през WAN, тъй като бяха изпратени само промените, което беше много, много по-малко от базата данни.
- Създаден е контролен файл в режим на готовност: ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/dir/path’;
- За да опростим нещата, искахме да използваме режим на готовност за един екземпляр, докато не го пуснем и стартираме. Така че създадохме PFILE от RAC SPFILE в режим на готовност и след това използвахме текстов редактор, за да модифицираме файла с параметри, за да премахнем всички RAC-ориентирани параметри. Премахнахме CLUSTER_DATABASE, зададохме специфичен за екземпляр параметър UNDO_TABLESPACE, който да се използва за всички екземпляри „*.“, премахнахме параметри THREAD и т.н. Нашата нормална база данни в режим на готовност има два екземпляра, STANDBY1 и STANDBY2. В възел 1 поставяме pfile в $ORACLE_HOME/dbs/initstandby.ora вместо initstandby1.ora, така че базата данни с един екземпляр може да намери своя файл с параметри. Направихме нещо подобно за файла с парола.
- Копирахме контролния файл в режим на готовност от стъпка 9 върху контролните файлове в моментната снимка на базата данни.
- С файла pfile и pswd на място за база данни с един екземпляр, направихме STARTUP MOUNT.
- Създадохме всички дневници за повторно изпълнение в готовност, от които се нуждаем. В нашия случай основният също има резервни регистрационни файлове за повторно изпълнение за улесняване на операциите по превключване и резервните регистри за повторно изпълнение от първичния не бяха част от моментната снимка. Така че трябваше да премахнем SRL, които не са направили пътуването.
- В основния задайте LOG_ARCHIVE_DEST_STATE_n на ENABLE.
- В първичните случаи, извършено ALTER SYSTEM SWITCH LOGFILE;
- Проверено както в основния, така и в резервния дневник за предупреждения, че резервният режим получава регистрационни файлове, т.е. потвърдено е, че транспортирането на регистрационни файлове работи.
- Включено управляван режим на готовност:ПРОМЕНИ БАЗА ДАННИ ВЪЗСТАНОВЯВАНЕ НА УПРАВЛЕНА БАЗА ДАННИ В РЕЖИМ ИЗКЛЮЧВАНЕ ОТ СЕСИЯ;
- Потвърдено в дневника за сигнали в режим на готовност, че регистрационните файлове се прилагат, т.е. провереното приложение вече работи.
В този момент имахме резервна и работеща резервна база данни. Създадохме проста таблица в първичната и вмъкнахме един ред с данни в нея, извършихме превключването на дневника отново и след това отворихме режима на готовност в режим САМО ЧЕТЕНЕ, за да проверим дали транзакцията е възпроизведена в режим на готовност, както трябва. След като се уверим, че резервната база данни работи, трябва да я направим RAC база данни. Е, всичко вече е на място, за да бъде RAC база данни, защото някога беше. За да завършим работата, просто изключихме резервната база данни с един екземпляр (SHUTDOWN ABORT) в SQL*Plus и след това използвахме srvctl, за да стартираме готовността като RAC база данни:
srvctl стартиране на база данни -d готовност -o монтиране
Единственото нещо, което остана в този момент, беше да добавите режима на готовност обратно към конфигурацията на DG Broker (в DGMGRL): ДОБАВЯНЕ НА БАЗА ДАННИ в готовност
Когато това се случи за първи път, бях нервен как ще стане толкова голяма база данни. Нито една от горните операции не зависи от размера, освен копирането на файловете към и от носителя. Но всичко мина добре.
За да гарантираме, че няма да се сблъскаме с тази ситуация в бъдеще, добавихме предупреждение към нашия Oracle Enterprise Manager Grid Control. Сега ще получавам ПРЕДУПРЕЖДЕНИЕ известие, когато доставката на регистрационни файлове или прилагането на регистрационните файлове е 12 часа назад и КРИТИЧНО предупреждение, когато 24 часа назад. Това би трябвало да ни даде достатъчно време да отстраним всички проблеми, преди архивираните регистрационни файлове за повторно изпълнение да бъдат премахнати автоматично след 7 дни или най-малкото да променим процеса, за да задържим архивирани дневници за повторно изпълнение на повече дни, докато не коригираме ситуацията.
