PowerPoint 演示文稿

Transcription

1 ParnassusData 诗檀软件 Oracle 数据库修复专家 Oracle 数据库的保护之手 Oracle 数据库救援热线 : Know More about Oracle Database Block Corruption

2 古希腊的 Delphi( 世界中心 ), 屹立着 Parnassus Mount( 诗檀山 ), 山上有一座阿波罗神庙, 庙中住着女祭司 (Oracle)

3 PRM-DUL PRM-DUL 是诗檀软件自主研发的 Oracle 数据库灾难修复软件, 拥有独立的软件著作权 PRM 是基于 JAVA 语言开发的绿色工具软件, 任何能够安装 JDK 1.4 及以上版本的操作系统均可以运行 PRM, PRM 天生是跨平台的 即便数据库无法打开 (OPEN), 也能从数据文件的黑盒中将数据抽取出来 全程使用图形化界面, 无需用户对 ORACLE 数据库数据结构有深入理解, 简单易用 完美支持 ORACLE ASM 存储 PRM 免费下载地址 :

4 PRM-DUL 的适用场景 未开归档无备份情况下意外 truncate 数据表 数据字典损坏, 导致数据库无法打开 Undo/Redo 损坏, 导致数据库无法打开 丢失了 SYSTEM 表空间 ASM 下数据库无法打开 ASM diskgroup 无法 MOUNT,ASM 变成黑盒 PRM 免费下载地址 :

5 Oracle Data Block Oracle 中最小 I/O 单位 RDBMS 具体存放数据的区域 一个 Block 对应磁盘上的一定区域, 可能跨多个磁盘 微观的说, 空间分配以块为单位 数据块 数据库

6 Oracle Block 的构成 主要由 Cache 层, 事务层和数据层组成 Cache 层 事务层 数据层 Tail

7 Oracle Block 构成 Cache 层 Kcbh Cache 层包含用来检测块损坏的信息 Cache 层的 chkval_kcbh 用来确认, 上一次的写入到磁盘, 到现在读取出来磁盘上的 Block 的内容是否一致 Cache 层存放的信息 本数据块存放何种数据 type_kcbh(data,index) RDBA 和格式版本 本数据块的更新情况 几乎所有的数据块都有 Cache 层,KCBH

8 Oracle Block 构成事务层 ktbbh 在本数据块上执行着的或者执行过的事务信息 存放 SCN (System Change Number) ITL 一种事务列表 ktbbhitl 存放的数据类型 ktbbhtyp, KDDBTINDEX 代表索引,KDDBTDATA 代表数据 ktbbhflg, MSSM or ASSM, KTBFONFL or KTBFBSEG 不是每个块都有 ktbbh, 例如 Undo block 就没有 ktbbh

9 ITL(Interested Transaction List) XID:ktbitxid 事务 ID UBA: 指向事务最后一次修改对应的 Undo Flag: 是否提交了, 提交的情形 C B U T Lck: 在本数据块锁住的行数 Scn/Fsc: commit scn 或 control scn _ktbitfsc _ktbitwrp ktbitbas

10 Oracle Block 构造数据层 数据的存储信息 数据头信息 kdbh Table Direcotry kdbt, 针对簇表有多条记录 Row Directory kdbr, 记录了每一个 row piece 的块内偏移量 Row piece 数据行片, 一个 row piece 最多 255 字段, 因为 CC column count 是单字节最大 0xFF 根据存储数据类型的不同, 其结构也会有区别

11 kdbh 数据头信息 kdbhflag bit 位, KDBHFFK 0x01 Flushable Key kdbhntab Number of tables in the table index kdbhnrow Number of rows in the row index kdbhfrre first FRee Row index Entry kdbhfsbo Free Space Beginning Offset kdbhfseo Free Space Ending Offset kdbhavsp AVailable SPace in the block kdbhtosp TOtal Space that will be available

12 Table Directory kdbt kdbtoffs 对应表记录的偏移量 kdbtnrow 对应表在本块的行数 通常情况下一张表仅仅有一条 kdbt 记录 当时簇表 Cluster Table 情况下, 一个块中存放多张表记录, KDBT 中有多条记录

13 Row Directory kdbr 一个 kdbr 数组, 每一个成员为 2 个字节的 signed bytes 每一个成员代表一行数据的块内相对偏移量 相对偏移量从数据层的起始位置开始 相对偏移量 + 环境偏移量 = 块内的绝对偏移量

14 数据块的大小 默认数据块的大小取决于建库时的 DB_BLOCK_SIZE 可选项为 2k,4k,8k,16k,32k 默认数据块大小在建库后不可修改 可以混用非标准块大小的表空间, 例如 8k 默认块大小下建 16k 大小的表空间 注意 : 非官方的看法是 8k 是最稳定, 测试最多的块大小 少数情况下非 8k 的 Block Size 更容易触发部分 BUG

15 数据块的损坏 什么是 Oracle 数据块损坏? 根据不同的情况, 可以分成三种 : 物理损坏 Physical Corrupt 逻辑损坏 Logical Corrupt 写丢失 Lost Write

