前回のおさらい

前回「動かない心臓(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課長「・・・。」
たろー「H課長、あなたは begin backup さえして、なおかつ OPEN RESETLOGS すれば、少なくともその地点までは戻せると思っていませんでしたか?」
H課長「❗・・・」

H課長

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

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

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

最後の手段

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

H課長

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

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

たろー

新人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

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

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


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

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


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

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

部長

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

H課長

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

たろー

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

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

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

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

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

 

投稿者プロフィール

たろーちゃん
たろーちゃん
株式会社システムサポート インフラソリューション事業部に在籍するPlatinumホルダー。
Oracle Databaseのパフォーマンスチューニングを得意とする。
データベースは Oracle 以外興味がないという変わり者。
一番嫌いなエラーメッセージは CRS-02625。
連載「心臓外科医の術式」を執筆。