【IRIS/Cache】エラーで起動しない時の対処方法

内部でエラーが発生し、インスタンスが起動しない時のトラブルシューティングです。

もしインスタンスがエラーで起動しない時は、この記事を一読してみて下さい。
解決の糸口になれば幸いです。

はじめに
.WIJファイルに異常が派生したケース
ジャーナルに異常が派生したケース
おわりに

はじめに

この記事では、下記２つの事例に沿って解決方法をご紹介します。

インスタンスが起動しないケース

.WIJファイルに異常が発生したケース
ジャーナルに異常が派生したケース

※他の事例に遭遇したら、都度追記していきます。

システム部分でエラーを確認したら、兎にも角にもログファイル(IRIS=messages.log, cache=cconsole.log)を確認しましょう。
そこには、解決するための何らかのメッセージが記載されています。

.WIJファイルに異常が派生したケース

ログファイルを確認すると、下記表示が記載されています。
また、「MISMATCH.WIJ file」とも記載されています。

上記赤枠部分は、コマンドプロンプトを起動し２つのコマンドを実行し、状況の改善を試みろと記載しています。

先ずは、コマンドプロンプトにて下記コマンドを実行し、コマンドプロンプトからIRIS(Cache)へ接続を行いましょう。
コマンド実行後、いつもの見慣れたターミナル表示になります。

d:\[インストールディレクトリ]\bin\cache -sd:\[インストールディレクトリ]\mgr -B

IRIS(Cache)接続後は、通常のターミナルと同様のコマンドが実行可能です。
ログインが必要であれば、併せて行って下さい。

下記サンプル画面は、ログインとコマンド「D ^STURECOV」を実行した直後の画面になります。

表示されている文面を下記に記載します。

The system crashed and some database blocks do not match what was expected based on the contents of write image journal (the WIJ).
The WIJ blocks have been placed in the MISMATCH.WIJ file.
If any database files, or the WIJ, were modified or replaced since the crash, you should delete the MISMATCH.WIJ.
Otherwise, MISMATCH.WIJ probably contains blocks that were lost due to a disk problem.
You can view those blocks and apply them if necessary.
When finished, delete the MISMATCH.WIJ in order to continue startup.

システムがクラッシュし、一部のデータベースブロックが書き込みイメージジャーナル (WIJ) の内容に基づいて予測されたものと一致しません。
WIJ ブロックは MISMATCH.WIJ ファイルに配置されています。
クラッシュ以降にデータベースファイルまたは WIJ が変更または置換された場合は、MISMATCH.WIJ を削除する必要があります。
それ以外の場合は、MISMATCH.WIJ にディスクの問題により失われたブロックが含まれている可能性があります。
これらのブロックを表示し、必要に応じて適用できます。
終了したら、起動を続行するために MISMATCH.WIJ を削除してください。

データベースとWIJファイルに相違が発生している旨と、この問題を解決するには、WIJファイルの削除が必要と記載されています。

正常に復旧を目指すのであれば、諸々手続きが必要ですが、今回はデータの保全より早期復旧を目指します。

コマンドプロンプトより、「3) Delete MISMATCH.WIJ」を選択し、WIJファイルを削除しましょう。

WIJファイル削除後、コマンドプロンプトに以下の確認メッセージが表示されます。

Do you want to broadcast a message to anyone? No =>
（メッセージを誰かにブロードキャストしますか?）
Do you want to see the Cache status report? No =>
（キャッシュステータスレポートを表示しますか?）
Do you want to run the user defined shutdown routine? Yes =>
（ユーザー定義のシャットダウンルーチンを実行しますか?）
Are you ready for the system to halt? Yes =>
（システムを停止する準備はできていますか?）

特に無ければ、「Enter」４回で問題ありません。
インスタンスは静かにシャットダウンします。

その後、高確立で各データベースにロックファイル(.lck)が残存しています。
　→残存の程度は、クラッシュした部位やタイミングによります。

これらは、データベースのロックファイルは、インスタンスの起動に邪魔しかならないので、削除します。

以上で復旧作業が完了となります。
稀にエラーが複合しているケースがあり、再起動後に別のエラーで再度システムが起動しない事がありますが、同様にログファイルを確認して対応して下さい。

ジャーナルに異常が派生したケース

ログファイルを確認すると、下記表示が記載されています。
　※先ほどのケースと同じコマンドになります

また「errors during journal restore」と記載されています。

作業の流れは、[コマンドプロンプト] > [接続] > 「D ^STURECOV」まで同じ流れになります。

同じコマンドを実行しますが、今回のケースはジャーナルのエラーなので、ジャーナルのリカバリーオプションが表示されています。

今回も復旧を優先します。
「8) Reset system so journal is not restored at startup」を選択して下さい。

選択後、コマンドプロンプト上に下記メッセージが表示されます。

If you erase this information then journal restore and transaction rollback will not occur when the system is brought up in multi-user mode.
Use this if you are going to restore the journal manually after users are allowed on the system.
The console log will contain the current journal file name and the position in the journal file to start the restore (the number preceding the journal file name).

Are you sure you want to do this?

この情報を消去すると、システムがマルチユーザーモードで起動されたときに、ジャーナルの復元とトランザクションのロールバックは行われません。
ユーザーがシステムにアクセスできるようにした後で、ジャーナルを手動で復元する場合は、これを使用します。
コンソールログには、現在のジャーナルファイル名と、復元を開始するジャーナルファイル内の位置 (ジャーナルファイル名の前の番号) が含まれます。

本当にこれを実行しますか?

とりあえず「Y」を入力します。

コマンド実行後の流れは、ロックファイルの残存を確認しておきます。
残存していれば削除を行って下さい。