16 造成数据块损坏的原因 存储 / 硬盘断电, 机械老化故障 卷管理软件或文件系统 bug OS I/O API bug 人为的误操作 dd/lvm/bbed Oracle RDBMS/ASM 自身的 bug, 越来越少了

17 存储 / 硬盘故障 右图为 36 个月的硬盘留任率 一些案例 : ORA-1578 Transient Corruption Caused by Parity Error on EMC DMX4 (Doc ID ) ORA-1578 Data Block Corruptions when using EMC Storage. Blocks with 0xc9 byte (Doc ID ) Database Corruption due to Lost IO on Hitachi storage. ORA-600 [kdsgrp1] ORA ORA-1410 ORA-600 [3020] (Doc ID )

18 卷管理软件或文件系统 bug 一些案例 : ORA-354 Redo log corruption when using Xisgo Driver (Doc ID ) ORA-1578 ORA-353 ORA Corrupt blocks with zeros when filesystemio_options=setall on ext4 file system using Linux (Doc ID ) ORA-1578 Misplaced blocks against datafiles stored in NFS filers (Doc ID ) ORA-1578 ORA-354 ORA-600 [3020] Misplaced blocks by Symantec / Veritas after adding LUN (Doc ID ) ORA-1578 Block overwritten with string DiskDescription cyl alt hd sec when using Symantec / Veritas (Doc ID ) Block Corruption (ALL ZERO) detected after reclaiming space on Veritas Filesystem (Doc ID ) 遇到过的 VxCFS 问题 : 32 位指针问题导致内存泄露 卷同步存在漏洞, 将实际未完成同步的数据返回给 Oracle 使用

19 数据块损坏的影响 乐观 : 不发生显性错误, 或仅少量 SQL 报错 悲观 : 业务几乎不可用, 大量 ORA-1578 ORA-8103 ORA 错误出现, 或者数据库干脆打不开 部分数据可能丢失 数据库宕机 长时间的数据恢复流程, 带库恢复几 T 数据? 上报保监会 银监会?

20 数据块物理损坏 在读取数据块时发现, 或者通过工具 (dbv,rman) 预先发现 一般会报错 ORA-01578, 具体损坏信息在 trace 中 可能是 : 块头错乱, 块不完整,checksum 验证错误 物理损坏表现在磁盘上, 不会自动消失,checksum 要么读不出要么不对 Redo 日志流中不存在损坏, 可以通过 blockrecover 修复, 前提是有备份和归档 Corrupt Block: Header Corrupt Block: Header Corrupt Block: Header Data Footer Data Footer Data Footer Mismatch

21 数据块物理损坏 - 现象 ORA 错误被报出,alert.log 中出现相关损坏描述 : Corrupt block relative dba: 0x0380e573 (file 14, block 58739) Fractured block found during buffer read Data in bad block - type: 6 format: 2 rdba: 0x0380e573 last change scn: 0x0288.8e5a2f78 seq: 0x1 flg: 0x04 consistency value in tail: 0x 应为 0x2f check value in block header: 0x8739, computed block checksum: 0x2f00 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** Reread of rdba: 0x0380e573 (file 14, block 58739) found same corrupted data

22 ORA-1578 ORA-1578 "ORACLE data block corrupted (file # %s, block # %s)" Information about object and corruption description is found in the alert log. Normally is reported with an ORA-1110 reporting the Absolute File Number: SQL> select * from scott.case1; select * from scott.case1 * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 11, block # 34) ORA-01110: data file 6: /home/oracle/corrclass.dbf => 相对文件号 RFN => 绝对文件号 AFN

23 块断裂 Fractured Block Corrupt block relative dba: 0x0380e573 (file 14, block 58739) Fractured block found during buffer read Data in bad block - type: 6 format: 2 rdba: 0x0380e573 last change scn: 0x0288.8e5a2f78 seq: 0x1 flg: 0x04 consistency value in tail: 0x check value in block header: 0x8739, computed block checksum: 0x2f00 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** Reread of rdba: 0x0380e573 (file 14, block 58739) found same corrupted data

24 错误的校验码 bad checksum Corrupt block relative dba: 0x0380a58f (file 14, block 42383) Bad check value found during buffer read Data in bad block - type: 6 format: 2 rdba: 0x0380a58f last change scn: 0x c5ee seq: 0x1 flg: 0x06 consistency value in tail: 0xc5ee0601 check value in block header: 0x68a7, computed block checksum: 0x2f00 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** Reread of rdba: 0x0380a58f (file 14, block 42383) found same corrupted data

25 损坏的块头 Bad header Corrupt block relative dba: 0x0d805a89 (file 54, block 23177) Bad header found during buffer read Data in bad block - type: 6 format: 2 rdba: 0x0d805b08 last change scn: 0x dc08e3 seq: 0x1 flg: 0x04 consistency value in tail: 0x08e30601 check value in block header: 0x2a6e, computed block checksum: 0x0 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** Reread of rdba: 0x0d805a89 (file 54, block 23177) found valid data

26 数据块损坏检测参数 DB_BLOCK_CHECKSUM 三种不同作用的检测保护机制, 但都不负责修复现有问题 DB_BLOCK_CHECKSUM 负责控制块的 cache 层的 chkval_kcbh 是否在块被写出时计算并写入到磁盘中 BBED> sum Check value for File 0, Block 500: current = 0x5327, required = 0x5327 BBED> p chkval_kcbh ub2 0x5327

