物理備庫open報錯ORA-10458: standby database requires recovery
問題展現:
機房掉電導致oracle 11g RAC+DG 所有3節點都非正常關機。
開機之後,RAC兩節點正常啟動,DG上面的資料庫例項只能啟動到mount狀態,無法open。
DG:
alter database open;
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/oracle/oradata/system01.dbf'
RAC01的alert日誌報錯:
Thread 1 advanced to log sequence 71686 (LGWR switch)
Current log# 2 seq# 71686 mem# 0: +DATA/scprd/onlinelog/group_2.300.926178257
Tue Dec 26 14:43:46 2017
Archived Log entry 267550 added for thread 1 sequence 71685 ID 0x350f8bcc dest 1:
Tue Dec 26 14:43:52 2017
ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH SID='*';
Tue Dec 26 14:43:59 2017
Error 12169 received logging on to the standby
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH SID='*';
Tue Dec 26 14:44:01 2017
Thread 1 cannot allocate new log, sequence 71687
Checkpoint not complete
Current log# 2 seq# 71686 mem# 0: +DATA/scprd/onlinelog/group_2.300.926178257
Thread 1 advanced to log sequence 71687 (LGWR switch)
Current log# 1 seq# 71687 mem# 0: +DATA/scprd/onlinelog/group_1.304.926178257
Tue Dec 26 14:44:07 2017
Archived Log entry 267552 added for thread 1 sequence 71686 ID 0x350f8bcc dest 1:
Tue Dec 26 14:49:14 2017
Error 12169 received logging on to the standby
Tue Dec 26 14:49:50 2017
Thread 1 advanced to log sequence 71688 (LGWR switch)
Current log# 2 seq# 71688 mem# 0: +DATA/scprd/onlinelog/group_2.300.926178257
Tue Dec 26 14:49:50 2017
Archived Log entry 267558 added for thread 1 sequence 71687 ID 0x350f8bcc dest 1:
Tue Dec 26 14:49:50 2017
Error 12169 received logging on to the standby
FAL[server, ARC3]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance SCPRD1 - Archival Error. Archiver continuing.
Tue Dec 26 14:51:09 2017
主從日誌同步有問題:
DG:
SQL> COL NAME FOR A13
SQL> COL VALUE FOR A20
SQL> COL UNIT FOR A30
SQL> SET LINES 122
SQL> SELECT NAME,VALUE,UNIT,TIME_COMPUTED
2 FROM V$DATAGUARD_STATS
3 WHERE NAME IN ('transport lag','apply lag');
NAME VALUE UNIT TIME_COMPUTED
------------- -------------------- ------------------------------ ------------------------------
transport lag day(2) to second(0) interval 12/26/2017 14:19:22
apply lag +00 01:53:52 day(2) to second(0) interval 12/26/2017 14:19:22
apply lag有延時。
主庫:
SQL> select thread#, max(sequence#) from v$archived_log group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 71710
2 68404
DG:
SQL> select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 71634
2 68325
DG比主庫的SEQUENCE慢,主從同步有問題。
問題解決:
檢視RAC01的tnsnames有問題:
SCPRDDG =
CPRD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = wmsscan2)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SCPRD)
)
)
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.20)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SCPRDDG)
)
)
修改為:
SCPRDDG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.20)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SCPRDDG)
)
)
重新測試同步,正常了。
apply lag沒有延時了。
主從日誌同步的SEQUENCE也一樣了。
再把DG變為open:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> alter database open read only;
Database altered.
SQL> select RECOVERY_MODE from v$archive_dest_status where rownum<5;
RECOVERY_MODE
-----------------------
IDLE
IDLE
IDLE
IDLE
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Database altered.
SQL> select RECOVERY_MODE from v$archive_dest_status where rownum<5;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
IDLE
IDLE
IDLE
SQL> SELECT NAME,VALUE,UNIT,TIME_COMPUTED
FROM V$DATAGUARD_STATS
2 3 WHERE NAME IN ('transport lag','apply lag');
NAME VALUE UNIT TIME_COMPUTED
------------- -------------------- ------------------------------ ------------------------------
transport lag +00 00:00:00 day(2) to second(0) interval 12/26/2017 16:31:30
apply lag +00 00:00:00 day(2) to second(0) interval 12/26/2017 16:31:30
DG可以提供只讀服務了,一切恢復正常。
機房掉電導致oracle 11g RAC+DG 所有3節點都非正常關機。
開機之後,RAC兩節點正常啟動,DG上面的資料庫例項只能啟動到mount狀態,無法open。
DG:
alter database open;
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/oracle/oradata/system01.dbf'
RAC01的alert日誌報錯:
Thread 1 advanced to log sequence 71686 (LGWR switch)
Current log# 2 seq# 71686 mem# 0: +DATA/scprd/onlinelog/group_2.300.926178257
Tue Dec 26 14:43:46 2017
Archived Log entry 267550 added for thread 1 sequence 71685 ID 0x350f8bcc dest 1:
Tue Dec 26 14:43:52 2017
ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH SID='*';
Tue Dec 26 14:43:59 2017
Error 12169 received logging on to the standby
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH SID='*';
Tue Dec 26 14:44:01 2017
Thread 1 cannot allocate new log, sequence 71687
Checkpoint not complete
Current log# 2 seq# 71686 mem# 0: +DATA/scprd/onlinelog/group_2.300.926178257
Thread 1 advanced to log sequence 71687 (LGWR switch)
Current log# 1 seq# 71687 mem# 0: +DATA/scprd/onlinelog/group_1.304.926178257
Tue Dec 26 14:44:07 2017
Archived Log entry 267552 added for thread 1 sequence 71686 ID 0x350f8bcc dest 1:
Tue Dec 26 14:49:14 2017
Error 12169 received logging on to the standby
Tue Dec 26 14:49:50 2017
Thread 1 advanced to log sequence 71688 (LGWR switch)
Current log# 2 seq# 71688 mem# 0: +DATA/scprd/onlinelog/group_2.300.926178257
Tue Dec 26 14:49:50 2017
Archived Log entry 267558 added for thread 1 sequence 71687 ID 0x350f8bcc dest 1:
Tue Dec 26 14:49:50 2017
Error 12169 received logging on to the standby
FAL[server, ARC3]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance SCPRD1 - Archival Error. Archiver continuing.
Tue Dec 26 14:51:09 2017
主從日誌同步有問題:
DG:
SQL> COL NAME FOR A13
SQL> COL VALUE FOR A20
SQL> COL UNIT FOR A30
SQL> SET LINES 122
SQL> SELECT NAME,VALUE,UNIT,TIME_COMPUTED
2 FROM V$DATAGUARD_STATS
3 WHERE NAME IN ('transport lag','apply lag');
NAME VALUE UNIT TIME_COMPUTED
------------- -------------------- ------------------------------ ------------------------------
transport lag day(2) to second(0) interval 12/26/2017 14:19:22
apply lag +00 01:53:52 day(2) to second(0) interval 12/26/2017 14:19:22
apply lag有延時。
主庫:
SQL> select thread#, max(sequence#) from v$archived_log group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 71710
2 68404
DG:
SQL> select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 71634
2 68325
DG比主庫的SEQUENCE慢,主從同步有問題。
問題解決:
檢視RAC01的tnsnames有問題:
SCPRDDG =
CPRD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = wmsscan2)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SCPRD)
)
)
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.20)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SCPRDDG)
)
)
修改為:
SCPRDDG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.20)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SCPRDDG)
)
)
重新測試同步,正常了。
apply lag沒有延時了。
主從日誌同步的SEQUENCE也一樣了。
再把DG變為open:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> alter database open read only;
Database altered.
SQL> select RECOVERY_MODE from v$archive_dest_status where rownum<5;
RECOVERY_MODE
-----------------------
IDLE
IDLE
IDLE
IDLE
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Database altered.
SQL> select RECOVERY_MODE from v$archive_dest_status where rownum<5;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
IDLE
IDLE
IDLE
SQL> SELECT NAME,VALUE,UNIT,TIME_COMPUTED
FROM V$DATAGUARD_STATS
2 3 WHERE NAME IN ('transport lag','apply lag');
NAME VALUE UNIT TIME_COMPUTED
------------- -------------------- ------------------------------ ------------------------------
transport lag +00 00:00:00 day(2) to second(0) interval 12/26/2017 16:31:30
apply lag +00 00:00:00 day(2) to second(0) interval 12/26/2017 16:31:30
DG可以提供只讀服務了,一切恢復正常。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22996654/viewspace-2149347/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle 12c DG備庫啟動報錯standby database requires recoveryOracleDatabaseUI
- 物理data guard備standby庫的時候報錯。
- 部署 11G 物理DataGuard時 ALTER DATABASE OPEN 報錯Database
- 恢復備庫 activate standby database 報錯找不到standby redo - ORA-00313Database
- Oracle11g的Dataguard測試,建立物理備庫(Physical Standby Database)OracleDatabase
- 配置Oracle11g的Dataguard測試,建立物理備庫(Physical Standby Database)OracleDatabase
- 主庫歷經open resetlogs後,如何redo apply 物理備庫_flashback physical standby dbAPP
- 物理standby database的日常維護Database
- 通過RMAN Duplicate建立Oracle物理standby備庫Oracle
- RAC環境的STANDBY資料庫備份報錯資料庫
- 為物理備庫新增standby logfile group相關事則
- 物理Standby資料庫及邏輯Standby資料庫(Physical Standby & Logical Standby)資料庫
- 4 Creating a Logical Standby Database 建立邏輯備庫Database
- 【DATAGUARD】 將11g物理備庫轉換為Snapshot Standby
- duplicate standby database 報ORA-05507錯誤解決方法Database
- ORACLE DUPLICATE建立物理standby資料庫Oracle資料庫
- 使用RMAN建立物理Standby資料庫資料庫
- Oracle DataGuard Standby database ID mismatch錯誤OracleDatabase
- 使用RMAN DUPLICATE...FROM ACTIVE DATABASE命令來建立DataGuard物理備庫Database
- 備庫open read only報錯,經查是有一個trigger在open後觸發
- 物理備庫互轉快照備庫
- 配置物理備庫+邏輯備庫
- standby databaseDatabase
- Oracle 12.2 physical standby備庫收集AWR報告Oracle
- Convert a Physical Standby Database into a Snapshot Standby DatabaseDatabase
- dataguard之物理standby庫failover 切換AI
- Data Guard 之RMAN備份線上搭建物理standby
- standby database to primary database.Database
- 搭建物理備庫
- Physical Standby Database 切換到 Snapshot Standby DatabaseDatabase
- oracle9i(9204)dg(data guard)_ place the standby database in manual recovery modeOracleDatabase
- Creating a Standby Database using RMAN (Recovery Manager) [ID 118409.1]Database
- Standby Database ---09Database
- ORA-19527 reported in Standby Database when starting Managed Recovery_352879.1Database
- 使用 RMAN DUPLICATE...FROM ACTIVE DATABASE 建立物理備用資料庫的分步指南Database資料庫
- 第4章 資料庫恢復 Database Recovery資料庫Database
- DataGuard搭建物理StandBy
- 【DATAGUARD 學習】使用duplicate 建立物理standby 資料庫資料庫