ORA-600 [3020]解决方法

本文记录了一次因服务器突然掉电导致Oracle 10g数据库无法启动的问题处理过程。通过详细的错误日志分析、坏块定位及恢复操作,最终实现了数据库的成功启动。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

http://blog.chinaunix.net/u/7121/showart_415391.html

 

 

本文来自网络; http://blog.chinaunix.net/u/7121/showart_415391.html

 

 

作者:olivenan@hotmail.com
转载请注意保留本文地址与作者署名,谢谢。
由于服务器突然掉电,重启机器后发现数据库无法启动。
数据库版本 oracle10201,OS REDHAT AS4
数据库无归档,无备份
一、查看错误
查看报警日志错误如下:
Errors in file /u01/app/oracle/admin/monitor/bdump/monitorbj6_p001_9216.trc:
ORA-00600: internal error code, arguments: [3020], [5], [145802], [21117322], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 5, block# 145802)
ORA-10564: tablespace BWMONITOR
ORA-01110: data file 5: '/data/oradata/monitor/bwmonitor/bwmonitor01.dbf'
ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK'

[root@CCN-BJ-6-579 ~]# su - oracle
[oracle@CCN-BJ-6-579 ~]$ sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.1.0 - Production on Sun Nov 4 10:30:04 2007
Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> select open_mode from v$database;
OPEN_MODE
----------
MOUNTED
尝试打开数据库
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 2 needs media recovery
ORA-01110: data file 2: '/data/oradata/monitor/undotbs01.dbf'

SQL> recover datafile 2;
Media recovery complete.
SQL> alter database open; 
alter database open
*
ERROR at line 1:
ORA-01172: recovery of thread 1 stuck at block 145802 of file 5
ORA-01151: use media recovery to recover block, restore backup if needed

SQL> select file#,name from v$datafile where file#=5;

     FILE# NAME
------------------------------------------------------------
  5 /data/oradata/monitor/bwmonitor/bwmonitor01.dbf

1 rows selected.
SQL> recover datafile 5;
ORA-00283: recovery session canceled due to errors
ORA-12801: error signaled in parallel query server P001
ORA-00600: internal error code, arguments: [3020], [5], [145802], [21117322],
[], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 5, block# 145802)
ORA-10564: tablespace BWMONITOR
ORA-01110: data file 5: '/data/oradata/monitor/bwmonitor/bwmonitor01.dbf'
ORA-10560: block type 'FIRST L
使用dbv查看坏块
[oracle@CCN-BJ-6-579 bdump]$ dbv file=/data/oradata/monitor/bwmonitor/bwmonitor01.dbf blocksize=8192
DBVERIFY: Release 10.2.0.1.0 - Production on Sun Nov 4 10:47:56 2007
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
DBVERIFY - Verification starting : FILE = /data/oradata/monitor/bwmonitor/bwmonitor01.dbf
Page 128843 is influx - most likely media corrupt
Corrupt block relative dba: 0x0141f74b (file 5, block 128843)
Fractured block found during dbv:
Data in bad block:
 type: 6 format: 2 rdba: 0x0141f74b
 last change scn: 0x0000.14e1187e seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xbc660601
 check value in block header: 0x7cba
 computed block checksum: 0x54ae
Page 128851 is influx - most likely media corrupt
Corrupt block relative dba: 0x0141f753 (file 5, block 128851)
Fractured block found during dbv:
Data in bad block:
 type: 6 format: 2 rdba: 0x0141f753
 last change scn: 0x0000.14e0bc66 seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x187e0601
 check value in block header: 0x1e80
 computed block checksum: 0x1d10

DBV-00200: Block, dba 21108455, already marked corrupted
DBV-00200: Block, dba 21108463, already marked corrupted
DBV-00200: Block, dba 21108471, already marked corrupted
DBV-00200: Block, dba 21108479, already marked corrupted
Page 136967 is influx - most likely media corrupt
Corrupt block relative dba: 0x01421707 (file 5, block 136967)
Fractured block found during dbv:
Data in bad block:
 type: 6 format: 2 rdba: 0x01421707
 last change scn: 0x0000.14e0f557 seq: 0x2 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x2b38061b
 check value in block header: 0x4aaf
 computed block checksum: 0x3984