27 DB_BLOCK_CHECKSUM 数据块从 buffer cache 中写出时 Oracle 实例 Buffer バッファ Cache キャッシュ DBWn 计算 checksum 即 chkval_kcbh, 并写出

28 DB_BLOCK_CHECKSUM 数据块被从磁盘读取到 buffer cache 中时 Oracle 实例 Buffer バッファ Cache キャッシュ 验证块内的 checksum 和计算值是否一样

29 DB_BLOCK_CHECKSUM 检验发现 checksum 和计算值不一样 Oracle 实例 检测到物理损坏 Buffer バッファ Cache キャッシュ 验证块内的 checksum 和计算值是否一样 发现损坏 物理损坏 ORA 报错

30 DB_BLOCK_CHECKSUM 通过一个校验值来检测出块损坏 : 由于断电或硬盘故障, 一个块仅写出了一半或更少内容, 此时 chkval 必然不等于整个块 checksum 从写出到下一次读取的时间中硬盘发生了故障, 块中的部分内容不正确 DB_BLOCK_CHECKSUM 控制是否计算和写 chkval_kcbh, 如果不写则 chkval_kcbh 为 0000, 读取时也不做检测

31 DB_BLOCK_CHECKSUM 默认值 TRUE(10g),Typical(11g) 当块要写出到磁盘时,DBWn 从块中的每一个字节计算 checksum 并存放到块头的 chkval_kcbh 有了 checksum 后,Oracle 能判断由底层磁盘存储系统引起的损坏 每一次数据块从磁盘中被读取都会检查 checksum 更新过程如下 : 服务进程修改数据块,checksum 被置 0 DBW 负责计算 checksum 并写出块 在上述改数据块和 checksum 之间存在时间,DBW 不清楚这中间的问题, 也不负责

32 db_block_checksum=true Buffer cache Block#=X Chkval=0 Block#=X Chkval=A DBWn later calculates a new checksum, stores it in block header and writes the block Block#=X Chkval=B Server process reads block X. Checksum is calculated and compared with the one in the block header. Block is modified and checksum=0 Datafiles

33 db_block_checksum=full Buffer cache Block#=X Chkval=B Block#=X Chkval=A DBWn later checks the checksum and writes the block Block#=X Chkval=B Server process reads block X. Checksum is calculated and compared with the one in the block header. Block is modified and new checksum is calculated =B Datafiles

34 db_block_checksum=false db_block_checksum=false, 那么仅 SYSTEM 表空间上的 block 还做 checksum _db_always_check_system_ts Always perform block check and checksum for System tablespace, 该隐藏参数控制是否对 SYSTEM 表空间做 checksum

35 数据块逻辑损坏 存在 block header 正常 (checksum 也无问题 ), 而 header 以下部分正常的可能性, 这种现象称作逻辑损坏 logical block corruption, 常会引起 ora 错误, 例如 : 行覆盖, 错乱长度的错乱行 块内的空间管理结构错乱 具有正常 checksum 的损坏块 Header Invalid Content Footer

36 数据块逻辑损坏 若发现逻辑损坏则会报内部错误并写到 alert.log 中, 具体需要看对应的 ORA-00600/07445 trace Dbv 能检测到部分形式的逻辑损坏, 例如 : 行被不存在的事务锁住,ora-00600[4512] 可用空间 + 未用空间大于 block size 不正确的可用空间 若启用 db_block_checking, 则可能触发发生 ORA-600 [kddummy_blkchk], ORA-600 [kdblkcheckerror] 损坏也可能是由于 redo 流的不一致导致在 db recover 时被引入 若未启用 db_block_checking 则较难了解到损坏何时被引入, 这是因为 redo 不一致可能在错误报出前很久就发生了

37 数据块逻辑损坏 例子 : Bug Index coalesce may generate invalid redo if blocks in the buffer cache are invalid/corrupted 若未启用 db_block_checking,buffer cache 中的 block 出现讹误, 则索引 index coalesce 操作可能生成错乱的 redo 数据 对于 oracle 检测到的逻辑损坏, 绝大多数情况可以从 ORA-600 [kddummy_blkchk] (Doc ID ) 中找到 逻辑讹误也可能由于非 Oracle 的进程或硬件意外写入到 buffer cache 内存中引发

38 Buffer cache 中的块逻辑损坏 这种仅发生在 buffer cache 中的块逻辑损坏, 可能还没有落实到磁盘上 若 db_block_checking=false & db_block_checksum!=full, 且该块 header & footer 是正常的, 那么该已经损坏的 buffer 将写入到磁盘上 若块的 header/footer 并不正常, 那么 DBWR 进程写出时会报错 ORA-00600[kcbzfb_1]; 并会引起实例崩溃, 来避免写出损坏块到磁盘 写出过程中的块损坏, Bug Block corrupted during write not noticed (Doc ID ). ORA-600 [kcbbvr_verify_disk_blk_1].

