Oracle ADG备库SYSAUX数据文件坏块恢复处理（ORA-00600,ORA-10567,ORA-10564......
本文阐述了Oracle ADG备库SYSAUX数据文件坏块恢复处理（ORA-00600,ORA-10567,ORA-10564,ORA-01110,ORA-10561）的思路、步骤、解决方案。
查看ADG同步情况
SQL> set line 999
SQL> select inst_id,thread#,process,pid,status,client_process,client_pid,sequence#,block#,active_agents,known_agents from gv$managed_standby;
ID THREAD# PROCESS PID STATUS CLIENT_PROCESS CLIENT_PID SEQUENCE# BLOCK# ACTIVE_AGENTS KNOWN_AGENTS
--- ---------- ------------------ ---------- ------------------------ ---------------- --------- ---------- ---------- ------------- ------------
1 2 ARCH 75175 CLOSING ARCH 75175 57 356352 0 0
0 DGRD 75179 ALLOCATED N/A N/A 0 0 0 0
0 DGRD 75183 ALLOCATED N/A N/A 0 0 0 0
2 ARCH 75191 CLOSING ARCH 75191 58 352256 0 0
2 ARCH 75195 CLOSING ARCH 75195 59 1 0 0
1 ARCH 75199 CLOSING ARCH 75199 72 1 0 0
0 RFS 98051 IDLE UNKNOWN 37620 0 0 0 0
0 RFS 100998 IDLE UNKNOWN 1424 0 0 0 0
2 RFS 101005 IDLE LGWR 1439 60 31391 0 0
0 RFS 97935 IDLE UNKNOWN 37632 0 0 0 0
1 RFS 97933 IDLE LGWR 37670 73 131240 0 0
1 RFS 97941 IDLE Archival 37602 0 0 0 0
2 RFS 101035 IDLE Archival 1412 0 0 0 0
2 0 ARCH 121781 CONNECTED ARCH 121781 0 0 0 0
0 DGRD 121789 ALLOCATED N/A N/A 0 0 0 0
0 DGRD 121793 ALLOCATED N/A N/A 0 0 0 0
0 ARCH 121809 CONNECTED ARCH 121809 0 0 0 0
0 ARCH 121813 CONNECTED ARCH 121813 0 0 0 0
0 ARCH 121822 CONNECTED ARCH 121822 0 0 0 0
19 rows selected.
SQL> select inst_id,name,value,time_computed,DATUM_TIME,sysdate from gv$dataguard_stats order by inst_id;
ID NAME VALUE TIME_COMPUTED LAST_RECEIVED_TIME SYSDATE
--- ------------------------------ ------------------------------ -------------------- -------------------- -------------------
1 apply finish time +00 00:18:11.925 09/08/2021 10:52:23 2021-09-08 10:52:23
apply lag +03 20:51:36 09/08/2021 10:52:23 09/08/2021 10:52:22 2021-09-08 10:52:23
transport lag +00 00:00:00 09/08/2021 10:52:23 09/08/2021 10:52:22 2021-09-08 10:52:23
estimated startup time 42 09/08/2021 10:52:23 2021-09-08 10:52:23
2 apply finish time 09/08/2021 10:52:23 2021-09-08 10:52:23
apply lag 09/08/2021 10:52:23 2021-09-08 10:52:23
transport lag +00 00:00:00 09/08/2021 10:52:23 09/08/2021 10:52:22 2021-09-08 10:52:23
estimated startup time 46 09/08/2021 10:52:23 2021-09-08 10:52:23
8 rows selected.
MRP0进程没启动
重新启动一下
SQL> alter database recover managed standby database using current logfile disconnect;还是没有MRP0进程
看看alert日志
alter database recover managed standby database using current logfile disconnect
ERROR: ORA-00600: internal error code, arguments: [3020] recovery detected a data block with invalid SCN. This could be caused by a lost write on the primary; do NOT attempt to bypass this error by copying blocks or datafiles from the primary database to the standby database because that would propagate the lost write from the primary to the standby.
Errors in file /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/trace/TESTDB1_pr01_55707.trc (incident=150042):
ORA-00600: internal error code, arguments: [3020], [3], [307241], [12890153], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 307241, file offset is 2516918272 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 3: '+DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 331551
Incident details in: /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/incident/incdir_150042/TESTDB1_pr01_55707_i150042.trc
2021-09-08T10:58:34.421283+08:00
*****************************************************************
An internal routine has requested a dump of selected redo.
This usually happens following a specific internal error, when
analysis of the redo logs will help Oracle Support with the
diagnosis.
It is recommended that you retain all the redo logs generated (by
all the instances) during the past 12 hours, in case additional
redo dumps are required to help with the diagnosis.
*****************************************************************
2021-09-08T10:58:47.102879+08:00
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2021-09-08T10:58:47.114814+08:00
Slave exiting with ORA-600 exception
2021-09-08T10:58:47.115031+08:00
Errors in file /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/trace/TESTDB1_pr01_55707.trc:
ORA-00600: internal error code, arguments: [3020], [3], [307241], [12890153], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 307241, file offset is 2516918272 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 3: '+DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 331551
2021-09-08T10:58:47.330512+08:00
Dumping diagnostic data in directory=[cdmp_20210908105847], requested by (instance=1, osid=55707 (PR01)), summary=[incident=150042].
2021-09-08T10:58:47.339785+08:00
Errors in file /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/trace/TESTDB1_mrp0_55537.trc (incident=149889):
ORA-00600: internal error code, arguments: [3020], [3], [307241], [12890153], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 307241, file offset is 2516918272 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 3: '+DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 331551
Incident details in: /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/incident/incdir_149889/TESTDB1_mrp0_55537_i149889.trc
2021-09-08T10:58:48.519224+08:00
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2021-09-08T10:58:48.519339+08:00
Recovery Slave PR01 previously exited with exception 600
2021-09-08T10:58:48.520870+08:00
Errors with log +DATA/TESTDBDG/ARCHIVELOG/2021_09_04/thread_2_seq_42.273.1082383369
PR00 (PID:55650): MRP0: Background Media Recovery terminated with error 448
2021-09-08T10:58:48.574663+08:00
Errors in file /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/trace/TESTDB1_pr00_55650.trc:
ORA-00448: normal completion of background process
2021-09-08T10:58:48.576213+08:00
.... (PID:74660): Managed Standby Recovery not using Real Time Apply
2021-09-08T10:58:48.628897+08:00
Recovery interrupted!
2021-09-08T10:58:48.646974+08:00
Dumping diagnostic data in directory=[cdmp_20210908105848], requested by (instance=1, osid=55537 (MRP0)), summary=[incident=149889].
2021-09-08T10:58:48.671922+08:00
Recovered data files to a consistent state at change 1083026445
2021-09-08T10:58:49.224205+08:00
Increasing priority of 2 RS
Reconfiguration started (old inc 10, new inc 12)
List of instances (total 2) :
1 2
My inst 1
Global Resource Directory frozen
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
2021-09-08T10:58:49.317423+08:00
LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2021-09-08T10:58:49.317516+08:00
LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
Set master node info
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
2021-09-08T10:58:51.677386+08:00
Reconfiguration complete (total time 2.5 secs)
Decreasing priority of 2 RS
2021-09-08T10:58:52.067037+08:00
stopping change tracking
2021-09-08T10:58:52.073397+08:00
Errors in file /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/trace/TESTDB1_pr00_55650.trc:
ORA-00448: normal completion of background process
2021-09-08T10:58:52.104767+08:00
Errors in file /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/trace/TESTDB1_mrp0_55537.trc:
ORA-00600: internal error code, arguments: [3020], [3], [307241], [12890153], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 307241, file offset is 2516918272 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 3: '+DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 331551
2021-09-08T10:58:52.104916+08:00
Background Media Recovery process shutdown (TESTDB1)
数据文件sysaux.268.1081620609有坏快
尝试修复
RMAN> blockrecover datafile 3 block 307241;
Starting recover at 08-SEP-21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1165 instance=TESTDB1 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 08-SEP-21启动下MRP，检查下日志
SQL> alter database recover managed standby database using current logfile disconnect;
2021-09-08T11:14:17.325866+08:00
Errors in file /home/db/oracle/diag/rdbms/TESTDBdg/TESTDB1/trace/TESTDB1_mrp0_64635.trc:
ORA-00600: internal error code, arguments: [3020], [3], [307241], [12890153], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 307241, file offset is 2516918272 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 3: '+DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 331551
2021-09-08T11:14:17.325980+08:00
Background Media Recovery process shutdown (TESTDB1)
没有修复
那么从主库把sysaux单独恢复至备库
主库备份sysaux数据文件
FILE_ID FILE_NAME TABLESPACE_NAME
---------- ---------------------------------------------------------------------- --------------------
1 +DATA/TESTDBDG/DATAFILE/system.257.1081620983 SYSTEM
3 +DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609 SYSAUX
5 +DATA/TESTDBDG/DATAFILE/undotbs11.261.1081620609 UNDOTBS11
7 +DATA/TESTDBDG/DATAFILE/users.258.1081621049 USERS
2 +DATA/TESTDBDG/DATAFILE/ig_space.267.1081620607 IG_SPACE
4 +DATA/TESTDBDG/DATAFILE/undotbs12.264.1081620607 UNDOTBS12
RMAN> backup as copy datafile 3 format '/tmp/copy_%U.bak';
Starting backup at 08-SEP-21
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=+DATA/TESTDB/DATAFILE/sysaux.260.1081508249
output file name=/tmp/copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak tag=TAG20210908T113937 RECID=1 STAMP=1082720481
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:45
Finished backup at 08-SEP-21
Starting Control File and SPFILE Autobackup at 08-SEP-21
piece handle=/home/db/oracle/product/19.3.0/dbhome_1/dbs/c-3511964840-20210908-00 comment=NONE
Finished Control File and SPFILE Autobackup at 08-SEP-21
RMAN> list copy of datafile 3;
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time Sparse
------- ---- - --------------- ---------- --------------- ------
1 3 A 08-SEP-21 1089480811 08-SEP-21 NO
Name: /tmp/copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak
Tag: TAG20210908T113937
已将sysaux数据文件备份至/tmp下
备份文件传至备库
[oracle@TESTDB03 tmp]$ scp oracle@10.1.1.2:/tmp/copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak .
The authenticity of host '10.1.1.2 (10.1.1.2)' can't be established.
ECDSA key fingerprint is SHA256:qpeYKUxXVw+YiZX/Hf2fgxO8+Lv8n5Mhs2Dn35DWGvc.
ECDSA key fingerprint is MD5:d3:03:e4:b0:0e:ee:45:12:2a:88:3c:31:31:47:27:66.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.1.2' (ECDSA) to the list of known hosts.
oracle@10.1.1.2's password:
copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak传至备库
备库将备份文件cp至共享存储
ASMCMD> cp /tmp/copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak SYSAUX.dbf
copying /tmp/copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak -> +data/TESTDBDG/DATAFILE/SYSAUX.dbf注意：cp前检查下本地文件系统的权限，对grid的用户要有权限访问：
-rw-r----- 1 grid oinstall 6763323392 Sep 8 11:46 copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak
ASMCMD> ls -l
Type Redund Striped Time Sys Name
DATAFILE UNPROT COARSE SEP 08 14:00:00 N SYSAUX.dbf => +DATA/ASM/DATAFILE/SYSAUX.dbf.268.1082732213
已经复制到数据文件所在磁盘目录
删除原故障文件，进行恢复
SQL> alter database datafile 3 offline;
alter database datafile 3 offline
ERROR at line 1:
ORA-01668: standby database requires DROP option for offline of data file
SQL> alter database datafile 3 offline drop;
Database altered.
FILE_ID FILE_NAME TABLESPACE_NAME ONLINE_STATUS
---------- --------------------------------------------------- ---------------- --------------
1 +DATA/TESTDBDG/DATAFILE/system.257.1081620983 SYSTEM SYSTEM
3 +DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609 SYSAUX RECOVER
5 +DATA/TESTDBDG/DATAFILE/undotbs11.261.1081620609 UNDOTBS11 ONLINE
7 +DATA/TESTDBDG/DATAFILE/users.258.1081621049 USERS ONLINE
2 +DATA/TESTDBDG/DATAFILE/ig_space.267.1081620607 IG_SPACE ONLINE
4 +DATA/TESTDBDG/DATAFILE/undotbs12.264.1081620607 UNDOTBS12 ONLINE
ASMCMD> rm -f SYSAUX.268.1081620609
原数据文件已删除
检查下目前读取到的数据文件
RMAN> report schema;
using target database control file instead of recovery catalog
RMAN-06139: warning: control file is not current for REPORT SCHEMA
Report of database schema for database with db_unique_name TESTDBDG
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 1310 SYSTEM YES +DATA/TESTDBDG/DATAFILE/system.257.1081620983
2 30720 IG_SPACE NO +DATA/TESTDBDG/DATAFILE/ig_space.267.1081620607
3 0 SYSAUX NO +DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609
4 10240 UNDOTBS12 YES +DATA/TESTDBDG/DATAFILE/undotbs12.264.1081620607
5 10240 UNDOTBS11 YES +DATA/TESTDBDG/DATAFILE/undotbs11.261.1081620609
7 5 USERS NO +DATA/TESTDBDG/DATAFILE/users.258.1081621049
此时控制文件中的sysaux数据文件路径没变，大小为0，说明还没被控制文件识别到新的备份的数据文件
在控制文件中添加映像副本的路径
RMAN> catalog start with '+data/TESTDBDG/DATAFILE/';--方法一
RMAN> catalog datafilecopy '+data/TESTDBDG/DATAFILE/SYSAUX.dbf'; --方法二
using target database control file instead of recovery catalog
cataloged datafile copy
datafile copy file name=+DATA/TESTDBDG/DATAFILE/sysaux.dbf RECID=8 STAMP=1082733597
控制文件中添加映像副本
switch修改控制文件中的路径（相当于rename）
RMAN> switch database to copy; --整库用
RMAN> switch datafile 3 to copy;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch to copy command at 09/08/2021 16:12:53
ORA-00376: file 3 cannot be read at this time
ORA-01110: data file 3: '+DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609'
还是在找原故障文件的路径，并未将映像副本路径添加到控制文件
这里sysaux的online_status状态为recover,不是offline
FILE_ID FILE_NAME TABLESPACE_NAME ONLINE_STATUS
---------- --------------------------------------------------- ---------------- --------------
1 +DATA/TESTDBDG/DATAFILE/system.257.1081620983 SYSTEM SYSTEM
3 +DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609 SYSAUX RECOVER
5 +DATA/TESTDBDG/DATAFILE/undotbs11.261.1081620609 UNDOTBS11 ONLINE
停下库，启动的mount再试（两个节点）
RMAN> catalog datafilecopy '+data/TESTDBDG/DATAFILE/SYSAUX.dbf';
cataloged datafile copy
datafile copy file name=+DATA/TESTDBDG/DATAFILE/sysaux.dbf RECID=17 STAMP=1082738282
RMAN> list copy of datafile 3;
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time Sparse
------- ---- - --------------- ---------- --------------- ------
17 3 A 08-SEP-21 1089480811 08-SEP-21 NO
Name: +DATA/TESTDBDG/DATAFILE/sysaux.dbf
Tag: TAG20210908T113937
16 3 A 08-SEP-21 1089480811 08-SEP-21 NO
Name: /tmp/copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak
Tag: TAG20210908T113937
12 3 A 08-SEP-21 1089480811 08-SEP-21 NO
Name: +DATA/ASM/DATAFILE/sysaux.dbf.268.1082734639
Tag: TAG20210908T113937
15 3 A 08-SEP-21 1083026445 04-SEP-21 NO
Name: +DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609_bak
Tag: TAG20210826T180958
这里Key17就是我们需要的
其他的文件可以uncatalog
RMAN> change datafilecopy '/tmp/copy_data_D-TESTDB_I-3511964840_TS-SYSAUX_FNO-3_op08i03p.bak' uncatalog;
RMAN> change datafilecopy '+DATA/ASM/DATAFILE/sysaux.dbf.268.1082734639' uncatalog;
RMAN> change datafilecopy '+DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609_bak' uncatalog;report schema看一下
RMAN> report schema;
RMAN-06139: warning: control file is not current for REPORT SCHEMA
Report of database schema for database with db_unique_name TESTDBDG
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 1310 SYSTEM *** +DATA/TESTDBDG/DATAFILE/system.257.1081620983
2 30720 IG_SPACE *** +DATA/TESTDBDG/DATAFILE/ig_space.267.1081620607
3 0 SYSAUX *** +DATA/TESTDBDG/DATAFILE/sysaux.268.1081620609
4 10240 UNDOTBS12 *** +DATA/TESTDBDG/DATAFILE/undotbs12.264.1081620607
5 10240 UNDOTBS11 *** +DATA/TESTDBDG/DATAFILE/undotbs11.261.1081620609
7 5 USERS *** +DATA/TESTDBDG/DATAFILE/users.258.1081621049还是原来的
现在switch datafile 3 to copy
RMAN> switch datafile 3 to copy;
datafile 3 switched to datafile copy "+DATA/TESTDBDG/DATAFILE/sysaux.dbf"再report schema看一下
RMAN> report schema;
RMAN-06139: warning: control file is not current for REPORT SCHEMA
Report of database schema for database with db_unique_name TESTDBDG
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 1310 SYSTEM *** +DATA/TESTDBDG/DATAFILE/system.257.1081620983
2 30720 IG_SPACE *** +DATA/TESTDBDG/DATAFILE/ig_space.267.1081620607
3 6450 SYSAUX *** +DATA/TESTDBDG/DATAFILE/sysaux.dbf
4 10240 UNDOTBS12 *** +DATA/TESTDBDG/DATAFILE/undotbs12.264.1081620607
5 10240 UNDOTBS11 *** +DATA/TESTDBDG/DATAFILE/undotbs11.261.1081620609
7 5 USERS *** +DATA/TESTDBDG/DATAFILE/users.258.1081621049可以看到datafile3已经使我们想要的了
启动MRP
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.检查下同步情况
SQL> set line 999
SQL> select inst_id,thread#,process,pid,status,client_process,client_pid,sequence#,block#,active_agents,known_agents from gv$managed_standby;
ID THREAD# PROCESS PID STATUS CLIENT_PROCESS CLIENT_PID SEQUENCE# BLOCK# ACTIVE_AGENTS KNOWN_AGENTS
--- ---------- ------------------ ----------------- ------------------------ ---------------- -------------- ---------- ---------- ------------- ------------
2 0 ARCH 25489 CONNECTED ARCH 25489 0 0 0 0
0 DGRD 25493 ALLOCATED N/A N/A 0 0 0 0
0 DGRD 25500 ALLOCATED N/A N/A 0 0 0 0
0 ARCH 25512 CONNECTED ARCH 25512 0 0 0 0
0 ARCH 25524 CONNECTED ARCH 25524 0 0 0 0
0 ARCH 25531 CONNECTED ARCH 25531 0 0 0 0
1 0 ARCH 4917 CONNECTED ARCH 4917 0 0 0 0
0 DGRD 4921 ALLOCATED N/A N/A 0 0 0 0
0 DGRD 4927 ALLOCATED N/A N/A 0 0 0 0
0 ARCH 4937 CONNECTED ARCH 4937 0 0 0 0
0 ARCH 4945 CONNECTED ARCH 4945 0 0 0 0
0 ARCH 4952 CONNECTED ARCH 4952 0 0 0 0
1 RFS 6728 IDLE Archival 1412 0 0 0 0
1 RFS 6730 IDLE Archival 37602 0 0 0 0
1 RFS 6743 IDLE LGWR 73139 74 329474 0 0
2 RFS 6749 RECEIVING LGWR 97836 61 101874 0 0
2 MRP0 33125 APPLYING_LOG N/A N/A 61 101873 5 5
17 rows selected.
SQL> select inst_id,name,value,time_computed,DATUM_TIME,sysdate from gv$dataguard_stats order by inst_id;
ID NAME VALUE TIME_COMPUTED LAST_RECEIVED_TIME SYSDATE
--- ------------------------------ ------------------------------ -------------------- -------------------- -------------------
1 apply finish time +00 00:00:00.000 09/08/2021 17:22:01 2021-09-08 17:21:59
apply lag +00 00:00:00 09/08/2021 17:22:01 09/08/2021 17:21:59 2021-09-08 17:21:59
transport lag +00 00:00:00 09/08/2021 17:22:01 09/08/2021 17:21:59 2021-09-08 17:21:59
estimated startup time 42 09/08/2021 17:22:01 2021-09-08 17:21:59
2 apply finish time 09/08/2021 17:22:00 2021-09-08 17:21:59
apply lag 09/08/2021 17:22:00 2021-09-08 17:21:59
transport lag +00 01:33:04 09/08/2021 17:22:00 09/08/2021 17:21:58 2021-09-08 17:21:59
estimated startup time 46 09/08/2021 17:22:00 2021-09-08 17:21:59
8 rows selected.
同步进程正常
现在启动数据库
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10456: cannot open standby database; media recovery session may be in progress
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database open read only;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
墨天轮原文链接：https://www.modb.pro/db/133259?sjhy（复制到浏览器或者点击“阅读原文”立即查看）
