Block Corruption造成的影响对商业运行造成的直接影响
数据损坏导致业务停止
数据恢复时间变长
修复工作发生错误，造成二次灾害
寻找原因的时间变长
数据损坏的主要原因
复杂并且有可能被分割的Layer的风险
系统中数据保护的机制
§ 单个系统中，考虑到了一些无法防御的的风险的机制。
– 例：因为人为错误删除数据时，在RAID结构中无法防御。
§ 复制数据中保护一致性与确实性的机制。
– 例：部分备份导致的数据完整性的欠缺。
§ 考虑到迅速切换以及确实的修复的机制。
– 例：由于灾害恢复训练不足，实际上无法切换，无法返回的备份。
为了确实地能提高工作的可持续性需要什么？
Oracle Maximum Availability Architecture
§ Maximum Availability Architecture (MAA) 是基于oracle验证完成的高可用性的数码与成功事例的最佳实践。
§ MAA的目的
– 为了修复、查出、规避所有的停止的情况提供最优实践。
– 在样本中构成最优的高可用性的架构。
§ 不受硬件以及OS影响(不需要特定的高价的产品以及技术)
§ 马上就可以提供高可用性的解决策略(Oracle事先完成验证)
高可用性的数码的最佳实践。
OracleMAA 的整体映像
Low-Cost, Integrated, Fully Active, High ROI
OracleMAA の Data Protection
Oracle Database 11gRelease 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 Database的各Technology，可以提高检测水平
– OS、文件系统以及存储中，仅仅是和命令一样对块进行I/O，但无法判断块的结构作为一个数据块来说是否正确。Exadata Cell Storage Serverと、H.A.R.D Initiative 是可以检测的
Data Block Format
Oracle DatabaseのData 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 Block进行Checksum的生成与验证(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」的检查 + 所有的Block的Block Header Check
– 基本上，Buffer Cache上的Block内容在变更后会执行检测，但
Block Header Check是RAC的实例之间的Block在传送后也会被执行
设定值的操作
DB_BLOCK_CHECKING
– 包含没有commit的redo，发生错误之前的Block的状态
à 同一会话中继续进行事务的可能
检测出破损后的操作(Disk上的Block是正常的情况)
DB_BLOCK_CHECKING
§ Oracle Client
§ Alert.log
检测出时的参考日志(Disk上的Block正常的情况)
DB_BLOCK_CHECKING
– 即使自动修复失败，请注意成功时，只会返回同样的错误。
§ 之后，重新访问block时，会发生ORA-1578 或者ORA-600
à 需要手动操作 Block Media Recovery(ABR不会发动)
检测出破损后的操作(Disk上的Block也破损的情况)
DB_BLOCK_CHECKING
§ Oracle Client
§ Alert.log
检测时的参考日志(Disk上的Blockも发生破损的情况)
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 Address(DBA)
§ System Change Number(SCN)
• 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 Write时(对Disk的写入不足的瞬间)将发生Lost Write的Block从Disk读入的时机
– 特定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检测的流程(Primary中发生Lost 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后的操作(Primary中发生Lost 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 Write检出时的Standby Database的Alert.log输出的一部分摘选
(Primary中发生Lost 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.003cd8d3SUBSCN: 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 )
续) PRxx的Trace File输出例(Primary中发生了Lost Write的情况)
DB_LOST_WRITE_PROTECT
Lost Write检测流程(Standby中发生Lost Write的案例)
DB_LOST_WRITE_PROTECT
§ 在Standby Database检测出了 Lost Write。
§ 与Primary中发生的Lost Write不同，自动进行修复
– Primary Database中因为保存了最新的正常Block
用Data Guard的Automatic 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个参数的一致设定
OLTP系的Workload中性能比较
§ 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
验证环境
OLTP系的Workload中性能比较
§ 在下面的用户脚步中反复执行泛用的SQL
Workload与Transaction的定义
OLTP系的Workload中性能比较
§ 验证变更了Transaction的比例的三个Workload
– 伴随着Test#的增加，将更新处理的比例
Transaction比例的模式
OLTP系的Workload中性能比较
§ 在前页的各个Workload中，验证下面四个设定模式
Parameter的设定模式
OLTP系的Workload中性能比较
検証結果) 全模式测试的吞吐量(Transaction Per Sec)
OLTP系的Workload中性能比较
验证结果) 全模式测试的Response Time
OLTP系的Workload中性能比较
验证结果) 全模式测试的CPU使用率
Oracle DatabaseのData 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 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 CorruptEmpty 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 Guard的Physical 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 Job的发行(执行Advisor的结果脚步)
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-Over的Database环境
§ 特别是在Primary Database中发生Lost Write时有效
– 使用正常数据迅速重新展开业务
– 可以不影响正常业务来调查Lost Write发生原因
§ 原因不明时，请考虑持续使用Primary的H/W的风险
对Physical Standby Database的Fail-Over
Oracle Data Guard
§ 从Lost Write检测开始到Fail-Over为止，被执行的事务会失去
– Primary是Standby中检测出Lost Write也继续运行
à 由于业务事务，发生新变更的状况
à 虽然也有正确的变更，但也混合了一些使用了Lost Write的Block的变更
– Standby为了防止数据污染，检出以后的redo适用停止了。
– à 重要的是如何迅速停止Primary仅限Fail-Over
à Release 11.2.0.4以后，追加Data Guard Broker的Primary Lost Write Action Property检测出Lost Write事可以自动对Primary进行ABORT
检测出Lost Write后Fail-Over时需要考虑的事情(1)
Oracle Data Guard
§ Fail-Over之后，Data Guard结构崩溃的状态
– 因为旧Primary与新Primary(原Standby)是在不同的道路上前进
à需要对新Standby Database重新制成旧Primary Database
§ 重新制成的方法
检测出Lost Write后Fail-Over时需要考虑的事情(2)
Oracle’s Data ProtectionConclusion
Data Protection
Oracle Database 11g Release 2
Data Protection
3个初始化参数的检测操作以及修复方法的概要
ConclusionData Protection
Oracle Database 可以提供保护数据的高可用性的解决方法。
l DB_ULTRA_SAFE Parameter
l Oracle Data Guard
l Oracle Recovery Manager
Oracle Enterprise Manager
扫一扫
2245
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
