Oracle 数据库完全破损/损坏对策

Block Corruption 造成的影响
行造成的直接影响

  1. 数据业务停止
  2. 数据恢复时间变长
  3. 修复工作错误,造成二次灾害
  4. 找原因的时间变长

数据坏的主要原因

并且有可能被分割的Layer风险

中数据保的机制

§ 单个系统中,考虑到了一些无法防御的的风险的机制。

–    例:因为人为错误删除数据时,在RAID结构中无法防御。

§ 复制数据中保护一致性与确实性的机制。

–    例:部分备份导致的数据完整性的欠缺。

§ 考虑到迅速切换以及确实的修复的机制。

–    例:由于灾害恢复训练不足,实际上无法切换,无法返回的备份。

了确地能提高工作的可持性需要什么?

Oracle Maximum Availability Architecture

§ Maximum Availability Architecture (MAA) 是基于oracle验证完成的高可用性的数码与成功事例的最佳实践。

§ MAA的目的

–    为了修复、查出、规避所有的停止的情况提供最优实践。

–    在样本中构成最优的高可用性的架构。

§ 不受硬件以及OS影响(不需要特定的高价的产品以及技术)

§ 马上就可以提供高可用性的解决策略(Oracle事先完成验证)

高可用性的数的最佳践。

Oracle MAA 的整体映像

Low-Cost, Integrated, Fully Active, High ROI

Oracle MAA Data Protection

Oracle Database 11g Release 2

Oracle Database
Data Protection功能

Type of Block Corruption

§ Data Block Corruption(Doc ID 840978.1)

–    Physical Block Corruption

–    Logical Block Corruption

§ Other Corruptions

–    Control file Corruption

§ Use control file mirror & Copy

–    Redo Corruption

§ ASM Mirroring / Use multiplexed log file

–    Dictionary Corruption(Doc ID 136697.1)

Doc ID 1088018.1 Master Note for Handling Oracle Database Corruption

KROWN#152523 [Master Notes] Corruption()

Data Block Corruption

§ 物理性的块内数据破损状态的块

–    破损例

•          Block Header不正确

•          Block Header与Footer信息不一致

•         数据缺失

•          Block配置地点不正确

•          0隐藏的Block

Physical Block Corruptions

Data Block Corruption

§ Block中结构发生理论破损的状态的块

–    物理性(Block Header以及Footer的信息、Checksum的计算结果)正确

–    破损例

•          行碎片的开始与结束位置不在块内。

•          行碎片直接发生重叠

•          锁定行碎片的ITL编号不正确

•          ITL展示的锁定中的行碎片的数量与实际不一致

•          Block中空白区域的尺寸不正确

•          Lost Write

Logical Block Corruptions

Oracle Database中最适合的破损检测

§ Oracle Database的Block并不是单独的bit的罗列,
明确地事先定义过的结构

à 正是有理解了Block的结构的Oracle Database,可以检测
Physical Corruption以及Logical Corruption。

à 并且,通过同时使用Oracle DatabaseTechnology,可以提高检测水平

–    OS、文件系统以及存储中,仅仅是和命令一样对块进行I/O,但无法判断块的结构作为一个数据块来说是否正确。Exadata Cell Storage Serverと、H.A.R.D Initiative 是可以检测的

Data Block Format

Oracle DatabaseData Protection

§ 控制检测范围、水平、破损类型的初始化参数

–    DB_BLOCK_CHECKSUM

–    DB_BLOCK_CHECKING

–    DB_LOST_WRITE_PROTECT

§ 定期检测功能

–    Oracle Recovery Manager(CHECK LOGICAL句 / VALIDATE 命令)

–    SQL> ANALYZE TABLE文(VALIDATE STRUCTURE CASCADE 选项)

提高检测水平的功能

DB_BLOCK_CHECKSUM

§ 利用Data Block中的Checksum的Physical Corruption检测的机制

–    向Disk写入Block之前

§ 将DBWR以及Direct Load的服务器进程、Checksum(从Block中所有数据为基础来计算出的数值)储存到Block Header之中。

