動かない心臓（2/2）

2019年5月15日『心臓外科医の術式』

1 前回のおさらい
2 なぜ復旧できないのか？
3 最後の手段

前回のおさらい

前回「動かない心臓（1/2）」では、いじわるなH課長の担当するシステムでデータベース障害が発生し、たろーちゃんが緊急招集されましたが、
なんと アーカイブログが無いということが発覚しました😱

果たして、復旧できるのでしょうか❓

ここで改めて人物相関図を見てみましょう。

今回登場しないAさん、Dさんについては、過去記事『正体不明のパフォーマンス悪化の謎を解き明かせ！(1/2)』および『UNDO障害（1/2）』をご参照下さい❗

なぜ復旧できないのか？

たろー「どうして最後にアーカイブログを全削除しているんですか？」
H課長「昔、私が関わったプロジェクトで、アーカイブログ領域が溢れてデータベースが停止したことがあった。そのためアーカイブログ領域はなるべく空けるようにしている。これは私の経験に基づく設計だ。バックアップを取得すれば、それまでのアーカイブログは必要ない。だから全削除してるんだ。」
たろー「いや、そのアーカイブログが必要なんですよ。」
H課長「なに？！」
たろー「完全リカバリを行うには、スナップショット取得時点からの全アーカイブログが必要なんです。」
H課長「だから alter database begin backup はちゃんと行っているぞ？！」
たろー「違うんです、H課長。この際begin backupは関係ないんです。データファイルが正しい状態になっていないんです。」
H課長「いいや！少なくとも begin backup時点には戻せる筈だ。不完全リカバリは出来る筈だ！」
たろー「いいえ、不完全リカバリすら出来ないんです。H課長の理屈だと、ノーアーカイブログモードでもオンラインバックアップが取得出来ることになりませんか？」
H課長「❗」
たろー「オンラインバックアップである以上、アーカイブログは必須なんです。少なくとも、スナップショット取得直後からの物は。この手順では、alter system archive log current した一番大切なアーカイブログ が消されてしまっています。」

部長

部長「二人ともちょっと落ち着いて。一体どういうことかね？」
たろー「残念ながら、この Oracle Database は死にました。」

たろー

部長「おいおい、冗談はよしてくれ。バックアップがあるから元に戻せるんだろう？」
たろー「いいえ、リカバリに必要なアーカイブログが無いんです。復旧は出来ません。」
部長「なんだって？！」
H課長「・・・。」
たろー「Ｈ課長、あなたは begin backup さえして、なおかつ OPEN RESETLOGS すれば、少なくともその地点までは戻せると思っていませんでしたか？」
H課長「❗・・・」

H課長

たろー「バックアップの取得手順は順番を変えて、せめてこうしなければダメです。」

● スナップショットを取得するため、alter database begin backup を実行する。
● データ領域のスナップショットを取得する。
● スナップショット取得後、 alter database end backup を実行する。
● alter system archive log current を実行する。
● アーカイブログ領域のスナップショットを取得する。
● 領域確保のため、直近１時間分は残して、アーカイブログファイルを削除する。（SYSDATE-(1/24)）

たろー「こうすれば、少なくともスナップショット取得時点に不完全リカバリが出来ます。
たとえ Oracle側のアーカイブログ領域が壊れたとしても、です。」
H課長「・・・。」
たろー「 RMAN を使っておけば、こんな事にはならなかった筈です。」

最後の手段

部長「このシステムは、もう元に戻らないのかね？！」
H課長「・・・。」
部長「H課長？！」

H課長

Ｈ課長は顔面蒼白になっていました。

たろー「・・・Ｔさん、試したいことがあるんだ。ちょっと手伝ってくれるかな。」

たろー

新人T「は、はい！」
たろー「この手順を試してみてくれ。」

● データベースを MOUNT モードにする。
● spfile から pfile を作成する。
● pfile をテキストエディタで編集して、隠しパラメータ “_allow_resetlogs_corruption” を true に設定する。
● shutdown immediate でデータベースを停止する。
● startup mount pfile=’フルパスinitファイル名’ でデータベースを MOUNT モードにする。
● alter session set events ‘10015 trace name adjust_scn level 1’; を実行する。
● recover database until cancel; を実行する。プロンプトが表示されるので、CANCEL を入力する。
● alter database open resetlogs; でデータベースの OPEN を試みる。

新人T（カタカタカタ）
新人T「ダメです、OPEN出来ません。」
たろー「もう一回shutdown immediate から試してみてくれ。但し、次は adjust_scn level 2 で実行するんだ。」

新人T（カタカタカタ）
新人T「ダメです、OPEN出来ません。」
たろー「adjust_scn level に指定する数字を1ずつ増やしてくれ。それをOPEN出来るまで繰り返してみて。」
新人T「はい！」

新人T

Ｔさんは何度も繰り返し、adjust_scn level 9 で OPENした時・・・。

新人T（カタカタカタ）
新人T「あ！OPEN出来ました！」
H課長「❗」
たろー「運がいいな。今のうちに業務データを Datapump で全て出力するんだ。」
新人T「はい！」

Ｔさんは expdp で全業務データの抽出に成功しました。

たろー「この Oracle Database は、もう死んでいる。新しくデータベースを作り直すぞ。」
新人T「はい！」

このあと、たろーちゃんとＴさんは DBCA で新たにデータベースを作成し、impdp で全業務データをインポートして、なんとか業務で使える状態に復元しました。

部長「たろーちゃん！ありがとう！！あのままデータが戻らなければ、大問題だった！」

部長

たろー「いいえ、復元できたのは運がよかっただけです。あの方法でも復元できないことのほうが多いので。」
部長「しかし、どういうことなんだ？
たろーちゃんがレビューして、こんなことになるなんて・・・。」
H課長「！」
たろー「いいえ、私はレビューしていませんよ。」
部長「なんだって？！」
たろー「Ｈ課長に、『レビューアは間に合ってる』と言われまして。」
部長「Ｈ課長、どういうことかね。私は君から『たろーちゃんのレビューを受けた』との報告を受けているが？！」
H課長「え、あ、いや、それは・・・。」

H課長

なんとＨ課長は部長に虚偽報告まで行っていました。
これには流石のたろーちゃんも呆れ顔・・・。

たろー

今回の「心臓外科医の術式」いかがだったでしょうか？
本来なら復旧できない障害を、裏ワザを使ってなんとか復旧することが出来ました。
バックアップは大切です。

今回は運よく復旧出来ましたが、この裏ワザがいつも成功するとは限りません。
（むしろ失敗することのほうが多いです。）
特に RMAN を使わず、ユーザー管理のバックアップ方式でオンラインバックアップされている方は、注意して下さい。

そして、RMAN を使う場合でもユーザー管理の場合でも、リストア＆リカバリの試験は必ず実施しましょう。
元に戻せないバックアップなんて、意味ないですからね。

それでは次回も頑張りますので、応援よろしくお願い致します。

しかし今回の出来事が、のちにH課長の恨みを買うことになるとは、
この時のたろーちゃんは、知る由もありませんでした・・・。

投稿者プロフィール

DBひとりでできるもん運営チーム

「DBひとりでできるもん」運営チームです。
「親しみやすさと技術力」をテーマに、技術情報・サービス・インフラ系資格取得に役立つ情報、社員等の情報をお届けします。
70名弱の事業部員で鋭意、執筆中です。
少しでも当社を知って頂けるよう、愛情込めて頑張ります！
※facebook、X(旧twitter)、インスタグラムでは「DBひとりでできるもん」の更新情報を発信しています。