oracle事务污染,Oracle 数据库完全破损/损坏对策

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