–    从Disk中读出Block后

§ 读出Block的进程将重新计算的Checksum与储存到Block Header中的Checksum进行比较验证。

à 如果Checksum不一致为块内数据可能会可能判断Physical Block Corruption以及生了

概要

DB_BLOCK_CHECKSUM

中的每个操作

DB_BLOCK_CHECKSUM

§ 请注意设定值的不同造成的操作的不同

–    DB_BLOCK_CHECKSUM=TYPICAL

•          由于服务器进程的Block更新之后,Checksum为0

•          DBWR在向Disk写入时,计算Checksum再嵌入

à 每次更新,因不会Checksum而高效化

–    DB_BLOCK_CHECKSUM=FULL

•          由于服务器进程的Block更新之后,计算Checksum再嵌入

•          DBWR在向Disk写入时, 验证Checksum

à可以验证内存上的Block Corruption

Buffer Cache上被更新Data Block
Checksum
嵌入

DB_BLOCK_CHECKSUM

§ 每次发行时,请注意其中不同的操作

–    Release 11.1以降では、Redo BlockのChecksumの
将生成处理由生成了Redo的Foreground Process担当à LGWR

§ 但是,Release 11.1~11.2.0.1中,设定为FULL时,
LGWR在向磁盘写入Redo Block之前,会执行Foreground Process所生成的Checksum的完整性检查。

Redo BlockChecksum生成验证KROWN#155653

DB_BLOCK_CHECKSUM

检测出破的操作

DB_BLOCK_CHECKSUM

§ Primary Database’s Alert.log

Automatic Block Media Recovery(ABR)来自修复所参考的日志

DB_BLOCK_CHECKING

§ Buffer Cache变更Block之后,
通过检测理论性的完整性,可以检测Logical Corruption

–    即使是Checksum正确,可以检测理论性的不正确的状态。

–    变更后被标记的理由是由于DML数据更新以外,包含变更。

§ 例:伴随着DBWR的写出,变更Block Header的信息

–    不经过Buffer Cache的Direct Load Operation不在本次检测对象中

–    根据参数的设定值,可以控制检测的对象以及水平

概要

DB_BLOCK_CHECKING

§ 上位设定值包含下位设定值的检测

–     比如,「LOW」=OFF检查 + 所有的BlockBlock Header Check

 

 

 

 

 

 

–     基本上,Buffer Cache上的Block内容在变更后会执行检测,但
Block Header Check是RAC的实例之间的Block在传送后也会被执行

的操作

DB_BLOCK_CHECKING

–     包含没有commit的redo,发生错误之前的Block的状态

à 同一继续进行事的可能

检测出破后的操作DiskBlock是正常的情况

DB_BLOCK_CHECKING

§ Oracle Client

§ Alert.log

检测的参考日志DiskBlock正常的情况

DB_BLOCK_CHECKING

–     即使自动修复失败,请注意成功时,只会返回同样的错误。

§  之后,重新访问block时,会发生ORA-1578 或者ORA-600

à 需要手操作 Block Media RecoveryABR不会发动

检测出破后的操作DiskBlock也破的情况

DB_BLOCK_CHECKING

§ Oracle Client

§ Alert.log

检测时的参考日志DiskBlock生破的情况

Soft Corrupt

§ 检测出破损的(Oracle的破损与认识)Block中被加上的标记

–    访问这些被标记的块时,会发生ORA-1578。

不是与Physical Corruption / Logical Corruption同列的单词

DB_LOST_WRITE_PROTECT

§ 不管从存储装置中block的写入完成是否发出通知,实际上磁盘中没有被写入的事项。

–    因为Data Block的构造是正常的,
即使访问发生了Lost Write 的Block也没有发生错误

à 可能会有提供不正确的数据给顾客或者用风险

à 不正确的数据染可能会

§ Lost Write所影响的例子

–    不管是否有没有储备,都作为有储备来接收订单
–    不管是否接受订单都会变成没有接收订单

Lost Write是什么

DB_LOST_WRITE_PROTECT

