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

「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; ←これで戻ります

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

データの論理破壊

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

SQL> shutdown immediate
SQL> startup mount
SQL> flashback database to restore point ;
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;

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

データブロックが破損

• 商品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;

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

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

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

原因不明の障害が発生

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

DGMGRL> validate database osaka
DGMGRL> failover to osaka;

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

再び、表データが消えた

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

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

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

最後に

• OracleMAA構成は業務影響を極小化
• MAA構成を組むことがゴールではない
  • 万が一の際に迅速に復旧オペレーションができるのかが大事
  • 障害を想定した運用設計/実装を充実させる
  • 日頃から復旧手順を確認する
• ORAChkで今回紹介した機能が使えるかどうかが判断できます

@mogmetの所感

実践で使える目から鱗な技術でとても参考になるセッションでした。

表データが消えた時はrecover tableまではすぐにおもいついたのですが、スタンバイDBから戻すという方法もいい方法だとおもいました。