前回のおさらい

前回、「UNDO障害（2/2）」では、Dさんが TEMP表領域 も UNDO表領域 もバックアップしてなく復旧できないという絶望的な状態で終わりました。

しかし、何か閃いたたろーちゃん。
この後、どうなるのでしょうか❓❗

復旧への道のり

たろー「先輩、 コールドバックアップ を取得する時、データベースはどのモードで shutdown していますか？」
Dさん「 immediate だ。」
たろー「 abort じゃないんですね？」
Dさん「勿論だ。 abort なんて、恐くて使ってないよ。」
たろー「であれば、方法があるかもしれません。」
Dさん「なに？本当か？！」
たろー「ちょっと失礼します。」

 

 

 

 

 

SQL> alter database open ;

＜アラートログファイル内＞
Errors in file /opt/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_9051.trc:
ORA-01157: データファイル4を識別/ロックできません - DBWRトレース・ファイルを参照してください
ORA-01110: データファイル4: '/opt/app/oracle/oradata/orcl/undotbs01.dbf'
ORA-1157 signalled during: ALTER DATABASE OPEN...

Errors in file /opt/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_9053.trc:
ORA-01110: データファイル4: '/opt/app/oracle/oradata/orcl/undotbs01.dbf'
ORA-01565: ファイル'/opt/app/oracle/oradata/orcl/undotbs01.dbf'の識別中にエラーが発生しました
ORA-27037: ファイル・ステータスを取得できません。
Linux-x86_64 Error: 2: No such file or directory
Additional information: 7
Checker run found 1 new persistent data failures

 

Dさん「それはさっき試したよな？制御ファイルに記録されているUNDOデータファイルが無いからOPEN出来ないんだよ。」

たろー「そうです。では、制御ファイルにUNDOデータファイルの存在を忘れてもらいましょう。」

 

SQL> alter database datafile '/opt/app/oracle/oradata/orcl/undotbs01.dbf' offline drop;

データベースが変更されました。

 

Dさん「何❓❗」

 

 

たろー「これなら・・・」

 

SQL> alter database open ;

データベースが変更されました。

 

Dさん「OPEN出来た！」

たろー「そして、代わりのUNDO表領域を用意します。」

 

SQL> create undo tablespace UNDOTBS2 datafile '/opt/app/oracle/oradata/orcl/undotbs02.dbf' size 1G;

表領域が作成されました。

 

Dさん「❗」

 

たろー「次に、初期化パラメータの変更です。」

 

SQL> show parameter undo_tablespace 

NAME             TYPE    VALUE
---------------  ------- ---------
undo_tablespace  string  UNDOTBS1


SQL> alter system set undo_tablespace='UNDOTBS2' ;

システムが変更されました。

SQL> show parameter undo_tablespace 

NAME             TYPE    VALUE
---------------  ------- ---------
undo_tablespace  string  UNDOTBS2

 

Dさん「これで、データベースが使える！」
たろー「待って下さい。さっき offline drop した UNDOTBS1の情報が、まだ残っています。それを削除しましょう。」

 

SQL > SELECT TABLESPACE_NAME FROM DBA_TABLESPACES ORDER BY TABLESPACE_NAME ;

TABLESPACE_NAME
--------------------------------------------------------------------------------
INDEX
SYSAUX
SYSTEM
TABLE
TEMP
UNDOTBS1
UNDOTBS2


SQL > drop tablespace UNDOTBS1 ;

表領域が削除されました。


SQL > SELECT TABLESPACE_NAME FROM DBA_TABLESPACES ORDER BY TABLESPACE_NAME ;

TABLESPACE_NAME
--------------------------------------------------------------------------------
INDEX
SYSAUX
SYSTEM
TABLE
TEMP
UNDOTBS2

 

Dさん「DBA_TABLESPACESからUNDOTBS1が消えた！」
たろー「これで使えるはずです。先輩、動作確認をお願いします。」
Dさん「わかった！」

---

Dさんは動作確認を行い、問題なくシステムが稼働するのを確認出来ました。

Dさん「ありがとう、たろーちゃん！今のところ、問題なくシステムが動作している。」
たろー「よかったです。ただ、いつまたディスク障害が発生するか分かりません。今のうちに、一緒にバックアップ設計を考えましょう。」
Dさん「ああ、そうだな！」

Dさん「………データベースがOPEN出来ないときは、もうダメだと思った。辞表を書くつもりでいたよ。」
たろー「そんな、先輩。大袈裟な。」
Dさん「ありがとう（泣）」

 

DBAって孤独なんですよね。
データベースがOPEN出来ない時の恐怖は、経験したことのある人じゃないと分からないです。
そんな人を救うことが出来てよかった！

 

 

 

今回、Dさんはラッキーでした。

●　 コールドバックアップ 時のデータベースの停止を immediate で実行していた。
●　ディスク障害がオンライン時間帯ではなく、データベースが完全停止している時に発生した。

どちらの条件も満たせなかった場合、データベースは復旧出来なかったでしょう。

UNDOの役割

UNDOについて、ここでもう一度振り返ってみましょう。
UNDOには主に３つの役割があります。

●トランザクションのロールバック
DML(INSERT、DELETE、UPDATE)文を発行すると、データベースへの変更を行う「トランザクション」がスタートします。
トランザクションは、ロールバック又はコミットするまで継続します。
ROLLBACK文を発行すると、コミットされていないデータベースに加えられた変更が、UNDOデータを使用して取り消されます。

● 読み込み一貫性の提供
読み取り一貫性とは、あるユーザが変更しているコミットされていない情報を、他のユーザがアクセスした時に、更新処理中の情報を提供するのではなく、変更前の情報を提供する機能です。

● クラッシュリカバリ
トランザクション実行中にデータベースが障害等で停止した場合、次回インスタンスを起動しようとすると、コミットされていない情報がUNDOデータを使用してロールバックされます。

 

今回のシステムでは、コールドバックアップ取得時に、データベースを abort ではなく immediate で停止していました。
immediate はトランザクションをロールバックしてから停止するため、

次回インスタンス起動時にUNDOデータを必要としません。

一方、 abort はロールバックせずに強制停止します。
つまり、次回インスタンス起動時にクラッシュリカバリが実行されるため、UNDOデータが必要となります。

コールドバックアップ取得時に immediate で停止しており、インスタンス起動時にUNDOデータを必要としなかったため、なんとかデータベースをOPENすることが出来たのです。

 

まさに紙一重でした。

 

 

---

今回の「心臓外科医の術式」いかがだったでしょうか？
システムの復旧（蘇生）までの、見事な「術式」だったのではないでしょうか？
次回も頑張りますので、応援よろしくお願い致します。

 

Dさんは技術者としては、確かに未熟だったかもわかりません。
でもDさんを責めないであげて欲しい。
Dさんは御客様から厳しいコスト削減を要求されました。
その要求に応えようと必死に考え、思いついたのがディスク容量の削減でした。
少しでも御客様の御要望に沿った形でシステムを提供しようと努力した結果だったのです。
それだけは、酌んであげて欲しいです。

 

 

 

 

 

たろーちゃんナイスだよっ❗