corruption and revive - db tech showcase 2013 特濃jpoug

Corruption And Revive

2013年11月15日

JPOUGボードメンバー / 株式会社コーソル渡部亮太

Copyright (C) 2013 CO-Sol Inc. All Rights Reserved

自己紹介+所属会社紹介

渡部亮太（わたべりょうた） JPOUG 共同創設者、ボードメンバー

Oracle ACE

著書「プロとしてのOracleアーキテクチャ入門」「プロとしてのOracle運用管理入門」

ブログ「コーソルDatabaseエンジニアのBlog」 http://co-sol.jp/techdb/

株式会社コーソル

「CO-Solutions＝共に解決する」の理念のもと、Oracle技術に特化した事業を展開中。心あるサービスの提供とデータベースエンジニアの育成に注力している。

社員数: 111名 (2013年11月現在)

所在地：東京千代田区（本社）、福岡

1


このセッションの概要

2 2

ブロック破損と復旧についてお話します


ブロック破損

ブロック破損とは

ひとことでいうと、Oracle Databaseに格納したデータが破損すること

Oracle Databaseのデータ保管における最小単位は「ブロック」

ブロック破損ってよく発生するの？原因は？

そうそう発生するものではありませんが、発生することもあります

発生原因の追究は一般に困難ですが、以下の要因で発生すると考えられます

1. ストレージの物理的な特性に起因するデータロス

2. 主に書き込み処理におけるOS、ドライバ、ストレージのBug

My Oracle Support Document 1323649.1 : Known Corruption issues caused by 3rd party Software Provider （参照にはサポート契約要）

3. Oracle DatabaseのBug

破損したら、どうやって対処するの？

次のスライド以降で・・・

3


破損

状況

の把握

対処

修復廃棄 or

破損

検出

破損対処の全体像

4

SQL>

破損データ

アクセス

破損の発生と破損の検出

一般にタイムラグがある

破損したデータにアクセスして初めて検出される

対処方法は修復または廃棄のいずれか


破損検出

破損データにアクセスして初めて破損を検出できる

Oracle Databaseの破損検出機能

1. SQLアクセス時の整合性チェック → ORA-1578

必須チェック / DB_BLOCK_CHECKSUM / DB_BLOCK_CHECKING

2. RMANバックアップ時の整合性チェック

3. DB_LOST_WRITE_PROTECT など

早期に検出することが重要、一般に検出が遅れると修復が困難に

5

破損

状況

の把握

対処

修復廃棄 or

破損

検出 SQL>

データ

アクセス


破損状況の把握

アクセスされていない箇所も含めた全体の破損状況を把握する

Oracle Databaseの破損検出機能

1. DBV / dbverify

2. RMAN BACKUP VALIDATE

3. データリカバリアドバイザ

6

破損

状況

の把握

対処

修復廃棄 or

破損

検出 SQL>

データ

アクセス


対処 - 修復

破損したデータを正常な状態に修復する

Oracle Databaseの破損修復機能

1. メディアリカバリ

2. RMAN blockrecover (要Enterpise Edition)

3. Auto BMR (Data Guardフィジカルスタンバイ, 要Active Data Guard)

4. ASM Scrubbing

5. スタンバイデータベースへのフェイルオーバー(厳密には修復ではないが)

元データがなければ、修復は不可能

7

破損

状況

の把握

対処

修復廃棄 or

破損

検出 SQL>

データ

アクセス


対処 - 廃棄

破損したデータだけ、または破損したデータを含むオブジェクトを廃棄

修復に活用できる元データがない場合は、修復不可

Oracle Databaseの破損廃棄機能 (一部機能ではないものも)

1. データを読み飛ばす（DBMS_REPAIRパッケージ）

[注意] “REPAIR”、“FIX”という名称の機能の実態が、実際には「廃棄」のことがある・・・

2. オブジェクトの再作成（再作成可能な場合、例：インデックス / 外部フラットファイルの再ロード）

