目次


DB2問題判別 習熟シリーズ

第3回 接続の問題判別

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: DB2問題判別 習熟シリーズ

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:DB2問題判別 習熟シリーズ

このシリーズの続きに乞うご期待。

セクション1: この回について

目的

この回では、DB2における一般的な通信の問題の原因を特定する方法を紹介し、2層環境と3層環境での診断方法の違いについて説明します。

対象読者と前提事項

既にDB2の使い方に慣れており、通信エラーに関連する問題判別のテクニックを学びたいと考えているユーザーを対象としています。ここでは、クライアントとサーバーの間の接続のセットアップに関する基礎知識があること、および多層環境とは何かを理解していることが前提となります。また、DB2が使用するプロトコル、とりわけTCP/IPについての一般的な知識も必要です。

開始前のセットアップ

この回のほとんどの例はMicrosoft®Windows® オペレーティング・システムを対象に作られていますが、すべての概念はどのオペレーティング・システムにも当てはまります。また、実習についても、どのDB2 UDB分散システムでも完了できます。

この回では、すべての例でTCP/IPが使用されていますが、デバッグの手順は、サポートされている他のプロトコルでもほとんど同じです。

例を実際に試してみるには、以下の環境が必要になります。

1. 以下の要素がそろっているサーバー

  • インストール済みのDB2とDB2サンプル
  • DB2 SAMPLEデータベースが作成されているインスタンス
  • SAMPLEデータベースに対するSYSADM権限

2. 以下の要素がそろっているクライアント

  • インストール済みのDB2
  • TCP/IPでサーバーのSAMPLEデータベースをカタログしてあるインスタンス
  • ローカル・インスタンスに対するSYSADM権限
  • サーバーのSAMPLEデータベースに対する有効な接続

表記規則

ツールやユーティリティーの名前は、初出時には太字で表記されています。

すべてのコマンド・ステートメントおよびその出力は、モノスペース・フォントで表記されています。

例で使われているコマンド・オプションは、その後に変更されている可能性があります。各コマンド・オプションについては、DB2 UDBのマニュアルを参照してください。

著者について

B.C.SのLisa Cawleyは、DB2認定アドバンスト・テクニカル・エキスパートであり、IBMトロント・ソフトウェア研究所のDB2 UDBワールドワイド・サポート・チームの一員です。現在は、DB2のツール、接続、およびエクステンダーのフロントライン・サポート・チームで、世界中のDB2のお客様を対象とするテクニカル・サポートを担当しています。

Lisa Cawleyの連絡先については、http://www.ibm.com/contact/employees/usのIBM Global Directoryで、Canada Employeeのディレクトリーをご覧ください。

セクション2: 環境の理解

関与しているシステムの定義

接続の問題を分析するには、まず環境を理解しておかなければなりません。少なくとも、以下の3つの情報が必要です。

  1. オペレーティング・システム
  2. DB2の製品名、バージョン、およびFixPakレベル
  3. 各層の間で使用されている通信プロトコル

多層モデルを利用している場合(クライアント層が1つ以上の中間層によって補われている場合)は、次のように環境を図に表してみると、全体の把握に役立ちます。

Windows 2000, TCP/IP, gateway, APPC, OS/390 server
Windows 2000, TCP/IP, gateway, APPC, OS/390 server

このほか、「アプリケーション・リクエスター(AR)」や「アプリケーション・サーバー(AS)」などの用語も耳にするかもしれません。これらは、DRDA (分散リレーショナル・データベース体系)の用語です。DRDAとは、DB2 v7でメインフレーム・データベースとの通信に使用されている一連のプロトコルです。DB2 v8では、メインフレームへの接続だけでなく、すべてのDB2サーバー間の通信にDRDAが使用されています。このため、ARやASの概念は、これから頻繁に目にすることになるでしょう。アプリケーション・リクエスターは、分散接続のアプリケーション側を処理するコードです。つまり、接続「元」となるマシンです。一方、アプリケーション・サーバーは、接続のデータベース側を処理するコードです。したがって、接続「先」のマシンになります。

問題はどこにありますか?

通信の問題を分析する際の目標は、問題が発生しているのが「どこ」かを絞り込んでいくことです。環境の理解に焦点を絞るのも、複雑さをできるだけ軽減するためです。以下にそのための方法を示します。

  1. 通信エラーが発生しているのはクライアント上で実行されているアプリケーションですか? その場合は、DB2のコマンド行から問題を再現できるかどうかを試してみます。これにより、アプリケーションを対象から除外できます。
  2. 3層環境を利用していて、クライアントにエラーが返されていますか? その場合は、直接中間層(しばしば「ゲートウェイ」と呼ばれる)から問題を再現できるかどうかを試してみます。これにより、クライアントと、クライアントとゲートウェイの間のネットワークを対象から除外できます。

同様に、発生している問題がDB2に特有の問題かどうかを特定することも重要です。たとえば、ネットワーク・エラーが発生する場合は、エラーになるのはDB2の接続を使った場合だけかどうかを調べます。このことは、断続的なエラーの場合には特に重要になります。というのも、そのような場合は、問題がDB2の外部にある可能性が高いからです。

問題箇所を特定するためのツール

問題がDB2に特有の問題かどうかを確定するにはどうすればよいでしょうか。各プロトコルにはそれぞれ専用のツールがあり、ネットワークに参加しているマシンの間で通信が可能かどうかを検証できます。以下はその例です。

TCP/IP:

ping <hostname or ip address>

実際に試してみてください。成功した場合は、以下のような結果が返されます。

Pinging myserver [1.23.45.678] with 32 bytes of data:
Reply from 1.23.45.678: bytes=32 time=921ms TTL=253
Reply from 1.23.45.678: bytes=32 time=721ms TTL=253
Reply from 1.23.45.678: bytes=32 time=942ms TTL=253
Reply from 1.23.45.678: bytes=32 time=80ms TTL=253