39 Buffer cache 中的块逻辑损坏 SR: ORA-600 [2662] and ora-600 [kcbzpbuf_1] caused database to crash 多次 ORA 报错引起实例崩溃, 多个 buffer 引起 ORA [kcbzfb_1]. 就 trace 文件看似乎是由于 buffer cache 讹误内存讹误引起 若没有设置 db_block_checksum=full, 则部分损坏块将可能写出到磁盘上 若没有启用 db_block_checking, 则可能引起进程污染 buffer cache 中的 block

40 Buffer cache 中的块逻辑损坏 Bug bad check value found during preparing block for write for 32k block Bug ORA-600 [kcbzpbuf_1] block corruption in buffer cache for 32k block size / ORA-7445 [kdb4cpss] by cache protect. db_block_checksum=full 避免损坏污染到磁盘上 Oracle 检测代码, 参见文档 ORA-600 [kcbzpbuf_1] (Doc ID )

41 数据块损坏检测参数 DB_BLOCK_CHECKING 对内存中的块内容做修改前, 是否对块做检测 考虑这样一个问题, 假设使用 FPE 工具 ( 一种古老的游戏内存修改工具 ) 修改了内存中一个块的内容, 这意味着这个块已经错了 然后 Oracle 不做任何检测继续在这个块上做修改, 那么就是错上加错了 DB_BLOCK_CHECKING 的义务

42 DB_BLOCK_CHECKING 当数据块在内存中被修改时, 检测块的事务层和数据层的完整性 Buffer Cache 数据块检测 数据块的更新 Oracle 实例

43 DB_BLOCK_CHECKING 对于更新过程中检测发现问题时, 阻止在这个缓存块中继续更新和回滚, 直接报 ORA 错误 Oracle 实例 Buffer バッファ Cache キャッシュ 数据块检测 REDO ログ 发现问题 数据块的更新 ORA-600 报错

44 DB_BLOCK_CHECKING Oracle 实例 Buffer バッファ Cache キャッシュ REDO 日志 从磁盘中读取一个正常的数据块

45 DB_BLOCK_CHECKING Oracle 实例 Buffer バッファ Cache キャッシュ REDO 应用 REDO 应用 REDO 到故障点

46 DB_BLOCK_CHECKING 对于仅仅发生在 buffer cache 里的损坏, 通过 db_block_checking 检测并保护, 不让它写出到磁盘上, 不让错上加错发生 则大事化小小事化了 Oracle 实例 Buffer バッファ Cache キャッシュ 数据块恢复 REDO 可后续访问

47 DB_BLOCK_CHECKING 当数据块在内存中被修改时, 检测块的事务层和数据层的完整性 Row piece 没有重叠在一起 可用空间的大小是合理的 ITL 锁定的行数, 和实际有 lock bit 的行数是对应的 Oracle 定义了上百个检测 C 语言宏

48 DB_BLOCK_CHECKING False/OFF 除了 SYSTEM 表空间的块还做部分检测外, 其他表空间的块不做此类检测 LOW 基本的块头检测 ( 如 rbba,seqno) 会在内存中块内存修改后被检测, 例如 UPDATE/INSERT, 磁盘读或 RAC 节点间传输 MEDIUM 所有的 LOW 级别检测, 同时对堆表的数据块做语义检测 FULL/TRUE 所有 LOW 和 MEDIUM 检测的, 同时也对索引块做语义检测 DB_BLOCK_CHECKING 的表现实际受到 _DB_BLOCK_ADJCHK_LEVEL( 默认为 7) 的影响

49 DB_BLOCK_CHECKING 默认值为 FALSE 为了检测和避免逻辑损坏 典型情况下 block checking 的性能损耗为 1% 到 10%, 但更视乎合计负载类型, 某银行启用 DB_BLOCK_CHECKING=FULL 后 CPU 使用率增长了 20%~30% DB_BLOCK_CHECKING=MEDIUM 时性能损耗较少, 原因是其不检测索引块, 也不检测 IOT 如果发现了损坏, 报错常为 ORA-600 [kddummy_blkchk] 或 ORA- 600 [kdblkcheckerror], 进一步损坏被避免

50 _db_block_check_for_debug=true 默认为 False 和 DB_BLOCK_CHECKING 配合使用, 如果没设 DB_BLOCK_CHECKING 那么不要用 当发现损坏时 DUMP 块以便诊断 该参数控制在修改块前拷贝块到 PGA 中, 若发现问题则将该拷贝转出到跟踪文件中 性能损耗在于每次修改块前都会拷贝块到 PGA 中, 其损耗实际并不大

51 DB_LOST_WRITE_PROTECT 啥是 Lost Write? 存储或卷管理软件 ( 如 Veritas) 都可能是引发 Lost Write 的层面, 表现为 : 因为是 Lost Write, 所以上一次写入的 Block 结构完全正常,Oracle 默认不会检测报错 提高了返回给用户不正确数据的可能 不正确的数据可能进一步污染其他业务数据 Lost Write 的业务影响 缺货还超卖 下单的记忆似乎不那么真实

