#odc16 DB障害解決の極意:しばちょう先生の特別講義!! 実体験に基づくトラブル対応と対策案 @Oracle Database Connect 2016まとめ

公開日：2016/05/12

「Oracle Database」のエンジニアを対象にデータベース運用のためのテクニックなどに関するノウハウを紹介するイベントOracle Database Connect 2016に参加してきました。

その時のリカバリテクニックについてのセッションのまとめです。

日本オラクル株式会社

柴田長様

表データが消えた

検証DBをメンテナンス中に本番側でアラート報告
- ORA-942（表やビューが存在しない）が発生
- →DBAが誤って消してしまっていた
この場合はFlashbackドロップで戻せる
demo

SQL> drop table table;
SQL> show recytclebin
SQL> flashback table TAB1 to before drop; ←これで戻ります

SQL> drop table table;

SQL> show recytclebin

SQL> flashback table TAB1 to before drop; ←これで戻ります

索引も回復するが、参照性整合性役は消えているので再設定をしましょう
ちなみにゴミが貯まると性能問題が起こるので注意

データの論理破壊

DB用のDML文の実行順序を誤っていたことが発覚
- バックアップからのリカバリ！と思ったが、4TBのリストアや1日分のredoでリカバリとなると間に合わない
→Flashbackデータベースで戻せる
予めバッチ処理の前にrestore pointを作っておく

SQL> shutdown immediate
SQL> startup mount
SQL> flashback database to restore point <before_batch>;
SQL> alter database open resetlogs;

SQL> shutdown immediate

SQL> startup mount

SQL> flashback database to restore point <before_batch>;

SQL> alter database open resetlogs;

戻っているかどうか確認する場合はREAD ONLYでopenして確認する
- 巻き戻しが不十分ならflashbac database
- 巻き戻しすぎならrecover database
- 期待通りならopen reset logs

データファイルを消してしまった

オペミスで開発環境のデータを削除してしまった
- flashback dropで戻せると思ったが、rmコマンドでデータファイルのディレクトリを削除してしまった
→rmanのswitchコマンドで短時間で戻せる

$ rm -f データファイル
SQL> alter system checkpoint;
SQL> alter system checkpoint;
SQL> alter system checkpoint;
SQL> select * from v$datafile;

$ rman target /
RMAN> switch datafile 5 to copy;
RMAN> recover datafile 5;

$ sqlplus / as sysdba
SQL> alter database datafile 5 online;

$ rm -f データファイル

SQL> alter system checkpoint;

SQL> select * from v$datafile;

$ rman target /

RMAN> switch datafile 5 to copy;

RMAN> recover datafile 5;

$ sqlplus / as sysdba

SQL> alter database datafile 5 online;

バックアップファイルをみるように変えている

データブロックが破損

商品XYZの検索時のみ、ORA-1578が発生
- BlockMediaRecoveryで修復できる
- 環境のバックアップはストレージ側のミラーコピー機能で取得している
- データファイルのリストア+リカバリは時間がかかりすぎる
→ActiveDataGuardの自動ブロック修復を使えば直せる

SQL> select * from TBL1;

-- ブロック破損させる (dd) --

SQL> select * from TBL1;
ora-01578!!

-- 破損ブロックの確認 -- 
SQL> select name, value from v$database_block_corruption;

$ rman target /
RMAN> recover datafile 5 block 154;

SQL> select * from TBL1;

-- ブロック破損させる (dd) --

SQL> select * from TBL1;

ora-01578!!

-- 破損ブロックの確認 --

SQL> select name, value from v$database_block_corruption;

$ rman target /

RMAN> recover datafile 5 block 154;

rmanはスタンバイdatabase→flashback log→rman次の順序で正常ブロックを検索する

Active Data Guardによる透過的なブロック修復

SQL発行してプライマリDBでblock破損を検知したらスタンバイに正常blockを要求して自動転送し、自動的にリカバリされる。
ASM mirrorで修復施行も可能

原因不明の障害が発生

業務処理が戻ってこないと現場からアラートが上がっている
- しかしなかなか原因がわからない
→まずはDataGuardでフェイルオーバーして業務継続を確保した上で原因を特定する

DGMGRL> validate database osaka
DGMGRL> failover to osaka;

1 2	DGMGRL> validate database osaka DGMGRL> failover to osaka;

何分間か原因調査してだめだったらフェイルオーバーするといった指針にするといい

再び、表データが消えた

日中の業務開始後に、昨晩のバッチ処理でtruncateされていたことがあとから判明した
- dataguardのstandbyは使えない
- リストア+リカバリやfalshback databaseだと他の表も全て戻る
→12cだと表単位のリカバリもできる
- 11gR2以前の場合はDataGuardとFlashbackを使う

RMAN> recover table テーブル名 until time ...;
→その後、リカバリーしたテーブルをimpdpで現在のテーブルにappendする

1 2	RMAN> recover table テーブル名 until time ...; →その後、リカバリーしたテーブルをimpdpで現在のテーブルにappendする

DBの部分バックアップを代替の場所にリストアしてrecoverする方法
しばちょうさんの場合は以下のようにやる
- Flashback databaseでスタンバイDBをtruncate前まで戻す
- standby databaseをsnapshot standbyモードで起動する
- standby databaseからdatapumpで対照表をエクスポートする
- primary databaseへdatapumpで追記型インポートする