§ Data Guard(Physical Standby Database)中检测出Lost Write的机制Primary Database中从磁盘中读出Block时,生成验证用的redo

§ Data File Number

§ Data Block AddressDBA

§ System Change NumberSCN

•          Data Guard的机制中,对Physical Standby Database传送Redo

•          比较验证Standby Database方的对象Block与Redo内的SCN

à 如果SCN不一致,可能Lost Write

概要

DB_LOST_WRITE_PROTECT

§ 需要Primary Database以及Standby Database两方面的设定

–    Primary 或者 Standby Database的两方面的定都是NONE无效

§ Primary因为没有生成验证用的redo无法用Standby来验证

§ 即使用Primary来生成Redo,用Standby也不能验证

各个的操作

DB_LOST_WRITE_PROTECT

§ 检测Lost Write的时机是?

–    从Primary Database中发生Lost Write的Block,从磁盘向Buffer读入时生成的Redo,Standby Database的MRP验证时

–         à 不是Lost WriteDisk的写入不足的瞬
  Lost WriteBlockDisk入的

 

–    特定Block中,即使发生Lost Write,只要不使用那个Block

§ 搜索结果以及更新事务都正常

§ 不正确的数据不会传染到其他的块中

Lost Write生以及检测时机不一致

DB_LOST_WRITE_PROTECT

§ 验证用redo的生成仅限于向Buffer Cache读入Block时

–    不经过Buffer Cache的Direct Path Read中,不生成验证用的Redo

 

§ 非Data Guard环境中,用TYPICAL以上的设定来生成验证用Redo

–    Media recovery可以验证Lost Write

 

§ 可以验证Standby Database生的Lost Write

–    与Primary中生成验证用redo + Standby中验证这样的功能相同

–    仅限这种情况,但也可以用ASM Mirror以及ABR来自修复(后面将讲到)

動作の補足

DB_LOST_WRITE_PROTECT

Lost Write检测的流程PrimaryLost Write的情况

DB_LOST_WRITE_PROTECT

§ Primary中发生的Lost Write在Standby中被检测出来

–    记录Standby DatabaseのAlert.log中发生的ORA-752

–    为了保护Standby Database的数据,自动停止MRP进程

§ 终止以后的Redo适用,防止不正确数据导致的数据污染

–    PRxx程的Trace File(xxx_xxx_prxx_xxx.trc)中记录了Block的详细内容

§ 访问Primary中的对象block时所生成的Redo记录的Dump

§ Standby中所保存的对象Block的Dump

–    从这些信息中,确认以后会发生Lost Write

检测Lost Write后的操作PrimaryLost Write的情况

DB_LOST_WRITE_PROTECT

Wed Oct 23 19:18:08 2013

Hex dump of (file 7, block 131) in trace file /u01/app/oracle/diag/rdbms/orcls/orcls1/trace/orcls1_pr02_1401.trc

Reading datafile ‘+DATA/orcls/datafile/lw.281.829593935’ for corruption at rdba: 0x01c00083 (file 7, block 131)

Read datafile mirror ‘DATA_0004’ (file 7, block 131) found same corrupt data (logically corrupt)

Read datafile mirror ‘DATA_0006’ (file 7, block 131) found same corrupt data (logically corrupt)

STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE

LOST A DISK WRITE OF BLOCK 131, FILE 7

NO REDO AT OR AFTER SCN 3987667 CAN BE USED FOR RECOVERY.

Recovery of Online Redo Log: Thread 1 Group 7 Seq 103 Reading mem 0

Slave exiting with ORA-752 exception

Errors in file /u01/app/oracle/diag/rdbms/orcls/orcls1/trace/orcls1_pr02_1401.trc:

ORA-00752: 由于恢复检测出数据的写入欠缺。

