oracle数据库损坏的应对措施 - askmaclean.com · • mysql ocp •...

PARNASSUSDATA.COM

针对Oracle数据库损坏的应对措施

PARNASSUSDATA.COM

Biot Wang

• 8年Oracle相关开发及数据库运维经验

(Oracle DB, MySQL, Oracle Apps)

• 11g OCM

• MySQL OCP

• 上海Oracle用户组核心成员

• E-Mail: [email protected]

PARNASSUSDATA.COM

诗檀公司介绍国内服务电话：13764045638

• 诗檀软件专注于数据服务– 提供Oracle, MySQL,MongoDB,Hadoop管理和咨询服务

– 提供解决方案并进行安装、升级、迁移及运维

– Oracle数据库救援(基于自主研发的PRM-DUL)

• 专业团队– 全天候的DBA专家服务

– 24/7/365 DBA远程支持咨询，系统管理及特定项目紧急回复

• 服务客户– 现服务客户主要有在线大型电商，金融机构，政府部门及企事业单位。

PARNASSUSDATA.COM

数据丢失的影响

长时间数据恢复

人为失误、二次灾害的恢复操作

长时间调查原因

数据损坏造成的影响

直接损害企业

PARNASSUSDATA.COM

Oracle Maximum Availability MAA架构

• Oracle Maximum Availability Architecture（MAA）、Oracle的最高可用性架构（MAA）是基于很多成功案例上的高可用性最佳实践蓝图

• MAA的目的

–避免所有的宕机和提供检测与修复的最佳实践

–简化配置最优的高可用性架构• 不受硬件与操作系统的影响

• 提供立竿见影的高可用性体验

PARNASSUSDATA.COM

One of Five Steps for Maximum Availability• 解决计划与非计划的Downtime

PARNASSUSDATA.COM

高可用性的五个步骤• 解决计划与非计划的Downtime

Automatic Storage Management,

Recovery Manager (RMAN),

Oracle Secure Backup

•存储故障

•数据恢复

•备份

Oracle RAC

•实例故障

•服务器故障

•Rolling maintenance

•双活: 性能拓展

•Active-Passive:

数据库实例在线转移

•合并

Active Data Guard / Data Guard

•数据库故障

•系统故障

•站点故障

•数据零丢失

•自动故障切换

•最佳数据保护

•数据库滚动升级

•分担只读负载和备份

Flashback

•快速时间点恢复

•逻辑损坏的细粒度修复

•事务

•表

•数据库

GoldenGate

•灵活的维护

•异构迁移

• Schema 迁移

•双向和多主机复制

•零停机维护

PARNASSUSDATA.COM

• Oracle Maximum Availability Architecture（MAA）Oracle的最高可用性架构

PARNASSUSDATA.COM

与传统的保护措施对比• 导入Scheme的通常方式

PARNASSUSDATA.COM

传统架构中潜伏着数据库损坏的危险• 复杂的碎片层结构构成潜在的风险

数据库

OS

Clusterware

Volume Manager

Driver / MultiPath SW

I/O-Interface(DsikNW)

Storage Utilities

存储管理器

Controller/Cache/DiskShelf

磁盘

检测不到在下层中发生的损坏

通过多层磁盘的写每层都是由多个厂商提供导致复杂性每层都有损坏的风险

由于软件中存在bug导致的损坏由于硬件中存在bug导致的损坏磁盘在不匹配时闪存物理组件故障，与老化有关的损坏

PARNASSUSDATA.COM

基于Oracle考虑的数据保护三原则

最新的保护数据的体系结构的概念• 考虑对企业的影响、结合数据的重要性

单个系统（部分双重化）存在无法防止单点故障的危险

单纯的复制无法确保数据一致性和准确性

无法快速切换和可靠的恢复与重建机制（持续服务）

不同模式(同步/异步等)创建数据的多个备份

当备份数据有所改动时，将需要通过一个严格控制的接口

发生数据损坏时能提供一个机制迅速恢复

以事务为基础的保护机制体系

PARNASSUSDATA.COM

防止块损坏

PARNASSUSDATA.COM

Oracle数据库的数据损坏应对措施块损坏 Lost Write

块的状态数据损坏（比特错误、部分缺失、地址错误）块处于未能正确识别的状态

在数据库端，它检测到已经写成功并且没有任何IO错误，但是实际上并没有写到磁盘，依然是原来的块。

故障原因示例系统bug另一个应用程序忽然在磁盘上的数据库领域写入信息

存储网络故障• 损坏的数据写入磁盘