Ping statistics for 1.23.45.678:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
    Minimum = 80ms, Maximum =  942ms, Average =  666ms

APPC:各APPC通信製品は、それぞれ独自の方法で、LU対LUセッションを確立できるかどうかを検証します。たとえばAIXでは、SNAサブシステムの始動、ノードの始動、リンク・ステーションの始動、セッションのテスト、という一連の操作のすべてを、smitユーティリティーを使って行うことができます。詳細については、お使いのAPPC通信製品のマニュアルを参照してください。

名前付きパイプ:クライアントからサーバー上の共用フォルダーに対してnet useコマンドを実行してみます。

PCTツール:クライアントとサーバーの間の通信のセットアップをデバッグする際には、DB2に用意されているProtocol Communications Testerというツールを使用できます。このツールは、sqllib/binディレクトリーにあるpctコマンドを使って起動します。このツールはスタンドアロン・ツールであり、特定のLANプロトコルが動作するかどうかや、そのLANプロトコルを使って2つのエンドポイントが互いに通信できるかどうかを検証できます。

このツールは、プロトコルの構成に関連する問題を解決する際に便利です。なぜなら、このツールを使用すると、通信に問題がないことが確認されるまで、DB2を効果的に対象から除外できるからです。こうしたDB2外部の通信テストが成功しない場合は、ネットワーク層にエラーの原因があるか、ツールで使用したプロトコル固有の値が間違っているかのいずれかです。ネットワークの問題が修正され、正しいプロトコル固有の値が特定されない限り、そのネットワークでDB2を接続することはできません。

このツールの使い方については、実行可能ファイルと同じディレクトリーにあるreadme.pctファイルを参照してください。PCTツールでテストできるプロトコルは以下の3つです。

  • NetBIOS
  • TCP/IP
  • IPX/SPX

サーバーでのPCTの構成

ここでは、1つの例を追いながら、TCP/IPバージョンのPCTを使用するための手順を紹介します。IPX/SPXプロトコルやNETBIOSプロトコルで作成した接続をテストする場合の手順もほとんど同じです。主な違いは、ここで「pctt」と入力する箇所に「pctn」や「pcti」を入力するということです。

お使いのサーバーで、以下の手順を実行します。

  1. 次のコマンドを使って、サーバーのホスト名とIPアドレスを確認します。
    D:\sqllib\bin>pctt -r
       TCPIP Resources...
       +--------------------------------------------+
       | HostName   : myserver                      |
       | HostAddress: myserver.ibm.com              |
       | IPAddress  : 123.456.7.890                 |
       +--------------------------------------------+
  2. pctt /gtを実行して、pct.iniファイルを生成します。
    #--------------------------------------------------------
    # PCT.INI
    # Protocol Communication Tester INI File
    # This file contains the Protocol Specific Configuration
    # Parameters & values to be used in conjunction with
    # the Protocol Communication Tester (PCTx).
    #
    # Defaults will be used if the parameter is not listed.
    #--------------------------------------------------------
    
    [TCPIP]
    ServerHostName =
    ServerHostAddress =
    ServerIPAddress =
    ServiceName =
    ServerPort = 49433

    このコマンドは、書き込みアクセス権限があるディレクトリーで実行してください。そうしないと、pct.iniファイルが正しく作成されません。

  3. このサーバーとインスタンス(クライアントの接続先となるインスタンス)のプロトコル固有のパラメーター値を反映して、pct.iniファイルを編集します。このツールを使ってDB2の問題をデバッグする際には、DB2インスタンスがクライアントからの要求をlistenするのに使用する値を正確に反映してpct.iniファイルを構成することが重要です。たとえば、pct.iniのServiceName値またはServerPort値を、db2 get database manager configurationコマンドの出力のSVCENAMEフィールドと同じ値に設定する必要があります。なお、ServerHostNameとServerIPAddressについては、いずれか一方の値を入力するだけでかまいません。ServiceNameとServerPortについても同様で、いずれか一方だけで十分です。

サーバーでのPCTの開始

PCTリスナーを開始するには、以下のコマンドを実行します。

pctt s

注: クライアントでPCTツールを起動する前に、サーバー上でPCTツールを実行しておく必要があります。そうしないと、クライアント上のPCTツールは、接続が拒否されたというメッセージを返してエラーになります。

サーバー上でPCTが正しく開始されると、以下のような出力が表示されます。

lcawley@steel:/home/lcawley> pctt s
- Reading configuration parameters
==> pct.ini file was found... using file specified protocol values!
 Protocol Tester values...
   Client/Server          : Server
   Connections            : 1
   Buffer Size            : 500
   Transaction Iterations : 1
   Trace                  : OFF
   Service                : Send/Recv/Verify
   Keep Connections       : NO
   Delayed Send (secs)    : 0
 Local TCPIP specific values...
          Hostname        : myserver
          HostAddress     : myserver.ibm.com
          IPAddress       : 123.456.7.890

上の出力には、pct.iniファイルから取得された情報が表示されています。この出力は、さらに次のように続きます。

- Initializing the Protocol             Date: 10-22-2002  Time: 0:39:5:45
| retcode = <    0>  ----[ TCPIP.socket     ]-----[  SUCCESS  ]------------
| retcode = <    0>  ----[ TCPIP.setsockopt ]-----[  SUCCESS  ]------------
| retcode = <    0>  ----[ TCPIP.bind       ]-----[  SUCCESS  ]------------
| retcode = <    0>  ----[ TCPIP.listen     ]-----[  SUCCESS  ]------------
- Listening for Remote Clients          Date: 10-22-2002  Time: 0:39:5:46

この時点で、PCTツールのサーバー側はクライアントからの通信を待っています。

