DB2 レイヤ別トラブルシューティング集：DB2マイスター養成講座（最終回）（1/2 ページ）

DB2ではどのようなトラブルが想定されるのか。レイヤ別に主なトラブルとその解決方法を紹介する。（編集局）

[小林慶彦，＠IT]

　最終回はトラブルシューティングですが、一言でデータベース・サーバのトラブルといっても、複数のレイヤでさまざまな原因が考えられます。トラブルシューティングは問題の切り分けがカギになります。

　DB2のトラブルをレイヤ別に分類すると、6種類に大別できます。

• インストール／アップデート関連
• システム（OS、ネットワーク）関連
• インスタンス関連
• データベース関連
• ツール／コマンド関連
• SQL／トランザクション関連

　細かいものを挙げると切りがないので、ここではLinuxに関係するものに絞って、代表的なトラブルを紹介します。

インストール／アップデートに関するトラブル

　LinuxにDB2をインストール／アップデートするに当たってよくあるトラブルは、以下の2つです。

■GUIインストール時のJDK問題

　DB2のGUIインストーラはJavaベースで、標準でJDKも付属しています。しかしJDKのバージョンがやや古い（J2RE 1.3.1 IBM build cxia32131-20020622）ため、最近のディストリビューション（Red Hat Enterprise Linux 3やSUSE LINUX Enterprise Server 9）では、segmentation faultなどを起こしてしまいます。

　この場合は、CUIインストール（第1回参照）を使う、ディストリビューションに付属するJDK（JRE）を使います。ディストリビューションに付属するJDK（JRE）を使う場合は、DB2のメディアの内容をハードディスクにすべてコピーします。次に、［CD-ROMのルート］/db2/linux/javaを削除して、ディストリビューションに付属するJDK（JRE）にシンボリックリンクを張ります。

　例えば、SUSE LINUX Enterprise Server 9の場合は、以下のように行います。

# cd cdrom/db2/linux/
# mv java java.org
# ln -fs /opt/IBMJava2-142 ./java

■FixPak適用時のインスタンス・アップデートの問題

　FixPak適用時、インスタンスは止まっているのにインスタンスのアップデートコマンド（db2iupdt）が失敗することがあります。この原因としては、すべてのデータベース・インスタンス（DASおよびライセンス・デーモンを含む）が停止していないか、DB2関連のリソース（プロセスやIPCリソース）が残っている場合が考えられます。

　この場合は、データベース・インスタンス（DASおよびライセンス・デーモンを含む）を停止します。次に、ipcleanとipcrmを使って残ったDB2プロセスやIPCリソースをクリーンアップします。

システム（OS、ネットワーク）に関するトラブル

　トラブルがOS関連（カーネルやドライバなど）の場合、DB2と直接関連のないことが多いので、DB2側でできることはほとんどありません。しかし、ネットワークの設定に起因する、DB2サーバとクライアントの接続に関するトラブルはLinuxでもよく見受けられます。

　例えば、クライアントからホスト名でDB2サーバをカタログしていたが、サーバのIPアドレスが変わってしまい、ある日突然接続できなくなってしまったということがあります。これは、名前解決のパフォーマンスなどを考慮して、クライアント側で/etc/hostsファイルを使っている場合によく起こります。思い当たる節がある場合は、クライアント側で名前解決が正確にできるかどうか、/etc/hostsファイルの内容を見直したり、pingなどのツールを使って実際に確認しましょう。

　コントロール・センターなどからカタログした場合は、db2system名によってカタログされることがありますが、これも同様のトラブルを引き起こします。通常、db2system名はホスト名になっています。ホスト名が解決できれば済むのですが、ホスト名での名前解決ができない場合は接続できません。このケースも、クライアント側の名前解決をチェックする必要があります。

インスタンスに関するトラブル

　インスタンスに関するトラブルは、DB2プロセスがOSから受け取ったシグナルが原因であることが一般的です。DB2プロセスがシグナルを受け取った結果、呼び出されたシグナル・ハンドラーがインスタンスをダウンさせています。このようなシグナルは、次のような場合に発生します。

• DB2のスタックがほかのソフトウェアによって上書きされた場合
• 許可ユーザーがDB2プロセスに対して手動でkillシグナルを送った場合
• DB2自体が原因となっている場合（ソフトウェア障害の可能性）

　インスタンスの問題が発生すると、必ずdb2diag.log（注）に重要な情報が記録され、場合によってはトラップ・ファイルやダンプ・ファイルが生成されます。これらのファイルを確認して問題判別を行うわけですが、トラブルが人為的なものではない場合はソフトウェアの障害の可能性が高いので、DB2のサポートに連絡しましょう。

注：db2diag.logは、デフォルトでは［インスタンス・ホームディレクトリ］/sqllib/db2dump以下にあります。

　次に多いのが、インスタンスの起動に関する問題です。多くは、FixPakの適用時と同様に、IPCリソースが原因であることがほとんどです。ipcsコマンドなどでシェアードメモリセグメントを確認し、インスタンス・ユーザーのリソースが残っている場合は、ipcleanとipcrmを使って残ったDB2プロセスやIPCリソースをクリーンアップします。