存储异常• 在高负荷时从I / O控制器写入磁盘出现丢失

检测方法读取块时进行校验和验证、由块检查检测出(ORA-1578)（相应的存储的硬盘，也可以在写入时检测）

Data Guard传输的REDO数据和备库的数据块的块版本（SCN）检测出不匹配(ORA-752) （不能在非Data Guard的场合检测到）

恢复方法由块介质恢复修复块• 从ASM镜像自动修复• 从Active Data Guard备库自动修复• 从RMAN备份手动修复

故障切换到备库、重新执行检测到Lost Write时或者更早的SCN点的事务（由于主库的数据被旧块更新污染）

PARNASSUSDATA.COM

预防数据损坏的扩散

• 使用Oracle Data Guard物理备库

– Oracle Data Guard是在Write lost中保护数据防止数据损坏最好的解决方案

• 在Data Guard中的主备库初始化参数设置数据损坏的相关参数

• 为了实现最全面的数据损坏预防和检测

PARNASSUSDATA.COM

Oracle Database的最优化损坏检测• 数据库块格式

PARNASSUSDATA.COM

初始化参数：DB_ULTRA_SAFE

• DB_ULTRA_SAFE参数、指定OFF,DATA_ONLY,DATA_AND_INDEX

• 设置以下是每个初始化参数– DB_ULTRA_SAFE = OFF *默认值

• DB_BLOCK_CHECKING = OFF

• DB_BLOCK_CHECKSUM = TYPICAL

• DB_LOST_WRITE_PROTECT = NONE

– DB_ULTRA_SAFE = DATA_ONLY

• DB_BLOCK_CHECKING = MEDIUM

• DB_BLOCK_CHECKSUM = FULL

• DB_LOST_WRITE_PROTECT = TYPICAL

– DB_ULTRA_SAFE = DATA_AND_INDEX

• DB_BLOCK_CHECKING = FULL

• DB_BLOCK_CHECKSUM = FULL

• DB_LOST_WRITE_PROTECT = TYPICAL

• DB_BLOCK_CHECKING，覆盖明确设置DB_BLOCK_CHECKSUM或DB_LOST_WRITE_PROTECT的情况下所设置的值。

• 加强块损坏的检测功能 DB_BLOCK_CHECKING 参数，指定是否在数据库更新时执行

检查

DB_BLOCK_CHECKING = OFF *默认值

仅检查SYSTEM 表空间

DB_BLOCK_CHECKING = LOW

除了检查SYSTEM表空间，它还会检查用户表空间

块在缓冲区被DML语句更新时，检测缓存区的块头

DB_BLOCK_CHECKING = MEDIUM

当设置为LOW 时，对除索引组织表外的所有表进行块校验

DB_BLOCK_CHECKING = FULL

设置为MEDIUM 时，除了LOW级别的检测外，还包括除了索引之外的所有对象

PARNASSUSDATA.COM

初始化参数：DB_ULTRA_SAFE

• DB_BLOCK_CHECKSUM初始化参数，指定是否计算校验码Checksum（由数据库中存储的所有字节算出来一个数）并写入数据块头和redo块– DB_BLOCK_CHECKSUM = OFF(FALSE)

• 只为SYSTEM 表空间计算校验码Check Sum

• 不对用户表空间计算

– DB_BLOCK_CHECKSUM = TYPICAL(TRUE) *默认值

• 在写入数据文件前计算

• 读取数据时，读取已有块校验码和基于块数据重新计算的校验码进行比较

• 当计算出的校验码与已有的不匹配时，将会输出校验码错误

– DB_BLOCK_CHECKSUM = FULL

• 除了执行TYPICAL级别的检测外，还会在DML语句产生的变更应用到数据库之前检测校验码，并在应用变更后重新计算校验码

• 当计算出的校验码与已有的不匹配时，将会输出校验码错误

• 补充 DB_LOST_WRITE_PROTECT参数指定是否启用写丢失检测

当IO子系统确认数据库对OS的write()调度完成，但底层存储实际上并未把数据写入磁盘，就可能发生写丢失

DB_LOST_WRITE_PROTECT = NONE *默认值

检测写丢失功能无效

DB_LOST_WRITE_PROTECT = TYPICAL

对于read/write 表空间写丢失检测功能有效

DB_LOST_WRITE_PROTECT = FULL

对于读写表空间和只读表空间的写丢失检测功能有效

PARNASSUSDATA.COM

定期块损坏检查• RMAN块损坏检查

RMAN> VALIDATE DATABASE;

RMAN> VALIDATE TABLESPACE <表空间名>;