クライアントでのPCTの構成

次に、クライアントでPCTツールをセットアップして、テストを実行できるようにします。

  1. pctt /gtを実行して、pct.iniファイルを生成します。サーバーでこのステップを実行したときとまったく同じ空のファイルが表示されます。
  2. 接続先となるサーバーのプロトコル固有のパラメーター値を反映して、このpct.iniファイルを編集します。このツールを使ってDB2の問題をデバッグする際には、クライアントからリモートDB2サーバーをカタログするときに使用した値を正確に反映してpct.iniファイルを構成することが重要です。たとえば、クライアントでCATALOG TCPIP NODEコマンドを実行したときに、サーバーのIPアドレスではなくホスト名を使用した場合は、pct.iniファイルでも同じようにホスト名を使用します。同様に、ポート番号ではなくサービス名を使用した場合は、pct.iniでもサービス名を使用します。以下は更新後のpct.iniファイルの例です。
     
    #--------------------------------------------------------
    # PCT.INI
    # Protocol Communication Tester INI File
    # This file contains the Protocol Specific Configuration
    # Parameters & values to be used in conjunction with
    # the Protocol Communication Tester (PCTx).
    #
    # Defaults will be used if the parameter is not listed.
    #--------------------------------------------------------
    
    [TCPIP]
    ServerHostName = myserver.ibm.com
    ServerHostAddress =
    ServerIPAddress =
    ServiceName =
    ServerPort = 50000
  3. pctt cを実行して、サーバー・リスナーを開始します。

成功した場合のPCTの出力

デフォルトでPCTは、まずエンド・ツー・エンドの接続操作を実行します。その後、データ検証付きの送受信操作を行い、最後に接続を切断します。成功した場合の結果は、次のようになります。

C:\temp>pctt c
- Reading configuration parameters
==> pct.ini file was found... using file specified protocol values!
 Protocol Tester values...
   Client/Server          : Client
   Connections            : 1
   Buffer Size            : 500
   Transaction Iterations : 1
   Trace                  : OFF
   Service                : Send/Recv/Verify
   Keep Connections       : NO
   Delayed Send (secs)    : 0
 Local TCPIP specific values...
          Hostname        : myclient
          HostAddress     : myclient.ibm.com
          IPAddress       : 98.765.4.321

(接続に失敗した場合の結果については、後に示します。)上の出力には、クライアント・マシンに関するプロトコル固有の情報に加え、PCTツールのデフォルト設定の情報も含まれています。

 Server TCPIP specific Values...
   Server Hostname        : myhostname.ibm.com
   Server HostAddress     : myhostname.ibm.com
   Server IPAddress       : 123.456.7.890
  Service Name           :
   Server Port            : 50000

上の情報は、クライアントのpct.iniファイルから取得されたものであり、サーバーを特定するために使われる値が含まれています。

-Initializing the Protocol   Date: 10/22/02  Time:00:45:26:791
-Connecting to Remote System Date: 10/22/02  Time: 00:45:26:801
| retcode = <0>  ----[ TCPIP.socket     ]-----[SUCCESS]--------
| retcode = <0>  ----[ TCPIP.connect    ]-----[SUCCESS]--------
- Connection established! 1  Date: 10/22/02  Time: 00:45:26:861

この時点で、このテストの接続のステップが完了しています。

- Sending Service Request    Date: 10/22/02  Time: 00:45:26:861
| retcode = <0>  ----[ TCPIP.send       ]---[Bytes=  316 ]-----
- Receiving                  Date: 10/22/02  Time: 00:45:26:871
| retcode = <0>  ----[ TCPIP.receive    ]---[Bytes= 4 ]--------
| retcode = <0>  ----[ TCPIP.receive    ]---[Bytes=  312 ]-----
- Server info:
    Computer Name   : MYHOST
    Operating System: AIX
    Version         : 4.3
    Hostname        : myserver
-Send/Receive/Verify Data Loop Date:10/22/02 Time: 00:45:26:971
- Sending Data               Date: 10/22/02  Time: 00:45:26:971
| retcode = <0>  ----[ TCPIP.send       ]---[Bytes=  500 ]-----
- Receiving                  Date: 10/22/02  Time: 00:45:26:971
| retcode = <0>  ----[ TCPIP.receive    ]---[Bytes=    4 ]-----
| retcode = <0>  ----[ TCPIP.receive    ]---[Bytes=  496 ]-----

デフォルトでPCTツールは、サーバーからクライアントにデータを渡して接続を検証します。その後、接続を閉じます(以下を参照)。

- Terminating the Connection Date: 10/22/02  Time: 00:45:27: 31
| retcode = <0>  ----[ TCPIP.sock_close ]-----[SUCCESS  ]------
+------------------------------------------------+
|  Protocol Connection Test Completed - SUCCESS  |
+------------------------------------------------+

失敗した場合のPCTの出力

テストを正しく完了できなかった場合は、次のようなエラー・メッセージが返されます。

- Reading configuration parameters
==> pct.ini file was found... using file specified protocol values!
 Protocol Tester values...
   Client/Server          : Client
   Connections            : 1
   Buffer Size            : 500
   Transaction Iterations : 1
   Trace                  : OFF
   Service                : Send/Recv/Verify
   Keep Connections       : NO
   Delayed Send (secs)    : 0
 Local TCPIP specific values...
          Hostname        : myclient
          HostAddress     : myclient.ibm.com
          IPAddress       : 98.765.4.321

 Server TCPIP specific Values...
   Server Hostname        : myserver
   Server HostAddress     : myserver.ibm.com
   Server IPAddress       : 1.23.45.678
   Service Name           :
   Server Port            : 99999