52 Lost write 写丢失的其他影响 数据库本身几乎没有任何报错 在物理读取块时,I/O 子系统返回陈旧版本的块 ORA-600 [kdsgrp1], ORA-600:[qertbFetchByRowID]. 表和索引不一致 ORA-600 [25027] 或其他 ORA ORA-600 [4137] Database Recover 时出现 ORA-600 [3020] ORA / ORA-01410

53 DB_LOST_WRITE_PROTECT 针对写丢失的保护 需要 DataGuard 版本 11g 中出现 默认为 NONE 当在 DG 环境的 Primary 上设置为 TYPICAL, 则将 readwrite 表空间上的 buffer cache 读记录到 redolog 中, 以便判断写丢失 则 Lost Write 可以在数据库 recovery 时被发现, 如物理备库

54 DB_LOST_WRITE_PROTECT DG 物理备库 Lost Write 检测机制 Primary Database 从磁盘读取 Block 的操作记录到 redo 中 Data File Number Data Block Address(DBA) System Change Number(SCN) 唯一指向一个数据块 Block 更新时会增长 DataGuard 中 redo 将传输到 Standby Database 在 Standby 上检验 redo 内的 SCN 和本地 block 如果 SCN 不一致, 则说明有 Lost Write 发生的可能

55 DB_LOST_WRITE_PROTECT Primary 和 Standby2 侧都要设置 Value Default Lost Write 检测对象 Primary Database Standby Database NONE N/A N/A N/A TYPICAL Read / Write 表空间从磁盘读取 block 到 Read / Write 表空间 buffer cache 中时生成检 FULL Read Only 表空间测用 Redo REDO APPLY 的一部分, MRP 将负责对比 REDO 里的 SCN Primary 或 Standby 上设置为 NONE 时是无效的 Primary 不生成相关 redo,standby 无法验证 Primary 生成 redo,standby 不验证

56 数据块损坏检测参数 DB_LOST_WRITE_PROTECT Lost Write 检测出的时机? 存在这样一种可能性, 即发生 Lost Write 后 Primary 立即发生了读取和修改, 那么 Standby 上 MRP 的验证已经晚了 一般情况下写丢失仅仅发生在少量块上, 只要不使用这些块 : 对其他块的查询更新都是正常的 错误的数据不会污染别的块

57 DB_LOST_WRITE_PROTECT 补充 相关验证 redo 仅限于 buffer cache 读 如果是 direct path read 直接路径读, 则不会生成 非 DataGuard 环境下也可以生成验证 Redo 可以在前滚时 rolling forward 时做检验 Standby 上也可能检测出 LostWrite 还可通过 ASM Mirror 或 ABR 自动修复

58 DEMO ma

59 DB_LOST_WRITE_PROTECT DBA=A SCN= Primary Database DBA=A SCN= Data Guard Disk Buffer Cache 设置 1 REDO 2 Read DBA=B SCN= db_lost_write_protect 将写出读取操作以 redo log 形式记录下来 当前 SCN 150 DBA=A SCN=100 Standby Database 比较块的 SCN 版本 O K Buffer Cache DBA=A SCN= DBA=B SCN= DBA=A SCN= DBA=A SCN= Lost Write 发生 Read DBA=A SCN= 丢失 DBA=A SCN= 收到旧块的 redo 3 提交 DBA=A SCN SCN= 当前 SCN 350 DBA=A SCN=100 4 O K 适用 N G DBA=A SCN= ORA-752 (Lost Write) 停止重做应用 DBA=B SCN= 提交 DBA=B SCN SCN= 不适用 DBA=B SCN=

60 发现 Lost Write 流程 (Primary 侧 Lost Write) SQL> update TAB1 set COL2='BBB' where COL1=101 ; Primary Database Buffer Cache File7 Block131 SCN# , AAA File7 Block131 SCN# , BBB Buffer Flush Disk File7 Block131 SCN# , AAA Lost Write 发生 Redo Record File7 Block131 SCN# COL2='BBB' Standby Database Buffer Cache File7 Block131 SCN# , AAA File7 Block131 SCN# , BBB SQL> select * from TAB1 where COL1=101 ; File7 Block131 SCN# , AAA File7 Block131 SCN# Block Read 发现 Lost Write(ORA-752) SCN <

61 DB_LOST_WRITE_PROTECT 发现 Lost Write 后的动作 负责通知 Lost Write 的是 Physical Standby 中的一个备库 其在 alert.log 中记录 ORA-752 为了保护备库, 自动停止 MRP 进程 后续的 redo 不被应用, 不用担心进一步数据污染 PRXX 进程对应的跟踪文件中记录了详细信息 包括对相关 redo 和 block 的转储 这些信息帮助 DBA 追查 Lost Write 问题

62 DB_LOST_WRITE_PROTECT 发现 Lost Write 的 Standby 端的 alert.log Wed Oct 23 19:18: 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 ' 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 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: recovery detected a lost write of a data block ORA-10567: Redo is inconsistent with data block (file# 7, block# 131, file offset is bytes) ORA-10564: tablespace LW ORA-01110: data file 7: '+DATA/orcls/datafile/lw ' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# Wed Oct 23 19:18: Recovery Slave PR02 previously exited with exception 752 Wed Oct 23 19:18: 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: normal completion of background process MRP0: Background Media Recovery process shutdown (orcls1)