8

破損

状況

の把握

対処

修復廃棄 or

破損

検出 SQL>

データ

アクセス


デモ - 物理破損

bbed modifyコマンドで物理破損と同様の状況をつくる

SELECT * FROM tab 実行時に発生したORA-1578で破損検出

dbvで破損状況把握

RMANブロックメディアリカバリで修復

9

破損

状況

の把握

対処

修復廃棄 or

破損

検出 SQL>

破損データ

アクセスバックアップ


データブロックのフォーマットとチェックサム

10

RDBA Typ Fmt Filler SCNBase SCN Wrap

Seq Flg

ChkVal

Tail

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

行データ格納用領域

行データの破損はチェックサムで検出できる

http://co-sol.jp/techdb/2013/11/physical_corruption_and_checksum.html


bbedコマンド

Oracle Block and Browser Editior

注意点

非公開のツールです

要ビルド

11.1以降ではビルドに必要なライブラリが削除

10.2のライブラリをコピーすればビルド可能

パスワードで保護されている

詳細はgoogle先生にお伺いを

11


破損早期検出の重要性

破損を検出した時点で、修復に必要な正常データ(破損していないデータ）があることが重要

正常なデータがない場合は、修復できない → 廃棄せざるを得ない

破損の早期検出が重要

あまりアクセスされないデータの破損は検出しにくい

12

破損バックアップバックアップ

SQL>

データ

アクセス


バックアップ時の整合性検証の有効性

バックアップ時の整合性検証は極めて重要

SQLで全データにアクセスすることは現実的でないため

バックアップ時の整合性検証

RMANではデフォルトで有効（物理破損検出可能）

定期的にバックアップしていれば、物理破損を早期に検出できる

[注意] ユーザー管理のバックアップでは整合性を検証できない

13


論理破損

定義は定まっていないが、「ブロックフォーマットの観点から見たブロックの構造には問題がないが、正常なデータが格納されていない状態」で、おおむね合意を得られるはず

論理破損の典型的なパターン

最新のブロックでない（古い）

インデックスとテーブルの整合性が取れていない

複数ブロックに配置された行断片どうしに整合性がない

主な発生原因

ストレージ機構のLost Write / Misplaced Write

Oracle DatabaseのBug

14


デモ - 論理破損

データをUPDATE ＋索引作成

表のブロックをUPDATE前の状態に戻す (bbed copyコマンド)

破損データをSELECT

破損検出されない

結果に一貫性がない

SELECT * FROM t_idx_mismatch;

SELECT * FROM t_idx_mismatch WHERE i = '2';

Data Guard REDO転送を有効化

特にエラーなし、データベース間でデータ不整合

プライマリ（論理破損）、スタンバイ（正常）

15


論理破損のやっかいさ

検出しにくい

形式的なブロックの構造には問題がない

SQLアクセスしてもエラーが発生しない場合が多い

RMANバックアップ時に破損検出されない

Lost Writeによる論理破損は一般に検出できない模様

BACKUP CHECK LOGICALで論理破損も検出可能とあるが、検証した限りではNG （ある種の論理破損であれば検出できるのかも？）

http://co-sol.jp/techdb/2013/11/annoying_lost_write_logical_corruption.html

http://co-sol.jp/techdb/2013/11/annoying_table_index_mismatch_logical_corruption.html

ちなみに、物理破損の検出は比較的容易

RMANバックアップ時に破損検出されるため

もちろん、SQLアクセスでもエラー発生

検出されない間に修復の元ネタが失われる可能性

一般に、破損発生前のバックアップが修復の元ネタとして使用される

破損発生前のバックアップが廃棄されると修復できない

16









"Lost Write"と論理破損

論理破損の発生要因は多くあると思われるが一般的に大部分の要因は“Lost Write”と考えられている

データファイルに対するブロックの更新処理が「ロストする」現象

17

SQL>

UPDATE SCN:100 SCN:200

SQL>

UPDATE SCN:100 SCN:200

正常動作

Lost Write


DB_LOST_WRITE_PROTECT

DB_LOST_WRITE_PROTECT （長いのでDLWPと略）

Oracle Database 11.1から導入

Data Guard構成と併用することで、Lost Writeを早期検出して、データベースを保護できる

シングル構成でも一応使用できるが、効果は限定的

TYPICAL or FULLで、ブロックの物理読み込み時に、Block Read Redoと呼ばれるREDOが生成されるようになる

デフォルトNONE：無効

18


Lost Writeを検出する仕組み

1. 物理読み込み時にBlock Read Redo(BRR)を生成

ブロックの物理読み込み時にBRR を生成

BRRのSCNは読み込んだブロックのSCN

REDOのop codeは23.2 19

CHANGE #4 CON_ID:0 TYP:0 CLS:4 AFN:4 DBA:0x01000026 OBJ:19202 SCN:0x0000.00080dbc SEQ:1 OP:23.2 ENC:0 RBL:0 Block Read - afn: 4 rdba: 0x01000026 BFT:(1024,16777254) non-BFT:(4,38) scn: 0x0000.00080dbc seq: 0x01 flags: 0x00000004 ( ckval )

プライマリDB スタンバイDB

19

SQL>

SELECT

REDO転送

破損ブロック SCN:100

正常ブロック SCN:200


Lost Writeを検出する仕組み

2. BRRによるLost Write検出

スタンバイデータベースでBRRを適用したとき、 BRRのSCN < ブロックのSCN を検出するとORA-752を発生させるため、プライマリデータベースでのLost Write発生を検出できる

20


BRR SCN:100

REDO転送




デモ - DB_LOST_WRITE_PROTECT

DB_LOST_WRITE_PROTECT=NONE[デ] ＋論理破損

プライマリで発生したLost Writeによる論理破損を検出できない

結果として、プライマリとスタンバイ間でデータの不整合が発生

先ほど実行したデモに相当

DB_LOST_WRITE_PROTECT=TYPICAL (or FULL) ＋論理破損

スタンバイでORA-752が発生するため、Lost Writeによる論理破損を検出できる

スタンバイにフェイルオーバーして、正常（未破損）データで運用継続可能

旧プライマリはスタンバイとして再作成

21


論理破損の早期検出とDLWP

22



SQL>


SELECT

REDO転送

BRR SCN:100

SQL>

SELECT

REDO転送

DB_LOST_WRITE_PROTECT=NONE [デ]

DB_LOST_WRITE_PROTECT= TYPICAL or FULL




ASM Disk Scrubbing

Oracle Database 12cより導入された論理破損の修復機能

ASMディスクグループのミラーを、修復の元ネタにする

仕組み的にはLost Writeによる論理破損の修復にも有効なはずだが・・・検証しましたがうまく動きませんでした orz

ALTER DISKGROUP data SCRUB; しても、破損ブロックが修復されない

そもそも破損検出の仕組みとセットでないと、運用には乗せにくいか

機能拡張、動作メカニズムの公開を期待かな・・・と個人的には結論

23


まとめに代えて

Oracle Databaseには、従来から物理破損を検出できる機能が実装されているため、早期検出による影響範囲の最小化、修復が可能です。

Oracle Database 11gにて、論理破損についても機能の強化が図られていますが、アーキテクチャ上の制約から、早期検出が有効に機能するのは事実上Data Guard構成に限定されることに注意してください。

Oracle Database 12c ではASMディスクグループのミラー機能を活用した修復機能(ASM Scrubbing)が導入されており、 Data Guardを使用していない環境でも、データの修復可能性が高くなっているようですが、検証で思うような結果が得られませんでした。機会を見て再度検証を行う予定です。

24

corruption and revive - db tech showcase 2013 特濃jpoug

Technology