- Initializing the Protocol    Date: 11/23/02 Time:22:18:12:507
- Connecting to Remote System  Date: 11/23/02 Time:22:18:12:517
| retcode = <    0>  ----[ TCPIP.socket ]-----[SUCCESS ]-------
| retcode = <10061> +----[ TCPIP.connect]-----[ERROR   ]-------
+===== ERROR ==================================================
| retcode = <10061> ->  Connection refused
+==============================================================

ここに示されている10061という戻りコードはTCP/IPの戻りコードであり、CONNECTION REFUSEDに対応します。この例のエラーの原因は、クライアントのpct.iniファイルのServerPort値が間違っていて、サーバーのpct.iniファイルに定義されているServerPort値と一致しなかったことでした。

PCTツールによってこのようなエラーが返された場合は、DB2の問題判別を進める前に、まず、こうしたDB2外部の問題を修正してください。

セクション3: 問題判別

一般的なDB2通信エラー

環境のセットアップを明らかにし、エラーをできる限り単純な状況まで絞り込み、DB2を介したときにしか問題を再現できないことが確定できたら、DB2での問題判別作業を開始します。

DB2内の通信エラーは、ほとんどの場合、SQL30081エラー・メッセージとして現れます。このエラー・メッセージには、プロトコル固有の戻りコードが含まれます。この戻りコードはプロトコルのエラー定義で調べることができますが、エラー・コードだけで問題の原因が明らかになることはほとんどありません。

以下は、DB2で最も一般的な通信エラー・メッセージです。

SQL30081N A communication error has been detected. Communication protocol being used:
<protocol>. Communication API being used: <interface>. Location where the error was
detected: <location>. Communication function detecting the error: <function>. Protocol
specific error code(s): <rc1>, <rc2>, <rc3>

このエラーをごく簡単にシミュレートするには、まずサーバーに移動し、クライアントの接続先となっているインスタンスに対してdb2stopコマンドを実行します。続いてクライアントに戻り、サーバーに接続してみます。クライアント側に次のようなエラーが表示されるはずです。

SQL30081N  A communication error has been detected.  Communication protocol being 
used: "TCP/IP".  Communication API being used: "SOCKETS".  Location where the 
error was detected: "".  Communication function detecting the error: "connect".  
Protocol specific error code(s): "10061", "*", "*". SQLSTATE=08001

このほか、db2diag.logに次のエラー・メッセージが書き込まれます(クライアントのデータベース・マネージャー構成パラメーターでDIAGLEVELが2以上に設定されている場合)。

2002-11-23-22.38.25.935000   Instance:DB2   Node:000
PID:1320(db2bp.exe)   TID:324  Appid:091A8A2E.07DF.021124033326
common_communication  sqlcctcpconnr   Probe:110 
DIA3202C The TCP/IP call "connect" returned an errno="10061".

この2つのエラー・メッセージはいずれも、TCP/IPの接続操作で10061というプロトコル固有のエラーが返されていることを伝えています。このエラーは、先ほどPCTのクライアント側で間違ったポート番号を使って接続しようとしたときにPCTの出力に現れたのと同じ、CONNECTION REFUSEDのエラー・コードです。ただし、ここでは事情が異なります。今回の場合、クライアントが使用しているポート番号は間違っていませんでしたが、サーバーのそのポート番号でlistenしているはずのインスタンスが開始されていませんでした。このように、プロトコル固有のエラー・コードだけでは、問題をデバッグするのに必ずしも十分ではありません。

なお、今後の実習でこの接続を引き続き正常に使用できるように、サーバー上のDB2インスタンスを再び開始しておくのを忘れないようにしてください(db2startコマンドを使用)。

問題判別のテクニック

これまで見てきたように、通信の問題の原因はエラー・メッセージだけで特定できるとは限りません。そのため、他の問題判別テクニックが必要になります。以下は、問題の調査に役立つ4つの問いのリストです。通信の問題に取り組むにあたって、まず最初にこれらの問いを自問してみることにより、その状況の性質を正確に特定できます。

  1. 問題は断続的ですか? それとも永続的ですか?
  2. サーバー上でローカルに接続することはできますか?
  3. 正しく接続できたことはありますか?
  4. すべてのユーザーまたはすべてのクライアントが接続に失敗しますか?

以降では、これらの問いに対する答えが持つ意味について、詳しく説明します。

問#1: 断続的な問題と永続的な問題

問#1: 問題は断続的ですか? それとも永続的ですか?

問題が永続的な場合(単純なステップによって確実に再現できる場合)は、構成の問題である可能性が高いと言えます。この場合は、クライアントとサーバーのセットアップの確認に焦点を絞ります(セットアップの確認方法の例についてはセクション4を参照)。

問題が断続的な場合は、デバッグがやや困難になります。エラー・メッセージ自体は変わりません。断続的な問題の場合も、永続的な問題の場合と同様に、SQL30081エラー・メッセージが返されるのが一般的です。断続的な問題のデバッグの難しさは、問題を思いどおりに再現できないという事実にあります。というのも、エラーをキャプチャーしたり診断したりするチャンスがそれだけ少なくなるからです。断続的なエラー・メッセージの分析を進めるには、まずエラーの状況を調査する必要があります。たとえば、次のような問いが役に立ちます。

  • 問題発生時のネットワークの状態はどうなっていますか?
  • 問題はどれくらいの頻度で発生しますか?
  • 問題発生時のイベントになんらかのパターンはありませんか?

エラーが発生する頻度によっては、トレースの収集が難しい場合もあります。というのも、トレースはパフォーマンスに影響するため、ただエラーをキャプチャーするためだけに長期間にわたってトレースを実行するのはできれば避けたいからです。問題が発生しているのが実稼動システムならなおさらです。したがって、このようなタイプの問題に対しては、多くの場合、db2diag.logファイルの情報に頼ることになります。

断続的なエラーとアイドル・スレッド