ORA-10567: Redo is inconsistent with data block (file# 7, block# 131, file offset is 1073152 bytes)

ORA-10564: tablespace LW

ORA-01110: 数据文件7: ‘+DATA/orcls/datafile/lw.281.829593935’

ORA-10561: block type ‘TRANSACTION MANAGED DATA BLOCK’, data object# 87637

Wed Oct 23 19:18:12 2013

Recovery Slave PR02 previously exited with exception 752

Wed Oct 23 19:18:12 2013

MRP0: Background Media Recovery terminated with error 448

Errors in file /u01/app/oracle/diag/rdbms/orcls/orcls1/trace/orcls1_pr00_1395.trc:

ORA-00448: バックグラウンド・プロセスが正常終了しました。

MRP0: Background Media Recovery process shutdown (orcls1)

Lost WriteStandby DatabaseAlert.log出的一部分摘

PrimaryLost Write的情况

 

DB_LOST_WRITE_PROTECT

Hex dump of (file 7, block 131)

Dump of memory from 0x00000000F03B0000 to 0x00000000F03B2000

0F03B0000 0000A206 01C00083 003CC55A 04010000  [……..Z.<…..]

STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE

LOST A DISK WRITE OF BLOCK 131, FILE 7

The block read on the primary had SCN 3977658 (0x0000.003cb1ba) seq 1 (0x01)

 while expected to have SCN 3982682 (0x0000.003cc55a) seq 1 (0x01)

The block was read at SCN 3987667 (0x0000.003cd8d3), BRR:

CHANGE #1 TYP:2 CLS:6 AFN:7 DBA:0x01c00083 OBJ:87637 SCN:0x0000.003cb1ba SEQ:1 OP:23.2 ENC:0 RBL:1

REDO RECORD – Thread:1 RBA: 0x000067.00000128.0010 LEN: 0x0034 VLD: 0x10

SCN: 0x0000.003cd8d3 SUBSCN:  1 10/23/2013 19:18:16

(LWN RBA: 0x000067.00000126.0010 LEN: 0003 NST: 0001 SCN: 0x0000.003cd8cf)

CHANGE #1 TYP:2 CLS:6 AFN:7 DBA:0x01c00083 OBJ:87637 SCN:0x0000.003cb1ba SEQ:1 OP:23.2 ENC:0 RBL:1

 Block Read – afn: 7 rdba: 0x01c00083 BFT:(1024,29360259) non-BFT:(7,131)

              scn: 0x0000.003cb1ba seq: 0x01

              flags: 0x00000006 ( dlog ckval )

PRxxTrace File出例Primary生了Lost Write的情况

DB_LOST_WRITE_PROTECT

Lost Write检测流程StandbyLost Write的案例

DB_LOST_WRITE_PROTECT

§ 在Standby Database检测出了 Lost Write。

§ 与Primary中发生的Lost Write不同,自动进行修复

–    Primary Database中因为保存了最新正常Block

      Data GuardAutomatic Block Media Recovery修复

–    如果自动修复的话就不会发生ORA-752(Alert.log中没有输出)

§ MRP进程正常继续运行

检测Lost Write的操作Standby生了Lost Write的情况

DB_LOST_WRITE_PROTECT

检测Lost Write后的操作总结

DB_ULTRA_SAFE Parameter

§ 通过变更DB_ULTRA_SAFE参数值,可以一起变更3个参数值

–    本参数的默认值是FALSE

–    明确地个别设定各个参数时,优先个别设定值

提高检测水平的3个参数的一致

OLTPWorkload性能

§ Exadata X2-2 Quarter Rack( 2node RAC结构)

§ Oracle Database 11g Release 11.2.0.4

§ Oracle Grid Infrastructure 11g Release 11.2.0.4

§ Exadata Storage Server Software 11g Release 11.2.3.2.1

–    Write Through Mode

验证环

OLTPWorkload性能

§ 在下面的用户脚步中反复执行泛用的SQL

WorkloadTransaction的定

OLTPWorkload性能

§ 验证变更了Transaction的比例的三个Workload

–    伴随着Test#的增加,将更新处理的比例

Transaction比例的模式

OLTPWorkload性能

§ 在前页的各个Workload中,验证下面四个设定模式

Parameter定模式

OLTPWorkload性能

検証結果) 全模式测试的吞吐量Transaction Per Sec