63 DB_LOST_WRITE_PROTECT PRXX 进程 TRACE Block Dump Main Message Redo Dump Hex dump of (file 7, block 131) 发现 Lost Write 的数据块 Dump of memory from 0x F03B0000 to 0x F03B2000 0F03B A206 01C CC55A [...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 (0x cb1ba) seq 1 (0x01) while expected to have SCN (0x cc55a) seq 1 (0x01) 1 Primary 侧 Block 的 SCN The block was read at SCN (0x cd8d3), BRR: 2 Standby 侧 Block 的 SCN CHANGE #1 TYP:2 CLS:6 AFN:7 DBA:0x01c00083 OBJ:87637 SCN:0x cb1ba SEQ:1 OP:23.2 ENC:0 RBL: Primary 侧读取该 block 时的 SCN REDO RECORD - Thread:1 RBA: 0x LEN: 0x0034 VLD: 0x10 SCN: 0x cd8d3 SUBSCN: 1 10/23/ :18:16 (LWN RBA: 0x LEN: 0003 NST: 0001 SCN: 0x cd8cf) CHANGE #1 TYP:2 CLS:6 AFN:7 DBA:0x01c00083 OBJ:87637 SCN:0x cb1ba SEQ:1 OP:23.2 ENC:0 RBL:1 Block Read - afn: 7 rdba: 0x01c00083 BFT:(1024, ) non-bft:(7,131) scn: 0x cb1ba seq: 0x01 flags: 0x ( dlog ckval ) (1) < (2) 可判定 Primary 发生 Lost Write (2) 的更新被丢失了 (3) 读取数据块时被检测到

64 DB_LOST_WRITE_PROTECT Standby 侧检测出 Lost Write SQL> select * from TAB1 where COL1=101 ; Primary Database Buffer Cache Buffer Flush File7 Block131 SCN# , BBB Disk Redo Record File7 Block131 SCN# COL2='BBB' File7 Block131 SCN# Block Read Automatic Block Media Recovery Standby Database Buffer Cache File7 Block131 SCN# , AAA File7 Block131 SCN# , BBB Buffer Flush Disk File7 Block131 SCN# , AAA File7 Block131 SCN# , AAA 发现 Lost WRite ABR Lost Write 发生

65 DB_BLOCK_CHECKSUM 性能损耗测试与设置为 OFF 时的执行耗时对比

66 DB_BLOCK_CHECKING 性能损耗测试与设置为 OFF 时的执行耗时对比

67 DB_LOST_WRITE_PROTECT 性能损耗测试与设置为 OFF 时的执行耗时对比

68 表 / 索引不一致 表和索引不一致, 例如表上有的记录而索引上没有, 或者相反 一般会引起 ORA-08102, ORA-8102, ORA-600 [kdsgrp1], ORA-600 [qertbfetchbyrowid], ORA-1499 等错误 需要做 analyze table validate structure cascade 验证操作 更多信息 : OERR: ORA-1499 table/index Cross Reference Failure - see trace file (Doc ID ) OERR: ORA-8102 "index key not found, obj# %s, file %s, block %s (%s)" (Doc ID )

69 表和索引不一致的原因 常见 bug 列表 : OERR: ORA-1499 table/index Cross Reference Failure - see trace file (Doc ID ) OERR: ORA-8102 "index key not found, obj# %s, file %s, block %s (%s)" (Doc ID ) 由于写丢失 lost write

70 数据字典不一致 数据字典记录错乱, 字典表之间逻辑不一致 属于 SYS 用户的系统核心表 bootstrap 对象, 存放在 system 表空间上, 是 Oracle 数据库能被实例打开并正常运作的基础 不一致的例子 : 'Problem: OBJ$.OWNER# not in USER$" which refers to a user in table OBJ$ that does not exist in USER$. ORPHAN TABPART$: OBJ= TS=33 RFILE/BLOCK= BO#= SegType= ORA-00600: internal error code, arguments: [ktsircinfo_num1], [33], [21], [ ], [], [], [], [] ORPHAN TAB$: OBJ= DOBJ= TS=45 RFILE/BLOCK= BOBJ#= SegType= ORA-00600: internal error code, arguments: [ktssdrp1], [45], [50], [304491], [], [], [], [] Identify the corruption extension using RMAN/DBV/ANALYZE etc (Doc ID )

71 Redo 在线日志损坏 损坏发生在 redo 日志文件的块上, 逻辑或者物理损 Redo log 中的无效块 : ORA-353 log corruption near block %s change %s time %s ORA-368 checksum error in redo log block ORA-355 change numbers out of order

72 控制文件损坏 control file 发生在控制文件中的块损坏 ORA "control files are not for the same database ORA-00600: internal error code, arguments: [kccpb_sanity_check_2]

73 人为错误 表被误 drop 误更新删除行 搞错脚本误删除了对象 误删除了数据文件 impdp 时误使用了 replace 太多太多了

74 针对损坏的恢复 使用 RMAN 的 BMR block media recovery RMAN : Block-Level Media Recovery - Concept & Example (Doc ID ) HOW TO PERFORM BLOCK MEDIA RECOVERY (BMR) WHEN BACKUPS ARE NOT TAKEN BY RMAN. (Doc ID ) DataGuard, 从 standby 恢复或 Switchover,Active Dataguard 的 Automatic Block Media recovery 重建索引 rebuild index 对于已经传播到磁盘上的逻辑损坏, 跳过损坏块或者从备份中重建表 DBMS_REPAIR 包跳过损坏块 采用 以后的 事件或 11g _index_scan_check_skip_corrupt 参数来跳过 IOT 上的坏块

75 针对损坏的恢复 控制文件损坏 : 使用镜像的控制文件或重建 数据字典损坏 : PITR 基于时间点的恢复 Flashback 在线日志文件 online redo logfile 损坏 多路复用 redo log PITR 基于时间点的恢复 Flashback

76 数据字典 Oracle 数据字典存放在 system 表空间上,owner 是 sys 部分的字典信息在 Database Open 后加载在 SGA Dictionary Cache 字典缓存中 主要是这些表 : obj$,tab$,ind$,undo$,ts$,seg$,user$,dependency$ Bootstrap 系统自举数据字典对象无法使用 DDL alter 修改, 这些核心对象信息存放在 boostrap$ 表中, 如果尝试 alter 它们那么会报错 : ORA "object necessary for warmstarting database cannot be altered"

77 数据字典基本关系

78 如何检测数据字典损坏? Hcheck8i.sql Note: Hcheck.sql To provide a single package which looks for common data dictionary-- problems.

79 常见数据字典损坏 字典表中丢失记录 : TAB$/IND$ 中有记录, 而 OBJ$ 中无对应记录 UNDO$/TAB$/IND$ 中有记录, 而 seg$ 中无对应记录 OBJ$ 中有记录, 而没有对应的 USER$ 中的 OWNER# OBJ$ 中有记录, 而没有对应的 tab$,ind$,seq$ 彻底丢失某些数据字典对象 损坏的数据字典对象表或索引 : Analyze table validate structure cascade 报错 ORA-01499(table/index cross reference failure - see trace file) 数据字典表中存在错乱记录

80 无备份情况下数据字典损坏 无备份情况下数据字典损坏 : 若数据库仍能打开 : 手动 patch 数据字典 : shutdown immediate startup restrict patch 数据字典 若数据库已经无法打开 : 尝试使用 BBED 修改数据字典 使用 PRM-DUL 工具整体恢复数据库数据

81 TAB$ 中有记录, 而 SEG$ 中无对应记录的场景 SQL> connect test/test Connected. SQL> drop table EMP; * ERROR at line 1: ORA-00600: internal error code, arguments: [ktssdrp1], [11], [10], [9], [], [],[], [] SQL> select * FROM EMP; select * FROM EMP * ERROR at line 1: ORA-00600: internal error code, arguments: [ktsircinfo_num1], [11], [10], [9] ERROR: ORA-600 [ktsircinfo_num1] [a] [b] [c] [d] [e] DESCRIPTION: This exception occurs when there are problems obtaining the row cache information correctly from sys.seg$ ARGUMENTS: Arg [a] tablespace number Arg [b] file number Arg [c] block number

82 IND$ 中有记录, 而 SEG$ 中无对应记录的场景 SQL> select * from dept where dname = 'ACCOUNTS'; select * from dept where dname = 'ACCOUNTS' * ERROR at line 1: ORA-00600: internal error code, arguments: [ktsircinfo_num1], [14], [2], [49],[], [], [], [] Problem: Orphaned IND$ (no SEG$) - See Note: (Bug:624613) ORPHAN IND$: OBJ=39442 DOBJ=39442 TS=14 RFILE/BLOCK=2 49 BO#=39438 SegType= SQL> select * from sys.seg$ where ts#=14 and file#=2 and block#=49; no rows selected Ind$ with an entry: SQL> select ts#, file#, block# from sys.ind$ where obj#=39442; TS# FILE# BLOCK#

83 SEG$ 中有记录, 而 OBJ$ 中无对应记录的场景 SQL> drop tablespace test_dict_corr including contents and datafiles; drop tablespace test_dict_corr including contents and datafiles * ERROR at line 1: ORA-01561: failed to remove all objects in the tablespace specified SQL> select * from dba_segments where tablespace_name = 'TEST_DICT_CORR'; no rows selected SQL> select ts#, name from v$tablespace where name = 'TEST_DICT_CORR'; TS# NAME TEST_DICT_CORR SQL> Select ts#, file#, block#, type# from seg$ where ts#=20; TS# FILE# BLOCK# TYPE# ? type#=6 (INDEX). Hcheck8i output: Problem: Orphaned SEG$ Entry ORPHAN SEG$: SegType=INDEX TS=20 RFILE/BLOCK=7 17 No orphaned IND$ entries

84 丢失字典对象导致数据库无法打开的例子 用户意外地 drop 了 sequence SYS.IDGEN1$ 数据库无法顺利打开, 启动进程会因为 ORA-600 [kokiasg1]. Alert.log 中显示 smon 在做事务恢复 : SMON: enabling tx recovery

85 若 bootstrap$ 中存放的自举对象受损 Bootstrap$ 中记录的数据字典索引不能被 rebuild 或 drop Bootstrap$ 中记录的数据表不能被 truncate 或 drop 常规的 DDL alter 操作不能针对 bootstrap$ 相关对象执行 SQL> truncate table obj$; truncate table obj$ * ERROR at line 1: ORA-00701: object necessary for warmstarting database cannot be altered SQL> alter index i_obj1 rebuild; alter index i_obj1 rebuild * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-00060: deadlock detected while waiting for resource SQL> drop index i_obj2; drop index i_obj2 * ERROR at line 1: ORA-00701: object necessary for warmstarting database cannot be altered

86 针对损坏收集诊断信息 使用 11g IPS incident package 数据文件块损坏 Identify the corruption extension using RMAN/DBV/ANALYZE etc (Doc ID ) How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFY (Doc ID ) RMAN 检测数据文件上的坏块 How to identify all the Corrupted Objects in the Database reported with RMAN (Doc ID ) Rman validate check logical database DBV 工具 问题数据库的 redo dump, 可以通过下列命令手动 dump redo alter system dump logfile '&name' dba min <file#> <block#> dba max <file#> <block#>;

87 针对损坏收集诊断信息 通过 dd 命令复制 oracle 数据块 : dd if=<datafile name> bs=<datafile blocksize> skip=<block#> count=1 of=<block#.dd> 通过 oracle 命令 dump 数据块 : SQL> alter system dump datafile &file_name block &blocknumber; SQL> alter system dump datafile &file_number block &blocknumber; 获得表 / 索引的 DDL Dbms_metadata.get_ddl exp user/passwd file=<tablename> statistics=none rows=n grants=n tables=<tablename>

88 针对损坏收集诊断信息 表或索引不一致 Analyze table <table_name> validate structure cascade; Redo 日志文件损坏 alter system dump logfile '<name>' validate; 数据字典不一致 Hcheck.sql 脚本检测数据字典健康情况

89 常见错误 ORA-1578 Note: ORA-1578 ORA Lob Note ORA-8103 Note: ORA-1499 Mismatch between table/index (analyze validate structure cascade):table/index row count mismatch row not found in index ORA-1498 (analyze validate structure) ORA-600 [kcbzpb_1] / ORA-600 [kcbzpbuf_1] ORA-600 [12700] Mismatch between Table and Index ORA-600 [kdsgrp1] New in 10g similar to ORA-600 [12700] Corrupt block relative dba: 信息

90 ORA-8103 简单来说 ORA-8103 的主要成因有 2 类 : 数据块的 block type 类型是无效的或者读出来的块类型与 Oracle 期望的不一致 例如 Oracle 认为该数据块的类型为 data(type=6), 但实际却不是 数据块中的 data_object_id 和数据字典中的 data_object_id 不匹配 针对 ORA-8103 问题我们优先推荐一些措施 : ORA 问题的诊断最好是能生成 8103 错误的 ERROR STACK TRACE, 在 TRACE 中会记录具体引发 8103 的对象的 OBJ 和 OBJD, 这便于我们定位可能存在 corruption 的对象 问题在于往往前台进程遇到 ORA 错误不会在后台生成 TRACE 文件, 这需要我们手动设置 8103 触发 ERRORSTACK 的 EVENTS: ALTER SYSTEM SET EVENTS 8103 TRACE NAME ERRORSTACK LEVEL 3 ; 解决思路包括 : 1. 通过 OBJD 和 DBA 定位到具体的表名和块号 2. 有条件的情况下对该表做一个 analyze.. validate structure 3. 有条件的情况下对该表所在 tablespace 做一个 dbms_space_admin.assm_tablespace_verify 4. 有条件的情况下 move 这张表或者相关的分区, 尝试绕过该问题 5. 有条件的情况下降该表或分区移动到 MSSM 表空间上, 绕过该问题 execute dbms_space_admin.tablespace_verify( &tablespace_name ) oradebug setmypid oradebug tracefile_name execute dbms_space_admin.assm_tablespace_verify( &tablespace_name,dbms_space_admin.ts_verify_bitmaps) oradebug setmypid oradebug tracefile_name

91 ORA-1499 table/index Cross Reference Failure - see trace file 该错误为表和索引数据交叉验证错误, 可以通过 analyze validate cascade 命令发现 ; 出现该错误说明表或索引可能损坏, 一般优先考虑重建索引 Analyze table validate structure cascade 设置 level 1 事件并运行报错 SELECT 语句, 会生成包含问题 index rdba 的 trace

92 ORA-00600[kcbzpb_1] 数据块从磁盘中被读取到 buffer cache, 且在 buffer cache 中被正常更新, 但是在写出到磁盘前的 cache header 健康检查时, 出现了问题 该报错一般说明问题仅仅发生在 buffer cache 中 ORA-600 [12700] / ORA-600 [kdsgrp1]

93 相关 event skip corrupt data blocks skip corrupt index blocks skip corrupt block in IOT s ( ) 11g use parameter _index_scan_check_skip_corrupt dumps blocks in hex tracing block consistent reads dump corrupted block

94 Thank You