断続的なエラーを調査する際に留意すべき点の1つは、エラーが発生する前に接続がどのくらいの間アイドル状態になっていたかです。接続がしばらくアイドル状態になった後に通信エラーが返される場合(特に、メインフレームが含まれている場合)は、サーバーをネットワーク・レベルでチェックして、タイムアウト値を確認する必要があります。たとえば、z/OS上で実行されているDB2に接続しようとしている場合は、ホスト上でIDLETHREADTIMEOUTの値を確認します。DB2 UDBがクライアントからのさらなる情報や要求を待っている間にホスト上のスレッドがタイムアウトになる場合、クライアント側では、次にその接続を使用しようとするときまで、ホストとの接続が失われていることはわかりません。同様に、3層環境でクライアントが異常終了した場合、サーバー側では、次にデータをクライアントに返そうとするときまで、クライアントとの接続が失われていることはわかりません。

使用しているプロトコルがTCP/IPの場合は、ネットワーク・レベルでKEEPALIVEパラメーターとKEEPALIVEINTERVALパラメーターを調整すると、接続が失われたことがより早くわかるようになります。ただし、KEEPALIVEの設定は、マシン上で実行されているすべてのTCP/IPアプリケーションに影響するので注意してください。KEEPALIVEのデフォルト値は、ほとんどの環境で約2時間になっています。

断続的なエラーとクエリー・タイムアウトの設定

断続的な通信エラーを調査するにあたってもう1つチェックすべき点は、サーバーからクエリーの結果が返されるのを長時間待った後に通信エラーが発生していないかどうかです。このような場合は、クライアント・アプリケーションがQUERYTIMEOUTのしきい値に達してクエリーをキャンセルしている可能性があります。QUERYTIMEOUT値はアプリケーションで設定される値であり、ODBCアプリケーションでよく使用されています。QUERYTIMEOUT値に達したときにまだデータが返されていないと、SQLCancel要求がサーバーに送信されます。

メインフレームが含まれている3層環境では、メインフレームでのクエリーのキャンセルは、ゲートウェイからホストへの接続を終了することによって行われます。通信エラーが発生するのはこのためです。アプリケーションで通信エラーが発生した場合に、QUERYTIMEOUTが関係しているかどうかを特定するには、クライアントのdb2cli.iniファイルの[COMMON]セクションにQUERYTIMEOUTINTERVAL=0を設定します。これにより、アプリケーションからのQUERYTIMEOUT要求が無視されます。この方法は、恒久的な解決にはなりませんが、問題の原因がQUERYTIMEOUT値にあるかどうかを確認するための一時的な手段としてよく使用されます。この問題に対しては、アプリケーションのQUERYTIMEOUT値を調整したり、クエリーの応答時間が長くなる原因を調査したりすることが最善の対処法になります。

断続的なエラーと接続プーリング

断続的なエラーの診断で検討しなければならない最後の状況は、接続プーリングです。アプリケーション層で(WebSphereやODBCなどを通じて)行われる接続プーリングとは別に、DB2では、DB2 UDBとメインフレームとの間の接続を独自にプールします。このため、メインフレームへの接続を切断しても、実際にはその接続が、将来使用できるようにまだ接続プールに保持されている可能性があります。プールされた接続がすぐにまた使用されない場合は、長期にわたってアイドル状態になり、IDLETHREADTIMEOUT (セクション3の「断続的なエラーとアイドル・スレッド」を参照)になる可能性があります。DB2は、接続をプールから取得する際、新しいアプリケーションに割り当てる前にその接続をテストして、まだ有効かどうかを確認します。しかし、メインフレームでメッセージを確認していて、既に存在しないと思っていた接続についてIDLETHREADTIMEOUTのメッセージが表示されたりすると、混乱を招く可能性があります。

