[36] Комментарий от Anonymous 13.12.2007(11:36:59)ОтветитьСпасибо за статью, пригодится
[157] Комментарий от wraick 24.06.2008(16:35:08)ОтветитьВ случае с failover после команды ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; (пункт failover 1 конец) не происходит восстановление процесса передачи redo logs на standby-базу. Почему?
[159] Комментарий от dbstalker 24.06.2008(17:08:02)ОтветитьТрудно сказать почему у Вас не восстановилась передача редо логов. Только что было проверено этот механизм : SQL> recover managed standby database disconnect from session; Media recovery complete. SQL> RECOVER MANAGED STANDBY DATABASE FINISH; Media recovery complete. SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; Media recovery complete. И вот что получено в алерте: Media Recovery Waiting for thread 1 seq# 14660 Tue Jun 24 17:02:00 2008 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH Tue Jun 24 17:02:00 2008 Terminal Recovery: request posted Tue Jun 24 17:02:12 2008 There are no standby current logs; terminal recovery is not required. MRP0: Background Media Recovery user canceled with status 16137 Recovery interrupted. Tue Jun 24 17:02:12 2008 Waiting for MRP0 pid 2160 to terminate Tue Jun 24 17:02:13 2008 MRP0: Background Media Recovery process shutdown Tue Jun 24 17:02:13 2008 Terminal Recovery: completion detected Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE Tue Jun 24 17:02:39 2008 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Attempt to start background Managed Standby Recovery process MRP0 started with pid=14 MRP0: Background Managed Standby Recovery process started Media Recovery Waiting for thread 1 seq# 14660 Tue Jun 24 17:02:45 2008 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE D Tue Jun 24 17:03:46 2008 Fetching gap sequence for thread 1, gap sequence 14660-14679 Trying FAL server: sta2201f.dpa.km.sta.ua Media Recovery Log C:\ORACLE\ORADATA\MB\MB_ARCHIVE\ARC14660.001 Media Recovery Log C:\ORACLE\ORADATA\MB\MB_ARCHIVE\ARC14661.001 Первое, что приходит на ум: recover managed standby database cancel; shutdown immediate startup nomount alter database mount standby database; recover managed standby database disconnect from session; Пробуйте - может получится
SQL> recover managed standby database disconnect from session; Media recovery complete. SQL> RECOVER MANAGED STANDBY DATABASE FINISH; Media recovery complete. SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; Media recovery complete.
Media Recovery Waiting for thread 1 seq# 14660 Tue Jun 24 17:02:00 2008 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH Tue Jun 24 17:02:00 2008 Terminal Recovery: request posted Tue Jun 24 17:02:12 2008 There are no standby current logs; terminal recovery is not required. MRP0: Background Media Recovery user canceled with status 16137 Recovery interrupted. Tue Jun 24 17:02:12 2008 Waiting for MRP0 pid 2160 to terminate Tue Jun 24 17:02:13 2008 MRP0: Background Media Recovery process shutdown Tue Jun 24 17:02:13 2008 Terminal Recovery: completion detected Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE Tue Jun 24 17:02:39 2008 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Attempt to start background Managed Standby Recovery process MRP0 started with pid=14 MRP0: Background Managed Standby Recovery process started Media Recovery Waiting for thread 1 seq# 14660 Tue Jun 24 17:02:45 2008 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE D Tue Jun 24 17:03:46 2008 Fetching gap sequence for thread 1, gap sequence 14660-14679 Trying FAL server: sta2201f.dpa.km.sta.ua Media Recovery Log C:\ORACLE\ORADATA\MB\MB_ARCHIVE\ARC14660.001 Media Recovery Log C:\ORACLE\ORADATA\MB\MB_ARCHIVE\ARC14661.001
recover managed standby database cancel; shutdown immediate startup nomount alter database mount standby database; recover managed standby database disconnect from session;
[229] Комментарий от Pupkin 14.08.2008(13:45:16)ОтветитьДобрый день. Помогите разобраться пожалуйста.Когда выполняю подъем основного сервера, на шаге 7, дает: SQL> startup pfile=D:\Oracle\database\initMyDB.ora; LRM-00101: unknown parameter name 'fal_client' ORA-01078: failure in processing system parameters Установлен Oracle 817. В чем может быть причина и как ее устранить? Или для этой версии описанные шаги не подходят?[246] Комментарий от dbstalker 01.09.2008(12:04:27)ОтветитьПараметр fal_client, действительно, появился в oracle 9.2. Цитирую:"New initialization parameters: REMOTE_ARCHIVE_ENABLE, FAL_CLIENT, FAL_SERVER, STANDBY_FILE_MANAGEMENT, ARCHIVE_LAG_TARGET". Смотрите здесь здесь
[246] Комментарий от dbstalker 01.09.2008(12:04:27)ОтветитьПараметр fal_client, действительно, появился в oracle 9.2. Цитирую:"New initialization parameters: REMOTE_ARCHIVE_ENABLE, FAL_CLIENT, FAL_SERVER, STANDBY_FILE_MANAGEMENT, ARCHIVE_LAG_TARGET". Смотрите здесь здесь
[244] Комментарий от Romas 28.08.2008(17:11:59)ОтветитьОтличная статья. Практически только благодаря ей я освоил технологию STANDBY. Спасибо огромное! Но вот какая штука... Я попробовал сделать свитчовер по приведённым здесь скриптам команда alter database commit to switchover to physical standby; отработала с ошибкой ORA-16014 signalled during: alter database commit to switchover to physical st... что означает, что LGWR было некуда записать последнюю архивную информацию. А причиной этого стала данная ранее команда alter system set log_archive_dest_state_2=defer scope=both; То есть, просто говоря, сами перекрыли краник, через который должна была произойти окончательная синхронизация со STANDBY перед SWITCHOVER. Я исправил команду на alter system set log_archive_dest_state_2=defer scope=spfile; и переключение прошло на ура.