RMAN> VALIDATE DATAFILE <文件路径>;

客户端

控制文件数据文件归档日志文件

目标数据库

服务进程RMAN

VALIDATE 命令、也可以检查没有备份的块损坏

表空间单位

数据文件单位

整个数据库

控制文件数据文件归档日志文件

备库

服务进程RMAN

Data Guard

另外，也可以在备库端检测

PARNASSUSDATA.COM

RMAN块损坏检查• 默认设置是停止一个检测块损坏RMAN> -- 执行增量备份backup incremental level 1 tablespace RTEST1;

启动backup(开始时间: 12-07-23)

分配的通道ORA_DISK_1

分配的通道ORA_DISK_2

通道ORA_DISK_1: 必须在增量备份level1启动数据文件备份通道ORA_DISK_1:没有再备份设置中指定数据文件输入数据文件编号=00010 名前=+DATA/o11g/datafile/rtest1.282.789398885

通道ORA_DISK_1: start piece 1 at(12-07-23)

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03009: backup命令(ORA_DISK_1 on the channel) failed at 07/23/2012 16:22:00ORA-19566: exceeded limit of 0 corrupt blocks for file (+DATA/o11g/datafile/rtest1.282.789398885)

SQL> select * from V$DATABASE_BLOCK_CORRUPTION;

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE

---------- ---------- ---------- ------------------ ---------------------------

10 14980 1 6681461 FRACTURED

KROWN#127924:how to deal with if corruption block is detected when you get a backup using RMANKROWN#68810:The main cause of ORA-1578 and their workarounds

PARNASSUSDATA.COM

块介质恢复• 粒度更小的恢复

检测「数据块」单位的损坏

– 基于逐块恢复

– 正常块可以连续访问表空间（在线）

数据文件

备份区

恢复

ASM镜像？自动恢复读取ASM镜像正常块

从Active Data Guard备用站点自动恢复传输正常块

手动恢复读取RMAN备份正常块

通过备份中体积单位恢复、手动修复介质进行恢复

Active DataGuard？

RMAN？

Y

Y

Y

N

N

N

例子块介质恢复的流程

PARNASSUSDATA.COM

块介质恢复

• ASM镜像自动修复损坏的地方，降低故障率• ASM自动修复（11gR1～）

ASM磁盘组

Oracle 实例

ASM实例

ASM可以是两重或者三重

位置信息

磁盘写

ASM磁盘组

Oracle实例

ASM实例

（1）检测到损坏

（3）修复说明

（4）修复

（2）从镜像读取

检测到损坏时

PARNASSUSDATA.COM

Oracle ASM发生磁盘故障时的举动

• 配置镜像的前提

–读操作期间检测到IO错误时

• 从二级自动读取修复

–写操作期间检测到IO错误时

• 故障磁盘自动离线处理

• 快速镜像重新同步、从存活的磁盘端同步最低所需数据– 如果不是在一个多存储捆绑环境端写、恢复后新的存储端无法被识别，ASM可以

• 可以弥补磁盘缺陷

PARNASSUSDATA.COM

块自动介质恢复• 通过Active Data Guard 块修复功能

MAX(C1)-----------------

5000

②检测到块损坏

④自动传输备库的正常块

③从备库请求正常的块

⑤自动恢复

①执行SQL

⑥返回无错误的结果

Waiting Auto BMR response