ワークステーションから直接メインフレームに接続している場合は、以下の場合を除いて接続はプールされません -- (a) DB2CONNECT_IN_APP_PROCESS (db2setレジストリー・プロファイルの設定の1つ)をNOに設定している (b) 「ループバック」接続を使用している(ループバック接続の詳細については、次の「問い#2: ローカルで接続できますか?」を参照)。この2つの操作は、直接メインフレームに接続する際のモニターにも影響します。ローカルで開始された接続に関する情報をdb2 list dcs applicationsコマンドの出力で確認したい場合は、この2つのいずれかの操作を行う必要があります。なお、DB2 Connect Personal Editionを使って直接メインフレームにアクセスする場合は、この2つの操作のいずれも実行できません。この製品には、これらの機能はありません。

DB2の接続プールを無効にする恒久的な方法はありませんが、NUM_POOLAGENTS (データベース・マネージャー構成設定のパラメーターの1つ)を0に設定すると、接続プールを一時的に無効にすることができます。まれに、通信エラーを診断していて、接続プールによって問題が複雑になっていると思われることがありますが、この方法はそのような場合に利用できます。ただし、この設定は、恒久的に使用できるような実用的な設定ではありません。なぜならこの設定は、プールされている接続に関係ないものも含むすべてのエージェントに影響するため、すべてのエージェントを毎回ゼロから作成しなければならなくなり、オーバーヘッドが大幅に増大するからです。

問#2: ローカルで接続できますか?

これは、通信エラーに遭遇するたびに問うべき、きわめて重要な問いです。エラーが発生したときにローカルで接続できない場合は、クライアントと通信層を完全に対象から除外して、直接サーバー上でエラーを再現したり診断したりする作業に集中できます。

一方、ローカル接続に問題がない場合は、直接サーバー上でリモート接続をシミュレートすることが次のステップになります。これを行うのは、問題全体を1つのマシン上で再現することによって、複雑さを軽減するためです。この方法は、しばしば「ループバック」と呼ばれます。ループバックとは、以下で説明するように、ローカル・データベースをまるでリモート・マシン上にあるかのようにカタログする方法にすぎません。以下の操作をすべてサーバー上で実行してください。

  1. db2 list db directoryというコマンドを実行して、サンプル・データベースの現在のカタログを確認します。
    Database X entry:
    
     Database alias                  = SAMPLE
     Database name                   = SAMPLE
     Database drive                  = C:\DB2
     Database release level          = 9.00
     Comment                         =
     Directory entry type            = Indirect
     Catalog node number             = 0

    操作がすべて完了すると、このリストに別のカタログが表示されます。そのカタログは、究極的には同じローカル・データベースを指しているにもかかわらず、リモートとして表示されます。ループバック・カタログを実行するには、ループバックの別名を元のデータベースの名前と一致させる方法もありますが、ここではその手順は省略します。なお、この方法は、アプリケーションでそのループバック・カタログを恒久的に使用する場合に、アプリケーションやスクリプトがデータベースを参照する方法を変更しなくても済むようにするためによく使われます。ここでは、この例のために単純な方法を使用します。

  2. db2 get dbm cfgというコマンドを実行して、インスタンスが着信要求をlistenしているポート番号またはサービス名を確認します。
    ...
    NetBIOS Workstation name               (NNAME) =
    TCP/IP Service name                    (SVCENAME) = db2cDB2
     APPC Transaction program name         (TPNAME) =
     IPX/SPX File server name              (FILESERVER) =
     IPX/SPX DB2 server object name        (OBJECTNAME) =
     IPX/SPX Socket number                 (IPX_SOCKET) = 879E
    ...

ノードをカタログするのに必要な情報は、この情報とサーバーのホスト名またはIPアドレスだけです。なお、クライアントで通信エラーが発生していて、カタログがサーバーのホスト名ではなくIPアドレスを使用している場合は、一貫性を保つために、ループバック・カタログでもIPアドレスを使用する必要があります。

問#2: ローカルで接続できますか?

  1. ループバック・ノードをカタログするには、次のコマンドを実行します。
    db2 catalog tcpip node loopnode remote <hostname/ip address> server

    このコマンドで使用するポート番号またはサービス名は、先ほどdb2 get dbm cfgの出力で確認したポート番号またはサービス名と一致している必要があります。続いてdb2 list node directoryを実行すると、結果のノード・カタログを表示できます。

     Node X entry:
     Node name                      = LOOPNODE
     Comment                        =
     Protocol                       = TCPIP
     Hostname                       = myhostname
     Service name                   = db2cDB2
  2. 次のコマンドを実行して、ループバック・データベースをカタログします。
    db2 catalog db <local db name> as <loop back db alias> at 
    node <loop back node name, per step 1. above>

    続いてdb2 list db directoryを実行すると、次のように、データベース・ディレクトリーによって2つの関連するデータベース・カタログが表示されます。

    Database X entry:
    
     Database alias                  = SAMPLE
     Database name                   = SAMPLE
     Database drive                  = C:\DB2
     Database release level          = 9.00
     Comment                         =
     Directory entry type            = Indirect
     Catalog node number             = 0
    
    Database Y entry:
    
     Database alias                  = LOOPDB
     Database name                   = SAMPLE
     Node name                       = LOOPNODE
     Database release level          = 9.00
     Comment                         =
     Directory entry type            = Remote
     Catalog node number             = -1

ループバック接続のテスト

ループバック・データベースに接続するには、「db2 connect to <loop back db alias> user <userid>」と入力します。パスワードの入力を求められます。

C:\PROGRA~1\SQLLIB\BIN>db2 connect to loopdb user tester

   Database Connection Information

 Database server        = DB2/NT 7.2.5
 SQL authorization ID   = TESTER
 Local database alias   = LOOPDB

このループバック接続のテストでは接続に成功するのに、リモート・クライアントからの接続は失敗するという場合は、以下について確認してください。

A. クライアントとサーバーの間にファイアウォールはありますか?

B. クライアント上のノード・カタログとデータベース・カタログは、ここでサーバー上で実行したものと一致していますか? なお、クライアントのノード・カタログでサービス名が使用されている場合、サービス名は一致していなくてもかまいません。ただし、その場合も、各マシンでサービス名がマップされているポート番号は一致している必要があります。

ローカル・ループバック・テストで接続に失敗する場合、以降の調査ではクライアントを完全に無視できます。エラーが永続的な場合は、構成に問題があり、サーバーが着信要求をlistenするように正しくセットアップされていないと考えられます。したがって、サーバーの構成値の確認に焦点を絞る必要があります。

問#3: 正しく接続できたことはありますか?

これが初めてのセットアップの場合は、構成の問題である可能性が高くなります。構成エラーによって引き起こされる初回の接続の問題は、ほとんどの場合、永続的でもあります。この問題を解決するには、セットアップが正しく行われているかどうかを確認します(セクション4を参照)。

以前は接続できていた場合は、接続できていたのはいつか、その後何が変更されたかなどの問いを自問してみる必要があります。こうしたタイプの問いは、最後に接続できたときから現在までの間に行われたネットワークの変更、FixPakレベルのアップグレード、アプリケーションの変更、システム停止などを特定するのに役立ちます。何がどこで(クライアント、ゲートウェイ、サーバーなど)変更されたのかを特定することによって、調査でどこに労力を集中するべきかがわかります。

問#4: すべてのユーザーまたはすべてのクライアントが接続に失敗しますか?

この問いの目的は、問題が発生している同様の環境や問題が発生していない同様の環境を比較することにあります。問題が発生しているのが、このサーバーに接続している一部のクライアントだけの場合は、それらのクライアントの間の共通点と相違点を特定し、その構成(DB2およびネットワークの構成)を比較します。問題がすべてのクライアントで発生している場合は、単純な比較という選択肢はなくなります。問題が断続的だがすべてのサーバーで同時に発生しているような場合は、クライアントではなくサーバーかネットワークにエラーの原因がある可能性が高くなります。このように、この問いから導き出される情報を他の4つの問いの答えと組み合わせることによって、問題の原因がどこにあるのかを特定するためのより確実な根拠が得られます。

セクション4: クライアントとサーバーの構成の確認

クライアントとサーバーの構成を確認すべきとき

前の議論をまとめると、通信の問題に以下のような特徴が見られる場合、一般に構成エラーが原因と考えられます。

A. 断続的なエラーではない。

B. 接続が一度も機能していない、または最近変更されている。

C. ローカルでは正常に接続できる。

D. サーバー上でループバック接続を作成しようとしたが失敗した(この場合は、この後の例の「サーバー」側の構成に関連する部分のみが対象になります)。

サーバーのセットアップの確認

サーバーのセットアップを確認するための手順は、以下のようになります。

  1. 以下のいずれかのコマンドを実行して、データベースの存在を確認します。
    • db2 list db directory
    • db2 list db directory show detail
    3層環境の場合は、リモート・データベースとしてカタログされたデータベースが表示されます。
    Database X entry:
    
     Database alias                  = SAMPLE
     Database name                   = SAMPLE
     Database drive                  = C:\DB2
     Database release level          = 9.00
     Comment                         =
     Directory entry type            = Indirect
     Catalog node number             = 0
  2. db2set -allを実行して、インスタンスが適切なプロトコルでlistenを開始するように構成されていることを確認します。パラメーターDB2COMMを探します。
    C:\PROGRA~1\SQLLIB\BIN>db2set -all
    [e] DB2PATH=C:\Program Files\SQLLIB
    [i] DB2INSTPROF=C:\PROGRAM FILES\SQLLIB
    [g] DB2SYSTEM=mysystem
    [g] DB2PATH=C:\Program Files\SQLLIB
    [g] DB2INSTDEF=DB2
    [g] DB2COMM=tcpip
    [g] DB2ADMINSERVER=DB2DAS00
  3. データベース・マネージャー構成設定で、適切なプロトコル固有のパラメーターが設定されていることを確認します。この設定が行われていないと、DB2はどの値をlistenすればよいのかがわかりません。たとえば、db2 get dbm cfgを実行して、以下のセクションを確認します。
     ...
    NetBIOS Workstation name               (NNAME) =
    TCP/IP Service name                    (SVCENAME) = db2cDB2
     APPC Transaction program name         (TPNAME) =
     IPX/SPX File server name              (FILESERVER) =
     IPX/SPX DB2 server object name        (OBJECTNAME) =
     IPX/SPX Socket number                 (IPX_SOCKET) = 
    ...
  4. 前のステップで、SVCENAMEフィールドの値がポート番号ではなくサービス名になっていた場合は、そこに表示されている値が、次のように、オペレーティング・システムの/etc/servicesファイルで固有のポート番号にマップされていることを確認します。
    db2cDB2    50000/tcp   # Connection port for DB2 instance db2inst1

サーバー上のDB2通信リスナーの開始

  1. db2diag.logのバックアップ・コピーを作成し、元のdb2diag.logファイルの内容を消去します。以下のコマンドを実行して、診断レベルを4に上げ、DB2インスタンスをいったん停止してからまた開始します。
    db2 update dbm cfg using diaglevel 4
    db2stop
    db2start
  2. db2diag.logで、目的のプロトコルのリスナーが正しく開始されたことを確認します。
    2002-11-24-01.09.46.282346   Instance:lcawley   Node:000
    PID:72732(db2tcpcm)   Appid:none
    common_communication  sqlcctcpconnmgr_child   Probe:66
    DIA3004I Normal shutdown requested for "TCPIP" protocol support.
    
    2002-11-24-01.09.46.784304   Instance:lcawley   Node:000
    PID:16744(db2stop2)   Appid:none
    base_sys_utilities  stopdbm    Probe:911
    
    2002-11-24-01.09.50.606535   Instance:lcawley   Node:000
    PID:23694(db2sysc)   Appid:none
    common_communication  sqlcctcpconnmgr   Probe:160
    DIA3218I "1" TCP/IP connection manager(s) was/were successfully started.
    
    2002-11-24-01.09.50.624615   Instance:lcawley   Node:000
    PID:23694(db2sysc)   Appid:none
    common_communication  sqlcctcp_start_listen   Probe:80
    DIA3000I "TCPIP" protocol support was successfully started.
    
    2002-11-24-01.09.51.652177   Instance:lcawley   Node:000
    PID:16748(db2star2)   Appid:none
    base_sys_utilities  startdbm   Probe:911
  3. 必要なセットアップ手順が実行されていなかった場合は、db2startコマンドを実行したときに、以下のようなエラーが返されます。
    SQL5043N  Support for one or more communications protocols 
    failed to start successfully. However, core database manager 
    functionality started successfully.
  4. この場合、DIAGLEVELが4に設定されていれば、db2diag.logファイルに詳細なエラー・メッセージが書き込まれます。たとえば、データベース・マネージャー構成設定のSVCENAMEパラメーターが設定されていなかった場合は、db2diag.logに以下のエラーが書き込まれます。
    2002-11-24-01.13.13.068436   Instance:lcawley   Node:000
    PID:20222(db2sysc)   Appid:none
    common_communication  sqlcctcpconnmgr   Probe:50
    DIA3200E The SVCENAME parameter in the database manager 
    configuration file is not configured. Update the SVCENAME 
    parameter using the service name defined in the TCP/IP 
    services file.
  5. インスタンスに対してDB2のプロトコル固有のリスナーが正しく開始されたことを確認できたら、忘れずに診断レベルを下げてください。そうしないと、パフォーマンスの問題が生じる可能性があります。デフォルトの診断レベルである3に戻すには、以下のコマンドを実行します。
    db2 update dbm cfg using diaglevel 3
    db2stop 
    db2start

クライアントのセットアップの確認

  1. db2 list node directoryまたはdb2 list node directory show detailを実行して、リモート・サーバーのインスタンスをカタログするのに使用した値を確認します。
    db2 list node directory show detail
    
     Node Directory
    
     Number of entries in the directory = 1
    
    Node 1 entry:
    
     Node name                      = MYNODE
     Comment                        =
     Protocol                       = TCPIP
     Hostname                       = myserver
     Service name                   = 50000
     Remote instance name           =
     System                         =
     Operating system type          = None

    この出力の"Service name"の値は、サーバー・インスタンスのデータベース・マネージャー構成のSVCENAMEの設定で定義されているポート番号と一致している必要があります。ポート番号の代わりにサービス名が使用されている場合は、クライアントのサービス名がマップされているポート番号が、サーバーで使用されているポート番号と一致していることが重要です。
  2. ステップ1の結果として表示されたHostnameの正確な値をpingできることを確認します。
  3. このほか、telnetコマンドを使って、特定のサーバーの特定のポート番号でlistenしているサービス(この場合はDB2インスタンス)があるかどうかを確認することもできます。たとえば、telnet myserver.ibm.com 50000などを実行します。サーバー側でTelnetを有効にする必要はありません。実際にそのポートでlistenしているサービスがあれば、Telnetのウィンドウが開き、そのままハングします。これは、そのサーバーに接続できたこと、およびそのポートで実際になんらかのサービスがlistenしていることを表します。一方、すぐにエラーが返される場合は、以下のいずれかになります。

    a. スト名またはIPアドレスの値が間違っている。ここでホスト名を使用した場合は、ホスト名解決の問題も考えられるので、IPアドレスを使って試してみてください。

    b. サービス名またはポート番号が間違っている。サービス名を使用した場合は、代わりにポート番号を使って試してみてください。クライアントの/etc/servicesファイルでサービス名が正しくマップされていない可能性が考えられます。

    c. クライアントとサーバーの間にファイアウォールがあり、このポートでの通信が許可されていない。ネットワーク管理者と一緒にこれが原因かどうかを確認してください。

    d. サーバー上のDB2がこのポートでlistenしていない。このセクションの始めに戻って、サーバーのセットアップを確認する方法について参照してください。

  4. Telnetとpingのテストが成功した場合は、必要に応じて、データベース・カタログとDCSデータベース・カタログに表示されるデータベースの値が正しいかどうかを確認してください。ただし、通常は、これらのカタログにエラーがあっても通信エラーにはなりません。

以上で、DB2の観点からクライアントとサーバーの両方の構成が正しいことを確認できました。まだ通信エラーが解決しない場合は、db2トレースなどの診断情報を収集する必要があります。

セクション5: 収集する診断情報

サポート情報の参照先(接続の問題)

プロトコル固有のエラー・コードの一部については、『DB2 Message Reference』の付録にリストがあります。さらに詳しい情報については、以下を参照してください。

TCP/IP:
/usr/include/sys/errno.h (UNIX(R)の場合)、nerrno.h (OS/2の場合)、winsock.h (Microsoft Windowsの場合)。winsock.hファイルについては、Microsoft Windowsの開発環境をインストールしていないと、システムにインストールされていない場合があります。

APPC:
お使いのAPPC製品のマニュアルを参照してください。

NETBIOS:
『LAN Technical Reference: IEEE 802.2 & NetBIOS APIs』を参照してください。

IPX/SPX:
/usr/include/sysにあるtiuser.h (OS/2またはUNIXの場合)またはwinsock.h (Microsoft Windowsの場合)のエラー値を参照してください。

収集するデータ

永続的な通信エラーで最もよく要求されるデータは以下のデータです。

  • サーバーのdbm cfg
  • クライアントとサーバーのカタログ
  • クライアントとサーバーのオペレーティング・システムとDB2のバージョンおよびFixPakレベル

これらの情報は、クライアントとサーバーで次のコマンドを実行することによって取得できます。

db2support <output path>

SYSADM権限を持つユーザーIDで実行すると、最も完全な情報が得られます。

DB2サポート・チームによって通信エラーのdb2トレースが要求された場合は、トレースを収集する方法についての指示があります。最も単純な再現シナリオでトレースを収集するように求められるのが一般的です。たとえば、サーバーだけで(ローカル接続またはループバック接続によって)問題を再現できる場合は、サーバーでトレースを収集するように求められます。一方、問題を再現するのにクライアントとサーバーの両方が必要な場合は、クライアントとゲートウェイまたはサーバーとで同時にトレースを収集するように求められます。これにより、クライアントからサーバーへの情報の流れを辿ることが可能になるため、破損やエラーの原因となっている箇所の特定に役立ちます。

セクション6: サマリー

この回で学んだこと

ここでは、環境を把握することの重要性、およびその知識を使って通信エラーの原因を特定する方法について学びました。また、DB2が含まれる前の段階の通信リンクを検証する手段としてPCTツールを使用する方法も紹介しました。このほか、4つの単純な問いを使って、返された通信エラーの性質と影響を特定したり、その情報を使ってエラーの原因をさらに絞り込んだりする方法についても説明しました。さらに、クライアントとサーバーの間のTCP/IP接続の構成を検証する方法や、サーバーでループバック接続を作成する方法に関する実践的知識も身に付けました。

詳細情報

『DB2 Troubleshooting Guide』および『Installation and Configuration Supplement』を参照してください。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=322458
ArticleTitle=DB2問題判別 習熟シリーズ: 第3回 接続の問題判別
publish-date=11162005