はじめに
ある日、USERネームスペースにデータを書き込もうとしたとき、<PROTECT>エラーが発生しました。
そもそも<PROTECT>エラーなんて、普段見たことないよ!
と、原因の目星がつかない状態でした。
今回は、この問題の原因と解決方法について記載したいと思います。
原因
原因自体は、とても簡単な事でした。
なんらかのシステム問題により、Cacheがシャットダウンした後、USERネームスペースのデータベースにロックファイル(.lck)が残ったままになっていました。
※システムに発生した問題自体は、残念ながら不明です。
そんな事はつゆ知らずCacheを起動した際、USERネームスペースはロックファイルが残っている事により、データベースのステータスが「マウント/R」となりました。
つまり書き込みが出来ない状態ですね。
このステータスの状況が<PROTECT>エラーになります。
この状態では、ディスマウントとマウントを繰り返してもステータスが一向に「マウント/RW」になりません。
当然、データベースを読込み専用でマウントもしていません。
また、データベースをディスマウントした状態でも「.lck」ファイルが残る不思議な状態です。
結局、この「.lck」ファイルを削除する事により、マウント時にステータスに書き込み権限が付与される事になりました。
解決方法は、手動による「.lck」ファイルの削除でした。
御覧の通り、見事ステータスが「マウント/RW」になっています。
解決までに時間がかかった原因
- <PROTECT>エラーが初見だった
- 「.lck」ファイルが残存している状態だと、システムが起動しないと思い込んでいた
<PROTECT>エラーについて
わかり難い・・・
しかも何をどうすれば解決するのかピンとこない説明文ですね。
「認証のないまま」の文言に引っかかりを覚えて、データベースのステータスを確認したら、「マウント/R」の状態でした。
今回の問題によって、<PROTECT>エラーは、読み込み専用のデータベースに書き込みを行う際に発生する事を認識しました。
.lckファイルがあるとシステムが起動しないと思い込んでいた
CACHEやCACHESYSネームスペースなど、システムのエラー等で「.lck」ファイルが残存している状態のまま起動すると、エラーが発生しシステムが起動しない事は知っていました。
これまでのメンテナンス経験で、この「.lck」ファイルが残存する事でシステムが起動しない障害を何度も見てきたので、「.lckファイルが残存している事は無いだろう」と思い込んでいました。
思い込みは本当にダメですね。
深く反省しています。
解決のヒント
解決のヒントとなるのが、「cconsole.log」にありました(IRISではmessages.log)。
困った時はログファイルを確認する。
鉄則ですね。
ここには下記メッセージが記載されていました。
MM/DD/YY-hh:mm:ss:msc (PID) 2 Database d:\xxx\mgr\user\ is locked from [ホスト名]
「is locked from」これですね。
「ユーザのデータベースファイルが、「ホスト名」によってロックされている」との事です。
「よそのシステムからロックされているよ!」って事なんでしょうね。
書き込み権限し付かない理由もうなずけます。
ただ、そんなシステムは無いんですが・・・(汗
おわりに
こんな状態をそうそう見る事は無いと思います。
低確率とは言え、次回発生した場合はもっとスムーズに解決したいと思います。
対応方法や<PROTECT>エラー等、忘れないよう記録していきたいです!