OLTPWorkload性能

验证结 全模式测试Response Time

OLTPWorkload性能

验证结 模式测试CPU使用率

Oracle DatabaseData Protection

§ Oracle Recovery Manager(RMAN)

–    VALIDATE评论Data File、Backup File(Image Copy / Backup Piece)的破损检查

–    CHECK LOGICAL句

§ 追加Physical Corruption的检测,检测Logical Corruption

§ 可以与BACKUP / VALIDATE / RECOVER 评论同时检测

§ ANALYZE TABLE <TableName> VALIDATE STRUCTURE CASCADE ;

–    可能检测出表与索引Block之间的不完整

提供定期破损检测的功能

RMAN> Validate Check Logical

RMAN> validate check logical datafile 18 ;

Starting validate at 28-AUG-13

using target database control file instead of recovery catalog

channel ORA_DISK_1: starting validation of datafile

channel ORA_DISK_1: specifying datafile(s) for validation

input datafile file number=00018 name=+DATA/orcl/datafile/tt.316.824637849

channel ORA_DISK_1: validation complete, elapsed time: 00:00:01

List of Datafiles

=================

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

—- —— ————– ———— ————— ———-

18   OK     1              277          320             224873829

  File Name: +DATA/orcl/datafile/tt.316.824637849

  Block Type Blocks Failing Blocks Processed

  ———- ————– —————-

  Data       0              4

  Index      0              1

  Other      0              38

Finished validate at 28-AUG-13

参考出日志

SQL> ANALYZE TABLE VALIDATE STRUCTURE CASCADE ;

–    如果发生了Physical Block Corruption,那么就会发生ORA-1578

–    如上所示,发生ORA-1499的话,表以及索引之间发生不完整的状态。

§ 需要区分到底是在那个块中发生了故障。

–    例:FULL提示,或者使用NO_INDEX提示执行全表搜索

KROWN#68739 参考出日志

Oracle Database
Data Protection

Block Corruption 造成的影响
造成的直接

ü数据损伤造成的业务停止

ü修复时间变长

ü修复工作的人为错误、二次灾害

ü探究原因的时间变长

 

à 需要快速找出故障以及行正确的修复

Oracle MAA的数据保功能一

Oracle Database 11g Release 2

Oracle MAA

主要的修复功能

Oracle ASM / Mirroring

§ 需要Normal(二重化) 以及High Redundancy(三重化)的结构

§ 检测到破损时,参考Mirror数据自动进行修复

–    对于Oracle Client(ORA错误不会返回)

–    Primary中关于发生的Lost Write,不在此次对象中

§ Standby中发生Lost Write时,使用Mirror防止误检测

§ Redo Block破损时,参考Mirror数据

–    Normal/High Redundancy的ASM Diskgroup上配置Redo Log file

§ Doc ID 1274318.1

Oracle Client对块进行自修复

Automatic Block Media Recovery

由于Active Data Guard行穿透性的修复

Automatic Block Media Recovery

§ Standby中检测出块破损是,就会用逆向ABR进行自动修复

–    对象块破损

§ Standby中的Physical Block Corruption

–    用DB_BLOCK_CHECKSUM的功能检测出的项目
–    对Soft Corrupt以及标记完成的块进行访问时,不会有任何操作
(ABR至多在标记之前进行尝试修复。)

§ Standby中发生了Lost Write的Block

–    Primary中发上来Lost Write的Block不在此次对象中
(更新不正确的块时,生成的不正确的redo是无法修复的)

操作的追加信息

Automatic Block Media Recovery

§ Primary Database’s Alert.log

检测块以及用ABR行自修复的参考日志

Oracle Recovery Manager

§ 储存修复对象块的Data File只有在ONLINE状态下才可以执行

§ Lost Write导致的块破损不在此次对象中

–    修复指定块的命令

§ 一般而言,在V$DATABASE_BLOCK_CORRUPTION视图中,指定被表示的block(检测出破损的块)(执行时也需要检测破损)