DBV-00200: Block, dba 21113354, already marked corrupted
DBV-00200: Block, dba 21113418, already marked corrupted
Block Checking: DBA = 21113419, Block Type = KTB-managed data block
data header at 0xb7f27264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141899 failed with check code 6101
Block Checking: DBA = 21113420, Block Type = KTB-managed data block
data header at 0xb7f29264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141900 failed with check code 6101
Block Checking: DBA = 21113421, Block Type = KTB-managed data block
data header at 0xb7f2b264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141901 failed with check code 6101
Block Checking: DBA = 21113422, Block Type = KTB-managed data block
data header at 0xb7f2d264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=1   ktbbhitc=2
Page 141902 failed with check code 6101
Block Checking: DBA = 21113423, Block Type = KTB-managed data block
data header at 0xb7f2f264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141903 failed with check code 6101
Block Checking: DBA = 21113424, Block Type = KTB-managed data block
data header at 0xb7f31264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141904 failed with check code 6101
Block Checking: DBA = 21113425, Block Type = KTB-managed data block
data header at 0xb7f33264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141905 failed with check code 6101
DBV-00200: Block, dba 21113426, already marked corrupted
DBV-00200: Block, dba 21113434, already marked corrupted
Block Checking: DBA = 21113435, Block Type = KTB-managed data block
data header at 0xb7f47264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141915 failed with check code 6101
Block Checking: DBA = 21113436, Block Type = KTB-managed data block
data header at 0xb7f49264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141916 failed with check code 6101
Block Checking: DBA = 21113437, Block Type = KTB-managed data block
data header at 0xb7f4b264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141917 failed with check code 6101
Block Checking: DBA = 21113438, Block Type = KTB-managed data block
data header at 0xb7f4d264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141918 failed with check code 6101
Block Checking: DBA = 21113439, Block Type = KTB-managed data block
data header at 0xb7f4f264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=1   ktbbhitc=2
Page 141919 failed with check code 6101
Block Checking: DBA = 21113440, Block Type = KTB-managed data block
data header at 0xb7f51264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141920 failed with check code 6101
Block Checking: DBA = 21113441, Block Type = KTB-managed data block
data header at 0xb7f53264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141921 failed with check code 6101
DBV-00200: Block, dba 21113442, already marked corrupted
DBV-00200: Block, dba 21113450, already marked corrupted
Block Checking: DBA = 21113451, Block Type = KTB-managed data block
data header at 0xb7f67264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=1   ktbbhitc=2
Page 141931 failed with check code 6101
Block Checking: DBA = 21113452, Block Type = KTB-managed data block
data header at 0xb7f69264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141932 failed with check code 6101
Block Checking: DBA = 21113453, Block Type = KTB-managed data block
data header at 0xb7f6b264
kdbchk: row locked by non-existent transaction
        table=0   slot=0
        lockid=2   ktbbhitc=2
Page 141933 failed with check code 6101

DBVERIFY - Verification complete
Total Pages Examined         : 384000
Total Pages Processed (Data) : 118235
Total Pages Failing   (Data) : 17
Total Pages Processed (Index): 37073
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 1431
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 227258
Total Pages Marked Corrupt   : 13
Total Pages Influx           : 3
Highest block SCN            : 350302023 (0.350302023)
[oracle@CCN-BJ-6-579 bdump]$

Alter Database Backup Controlfile to Trace;

二、根据metalink提供解决方法进行恢复。
metalink查找解决方案
https://metalink.oracle.com/metalink/plsql/f?
p=130:14:8927158941743069727::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,361172.1,1,1,1,helvetica
Subject:  Resolving ORA-600[3020] Raised During Recovery
Doc ID:  Note:361172.1
由于是无归档,无备份,只好死马当活马医。
SQL> recover database test;
ORA-10586: Test recovery had to corrupt 1 data block in order to proceed
ORA-10573: Test recovery tested redo from change 350296383 to 350302447
ORA-10570: Test recovery complete

SQL> recover database allow 1 corruption;
Media recovery complete.
SQL> recover database test;
ORA-10572: Test recovery canceled due to errors
ORA-00264: no recovery required

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

SQL> conn /as sysdba
Connected to an idle instance.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
 
SQL> startup
ORACLE instance started.
Total System Global Area 1241513984 bytes
Fixed Size                  1219136 bytes
Variable Size             134219200 bytes
Database Buffers         1090519040 bytes
Redo Buffers               15556608 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
三、修复错误 ORA-600 [3705]
查看报警日志,错误变为
Errors in file /u01/app/oracle/admin/monitor/bdump/monitorbj6_lgwr_9651.trc:
ORA-00600: internal error code, arguments: [3705], [1], [2], [2], [2], [], [], []
metalink查找 ora-600 3705解决方案
https://metalink.oracle.com/metalink/plsql/f?
p=130:14:8927158941743069727::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,1054592.6,1,1,1,helvetica
Subject:  ORA-449 AND ORA-600[3705] WHEN TRYING TO OPEN DATABASE
Doc ID:  Note:1054592.6

