|
数据由Oracle写入，并在到达磁盘之前被操作系统或硬件组件干预破坏。这些组件可能包括操作系统，文件系统，卷管理器，设备驱动程序，主机总线适配器和SAN交换结构。虽然Oracle可以在读取数据时检测到损坏，但Oracle可能会在几天或几个月后才读取数据。到那时，用于恢复数据的良好备份可能不再可用。
将块写入不正确的位置
Oracle向磁盘上的特定位置发出写入。不知何故，操作系统或存储系统将块写入错误的位置。这可能导致两个损坏：破坏磁盘上的有效数据并丢失已提交事务中的数据。
Oracle以外的程序对Oracle数据的错误写入
Oracle数据文件可能被非Oracle应用程序覆盖。非Oracle进程或程序可能会意外覆盖Oracle数据文件的内容。这可能是由于应用程序软件，操作系统中的错误或人为错误（例如，意外地将正常操作系统文件复制到Oracle数据文件上）。
损坏的第三方备份
将备份复制到磁带时可能会发生数据损坏。这种类型的损坏特别有害，因为备份用于修复数据损坏。因此，如果备份也已损坏，则无法恢复任何丢失的数据。对于第三方备份尤其如此（其中磁盘存储单元直接将数据复制到备份设备而不通过Oracle。）
可能的HARD检查
在实现Oracle HARD功能的存储系统中，Oracle服务器可以通过大量检查来验证Oracle块结构，块完整性和块位置。如果块在写入时未通过验证，则存储器拒绝写入，从而保护数据的完整性。在系统管理操作期间也可以选择性地禁用HARD验证检查，这可能会暂时使数据处于不一致状态。
关于这里描述的一种情形，让我想到在2010年我帮助用户进行恢复的一个案例，当时记录在博客上，原文:
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'
- ^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
如此少见的案例，在此与大家分享。 （编辑：衡阳站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
