В процес съм на подмяна на хардуера за съществуващ RAC клъстер с 3 възела. Тази система също е основна за резервна база данни RAC с 2 възела. За да сменя хардуера, планът ми е временно да разширя клъстера в конфигурация с 6 възела, 3 стари сървъра и 3 нови сървъра. След като екземплярите се изпълняват на новия хардуер и приложенията ми се свързват с новите екземпляри, ще премахна старите екземпляри и ще оттегля старите сървъри, като се върна към конфигурация с 3 възела.
След като разширих клъстера до всичките шест възела, през миналия уикенд стартирах новите екземпляри на новите възли. За да улесня живота си, просто използвах DBCA за тази работа. След като стартирах DBCA, избрах да работя върху RAC база данни и след това избрах Управление на инстанция и след това Добавяне на нов екземпляр. Преминавайки през съветника, оставям DBCA да се погрижи за всички подробности вместо мен. Звучи просто.
Тази сутрин получих обичайния си отчет за забавяне на архива. Изглежда подобно на следното:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Изпращам това в моята пощенска кутия два пъти на ден. Бърз поглед ми помага да определя дали моят режим на готовност получава и прилага транзакции от основния. Настроих всички мои бази данни в режим на готовност на четиричасово закъснение за прилагане. И моят основен ARCHIVE_LAG_TARGET е зададен на един час. Това означава, че забавянето на прилагането ще бъде най-малко 4 часа, но не трябва да бъде повече от 5 часа. Както можем да видим по-горе, имаме две бази данни в режим на готовност, които са надхвърлили значително 5-часовото максимално забавяне на прилагането. По-горе имам режим на готовност с забавяне на прилагането от 1 ден 21 часа! Така че веднага разбрах, че нещо не е наред. И не беше нужен учен по ракета, за да разбере, че добавянето на новия екземпляр към първичния вероятно е допринесло за проблема.
Както казах в началото на тази публикация, имам RAC система за готовност с 2 възела. Единият екземпляр е „приложи екземпляр“, а другият екземпляр седи там сравнително неактивен. В моя дневник за предупреждения за прилагане на инстанция видях следните съобщения за грешка:
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
Тъй като моята база данни в режим на готовност е настроена на STANDBY_FILE_MANAGEMENT=AUTO, първата част от съобщенията има смисъл. Когато добавите нов екземпляр към база данни на RAC, трябва да предоставите пространство за таблици за отмяна само за този екземпляр и също така трябва да предоставите онлайн групи регистрационни файлове за повторно изпълнение, посветени на нишката на този екземпляр. DBCA специално ми зададе въпроси, отнасящи се до файловите структури за отмяна и повторение. В съдържанието на дневника за предупреждения по-горе можем да видим, че режимът на готовност успешно е добавил файл с данни 342, който е моето пространство за таблица за отмяна. Но режимът на готовност не успя да добави онлайн регистрационните файлове за повторно изпълнение. Ако искате режимът на готовност да може автоматично да добавя онлайн регистрационните файлове за повторно изпълнение, трябва да посочите параметри на OMF, което не съм склонен да направя. Тъй като добавянето на онлайн регистрационен файл за повторно изпълнение доведе до грешка, режимът на готовност спря възстановяването на носителя. Режимът на готовност все още получава регистрационни файлове.
Не намерих много в Metalink или чрез търсене в Google за това как да разреша този проблем, но ето стъпките, които предприех, за да върна и да заработя Media Recovery. В резервната база данни (направих това на екземпляра за прилагане, но трябва да е жизнеспособен на всеки екземпляр в резервната база данни RAC):
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
Това не трябва да е шок, защото знаем, че Managed Recovery е прекратено. Но за пълнота включих тази стъпка. Ако трябва да добавите регистрационни файлове за повторно изпълнение към режим на готовност, който в момента прилага транзакции, тогава ще ви е необходима тази стъпка.
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
Горното е точно това, което беше пуснато на първичния. Трябва да добавите дневника за повторно изпълнение в режим на готовност точно както е направено на основния. Повторете за всяка група регистрационни файлове за повторно изпълнение, добавена към основната. Тъй като добавих 3 екземпляра към моята основна RAC база данни, трябва да добавя три нишки тук.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Започнете управлявано възстановяване. Всичко трябва да е наред сега и можем да проверим в дневника за предупреждения на инстанцията за прилагане:
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Можем също така да проверим, че забавянето на прилагането става по-кратко. В режим на готовност издайте следното:
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d
where d.name='apply lag';
За основна информация как да управлявате онлайн регистрационни файлове за повторение за вашата физическа база данни в режим на готовност, вижте бележката на Metalink 740675.1 Онлайн регистрационни файлове за повторно изпълнение в режим на готовност.
