|
数据由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
云云少见的案例，在此与各人分享。 （编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
