链接：http://www.eygle.com/archives/2010/11/recover_archivelog_corruption.html
最近在紧急故障处理时，帮助用户恢复数据库遇到了一则罕见的归档日志损坏案例，在这里和大家分享一下，看看是否有人遇到过类似的问题。
在进行归档recover时，数据库报错，提示归档日志损坏：
***
Corrupt block seq: 37288 blocknum=1.
Bad header found during deleting archived log
Data in bad block - seq:810559520. bno:170473264. time:707406346
beg:21280 cks:21061
calculated check value: 9226
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data
***
信息比较详细，说37288号归档日志Header损坏，无法读取数据。
提一个小问题：如果你遇到了这样的错误？会怎样思考？
如果这个归档日志损坏了，其实我们仍然有办法跳过去，继续尝试恢复其他日志，但是客户数据重要，不能容忍不一致性，这时候就只能放弃部分数据，由前台重新提交数据了。这在业务上可以实现，也就不是大问题了。
好了，问题是为什么日志会损坏？是如何损坏的？
我首先要做的就是，看看日志文件的内容，通过最简单的命令将日志文件中的内容输出出来：
strings arch_1_37288_632509987.dbf > log.txt
然后检查生成的这个日志文件，我们就发现了问题。
在这个归档日志文件中，被写入了大量的跟踪文件内容，其中开头部分就是一个跟踪文件的全部信息。
这是一种我从来没有遇到过的现象，也就是说，当操作系统在写出跟踪文件时，错误的覆盖掉了已经存在的归档文件，最后导致归档日志损坏，非常奇妙，从所未见。
最后我的判断是，这个故障应当是操作系统在写出时出现了问题，存在文件的空间仍然被认为是可写的，这样就导致了写冲突，出现这类问题，应当立即检查硬件，看看是否是硬件问题导致了如此严重的异常。
Dump file /ADMIN/bdump/erp_p007_19216.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /DBMS/erp/erpdb/10g
Linux
eygle.com
2.6.9-34.ELhugemem
#1 SMP Fri Feb 24 17:04:34 EST 2006
i686
Instance name: erp
Redo thread mounted by this instance: 1
Oracle process number: 22
Unix process pid: 19216, image: oracle@eygle.com (P007)
*** SERVICE NAME:() 2010-11-10 10:37:26.247
*** SESSION ID:(2184.1) 2010-11-10 10:37:26.247
*** 2010-11-10 10:37:26.247
KCRP: blocks claimed = 61, eliminated = 0
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 61/61 = 1.0
Max compares per lookup = 0
Avg compares per lookup = 0/61 = 0.0
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 61/61 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 1426/1426 = 1.0
----------------------------------------------
\GPAYMENTdxn
AP_CHECKS
Q(xn
.1=N
\Gxn
.1=N
^0e
^0e!
^0e"
^0e#
^0e$
^0e%
^0e&
^0e'
eygle.com!/
^0e(
^0e)
^0e*
^0e+
^0e+
^0e&
^ij1
R0:b
Q(xn
PaymentsN
a'VND
Userxn
AP_INVOICE_PAYMENTS
105273
5406105305-20101020-003
3001CASH CLEARING
CREATED
Dump file /ADMIN/bdump/erp_p002_19206.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /DBMS/erp/erpdb/10g
Linux
eygle.com
2.6.9-34.ELhugemem
#1 SMP Fri Feb 24 17:04:34 EST 2006
i686
Instance name: erp
Redo thread mounted by this instance: 1
Oracle process number: 17
Unix process pid: 19206, image: oracle@eygle.com (P002)
*** SERVICE NAME:() 2010-11-10 10:37:26.263
*** SESSION ID:(2187.1) 2010-11-10 10:37:26.263
*** 2010-11-10 10:37:26.263
KCRP: blocks claimed = 84, eliminated = 0
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 84/84 = 1.0
Max compares per lookup = 0
Avg compares per lookup = 0/84 = 0.0
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 84/84 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 880/880 = 1.0
----------------------------------------------
^A&A
^1b#
^1b!
^1b"
^0e'
^Mj8
^;&3
2010PS_Legal Entity
^6&L
Eoi_VND
Quick Payment: ID=47708
Cn/a
UNSENT
^9&1
\HPAYMENT
CREATEDNAP_CHECKS
^0e)
\Hxn
Dump file /ADMIN/bdump/erp_p001_19204.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /DBMS/erp/erpdb/10g
Linux
eygle.com
2.6.9-34.ELhugemem
#1 SMP Fri Feb 24 17:04:34 EST 2006
i686
Instance name: erp
Redo thread mounted by this instance: 1
Oracle process number: 16
Unix process pid: 19204, image: oracle@eygle.com (P001)
*** SERVICE NAME:() 2010-11-10 10:37:26.372
*** SESSION ID:(2189.1) 2010-11-10 10:37:26.372
*** 2010-11-10 10:37:26.372
KCRP: blocks claimed = 132, eliminated = 0
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 132/132 = 1.0
Max compares per lookup = 0
Avg compares per lookup = 0/132 = 0.0
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 132/132 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 3219/3219 = 1.0
----------------------------------------------
^ij!
^ij$
^ij!
@e>df
>df^>df
Userxn
Chen Restaurant
300190143
CASH CLEARING
AP_CHECKS
CREATED
ACCOUNTED
^ij!
CHECK
en/a
Quick Payment: ID=47708
n/a^n/a
CHECK
Chen Restaurant
210301
5&1`
54^`
^1b$
^1b&
^1b6
^1b,
^1b-
^1b4
^1b5
^1b0
^1b2
Dump file /ADMIN/bdump/erp_p000_19202.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /DBMS/erp/erpdb/10g
Linux
eygle.com
2.6.9-34.ELhugemem
#1 SMP Fri Feb 24 17:04:34 EST 2006
i686
Instance name: erp
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 19202, image: oracle@eygle.com (P000)
*** SERVICE NAME:() 2010-11-10 10:37:26.386
*** SESSION ID:(2190.1) 2010-11-10 10:37:26.386
*** 2010-11-10 10:37:26.386
KCRP: blocks claimed = 181, eliminated = 0
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 181/181 = 1.0
Max compares per lookup = 0
Avg compares per lookup = 0/181 = 0.0
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 32768
Longest hash chain = 1
Average hash chain = 181/181 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 8629/8629 = 1.0
----------------------------------------------
^ij0
AGENT_STATUS_MARKER
^AGENTS_MARKED
R0:b
^E!
^1b
^1b
^1b!
^1b!
^1b"
^1b"
^1b#
如此少见的案例，在此与大家分享。
站内相关文章|Related Articles
帮助用户恢复数据块损坏的海量数据库
Oracle数据恢复:格式化会损坏多少数据？
Oracle数据恢复:强制Resetlogs的可能数据损失
Oracle数据恢复:格式化、ASM及字典损坏案例三则
ORA-00600 kcratr_nab_less_than_odr案例一则
分享到：
相关推荐
在Oracle数据库管理领域，当遇到一些特殊的情况时，可能需要采用非常规的方式来恢复数据库，其中一种方法就是利用BBED工具来跳过归档日志进行恢复。这种方法主要用于解决在归档日志丢失或损坏的情况下，如何尽可能地...
Oracle数据库恢复是一个复杂而关键的过程，它涉及到数据库的完整性和数据的可靠性。在数据库系统遇到各种故障，如硬件故障、软件故障、网络问题、进程崩溃或系统错误时，数据库恢复技术能够确保数据的准确性和一致性...
本测试案例将深入探讨Oracle数据库的备份与恢复技术。 首先，我们了解Oracle数据库的备份类型。Oracle支持物理备份（如使用RMAN进行的文件级或映像副本备份）和逻辑备份（如使用SQL*Plus的EXPDP和IMPDP命令进行的...
在Oracle数据库环境中，当数据文件出现错误，如损坏或丢失部分数据时，`bbed`可以作为一个有效的辅助工具来修复这些问题，尤其是在非归档日志模式下，常规的备份和恢复策略可能无法直接应用。 非归档模式的Oracle...
本篇文章将详细阐述Oracle数据库的恢复机制及其应用案例。 首先，我们要理解数据库恢复的基本概念。数据库恢复是指在遇到故障导致数据丢失或损坏时，通过一系列步骤还原数据库到一个一致性的状态。恢复过程通常包括...
【Oracle 备份与恢复...总的来说，Oracle数据库的备份和恢复是一个复杂但至关重要的过程，它涉及到多个步骤和决策，需要DBA具备深厚的Oracle知识和实践经验，以应对各种可能出现的问题，保护企业的数据资产不受损失。
- 介质恢复是处理数据文件物理损坏的一种手段，但需要有可用的备份文件或者归档日志。 - 在此案例中，尝试使用`RECOVER DATAFILE 1`等命令进行恢复，但由于缺少归档日志而失败。 - 此外，尝试使用`RECOVER ...
在Oracle数据库系统中，PL/SQL是用于编写数据库脚本和处理事务的主要工具，它在数据库恢复中扮演着重要角色。 1. **备份策略**：备份是数据库恢复的基础，常见的备份类型包括完整备份、增量备份和差异备份。完整...
本案例主要探讨了Oracle数据库的实例恢复和介质恢复，以及不同类型的不完全恢复。 首先，我们来看一下实例恢复。实例恢复主要针对的是由于系统故障、进程异常等原因导致数据库实例非正常关闭的情况。在这种情况下，...
2. 不完全恢复：若归档日志丢失或损坏，无法应用所有归档日志和联机日志中的redo条目，只能将数据库恢复到故障前的某个时间点，导致该时间点之后的数据丢失。 案例分析 假定在t1时刻对数据库进行了物理备份，数据库...
完全介质恢复需要数据库备份以及归档日志来恢复所有丢失的更改，而不完全介质恢复则允许在无法进行完全恢复或不需要时，恢复到特定的事务一致性状态。不完全恢复可以是基于撤消、时间或修改的，每种都有其特定的应用...
Oracle 数据恢复是指在数据丢失或损坏后，利用备份文件和归档日志等手段恢复数据的过程。恢复通常分为完全恢复和不完全恢复两种。 1. **完全恢复**：完全恢复是指将数据库恢复到最新状态的过程。这意味着从最近的一...
总的来说，Oracle数据库的备份与恢复是数据库管理员必备的技能之一，通过案例学习，可以深入理解恢复机制，为实际工作中的数据安全提供保障。这包括对不同故障类型的理解，合理规划备份策略，以及熟练运用恢复工具，...
本文主要探讨Oracle数据库的两种备份方法：逻辑备份和物理备份，并通过一个学校一卡通数据库的案例来具体阐述备份策略的应用。 1. 逻辑备份 Oracle的逻辑备份主要依赖于Export和Import工具，它们能够在数据库运行...