SQL> conn /as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1241513984 bytes
Fixed Size                  1219136 bytes
Variable Size             134219200 bytes
Database Buffers         1090519040 bytes
Redo Buffers               15556608 bytes
Database mounted.
创建控制文件备份
SQL> Alter Database Backup Controlfile to Trace;
Database altered.
SQL> select d.value || '/' || lower(rtrim(i.instance, chr(0))) || '_ora_' ||
  2         p.SPID || '.trc'
  3    from (select p.SPID
  4            from v$mystat m, v$session s, v$process p
  5           where m.STATISTIC# = 1
  6             and s.SID = m.SID
  7             and p.ADDR = s.PADDR) p,
  8         (select t.INSTANCE
  9            from v$thread t, v$parameter v
 10           where v.name = 'thread'
 11             and (v.VALUE = 0 or t.THREAD# = to_number(v.VALUE))) i,
 12         (select value from v$parameter where name = 'user_dump_dest') d
 13  ;
D.VALUE||'/'||LOWER(RTRIM(I.INSTANCE,CHR(0)))||'_ORA_'||P.SPID||'.TRC'
--------------------------------------------------------------------------------
/u01/app/oracle/admin/monitor/udump/monitorbj6_ora_10203.trc
创建pfile文件
SQL> create pfile='/tmp/aa.txt' from spfile;
File created.
SQL> shutdown immediate
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
以pfile方式启动到nomount状态
SQL> startup nomount pfile='/tmp/aa.txt';
ORACLE instance started.
Total System Global Area 1241513984 bytes
Fixed Size                  1219136 bytes
Variable Size             134219200 bytes
Database Buffers         1090519040 bytes
Redo Buffers               15556608 bytes
创建控制文件
SQL> CREATE CONTROLFILE REUSE DATABASE "MONITOR" NORESETLOGS  NOARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 18688
  7  LOGFILE
  8    GROUP 1 '/data/oradata/monitor/redo01.log'  SIZE 50M,
  9    GROUP 2 '/data/oradata/monitor/redo02.log'  SIZE 50M,
 10    GROUP 3 '/data/oradata/monitor/redo03.log'  SIZE 50M
 11  -- STANDBY LOGFILE
 12  DATAFILE
 13    '/data/oradata/monitor/system01.dbf',
 14    '/data/oradata/monitor/undotbs01.dbf',
 15    '/data/oradata/monitor/sysaux01.dbf',
 16    '/data/oradata/monitor/users01.dbf',
 17    '/data/oradata/monitor/bwmonitor/bwmonitor01.dbf',
 18    '/data/oradata/monitor/bwmonitor/bw_m_c_1.dbf',
 19    '/data/oradata/monitor/bwmonitor/bw_m_c_2.dbf',
 20    '/data/oradata/monitor/bwmonitor/bw_m_c_3.dbf',
 21    '/data/oradata/monitor/bwmonitor/bw_m_c_4.dbf'
 22  CHARACTER SET ZHS16GBK
 23  ;
Control file created.
SQL> select open_mode from v$database;
OPEN_MODE
----------
MOUNTED
打开数据库,提示需要进行介质恢复
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/data/oradata/monitor/system01.dbf'
执行介质恢复。
SQL> recover database;
Media recovery complete.
打开数据库
SQL> alter database open;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
----------
READ WRITE
SQL>
最后数据库成功启动。
注意数据库启动后要添加临时表空间的数据文件。

<think>根据用户提供的引用信息和之前的问题,我们继续分析Oracle Data Guard主备库归档日志传输正常但数据未同步的原因。结合引用[1][2][3][4]中的关键点,以下是核心排查方向: ### 核心原因定位(基于引用) 1. **备库日志应用(MRP)未启动**(引用[1]明确提到): - 即使日志传输正常(LNSn进程活动),若备库未启动MRP进程,则日志不会被应用到备库数据库[^1]。 - 引用[1]中操作命令: - 停止应用:`ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL` - 启动应用:`ALTER DATABASE RECOVER MANAGED STEDNBY DATABASE DISCONNECT` 2. **归档日志存在间隙(GAP)**(引用[2][3]强调): - 通过`V$ARCHIVE_GAP`视图可检查缺失的日志序列[^2][^3]。 - 即使新日志持续传输,若中间有日志丢失(如网络中断导致),备库会卡在缺失日志处停止应用。 3. **日志应用参数配置错误**(引用[4]说明传输机制): - 主库日志传输依赖LNSn进程(非LGWR直接传输)[^4],但备库需正确配置`STANDBY_FILE_MANAGEMENT`等参数才能应用日志。 4. **备库状态不兼容**(引用[1]隐含): - 物理备库需处于`MOUNT`或`READ ONLY WITH APPLY`状态(Active Data Guard)才能应用日志[^1]。 --- ### 详细排查步骤(结合引用和实战) #### 1. **确认备库日志应用状态**(关键一步) ```sql -- 检查MRP进程状态(引用[1][2]) SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('MRP0', 'MRP'); ``` - **正常状态**:`STATUS`应为`APPLYING_LOG`且`SEQUENCE#`持续增长。 - **异常处理**: - 若未返回记录,说明MRP未启动,执行: ```sql ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; ``` #### 2. **检查日志序列连续性**(引用[2][3]) ```sql -- 是否存在日志间隙(GAP) SELECT * FROM V$ARCHIVE_GAP; ``` - **输出说明**: - `THREAD#`: 线程号(RAC环境需关注) - `LOW_SEQUENCE#`/`HIGH_SEQUENCE#`: 缺失的日志序列号范围。 - **处理缺失日志**: 1. 在主库定位缺失的归档日志文件: ```sql SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=<gap_thread> AND SEQUENCE# BETWEEN <low_seq> AND <high_seq>; ``` 2. 手动复制到备库归档目录。 3. 在备库注册日志: ```sql ALTER DATABASE REGISTER PHYSICAL LOGFILE '/path/to/archive_log_<sequence#>.arc'; ``` #### 3. **验证备库数据库状态**(引用[1]) ```sql SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE; ``` - **要求状态**: - Oracle 11g+:`OPEN_MODE`应为`READ ONLY WITH APPLY`(启用Active Data Guard)。 - Oracle 10g:`OPEN_MODE`应为`MOUNTED`。 - **错误状态示例**:`OPEN_MODE=READ ONLY`但未启用应用(无`WITH APPLY`)。 - **修复命令**: ```sql -- 先取消恢复(若已启动) ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -- 重启为正确模式 ALTER DATABASE OPEN READ ONLY; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; ``` #### 4. **检查关键参数配置**(引用[3][4]) ```sql -- 备库文件自动管理(避免文件缺失导致应用失败) SHOW PARAMETER STANDBY_FILE_MANAGEMENT; -- 应为 'AUTO' -- 备库归档路径(确认与主库传输路径匹配) SHOW PARAMETER STANDBY_ARCHIVE_DEST; -- 路径需有写入权限且磁盘空间充足 ``` - **异常处理**: - 若`STANDBY_FILE_MANAGEMENT=MANUAL`,需改为`AUTO`: ```sql ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH; ``` - 若路径错误或磁盘满,调整路径或清理空间。 #### 5. **检查备库告警日志**(终极手段) ```bash # 登录备库服务器 tail -100f $ORACLE_BASE/diag/rdbms/<dbname_standby>/<instance_name>/trace/alert_<instance_name>.log ``` - **关键错误**: - `ORA-00308`: 无法打开归档日志(文件损坏或路径错误) - `ORA-19502`: 写数据文件失败(存储问题) - `ORA-600 [3020]`: 块校验错误(主备库数据文件不一致) --- ### 总结解决方案 | **原因** | **解决措施** | |-------------------------|-----------------------------------------------------------------------------| | MRP进程未启动 | 启动MRP:`ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;` | | 存在日志间隙(GAP) | 手动注册缺失日志(方法见步骤2) | | 备库状态错误 | 调整为`MOUNT`或`READ ONLY WITH APPLY`(方法见步骤3) | | 参数配置错误 | 修正`STANDBY_FILE_MANAGEMENT=AUTO`,确保归档路径有效 | | 日志/数据文件损坏 | 从主库重新传输文件或重建备库 | > **预防建议**:部署定期监控脚本,检查`V$ARCHIVE_GAP`和`V$MANAGED_STANDBY`,并配置OEM告警。 §§相关问题§§ 1. Oracle Data Guard中如何自动修复日志间隙(GAP)? 2. 如何配置Active Data Guard以实现备库实时查询? 3. 主库与备库出现数据文件不一致时如何修复? 4. 如何监控Oracle Data Guard的实时同步延迟?</think>### Oracle DG 主备库日志传输正常但数据未同步的原因排查 根据引用内容,结合 Oracle Data Guard 的核心机制,以下是数据未同步的**根本原因**和**排查步骤**: --- ### 一、核心原因分析 1. **备库日志应用未启动(MRP 进程未运行)** - 归档日志传输(由 LNSn 进程完成)正常,但日志**应用**依赖 MRP 进程[^1][^4]。 - **典型表现**: ```sql -- 查询结果 STATUS 为空或非 APPLYING_LOG SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; ``` 2. **日志序列间隙(GAP)** - 主库日志序列不连续,导致备库无法应用后续日志(即使新日志持续传输)[^2][^3]。 - **检查命令**: ```sql SELECT * FROM V$ARCHIVE_GAP; -- 显示缺失的日志序列 ``` 3. **备库状态不兼容日志应用** - Oracle 10g:备库需处于 `MOUNT` 状态才能应用日志。 - Oracle 11g+:需启用 Active Data Guard(`READ ONLY WITH APPLY`)[^1]。 - **错误状态示例**: ```sql SELECT OPEN_MODE FROM V$DATABASE; -- 返回 OPEN(非 READ ONLY WITH APPLY) ``` 4. **参数配置错误** - `STANDBY_FILE_MANAGEMENT=MANUAL`(备库无法自动管理文件)[^3] - `LOG_ARCHIVE_DEST_2` 含 `DELAY` 属性(故意延迟应用)[^1] - `STANDBY_ARCHIVE_DEST` 路径错误(日志文件无法定位)[^3] 5. **日志/数据文件损坏** - 传输的归档日志在备库损坏(如 RFS 进程写入失败)[^4] - 备库数据文件与主库不一致(如手动修改备库文件) --- ### 二、关键排查步骤 #### 1. 检查备库日志应用状态(MRP 进程) ```sql -- 确认 MRP 进程是否运行 SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; -- 若未运行,手动启动 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; ``` #### 2. 检查日志序列连续性 ```sql -- 是否存在日志间隙 SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; -- 对比主备库日志序列 SELECT MAX(SEQUENCE#) AS "主库最新序列" FROM V$ARCHIVED_LOG WHERE DEST_ID=1; SELECT MAX(SEQUENCE#) AS "备库已应用序列" FROM V$ARCHIVED_LOG WHERE APPLIED='YES'; ``` #### 3. 验证备库状态和模式 ```sql -- 检查数据库状态 SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE; -- Oracle 11g+ 修复命令(启用 Active DG) ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; ALTER DATABASE OPEN; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; ``` #### 4. 审核关键参数 ```sql -- 检查文件自动管理 SHOW PARAMETER STANDBY_FILE_MANAGEMENT; -- 需为 AUTO -- 检查备库归档路径 SHOW PARAMETER STANDBY_ARCHIVE_DEST; -- 检查延迟设置(主库执行) SHOW PARAMETER LOG_ARCHIVE_DEST_2; -- 确认无 DELAY 属性 ``` #### 5. 检查日志错误和系统资源 ```sql -- 查看同步错误(引用[2][3]) SELECT ERROR_CODE, MESSAGE FROM V$DATAGUARD_STATUS; -- 检查备库存储空间 SELECT * FROM V$RECOVERY_AREA_USAGE; -- 归档区使用率 ``` --- ### 三、解决方案总结 | **问题类型** | **解决措施** | |----------------------|-----------------------------------------------------------------------------| | MRP 进程未运行 | 启动 MRP:`ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;` | | 日志间隙(GAP) | 手动注册缺失日志:`ALTER DATABASE REGISTER PHYSICAL LOGFILE '<路径>';` | | 备库状态错误 | 重启至正确模式(`MOUNT` 或 `READ ONLY WITH APPLY`) | | 参数配置错误 | 修正参数:`ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;` | | 日志/文件损坏 | 从主库重新传输日志或重建备库 | > **预防建议**: > - 部署监控脚本定期检查 `V$MANAGED_STANDBY` 和 `V$ARCHIVE_GAP`[^2] > - 启用 Active Data Guard(11g+)避免状态冲突[^1] > - 设置 `LOG_ARCHIVE_TRACE=15` 跟踪日志传输细节 --- ### 四、相关问题 1. 如何配置 Active Data Guard 实现备库实时查询? 2. Oracle Data Guard 出现 ORA-00308 错误如何修复? 3. 如何监控 Data Guard 的实时同步延迟? 4. 主库与备库数据文件不一致时如何修复? 通过以上步骤,90% 的同步问题可快速定位。若问题仍存在,请检查备库告警日志(`alert_<SID>.log`)中的 ORA 错误[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值