Corruption And Revive - db tech showcase 2013 特濃JPOUG

Corruption And Revive

2013年11月15日

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

自己紹介+所属会社紹介
 渡部亮太（わたべりょうた）
 JPOUG 共同創設者、ボードメンバー
 Oracle ACE
 著書「プロとしてのOracleアーキテクチャ入門」
「プロとしてのOracle運用管理入門」
 ブログ「コーソルDatabaseエンジニアのBlog」
http://co-sol.jp/techdb/

 株式会社コーソル
 「CO-Solutions＝共に解決する」の理念のもと、Oracle技術に特化した事
業を展開中。心あるサービスの提供とデータベースエンジニアの育成に注力して
いる。
 社員数: 111名 (2013年11月現在)
 所在地：東京千代田区（本社）、福岡

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

1

このセッションの概要
 ブロック破損と復旧についてお話します


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

破損対処の全体像
破損

データ
アクセス
SQL>

破損
検出

破損
状況
の把握

対処
修復 or

廃棄

 破損の発生と破損の検出
 一般にタイムラグがある
 破損したデータにアクセスして初めて検出される

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


4

破損検出
データ
アクセス
SQL>

破損
検出

破損
状況
の把握

対処
修復 or

廃棄

 破損データにアクセスして初めて破損を検出できる
 Oracle Databaseの破損検出機能
1. SQLアクセス時の整合性チェック → ORA-1578
 必須チェック / DB_BLOCK_CHECKSUM / DB_BLOCK_CHECKING

2. RMANバックアップ時の整合性チェック
3. DB_LOST_WRITE_PROTECT など

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

5

破損状況の把握
データ
アクセス
SQL>

破損
検出

破損
状況
の把握

対処
修復 or

廃棄

 アクセスされていない箇所も含めた全体の破損状況を把握する
 Oracle Databaseの破損検出機能
1. DBV / dbverify
2. RMAN BACKUP VALIDATE
3. データリカバリアドバイザ


6

対処 - 修復
データ
アクセス
SQL>

破損
検出

破損
状況
の把握

対処
修復 or

廃棄

 破損したデータを正常な状態に修復する
 Oracle Databaseの破損修復機能
1.
2.
3.
4.
5.

メディアリカバリ
RMAN blockrecover (要Enterpise Edition)
Auto BMR (Data Guardフィジカルスタンバイ, 要Active Data Guard)
ASM Scrubbing
スタンバイデータベースへのフェイルオーバー(厳密には修復ではないが)

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

7

対処 - 廃棄
データ
アクセス
SQL>

破損
検出

破損
状況
の把握

対処
修復 or

廃棄

 破損したデータだけ、または破損したデータを含むオブジェクトを廃棄
 修復に活用できる元データがない場合は、修復不可

 Oracle Databaseの破損廃棄機能

(一部機能ではないものも)

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

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

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

8

デモ - 物理破損
バックアップ

破損

データ
アクセス
SQL>

破損
検出

破損
状況
の把握

対処
修復 or

廃棄

 bbed modifyコマンドで物理破損と同様の状況をつくる
 SELECT * FROM tab 実行時に発生したORA-1578で破損検
出
 dbvで破損状況把握
 RMANブロックメディアリカバリで修復


9

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

1

Typ Fmt

2

3

4

Filler

5

6

7

8

RDBA

9

10 11 12 13 14 15

SCNBase

SCN
Seq Flg
Wrap

ChkVal

行データ格納用領域
Tail
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


10

bbedコマンド
 Oracle Block and Browser Editior
 注意点
 非公開のツールです
 要ビルド
 11.1以降ではビルドに必要なライブラリが削除
 10.2のライブラリをコピーすればビルド可能

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

 詳細はgoogle先生にお伺いを


11

破損早期検出の重要性
バックアップ

破損

バックアップ

データ
アクセス
SQL>

 破損を検出した時点で、修復に必要な正常データ(破損していない
データ）があることが重要
 正常なデータがない場合は、修復できない → 廃棄せざるを得ない

 破損の早期検出が重要
 あまりアクセスされないデータの破損は検出しにくい


12

バックアップ時の整合性検証の有効性
 バックアップ時の整合性検証は極めて重要
 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”と考えられている
 データファイルに対するブロックの更新処理が「ロストする」現象
正常動作
SQL>

UPDATE
SCN:100

SCN:200

SCN:100

SCN:200

Lost Write
SQL>

UPDATE


17

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を検出する仕組み
プライマリDB

スタンバイDB
REDO転送

SQL>

SELECT
破損ブロック

正常ブロック

SCN:100

SCN:200

 1. 物理読み込み時にBlock Read Redo(BRR)を生成
 ブロックの物理読み込み時にBRR を生成
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 )

 BRRのSCNは読み込んだブロックのSCN
 REDOのop codeは23.2

19

Lost Writeを検出する仕組み
プライマリDB

スタンバイDB
REDO転送

BRR
破損ブロック

SCN:100

SCN:100

正常ブロック
SCN:200

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


20

デモ -

DB_LOST_WRITE_PROTECT

 DB_LOST_WRITE_PROTECT=NONE[デ] ＋論理破損
 プライマリで発生したLost Writeによる論理破損を検出できない
 結果として、プライマリとスタンバイ間でデータの不整合が発生
 先ほど実行したデモに相当

 DB_LOST_WRITE_PROTECT=TYPICAL (or FULL) ＋論
理破損
 スタンバイでORA-752が発生するため、Lost Writeによる論理破損を検出
できる
 スタンバイにフェイルオーバーして、正常（未破損）データで運用継続可能
 旧プライマリはスタンバイとして再作成


21

論理破損の早期検出とDLWP
DB_LOST_WRITE_PROTECT=NONE [デ]
プライマリDB

スタンバイDB
REDO転送

SQL>

SELECT
破損ブロック

正常ブロック

SCN:100

SCN:200

DB_LOST_WRITE_PROTECT= TYPICAL or FULL
REDO転送
SQL>

SELECT

BRR
破損ブロック
SCN:100


SCN:100

正常ブロック
SCN:200
22

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Corruption And Revive - db tech showcase 2013 特濃JPOUG

Similar to Corruption And Revive - db tech showcase 2013 特濃JPOUG (20)

Recently uploaded

Recently uploaded (8)

Corruption And Revive - db tech showcase 2013 特濃JPOUG