for (file# 7, block# 261)

Auto BMR successful

Requesting Auto BMR for

(file# 7, block# 261)

alertalertSQL> SELECT max(c1)FROM tab1;

自动修复错误，并且返回没有错误的结果

※ Active Data Guard

可用的情况下

PARNASSUSDATA.COM

恢复块恢复

• 使用RMAN介质恢复坏块• 发生的原因有：块故障、间歇或随机的I/O错误、存储器损坏等以后数据被写入磁盘

• 它需要恢复一个或多个数据文件中的损坏块

• 由于只恢复指定的必要块，所以能缩短恢复时间

• 只要存在相同的文件，不必要的对象可以保持在线

在执行检查RMAN备份时即使存在块损坏，它也可以从正常备份集恢复

表空间(在线) 备份区

数据文件块介质恢复

PARNASSUSDATA.COM

RMAN可行性坏块恢复方法• 怎么进行坏块恢复

• 查看坏块

• 执行坏块恢复

• 修复指定的坏块

• V$DATABASE_BLOCK_CORRUPTION执行

• 修复已经了解到的所有的坏块

SQL> select * from v$database_block_corruption;

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO

------ -------- ------- ------------------ ---------

6 108 1 0 CHECKSUM

SQL> select ename from employees;

ERROR:

ORA-01578:

Oracle数据库损坏发生在(文件号6、块号108)ORA-01110: 数据文件6: '/u01/app/oracle/oradata/test01.dbf'

RMAN> RECOVER DATAFILE 6 BLOCK 108;

RMAN> RECOVER CORRUPTION LIST;

PARNASSUSDATA.COM

数据保护三原则

1. 有多个不同方式的数据副本– 一个错误的操作不至于丢失两个副本

2. 当改变副本时严格检查– 错误发生时取消连接

3. 如果问题发生，使用回滚快速恢复

PARNASSUSDATA.COM

Flashback Database

• 迅速回退到过去的时间点（point-in-time）

– 恢复改变的数据库、使数据库回到指定的时间点

• 不需要恢复数据库的所以备份

• 迅速 - 不需要几个小时，几分钟内恢复

• 容易 – 一个命令完成恢复

FLASHBACK DATABASE TO ‘2:05 PM’

• 快速回滚、返回更新

正确时间 = 错误发生时间 + f(DB_SIZE)

PARNASSUSDATA.COM

ASM功能使用

PARNASSUSDATA.COM

Oracle ASM在磁盘损坏时

• 在镜像配置前提下

–读操作时检查I/O 错误

• 再次读取时自动修复坏块

–写进程时检查I/O错误

• 损坏磁盘自动离线处理

• 快速镜像同步、并且从磁盘同步最低需求的数据

• 弥补存储的不足

PARNASSUSDATA.COM

写I/O错误时的操作

• 写到数据C

ASM磁盘组

ASM

A

A

B DC E

BC

D

E

E D

B C

A

磁盘１

磁盘３磁盘４磁盘７磁盘８

磁盘６磁盘５磁盘２

数据库实例ASM实例

Y

故障组1 故障组2

主分区第二分区

PARNASSUSDATA.COM

写I/O错误时的操作

• 磁盘8 发生写错误

ASM磁盘组

ASM文件

A

A

B DY E

BY

D

E

E D

B C

A

磁盘１



数据库实例主分区第二分区

ASM实例

Y


写入失败

写入成功

需要磁盘离线

PARNASSUSDATA.COM

写I/O错误时的操作• 使磁盘8离线

ASM磁盘组

ASM文件

A

A

B DY E

BY

D

E

E D

B C

A

磁盘１



数据库实例

主分区

第二分区

ASM实例

Y

故障组 1 故障组 2

需要磁盘离线

离线

成功

PARNASSUSDATA.COM

写I/O错误时的操作• 通过高速镜像同步实现冗余配置

ASM磁盘组

ASM文件

A

A

B DY E

BY

D

E

E D

B C

A

磁盘１



数据库实例ン主分区第二分区

ASM实例


成功

变更为online

同步Y

PARNASSUSDATA.COM

写I/O错误时的操作• 通过rebalance冗余恢复

ASM故障组

ASM文件

A

A

B DY E

Y

DE D

B

A

磁盘１



数据库实例主分区第二分区

ASM实例


EC

削除

重新复制数据到另一个磁盘

冗余恢复

Y

BE

PARNASSUSDATA.COM

读I/O错误时的操作• 读到数据C

ASM故障组

ASM文件

A

A

B DC E

B

D

E

E D

B C

A

磁盘１



数据库实例

主分区第二分区

ASM实例

C


第二分区读成功

主分区的读错误

Ｃ

PARNASSUSDATA.COM

读I/O错误时的操作

• Oracle检测到I/O错误时、自動I/O镜像

– 稍后执行镜像I/O

– 对应用程序透明（没有错误）

• DB的告警日志（节选）

• 输出到日志

…

ORA-27061:非同步I/O 等待失败

…

WARNING: failed to read mirror side 1 of virtual extent 0 logical extent 0 of file 263 in group 3 from

disk 2 allocation unit 50908; if possible, will try another mirror side

NOTE: successfully read mirror side 2 of virtual extent 0 logical extent 1 of file 263 in group 3 from

disk 1 allocation unit 316 自动从镜像读取

PARNASSUSDATA.COM

读I/O错误时的操作• 数据C 的坏块修复

ASM磁盘组

ASM文件

A

A

B DC E

B

D

E

E D

B C

A

磁盘１



DB实例

: 主分区: 第二分区

ASM实例

C


快修复

块修复需求

成功

??? 从正常块重写数据

PARNASSUSDATA.COM

发生I//O错误时的操作• 数据块C 的修复（重新执行）

ASM 磁盘组

ASM文件

A

A

B DC E

B

D

E

E D

B C

A

磁盘１



DB实例


ASM实例

C


块修复

块修复要求

???块修复失败

再次重写入相同磁盘上的另一个位置

PARNASSUSDATA.COM

读I/O错误时的操作• 磁盘3在离线状态 (快速镜像同步操作)

ASM磁盘组

ASM文件

A

A

B DC E

B

D

E

E D

B C

A

磁盘１



DB实例


ASM实例

C


块修复要求

???

磁盘自身离线

PARNASSUSDATA.COM

总结

PARNASSUSDATA.COM

防止块损坏• 使用Oracle Automatic Storage Management (Oracle ASM)防止存储故障

– 使用Oracle ASM HIGH REDUNDANCY的最佳损坏修复

– Oracle ASM磁盘组冗余，如果有扇区损坏，返回介质检查错误。

• 使用Oracle Active Data Guard自动块修复

• 配置Data Recovery Advisor，自动诊断数据损坏

• 逻辑坏块的快速时间点恢复（多数情况由于人为错误），主库故障切换后的快速修复，闪回数据库技术

• 通过Recovery Manager (RMAN)实现备份和恢复计划

– RMAN的BACKUP VALIDATE CHECK LOGICAL...定期扫描用来检查错误

– RMAN和Oracle Secure Backup是另外的块检查在使用在备份和修复操作时

PARNASSUSDATA.COM

检测并监控块损坏

• 监控错误和数据库告警

– Enterprise Manager用来监控所有目标的可用性

– 你能查看所有目标从一个视图HA Console

• 查看V$DATABASE_BLOCK_CORRUPTION视图，当块损坏或修复时自动更新

• 通过Data Recovery Advisor自动诊断数据故障，提供合适的修复选项，并且在用户请求时修复

• 使用Data Guard、检测物理坏块，检测写丢失

– 通过利用Active Data Guard的自动块介质恢复，自动修复在主库或备库的坏块

• 使用SQL*Plus检测数据文件损坏和块内损坏

– ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL*Plus语句

– 识别损坏后，重建表，执行其他操作

PARNASSUSDATA.COM

参阅

• Oracle® Database高可用性最好用11g版本2 (11.2)

• Master Note for Handling Oracle Database Corruption Issues [1088018.1]

• Best Practices for Corruption Detection, Prevention, and Automatic Repair - in a Data Guard Configuration [1302539.1]

PARNASSUSDATA.COM

附录

PARNASSUSDATA.COM

块损坏类型• 从磁盘读时检测到块损坏

– (例如前后不搭配等)

内部重复读时，如果错误信息不能被读，知道正确信息被标记

从磁盘读没有问题、随后检查出一个错误

– 它是内部块恢复(从磁盘读取redo)两次，我们仍然标记两次以防不能被转储。

• 何时检查错误

– 通过db_block_checking和_check_block_after_checksum设置

• 导出数据块

– 通过损坏标记，这个块有DBWR导出

– 介质损坏同时从磁盘标记，因为没有任何更新，没有脏缓冲区

– Media Corrupt同时被标记到磁盘。

– Soft Corrupt可能在脏缓冲后被标记、损坏标记写入到磁盘。

PARNASSUSDATA.COM

损坏情况

• 1. 不是Oracle导致的损坏情况– 1-1. 如果Oracle 数据库无法识别一个大小不正常的数据块，物理块没有问题，当你执行select 语句时会报ora-1587的错误

• [损坏情况]

内存中的错误信息、最后512位的块ffff ffff aaaa aaaa 5555 5555 0000 0000重复、异常值– 1-2. 许多块错误、个别的、相同物理位置但逻辑位置不同的块损坏

转储数据块的备份，如果你操作了多个数据块，ora-1578 c错误发生

• [损坏情况]

所有块头的1187位损坏、1 bit 异常值、oracle 管理的数据、行头区或列头区发现异常的值

• 2. Oracle 可能损坏情况– 2-1. 多个不同物理位置的损坏、逻辑损坏。例如（不同的物理位置损坏，损坏点是行头

• 3. Oracle 问题未知的情况

3-1. 多个块被破坏、个别的、物理位置相同的块错误、逻辑块错误、应用程序停止

• [损坏状况]

• 所有破坏的数据块头已经是一个异常的值

• 没有OS 错误的ORA-1578 错误发生

诗檀软件软件，方案，服务供应商

专注于数据

oracle数据库损坏的应对措施 - askmaclean.com · • mysql ocp •...

Documents