2009年09月29日

問題切り分けの技術について

( Update 2009-09-29: タイトルを変更しました)
ポルトガルのInformixブログに、興味深い記事を見つけました。

http://informix-technology.blogspot.com/2009/08/where-do-you-stop-as-dba-thoughts-about.html

運用環境でonbarがハングする、という現象が発生してから、その原因を突き止めるまでの長い道のりについての読み物です。お客様先にオンサイトで作業していたこのブログの著者は、ハング時のonbar_dプロセスの挙動をdbxやtrussなどのツールで調べ、このプロセスがsend()の結果を待っている状態になっていることに直ぐ気づき、ストレージマネージャのベンダーに報告し調査を依頼したそうです。ところが、ストレージマネージャ・ベンダーの担当者がデバッグツールについての知識に乏しく、onbar_dから見たときのストレージマネージャーの挙動について、直ぐには理解できなかったところから、数ヶ月にも及ぶ「無駄」な実験・議論の繰り返しに巻き込まれてしまったそうです。

実はこの時、ストレージマネージャー側はrecv()待ちでハングしていた、ということで、調査の対象がOSに移っていきました。

結局はOSが提供しているAPIの問題だったそうです。

ここで出てくる、onbarは、XBSAインターフェースを使って、多様なサードパーティ製ストレージマネージャーとの組み合わせで高機能なバックアップ・復元が行えるツールです。ですが、その一方で、関連するコンポーネントの多さ故、ちょっとした設定の誤りによって、意図しない挙動、原因不明のハングアップなどに遭遇することが考えられます。こんな時、ちょっと落ち着いて設定を見直してみる、とか、上記の例にあるような、デバッグツールによる解析(場合によってはツールを使わないで、OSのログ - /var/adm/messagesなどを参照してみる)を試みる、などにより、思わぬことに気づくことがあります。(もちろん、ソースコードを参照できるわけではないので、限度はありますが。)


でも、何より大事なのは、基本的な設定や利用方法に日頃から慣れておくことでしょうね。バックアップはともかく、特にリストアはふつうのユーザーが普段そんなに頻繁に使用するものではありません。避難訓練と同じで、緊急時に問題なくシステムの復元ができるよう、普段から手順に慣れておくことも、とても大事なことだと思います。


タグ :idsblog

同じカテゴリー(ちょっと細かいテックネタ)の記事
DBACCESS_COLUMNS
DBACCESS_COLUMNS(2020-04-03 00:33)


※このブログではブログの持ち主が承認した後、コメントが反映される設定です。
上の画像に書かれている文字を入力して下さい
 
<ご注意>
書き込まれた内容は公開され、ブログの持ち主だけが削除できます。