–    将在V$DATABASE_BLOCK_CORRUPTION视图中表示的视图一起修复的命令。

RECOVER命令来对块进行修复

Oracle Recovery Manager

§ 对块单位的恢复来说,需要可以Restore的正常块

–    正常块的搜索地址的优先顺序如下所示

•          Active Data GuardPhysical Standby Database

•          Flashback Log Recovery行中的Database内)

•          RMAN Image Backup Recovery行中的Database内)

–    前述都是正常的块被Restore,用自动恢复来实现最新化

–    如果块单位中无法修复时,需要用数据文件单位的恢复

才会是可以成为块单位中恢复基准的正常

Oracle Enterprise Manager Cloud Control 12c

§ 根据Database环境状况,可以简单实现最适合的恢复

–    考虑块单位中的恢复是否可能的命令

–    Oracle Enterprise Manager可以简单地执行恢复能

§ 执行例

–    在下面的Database环境中,我们将介绍用Physical Block Corruption以及
EM(Data Recovery Advisor)来修复的顺序

§ 没有Active Data Guard环境

§ 有Flashback Log(但是是过了保存期限的状态)

§ 没有RMAN Image Copy Backup

Data Recovery Advisor中自生成修复命令

Oracle Enterprise Manager Cloud Control 12c

早期掌握Incident Manager的故障

Oracle Enterprise Manager Cloud Control 12c

Data Recovery Advisor

Oracle Enterprise Manager Cloud Control 12c

§ 考虑Database环境的状况(3页之前),
判断为块单位中的恢复是不可能的

Data Recovery Advisor

Oracle Enterprise Manager Cloud Control 12c

Recovery JobAdvisor果脚步

Flashback Technology

§ Flashback Database命令

–    人为错误(删除数据以及不合适的更新处理等)可以迅速恢复

–    因为Primary中发生Lost Write了,在Data Guard中执行Fail-Over之后,
将旧Primary作为新Standby环境来迅速修复的情况

§ Flashback Log

–    执行上述的Flashback Database命令时

–    前章中介绍过的,执行RMAN主导的块单位中的Media Recovery时

Flashback Database (Flashback Log)活用例

Oracle Data Guard

§ Oracle Data GuardのPhysical Standby是完全复制Database

–    将在Primary Database中生成的Redo同样地应用于Standby中

§ Primary中的块更新处理,也适用于redo的块。

à 一定会Fail-OverDatabase

 

§ 特别是在Primary Database中发生Lost Write时有效

–    使用正常数据迅速重新展开业务

–    可以不影响正常业务来调查Lost Write发生原因

§ 原因不明时,请考虑持续使用Primary的H/W的风险

 

Physical Standby DatabaseFail-Over

Oracle Data Guard

§ 从Lost Write检测开始到Fail-Over为止,被执行的事务会失去

–    Primary是Standby中检测出Lost Write也继续运行

à 由于业务事务,发生新变更的状况

à 然也有正确的更,但也混合了一些使用了Lost WriteBlock

–    Standby为了防止数据污染,检出以后的redo适用停止了。

–         à 重要的是如何迅速停止PrimaryFail-Over

  à Release 11.2.0.4以后
追加Data Guard BrokerPrimary Lost Write Action Property
检测Lost Write事可以自动对PrimaryABORT

检测Lost WriteFail-Over需要考的事情1

Oracle Data Guard

§ Fail-Over之后,Data Guard结构崩溃的状态

–    因为旧Primary与新Primary(原Standby)是在不同的道路上前进

à 需要Standby Database重新制成Primary Database

§ 重新制成的方法

检测Lost WriteFail-Over需要考的事情2

Oracles Data Protection
Conclusion

Data Protection

Oracle Database 11g Release 2

Data Protection

3个初始化参数的检测操作以及修复方法的概要

Conclusion
Data Protection

Oracle Database 可以提供保护数据的高可用性的解决方法。

l DB_ULTRA_SAFE Parameter

l Oracle Data Guard

l Oracle Recovery Manager

 Oracle Enterprise Manager


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *