簡単シリーズ トレース編...program name: に 実行プログラム名が載ります。...

23
簡単シリーズ 簡単シリーズ トレース編 トレース編 2002/03 SS&WSCC#1 Systems Solution & Web Server Competence Center No.1 DM Group 目次 DB2 UDBのトレース機能と用途 DB2 イベントモニター 2-1 イベントモニター概要 2-2 SQLステートメントイベント 2-3 デッドロックイベント 2-4 イベントモニター補足事項 3. db2diag.log 4. CLIトレース 4-1 CLIトレースの収集方法 4-2 CLIトレースの調査例 5. db2trc 終わりに 付録 CLIトレースの追及例 1-2

Upload: others

Post on 02-Feb-2021

0 views

Category:

Documents


0 download

TRANSCRIPT

  • 簡単シリーズ簡単シリーズトレース編トレース編

    2002/03SS&WSCC#1

    Systems Solution & Web Server Competence Center No.1 DM Group

    目次

    1 DB2 UDBのトレース機能と用途2 DB2 イベントモニター

    2-1 イベントモニター概要2-2 SQLステートメントイベント2-3 デッドロックイベント2-4 イベントモニター補足事項

    3. db2diag.log4. CLIトレース

    4-1 CLIトレースの収集方法4-2 CLIトレースの調査例

    5. db2trc終わりに付録 CLIトレースの追及例

    1-2

  • Systems Solution & Web Server Competence Center No.1 DM Group

    トレース機能が欲しくなるのはどんな時でしょう?

    問題の原因究明

    なりゆきの把握

    悪い原因の発見

    証拠の収集

    DB2 UDBのアプリケーションやサーバーが期待通りの動きをしない時、何がどこまでうまく行って最後はどうなったか?成り行きを見て原因究明を行いたいことがあります。当資料ではこういった目的に使えるDB2の機能の使い方と見方をご紹介します。

    当資料では、各DB2の機能の正式名称にはこだわらず、この目的に合う機能をひろくトレース機能と呼んでいます

    1 DB2 UDBのトレース機能と用途

    Systems Solution & Web Server Competence Center No.1 DM Group

    よくある関心事と解決策

    アプリケーションの実行時間が長い、どこに時間がかかっているのだろう?実行時間の長いSQLがあるのか?それはどれか?SQLの発行と発行の間に時間がかかっているのか?SQLが非常に多く発行されているのか?

    イベントモニター for STATEMENTS を利用してみましょう

    デッドロックが起こってしまった。どこに原因があるのだろう?どのアプリケーションと、どのアプリケーションで起こったのか?どんなSQLとどんなSQLで起こったのか?どのクライアントとどのクライアントで起こったのか?

    イベントモニター for DEADLOCKS を利用してみましょう

    DB2でこんな現象が起きてしまった、その状況はどこに残っていないか?db2diag.log  ファイルを調べてみましょう

    Java や VB で不思議なエラーが返ってくる、これはなぜ?CLIトレースを収集してみましょう

    DB2内部エンジンの動きはわからないの?db2trc で資料収集してみましょう

    今までの資料でらちがあかない、そんな時どうする?状況によってはOSやPDツールによるiptraceも併用してみましょう

    1 DB2 UDBのトレース機能と用途

    3-4

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-1 イベントモニター概要

    イベントモニターの種類イベントモニターには次の8種類の事象を収集できます、この資料ではよく使われる2つを取り上げます

    DATABASEデータベースイベント

    全アプリケーションがデータベースから切断した時に記録TABLES

    各表のイベント全アプリケーションがデータベースから切断した時に記録

    DEADLOCKSデッドロックイベント

    デッドロックの発生時に記録TABLESPACE

    表スペースイベント全アプリケーションがデータベースから切断した時に記録

    BUFFERPOOLバッファープールイベント

    全アプリケーションがデータベースから切断した時に記録CONNECTIONS

    各アプリケーションの接続イベント各アプリケーションがデータベースから切断した時に記録

    STATEMENTSSQLステートメントイベント

    各SQLステートメントの完了時に記録TRANSACTION

    COMMIT/ROLLBACKイベント各トランザクションの終了時に記録

    デッドロックイベント

    ステートメントイベント

    Systems Solution & Web Server Competence Center No.1 DM Group

    2-1 イベントモニター概要

    イベントモニターの操作に必要な権限作成、削除、活動、非活動

    イベントモニターの操作はSYSADM または DBADM 権限に限られています

    イベントモニター使用の流れCREATE EVENT MONITOR sql によるイベントモニターの登録

    モニター名モニタータイプ書き出し先(ファイル、名前つきパイプ)オプション

    SET EVENT MONITOR STATE sql による イベントモニターの活動化

    発生したイベントをDB2が収集、書き出し

    SET EVENT MONITOR STATE sql によるイベントモニターの非活動化

    db2evmon プログラムによる編集出力

    イベントモニターの操作はCREATE EVENT MONITOR  SQL文であらかじめ登録された収集対象のイベントを活動化させてファイルまたは名前つきパイプにイベントを収集します

    ファイル出力すると、非活動化後に編集プログラムdb2evmonで編集出力できます名前つきパイプへ出力するとすぐに編集・処理プログラムへ渡すことができますイベントモニターのレコード形式は公開されていて編集プログラムをユーザーが作成す

    ることもできます。編集用サンプルプログラムも提供されています。

    db2 catalog登録

    アプリケーションdb2

    SQL

    出力先ファイル

    活動化

    非活動化

    0000000.evt

    db2evmon

    イベントモニター出力リスト

    5-6

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-2 SQL ステートメントイベント:収集手順

    収集手順使用環境:DB2 for Windows/NT V7.1 FP3

    Unix/Linux環境では書き出し先ディレクトリー名の変更と、そのディレクトリーへのdb2インスタンスのパーミッション付与が必要ですイベントモニターの登録

    create event monitor ev1 for statements write to file 'c:¥common¥kantan¥trace1' replaceDB20000I SQL コマンドが正常に終了しました。

    解説: DB2コマンドラインプロセッサーから、EV1 という名前のイベントモニターをSTATEMENTSイベントとして登録します出力はファイル書き出しとし、書き出し先ディレクトリー名を ' ' で囲んで指定しますreplace オプションをつけると、活動化-非活動化、のあと再度活動化した際に、前回のファイルを上書きします

    一般にトレースファイルは大きくなりがちですから、replaceオプションを使って前回分を含まない方が読みやすくなります

    イベントモニターの活動化set event monitor ev1 state 1DB20000I SQL コマンドが正常に終了しました。

    登録したイベントを活動化するとイベントの収集が始まります

    トレースしたいアプリケーションの実行

    イベントモニターの非活動化set event monitor ev1 state 0DB20000I SQL コマンドが正常に終了しました。

    登録したイベントを非活動化するとイベントの収集が終わり、ファイル書き出しが終了します

    イベントの編集出力db2evmon -db データベース別名  -evm ev1 > event1.txt

    イベントの出力を編集出力します。該当のデータベース別名とイベント名を指定します

    ブランクページ

    7-8

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-2 SQL ステートメントイベント:出力の見方

    実行時間の長いSQLはどれか? 8) Statement Event ... Appl Handle: 3 Appl Id: *LOCAL.DB2.010830105525 Appl Seq number: 0001

    Record is the result of a flush: FALSE ------------------------------------------- Type : Dynamic Operation: Close Section : 201 Creator : NULLID Package : SQLC2D01 Cursor : SQLCUR201 Cursor was blocking: FALSE Text : select count(*) from syscat.columns x, syscat.columns y ------------------------------------------- Start Time: 08/30/2001 19:59:09.057957 Stop Time: 08/30/2001 19:59:33.369759 Exec Time: 24.311802 seconds Number of Agents created: 1 User CPU: 23.573897 seconds System CPU: 0.040058 seconds Fetch Count: 1 Sorts: 0 Total sort time: 0 Sort overflows: 0 Rows read: 13158756 Rows written: 0 Internal rows deleted: 0 Internal rows updated: 0 Internal rows inserted: 0 SQLCA: sqlcode: 0 sqlstate: 00000

    実行時間 24.3秒

    CPU時間 23.5秒

    Select結果 1行

    DB2が読み取ったのは 13,158,756行

    正常終了 SQLCODE 0

    ①時間が長い

    ②行読み取り、行取り出しが多い

    ③問題の

    SQL

    カーソルのClose

    ハンドル3:アプリケーションのコネクション情報

    ハンドル3のコネクションヘッダー

    イベントを参照

    パッケージ名

    Select文はCloseイベントに注目すれば十分

    Select文を発行したパッケージ名(参考)

    参考

    発行された動的SQL文

    Systems Solution & Web Server Competence Center No.1 DM Group

    2-2 SQL ステートメントイベント:出力の見方:解説

    実行時間の長いSQLはどれか?

    ①:まず、実行時間とCPU時間の多いイベントに着目しましょうExec Time: に実行経過時間が秒単位でUser CPU Time: にDB2が使用したCPU時間が秒単位で表示されます

    これらが長いものを選びましょう、カーソルを使ったSelectの操作はPrepare Open Describe Close の4つのイベントとして載ります。このうちCloseの操作に着目すれ

    ば十分です

    ②:時間が長いのは取り扱った行数が多いためか、参考に見てみましょうFetch Count: にアプリケーションに返された、アプリケーションが受け取った行数がRows Read: には、その準備のためにDB2が内部的に読み取った行数が載ります

    ③:この処理に使われた動的SQLのSQL文を見てみましょうText:  に載ります、SQL文の最大長は64KB です

    次でこのSQLを発行したアプリケーション名を見るために、Appl Handle: と Appl Id: の値を確認しておきましょう

    9-10

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-2 SQL ステートメントイベント:出力の見方

    実行時間の長いSQLを発行したアプリケーションは何か? 3) Connection Header Event ... Appl Handle: 3 Appl Id: *LOCAL.DB2.010830105525 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.DB2.010830105525 Program Name : db2bp.exe Authorization Id: DB2ADMIN Execution Id : DB2ADMIN Codepage Id: 943 Country code: 81 Client Process Id: 832 Client Database Alias: sample Client Product Id: SQL07020 Client Platform: Unknown Client Communication Protocol: Local Client Network Name: Connect timestamp: 08/30/2001 19:55:25.815032

    ハンドル3:アプリケーションのコネクション情報

    ハンドル3のステートメントイベントを

    参照

    プログラム名 db2bp.exe (コマンドラインプロセッサー)

    接続したAUTHORIZATION IDはDB2ADMIN

    SAMPLEデータベース

    アプリケーションの情報をあらわす"コネクションヘッダーイベント"も出力に含まれています

    SQLの発行のステートメントイベントに載っていたAppl Handle: と Appl Id: の値を持つコネクションヘッダーイベントを探してみましょう

    Program Name: に 実行プログラム名が載ります。 db2bp.exe は DB2コマンドラインプロセッサーですJava ならば Java.exe 、MicroSoft Visual StudioのVisual Basic V6でADOを使っていてデバック中なら VB6.exe などと表示されますほかに、データベースへ接続時に指定したユーザーID(authorization ID) や接続のデータベース別名なども載ります

    この実行プログラム名は db2 list applications コマンドでも表示されます

    Systems Solution & Web Server Competence Center No.1 DM Group

    2-2 SQL ステートメントイベント:静的SQLの出力の見方

    実行時間の長いSQLを発行したアプリケーションは何か? 7) Statement Event ... Appl Handle: 10 Appl Id: *LOCAL.DB2.010830152055 Appl Seq number: 0001

    Record is the result of a flush: FALSE ------------------------------------------- Type : Static Operation: Execute Section : 1 Creator : DB2ADMIN Package : STATIC2 Cursor : Cursor was blocking: FALSE ------------------------------------------- Start Time: 08/30/2001 14:22:46.566173 Stop Time: 08/30/2001 14:23:20.986290 Exec Time: 34.420117 seconds Number of Agents created: 1 User CPU: 33.868701 seconds System CPU: 0.080115 seconds Fetch Count: 0 Sorts: 0 Total sort time: 0 Sort overflows: 0 Rows read: 2 Rows written: 0 Internal rows deleted: 0 Internal rows updated: 0 Internal rows inserted: 0 SQLCA: sqlcode: 0 sqlstate: 00000

    ハンドル10:アプリケーションのコネクション情報

    ハンドル10のコネクションヘッダー

    パッケージ名STATIC2

    Exucutes操作

    実行時間 34.4秒

    CPU時間 33.8秒

    6) Connection Header Event ... Appl Handle: 10 Appl Id: *LOCAL.DB2.010830152055 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.DB2.010830152055 Program Name : STATIC2.exe Authorization Id: DB2ADMIN Execution Id : DB2ADMIN Codepage Id: 943 Country code: 81 Client Process Id: 2068 Client Database Alias: sample Client Product Id: SQL07020 Client Platform: Unknown Client Communication Protocol: Local Client Network Name: Connect timestamp: 08/30/2001 14:22:46.556588

    プログラム名STATIC2.exe

    次に静的SQLについて見てみましょう静的SQLとは埋め込みSQLプログラムをプリコンパイルしバインドし実行するプログラミング方式です。実行時間やプログラム名は編集出力にあらわれますが、SQL文は直接現れません。これはすでにプリコンパイラーがSQL文を翻訳を事前に終えているためです。次に見るように、パッケージ名とセクション番号から、別のユーティリティを使ってSQL文を知ることができます

    セクション1

    11-12

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-2 SQL ステートメントイベント:静的SQLの出力の見方

    実行時間の長いSQLを発行したアプリケーションは何か?静的SQLプログラムの問題のSQL文はどんなものか?

    db2bfd -s static2.bnd

    static2.bnd: SQL Statements = 4

    Line Sec Typ Var Len SQL statement text---- --- --- --- --- --------------------------------------------------------- 41 0 10 0 13 INCLUDE SQLCA 51 0 5 0 21 BEGIN DECLARE SECTION 53 0 2 0 19 END DECLARE SECTION 65 1 0 1 135 SELECT CHAR(COUNT(*)) INTO :H00001 FROM SYSCAT.TABLES X, SYSCAT.TABLES Y, SYSCAT. TABLES Z

    ステートメントイベントでパッケージ中でSQL文が発行されたセクション番号がわかります。

    パッケージをバインドした元のバインドファイルがあれば、それに対してdb2bfdユーティリティを実行してセクション番号に対応するSQL文を表示することができます

    static2.bnd は静的SQLのソースをDB2プリコンパイラーでプリコンパイルして生成されたバインドファイルです

    セク

    ショ

    ン1

    static2.bndのセクション1のSQL文

    ブランクページ

    13-14

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-3 デッドロック イベント:収集手順

    収集手順説明使用環境:DB2 for Windows/NT V7.1 FP3

    Unix/Linux環境では書き出し先ディレクトリー名の変更と、そのディレクトリーへのdb2インスタンスのパーミッション付与が必要ですイベントモニターの登録

    create event monitor ev2 for deadlocks write to file 'c:¥common¥kantan¥trace2' replaceDB20000I SQL コマンドが正常に終了しました。

    解説: DB2コマンドラインプロセッサーから、EV2 という名前のイベントモニターをDEADLOCKSイベントとして登録します出力はファイル書き出しとし、書き出し先ディレクトリー名を ' ' で囲んで指定しますreplace オプションをつけると、活動化-非活動化、のあと再度活動化した際に、前回のファイルを上書きします

    一般にトレースファイルは大きくなりがちですから、replaceオプションで前回分を含まない方が読みやすくなります

    イベントモニターの活動化set event monitor ev2 state 1DB20000I SQL コマンドが正常に終了しました。

    登録したイベントを活動化するとイベントの収集が始まります

    デッドロックの発生

    イベントモニターの非活動化set event monitor ev2 state 0DB20000I SQL コマンドが正常に終了しました。

    登録したイベントを非活動化するとイベントの収集が終わり、ファイル書き出しが終了します

    イベントの編集出力db2evmon -db データベース別名  -evm ev2 > event2.txt

    イベントの出力を編集出力します。該当のデータベース別名とイベント名を指定します

    ブランクページ

    15-16

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-3 デッドロックイベント:出力の見方

    いつデッドロックが起こったのか?deadlock Event レコードの確認

    5) Deadlock Event ...(デッドロックの発生) Number of applications deadlocked: 2 Deadlock detection time: 08/30/2001 12:41:29.707303 Rolled back Appl Id: : *LOCAL.DB2.010830152046 Rolled back Appl seq number: : 0001

    6) Deadlocked Connection ...(デッドロック対象アプリケーション) Appl Id: *LOCAL.DB2.010830152046 (自分) Appl Seq number: 0001 (相手) Appl Id of connection holding the lock: *LOCAL.DB2.010830152045 Seq. no. of connection holding the lock: 0001 Lock wait start time: 08/30/2001 12:41:21.623688 Requesting lock as part of escalation: FALSE Deadlock detection time: 08/30/2001 12:41:29.707303 Table of lock waited on : EMPLOYEE Schema of lock waited on : ADMINISTRATOR Tablespace of lock waited on : USERSPACE1 Type of lock: Row Mode of lock: X Mode application requested on lock: NS Node lock occured on: 0 Lock object name: 4 Application Handle: 1 (自分)

    7) Deadlocked Connection ...(デッドロック対象アプリケーション) Appl Id: *LOCAL.DB2.010830152045 (自分) Appl Seq number: 0001 (相手) Appl Id of connection holding the lock: *LOCAL.DB2.010830152046 Seq. no. of connection holding the lock: 0001 Lock wait start time: 08/30/2001 12:39:42.599334 Requesting lock as part of escalation: FALSE Deadlock detection time: 08/30/2001 12:41:29.707303 Table of lock waited on : EMPLOYEE Schema of lock waited on : ADMINISTRATOR Tablespace of lock waited on : USERSPACE1 Type of lock: Row Mode of lock: X Mode application requested on lock: NS Node lock occured on: 0 Lock object name: 257 Application Handle: 0 (自分)

    2つのアプリケーションで発生この時刻にDEADLOCKが発生した

    RollBackしたのは6)の方

      

    コネクションヘッダー4)に対応

      

    コネクションヘッダー3)に対応

    Systems Solution & Web Server Competence Center No.1 DM Group

    2-3 デッドロックイベント:出力の見方:解説

    いつデッドロックが起こったのか?

    デッドロックイベントの出力にはDeadlock Event のレコードに続き、デッドロック対象のアプリケーションのレコードが載りますDeadlock Eventレコード はデッドロックの事象そのものですDeadlocked Connectionレコード がデッドロック対象アプリケーションです

    デッドロックイベントに発生時刻やRollbackされた側のアプリケーションID、関連したアプリケーション数が載ります

    デッドロック コネクションレコードには相手のアプリケーションのIDも載りますAppl Id of connection holding the lock: が相手のアプリケーションIDです

    デッドロック コネクションレコードには自分のAppl Id が載り、コネクションヘッダーイベントのレコードと対応付けられます。Appl Id とAppl Handle  がコネクションヘッダーイベントにもあります

    17-18

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-3 デッドロックイベント:出力の見方

    どのアプリケーションとどのアプリケーションでデッドロックが起こったのか?コネクションヘッダーイベントの確認

    3) Connection Header Event ...(コネクションヘッダー) Appl Handle: 0 Appl Id: *LOCAL.DB2.010830152045 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.DB2.010830105525 Program Name : db2bp.exe (DB2コマンドプロセッサー) Authorization Id: DB2ADMIN Execution Id : DB2ADMIN Codepage Id: 943 Country code: 81 Client Process Id: 832 Client Database Alias: sample      (SAMPLEデータベース) Client Product Id: SQL07020 Client Platform: Unknown Client Communication Protocol: Local Client Network Name: Connect timestamp: 08/30/2001 12:38:19.416275

    4) Connection Header Event ...(コネクションヘッダー) Appl Handle: 1 Appl Id: *LOCAL.DB2.010830152046 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.DB2.010830135535 Program Name : db2bp.exe (DB2コマンドプロセッサー) Authorization Id: DB2ADMIN Execution Id : DB2ADMIN Codepage Id: 943 Country code: 81 Client Process Id: 1980 Client Database Alias: sample (SAMPLEデータベース) Client Product Id: SQL07020 Client Platform: Unknown Client Communication Protocol: Local Client Network Name: Connect timestamp: 08/30/2001 12:38:27.186339

    前々ページのデッドロックコネクショ

    ンレコード7)に対応

    前々ページのデッドロックコネクションレコード

    6)に対応

    7)6)

    デッドロックコネクションレコードのAppl Id: か Appl Handle:の値を使ってコネクションヘッダーイベントを見つけることができますコネクションヘッダーイベントにはプログラム名があります

    Program Name: db2bp.exe は DB2コマンドプロセッサーがアプリケーションプログラムであることを示します

    Systems Solution & Web Server Competence Center No.1 DM Group

    2-3 デッドロックイベント:出力の見方

    どんなSQLと、どんなSQLで起こったのか?Deadlocked Connectionレコードの確認

    対象表名はTable of lock waited on とSchema of lock waited on でわかります、この場合Administrator.Employee表ですSQL文そのものは、この資料だけではわかりません

    しかしながら、取得されたLockのModeから発行されたSQLのタイプの候補を推測できますこのケースでは、INSERT/UPDATE/DELETE (Xロック)後SELECT(NSロック)された可能性があります

    ただしNSロックはSELECTだけとは限りませんのでこれ以外の可能性もあります、SQL文を特定するには別の情報が要ります

    6) Deadlocked Connection ...(デッドロック対象アプリケーション) Appl Id: *LOCAL.DB2.010830152046 (自分) Appl Seq number: 0001 (相手) Appl Id of connection holding the lock: *LOCAL.DB2.010830152045 Seq. no. of connection holding the lock: 0001 Lock wait start time: 08/30/2001 12:41:21.623688 Requesting lock as part of escalation: FALSE Deadlock detection time: 08/30/2001 12:41:29.707303 Table of lock waited on : EMPLOYEE Schema of lock waited on : ADMINISTRATOR Tablespace of lock waited on : USERSPACE1 Type of lock: Row (相手の保持していたロック) Mode of lock: X Mode application requested on lock: NS (自分の要求したロック) Node lock occured on: 0 Lock object name: 4 Application Handle: 1 (自分)

    7) Deadlocked Connection ...(デッドロック対象アプリケーション) Appl Id: *LOCAL.DB2.010830152045 (自分) Appl Seq number: 0001 (相手) Appl Id of connection holding the lock: *LOCAL.DB2.010830152046 Seq. no. of connection holding the lock: 0001 Lock wait start time: 08/30/2001 12:39:42.599334 Requesting lock as part of escalation: FALSE Deadlock detection time: 08/30/2001 12:41:29.707303 Table of lock waited on : EMPLOYEE Schema of lock waited on : ADMINISTRATOR Tablespace of lock waited on : USERSPACE1 Type of lock: Row (相手の保持していたロック) Mode of lock: X Mode application requested on lock: NS (自分の要求したロック) Node lock occured on: 0 Lock object name: 257 Application Handle: 0 (自分)

    相手がEMPLOYEE表の行のExclusive Lock持っている時に、自分はその行にNext Key Share Lockを取ろうとした

    相手がEMPLOYEE表の行のExclusive Lock持っている時に、自分はその行にNext Key Share Lockを取ろうとした

    対象表 対象表

    行のXロック

    行のXロック

    行のNextKey Shareロック

    行のNextKey Shareロック

    19-20

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-3 デッドロックトイベント:出力の見方

    どのクライアントと、どのクライアントで起こったのか?コネクションヘッダーイベントの確認

    3) Connection Header Event ...(コネクションヘッダー) Appl Handle: 0 Appl Id: *LOCAL.DB2.010830152045 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.DB2.010830105525 Program Name : db2bp.exe (DB2コマンドプロセッサー) Authorization Id: DB2ADMIN Execution Id : DB2ADMIN Codepage Id: 943 Country code: 81 Client Process Id: 832 Client Database Alias: sample      (SAMPLEデータベース) Client Product Id: SQL07020 Client Platform: Unknown Client Communication Protocol: Local (ローカルクライアント) Client Network Name: Connect timestamp: 08/30/2001 12:38:19.416275

    4) Connection Header Event ...(コネクションヘッダー) Appl Handle: 1 Appl Id: *LOCAL.DB2.010830152046 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.DB2.010830135535 Program Name : db2bp.exe (DB2コマンドプロセッサー) Authorization Id: DB2ADMIN Execution Id : DB2ADMIN Codepage Id: 943 Country code: 81 Client Process Id: 1980 Client Database Alias: sample (SAMPLEデータベース) Client Product Id: SQL07020 Client Platform: Unknown Client Communication Protocol: Local (ローカルクライアント) Client Network Name: Connect timestamp: 08/30/2001 12:38:27.186339

    このケースは Client Communication Protocol: Local となっていますので、サーバー内のアプリケーションでデッドロックが発生していますClient Communication Protocolが TCP/IPの場合、IPアドレスは application snapshot で知ることができます

    db2 get snapshot for all applications on データベース別名  でその時点のapplication snapshot をあらかじめ取得しておきますapplicaiton snapshotには各アプリケーションのあるクライアントのIPアドレスが出力されます、これとAppl Id でつき合わせことでIP

    アドレスがわかります、今回の例にはのっていません

    Systems Solution & Web Server Competence Center No.1 DM Group

    2-3 デッドロックイベント:再現させたSQLの流れ

    このケースでの発生原因(分離レベルCS)

    1)DELETE FROM EMPLOYEE WHERE EMPNO='000010'

    削除行にXロックEMPNOに索引あり

    3)SELECT COUNT(*) FROM EMPLOYEE WHERE SALARY = 1000.00

    索引の無い列Salaryの検索のために全件読み、2)のXロックへを待つ

    2)DELETE FROM EMPLOYEE WHERE EMPNO='000340'

    削除行にXロックEMPNOに索引あり

    4)SELECT COUNT(*) FROM EMPLOYEE WHERE SALARY = 2000.00

    索引の無い列Salaryの検索のために全件読み、1)のXロックを待つ

    Appl Id: *LOCAL.DB2.010830152046 Appl Id: *LOCAL.DB2.010830152045

    デッドロックを発生させる流れは次の通り1)左のアプリケーションでEMPLYEE表のキー000010をautocommit off でDELETEする2)右のアプリケーションでEMPLYEE表のキー000340をautocommit off でDELETEする3)左のアプリケーションでEMPLYEE表のSALARY = 1000.00 の条件を満たす行数をautocommit off で SELECTする

    SALARYには索引が無いので全行読んで調べるしかなく、1)で右が更新した行を読むためにNSロックを獲得しようとする、この時、右側のアプリケーションのDELETEによるXロック(Exclusive Lock)は保持されたままなのでロック待ちとなる

    NSロックは分離レベルCSでCommitずみの値を読むために要求される4)右のアプリケーションでEMPLYEE表のSALARY = 2000.00 の条件を満たす行数をautocommit off で SELECTする

    SALARYには索引が無いので全行読んで調べるしかなく、2)で左が更新した行を読むためにNSロックを獲得しようとする、この時、左側のアプリケーションのDELETEによるXロック(Exclusive Lock)は保持されたままなのでロック待ちとなる

    NSロックは分離レベルCSでCommitずみの値を読むために要求される5)左右ともロック待ちが解けないため、デッドロックが成立する

    21-22

  • Systems Solution & Web Server Competence Center No.1 DM Group

    2-4 イベントモニター補足事項イベントモニターの消去

    db2 drop event monitor for ev1 DB20000I SQL コマンドが正常に終了しました。

    登録したイベントモニターを削除します

    イベントモニターの再収集drop event monitor していなければ 何度でも "活動化、再現テスト、非活動化 、編集出力" を繰り返すことができます。

    参照情報記載場所

    CREATE EVENT MONITOR 他   SQL 解説書db2evmon コマンド解説書イベントモニター出力の解説 システムモニター手引きおよび解説書出力編集サンプルプログラム sqllib¥samples¥c¥ evm.c evmread.c evmprint.c

    ブランクページ

    23-24

  • Systems Solution & Web Server Competence Center No.1 DM Group

    db2diag.log ファイルの概要

    db2diag.logはDB2が情報を記録するASCIIファイル

    記録内容BACKUP / RESTORE などデータベース管理事象のログエラー情報

    エラーの理由を示すDIAメッセージエラーSQLCODEデータベースのクラッシュ時の情報、ダンプファイル、トラップファイル

    ファイルの場所データベースマネジャー構成パラメーターDB2DIAGPATHディレクトリー省略時:Windows SQLLIB¥DB2 ディレクトリー

    Unix インスタンスオーナーのホームディレクトリーの sqllib/db2dump

    記録方法常に最後に追加されるタイムスタンプ付き単調増大するため定期的に保存・削除が必要DIAGLEVELパラメータによる記録レベル指定(0-4、省略時3)

    DB2 EE/WE/PEでは3を推薦 4はinformationalメッセージが必要な場合に使用DB2 EEE本番システムでは3を推薦 4ではNFS共有ファイルへの書き込みのためパフォーマンスダウンの影響    DIAGPATHをNFSからローカルdiskに代えれば4も現実的

    3 db2diag.log ファイルの利用:概要

    Systems Solution & Web Server Competence Center No.1 DM Group

    db2diag.logファイルはdb2が情報を記録するasciiファイルです。記録内容には2種類あります。ひとつはデータベースのバックアップ・リストアなのデータベース管理の事象の記録です。もうひとつは発生したエラーに関する情報です。DIAではじまるメッセージコードでエラーの理由を説明する診断メッセージが書かれ、あわせてSQLCODEや発生したダンプファイルやトラップファイルを示します。

    db2diag.logファイルはDB2DIAGPATHデータベースマネジャー構成パラメータの示すディレクトリーに書かれます。省略時ではWindowsでsqllib¥db2 ディレクトリーにUnix/Linuxではインスタンスオーナーのホームディレクトリーのsqllib/db2dumpディレクトリーです。

    ファイルは常に最後に追加して書かれます。ファイルは単調増大するため、定期的に保存し削除する運用が必要です。メッセージにはタイムスタンプが付加されていて事象の発生時刻がわかります。

    データベース構成パラメータのDIAGLEVELパラメータ(0から4まで)により記録される情報のレベルが変わります。省略時は3でwarningまで記録されますが、4にするとより多く、informationalメッセージまで記録されます。DB2 EEではレベル4ではかなり情報量が多いためレベル3を推薦します。DB2 WE/PEも同様です。

    DB2 EEEでは省略時ではdb2diag.logファイルはNFS共有ファイルであるため書き出し量の多いレベル4ではパフォーマンスダウンを起こしえます。このため本番システムではレベル3を推薦します。レベル4を使いたい場合はDIAGPATHディレクトリーをNFSでなくローカルディスクへ変更することを推薦します

    解説:3 db2diag.log ファイルの利用:概要

    25-26

  • Systems Solution & Web Server Competence Center No.1 DM Group

    ロックエスカレーション事象の確認

    ロックエスカレーションが発生した時刻や表名、ロックタイプ等を知ることができます

    ロックエスカレーションの発生はSNAPSHOTモニターのデータベース スナップショットのLock escalations(ロックエスカレーション発生回数)やExclusive lock escalations(Xロックのロックエスカレーション回数)を見てわかります。

    db2diag.logを参照すれば時刻、表、該当Applid 等、より詳しい情報が把握できます

    DIAGLEVELは3で記録されます,DIAGLEVEL4ではさらにロックエスカレーションを起こした動的SQL文も表示されます

    3 db2diag.log ファイルの利用:ロックエスカレーション

    2001-09-05-08.48.38.752000 Instance:DB2 Node:000PID:852(db2syscs.exe) TID:1164 Appid:*LOCAL.DB2.010904234838data_management sqldEscalateLocks Probe:2 Database:TEST1

    -- Lock Count, Target : 1253, 626 -- Table (ID) Name : (2;6) DB2ADMIN.T1 -- Locks, Request Type : 1251, X -- Result (0 = success): 0

    表名:DB2ADMIN.T1

    Xロック(Exclusive ロック)

    ロックエスカレーション事象

    タイムスタンプ

    Systems Solution & Web Server Competence Center No.1 DM Group

    ロックタイムアウト事象の確認

    ロックタイムアウトの発生はSNAPSHOTモニターのデータベース スナップショットでのLock Timeouts(ロックタイムアウト発生回数)を見てわかります

    db2diag.logを参照すれば時刻、該当Applid 等、より詳しい情報が把握できます

    前提DIAGLEVELは4で記録されます

    3 db2diag.log ファイルの利用:ロックタイムアウト

    2001-09-05-09.09.36.370000 Instance:DB2 Node:000PID:848(db2syscs.exe) TID:1848 Appid:*LOCAL.DB2.010905000925lock_manager sqlplnfd Probe:80 Database:TEST1

    Request for lock "REC: (2, 6) RID 00000939" in mode "..X" timed outApplication caused the lock wait is "*LOCAL.DB2.010905000654"Package name: CURSOR2 Section: 2

    2001-09-05-09.08.40.931000 Instance:DB2 Node:000PID:848(db2syscs.exe) TID:1848 Appid:*LOCAL.DB2.010905000830lock_manager sqlplnfd Probe:80 Database:TEST1

    Request for lock "TAB: (2, 6)" in mode ".IX" timed outApplication caused the lock wait is "*LOCAL.DB2.010905000654"Package name: CURSOR2 Section: 1

    行のXロック要求がロックタイムアウト発生した例 表のIXロック要求がロックタイムアウト発生した例

    パッケージ名セクション番号

    パッケージ名セクション番号

    27-28

  • Systems Solution & Web Server Competence Center No.1 DM Group

    db2diag.logに載っているロックタイムアウトを起こしたパッケージ名とセクション名から、該当する静的SQLプログラムのSQL文を調査してみましょう。今回はDB2のカタログ視点からSQL文を調べてみます。

    前ページ左の行のXロック要求がロックタイムアウトした例はパッケージCURSOR2のセクション2でしたが、これはUPDATE文であることがSYSCAT.STATEMNTSをSELECTすることによりわかります

    このケースではロックタイムアウトの再現操作としてコマンドラインプロセッサーから次のSQLを発行しましたdb2 +c DELETE FROM T1 WHERE C1=1000

    前ページ右の表のIXロック要求がロックタイムアウトした例はパッケージCURSOR2のセクション1でしたが、これはSELECT文であることがSYSCAT.STATEMNTSをSELECTすることによりわかります。実際のコーディング上のステートメントはこのSELECT文に対するOpen cursor 文でロックタイムアウトが発生します。

    このケースではロックタイムアウトの再現操作としてコマンドラインプロセッサーから次のSQLを発行しましたdb2 +c LOCK TABLE T1 IN EXCLUSIVE MODE

    カタログ視点を使うとBINDされたパッケージのSQL文を実際に見ることができて確実です。一方、db2bfdユーティリティは使われたバインドファイルが確実にわかっているなら、データベースに全く影響を与えずにSQL文を調査できる利点があります

    3 db2diag.log ファイルの利用:ロックタイムアウト

    select pkgname, sectno, substr(text,1,128) as sql from syscat.statements where pkgname='CURSOR2'

    PKGNAME SECTNO SQL -------- ------ ----------------------------------------------------------CURSOR2 1 SELECT c1, c2 FROM t1 FOR UPDATE OF c2 CURSOR2 2 UPDATE T1 SET C2=C2+1 WHERE CURRENT OF C1

    2 レコードが選択されました。

    セクション1のSQL

    セクション2のSQL

    Systems Solution & Web Server Competence Center No.1 DM Group

    デッドロック事象の確認

    デッドロックの発生はSNAPSHOTモニターのデータベース スナップショットのDeadlock Detected(デッドロック検知した回数)を見てわかります

    db2diag.logを参照すれば時刻、Rollbackした動的SQL、要求されていたロックタイプ等、詳しい情報が把握できます

    DIAGLEVELは4で記録されます

    3 db2diag.log ファイルの利用:デッドロック

    2001-09-05-09.23.21.457000 Instance:DB2 Node:000PID:1856(db2syscs.exe) TID:1196 Appid:*LOCAL.DB2.010904121913lock_manager sqlplnfd Probe:80 Database:SAMPLE

    Request for lock "REC: (2, 6) RID 0000001B" in mode ".NS" failed due to deadlockApplication caused the lock wait is "*LOCAL.DB2.010905002035"Statement: 7365 6c65 6374 2063 6f75 6e74 282a 2920 select count(*) 6672 6f6d 2065 6d70 6c6f 7965 6520 7768 from employee wh 6572 6520 7361 6c61 7279 3d30 ere salary=0

    ロールバックしたSQL

    NSロック要求待ちでデッドロックになった

    相手のAppli Id

    Rollbackした側

    29-30

  • Systems Solution & Web Server Competence Center No.1 DM Group

    CLI(コールレベルインターフェース)の概要

    CLIとDB2Jdbc, ODBC, VB ADO, IBM native OLEDBプロバイダーなどはDB2へSQLを発行す

    るインターフェースとしてCLI(コールレベルインターフェース)を使っています。それぞれのプログラミングの結果がCLIのインターフェース変換されてDB2へ要求されます

    CLIはマイクロソフト社が提唱したODBCをもとに国際標準となったSQL/CLIプログラミングインターフェースです。

    DB2は国際標準SQL/CLIとODBC両方をサポートしています。DB2アプリケーションプログラミングはCLIプログラミングと埋め込みSQLプログラミングの2つに大別されます

    CLIの特徴CLIにはODBCの特徴でもあるデータベースの一覧を得るAPIや表の一覧を得るAPI

    が備わっています。CLIプログラミングでは表の一覧を得るために、データベースのカタログ表の名前や列名を知る必要がありません。

    埋め込みSQLプログラミングのようなアプリケーションプログラムのプリコンパイルは必要ありません。その代わりに、実行時に動的に必要な処理を行います。例えばアプリケーションプログラムがSELECT文を発行したら、結果を受け取る前にアプリケーションプログラムは、DB2に、”わたしが出したSELECT文の結果は何列ありましたっけ?”とか”1番目の列は列タイプは何で、長さはいくらでしたっけ?”、”二番目の列は......"のように動的に列属性に応じた処理をアプリケーションプログラムで行います。このためCLIのAPIは50個程度もあり、トレースも各列ごとにエントリーがあるためかなり長いものとなります。

    CLIトレースの用途JdbcやVB ADOからのプログラミングで予定外の事象が発生した場合はDB2へと

    CLIアプリケーションプログラムの接点でのなりゆきを示すCLIトレースの解析が役立ちます

    以下で資料の取り方と着眼点を紹介しましょう

    4 CLIトレース:概要

    ブランクページ

    31-32

  • Systems Solution & Web Server Competence Center No.1 DM Group

    CLIトレース収集の指定

    CLIはアプリケーションプログラムとDB2クライアントの接点となるインターフェースです。トレース収集の指定はDB2クライアント機に行います。

    以下はWindows 2000での指定です。Unix/Linux の場合は環境にあわせたディレクトリー名を指定し、DB2のインスタンスから書き出せるようにパーミッションを指定してください

    CLIアプリケーションの動くクライアントPCやクライアントインスタンスのdb2cli.iniファイルを編集しますsqllib¥db2cli.ini (Windowsの場合) sqllib/cfg/db2cli.ini (Unix/Linuxの場合)

    [COMMON]TRACEPATHNAME=C:¥CLITRACETRACE=1TRACEFLUSH=1

    説明TRACEPATHNAME

    CLIトレースを書き出すディレクトリーを指定しますマルチスレッドアプリケーションではスレッドごとにファイルができます

    TRACE=1CLIトレースを掛けることを指定します

    TRACEFLUSH=1トレースを同期的にディスクへ書き出す指定です、同期的書き出しの方がトレース収集のもれがないので安心です

    コメント化の方法;TRACE=1 のように先頭に; を付加すればコメントになります

    指定のタイミングdb2cli.ini ファイルを変更した後に、アプリケーションをデータベースへの接続から始めてください

    4-1 CLIトレースの収集方法

    Systems Solution & Web Server Competence Center No.1 DM Group

    例題:ストアードプロシージャビルダーで"ソース取得"がエラー

    ストアードプロシージャビルダーで開発したストアードプロシージャのソースはDB2カタログに格納されます。ストアードプロシージャビルダーを終了して次に開発の続きを行う場合はソースの取得という操作でソースプログラムを呼び出します

    この問題をCLIトレースで判別します、CLIトレースをエラーの起こるPCと正常のPCの両方で取得します

    ストアードプロシージャビルダーはJava jdbcアプリケーションです、jdbcドライバーはdb2へCLIのインターフェースでSQL発行します

    4-2 CLIトレース調査例

    33-34

  • Systems Solution & Web Server Competence Center No.1 DM Group

    トレース取得操作db2cli.ini にトレース取得のパラメータをセットします

    ストアードプロシージャビルダーを起動し、再現する直前まで操作します

    再現直前時点のトレースファイルコピー(参考)CLIトレースは多量に出力されるのでエラー個所を特定するためには"エラー発生前"のトレース範囲を知っておくと絞り込みが容易です

    参考のため、再現直前の段階でトレースディレクトリーに書かれたトレースファイルを別のディレクトリーにコピーしておきましょう。

    再現操作エラーが起きる操作を行って、エラーを再現させます

    再現直後のトレースファイルコピーエラー発生以降のエントリーができるだけ含まれないようにすみやかにコピーしましょう

    4-2 CLIトレース調査例

    db2cli.ini修正

    db2アプリケーション開始

    トレースコピー

    再現直前まで操作

    再現

    トレースコピー

    再現前トレース

    再現後トレース

    注目個所

    Systems Solution & Web Server Competence Center No.1 DM Group

    トレースファイルの確認再現直前にコピーしておいたトレースファイルと再現直後にコピーしたトレースファイルを比べると次のことがわかります

    ファイル数が、3個から4個に増えている1564.2のファイルの大きさが増えて最終更新時刻が1分あとに変わっている1564.3のファイルが再現後、新規に増えている

    このことから、問題のエラーの個所は1564.2のファイルの437バイト目より後、か1564.3ファイルに載っていると絞込むことができます

    4-2 CLIトレース調査例

    C:¥CLITRACE¥0906-1 のディレクトリ

    2001/09/06 06:23 .2001/09/06 06:23 ..2001/09/06 06:22 39,181 1564.02001/09/06 06:23 140,560 1564.12001/09/06 06:23 437 1564.2 3 個のファイル 180,178 バイト

    C:¥CLITRACE¥0906-2 のディレクトリ

    2001/09/06 06:24 .2001/09/06 06:24 ..2001/09/06 06:22 39,181 1564.02001/09/06 06:23 140,560 1564.12001/09/06 06:24 611 1564.22001/09/06 06:24 7,982 1564.3 4 個のファイル 188,334 バイト

    再現直前トレース

    再現直後トレース

    注 目 個 所

    注目個所

    35-36

  • Systems Solution & Web Server Competence Center No.1 DM Group

    エラーメッセージ発生個所の確認1564.3ファイルで SQL_ERROR を検索してみましょう、CLIプログラムでエラーメッセージが返される場合には必ずSQL_ERROR戻りコードが返ります

    ここではSQLGetDataInternal(列からのデータの取り出し)要求に対してSQL_ERRORが返っています、次にこのSQL_ERRORが問題のCLI0150Eメッセージ、SQLSTATE=HYC00になったのかどうか確認しましょう

    4-2 CLIトレース調査例

    C:¥CLITRACE¥0906-2 のディレクトリ

    2001/09/06 06:24 .2001/09/06 06:24 ..2001/09/06 06:22 39,181 1564.02001/09/06 06:23 140,560 1564.12001/09/06 06:24 611 1564.22001/09/06 06:24 7,982 1564.3 4 個のファイル 188,334 バイト

    再現直後トレース

    注 目 個 所

    SQLDescribeColW( hStmt=1:2, iCol=1, pszColName=NULL, cbColNameMax=0, pcbColName=NULL, pfSQLType=&0ab2fb08, pcbColDef=&0ab2fb0c, pibScale=NULL, pfNullable=NULL ) ---> Time elapsed - +6.798000E-003 seconds

    SQLDescribeColW( pfSQLType=SQL_LONGVARCHAR, pcbColDef=10485760 ) Time elapsed - +6.043000E-003 seconds

    SQLGetDataInternal( )

  • Systems Solution & Web Server Competence Center No.1 DM Group

    エラー発生個所のまとめ

    "どんな要求に対してどんなエラーメッセージが返されたのか?"トレースの第一次分析はここまでで十分です。前の2ページでわかったことをまとめてみましょう

    SQLGetDataInternal(列の値の取り出し)要求に対して、戻りコードSQL_ERROR が返された、エラーメッセージはCLI0150E SQLSTATEは HYC00, SQLCODE は -99999

    次に何をするか?

    エラーメッセージだけでは、"何をやったら"がわからなくて"どうなったか"だけしかわかりません。CLIトレースによって"何をやったら"の流れが始めからわかります。

    エラー発生より上を見て行く。このトレースの上を見ていけば原因は究明できるはずです。それには流れを追うためにCLIのプログラミングの知識が必要です。

    幸いCLIはODBCとISO のSQL/CLI の標準に準拠していますから、それらのプログラミングの経験者の方にも追いやすいものです。

    正常に動くトレースと比較する正常ケースのトレースと比較して違いを見つければ、あまりプログラミング知識がなくても原因がわかるでしょう。

    正常ケースとの環境の違いを見つけるdb2cli.iniの指定の違いなど、プログラムの外にある環境の違いでプログラムの動き方は変わります。db2cli.iniの指定はデータベー

    スのコネクションの際にトレースに載りますから、トレースを見ても違いがわかります。

    サポート部門への問い合わせ、事例照会ここまで資料がとれればIBMアンサーラインセンターなど専門の部門で追求ができるでしょう、また同様の事例検索のためのキー

    ワードもメッセージより多く得られたので問題事例照会も精度が上がるでしょう。これ以降の追及手順は付録に載せます。

    4-2 CLIトレース調査例

    ブランクページ

    39-40

  • Systems Solution & Web Server Competence Center No.1 DM Group

    db2trcの概要概要

    db2エンジンの動作の流れをトレースイベントモニターfor STATESMENTS や CLIトレースはアプリケーションプログラムから見たDB2への要求と応答の流れが載るものでした。これに対しdb2trcはdb2のエンジン内部の動きをトレースするツールです。

    出力情報は非公開db2trcの出力ファイルは読み方が公開されていません。アンサーラインセンターから要求されたら取得し、出力ファイルを送付します。

    注意点トレースは多量に出力されます、トレース収集は再現用のシステムを占有使用して、必要最小限の操作だけ行うのが現実的ですトレース収集は負荷のかかるため一般に、本番システムはサービス停止中に行うか別のシステムで再現させて収集します必要な権限はSYSADM SYSCTRL SYSMAINT ですDB2 EEE ではそれぞれのノードでトレース収集を実行する必要があります

    取得手順トレース取得手順はアンサーラインセンターから毎回具体的に指示されます。ここでは一例を紹介します。

    コマンドの仕様はコマンド解説書に記述されていますdb2trc on -e -1 -l 16000000

    トレースを開始します -e -1 はエラーが何個発生してもトレースを停止しない -l はトレースバッファーサイズです 問題を再現する db2trc dump trace.dat

    メモリー上のトレースをファイルに書き出します db2trc off

    トレースを止めます db2trc fmt trace.dat trace.fmt

    トレースのバイナリーファイルをフォーマットします、トレースがwrapしていないことをメッセージで確かめますwrapしていたら、始めの部分が上書きされて残っていません、トレースバッファーサイズを大きくするか、または手際よく、早く操作してとりなおしましょう

    db2trc flw trace.dat trace.flwフォーマットされたトレースがうまくとれていたら、トレースの流れのサマリーをあらわすflow トレースファイルを出力しましょう

    5 db2trc

    Systems Solution & Web Server Competence Center No.1 DM Group

    db2trcの利用例db2問題判別の手引きより

    問題:DB2を起動してアプリケーションからデータベースへCONNECTするとSQL1042C "予期しないシステムエラーが発生しました"のメッセージで全くCONNECTできない

    db2diag.log に情報があるが詳細が不明SQL1042Cの"メッセージのユーザーの応答":"データベースの接続中にエラーが起きた場合はトレースを取得(以下に指示があり

    ます)して、IBMサポートに連絡してください "

    5 db2trc

    db2diag.logメッセージ 1997-03-16-08:54:38.001160 Instance:payroll Node:000PID:74467(db2syscs (SAMPLE)) Appid:*LOCAL.payroll.970317140834data_management (5) sqldmund Probe:375 Database:SAMPLEError during undo. (3) 0ae6 ffff 0ae6 ffff 0000 005e efa2 6363 (4)

    db2trcのfmt出力3478 DB2 non-fatal_err oper_system_services sqloopenp (1.4.15.140) pid 55; tid 38; cpid 112; time 365535; trace_point 6 433a 5c44 4232 5c53 514c 3030 3030 315c /DB2/SQL00001/ 5351 4c54 3030 3032 2e30 5c53 514c 3030 SQLT0002.0/SQL00 3031 302e 4441 54 010.DAT (2)3479 DB2 cei_data oper_system_services sqloopenp (1.25.15.140) pid 55; tid 38; cpid 112; time 365535; trace_point 7 ffff ffff 3480 DB2 cei_errcode oper_system_services sqloopenp (1.6.15.140) pid 55; tid 38; cpid 112; time 365535; trace_point 254 return_code = 0xffffe60a (1) = -6646 = SQLO_FNEX

    db2diag.log のメッセージ

    0ae6 ffff はWindowsではバイト反転しているため実際は FFFF E60A ですE60A は 問題判別の手引き:付録A DB2 Internral Reuturn Codesの表ではFile does not exist ですどんなファイルが存在しなかったのか?ファイル名まではdb2diag.logには載っていません

    db2trcのトレース出力

    trace.fmt から e60a または E60A を検索するとトレースの3480番に0xffffe60a が見つかりますこれはOSのサービスsqloopenp の戻りコードですが、上へたどると/DB2/SQL00001/SQLT0002.0/SQL00010.DAT ファイルを処理していることがわかります。この処理の結果ファイルが見つからないメッセージが返されましたファイルの存在やUnix/Linuxならファイルのパーミッションを確認し、もし本当になければ、データベースのバックアップをrestoreしてend of log までrollforwardすればこのファイルも回復できるでしょう

    41-42

  • Systems Solution & Web Server Competence Center No.1 DM Group

    その他のツール参照情報

    DB2問題判別の手引き 第16章トレースAdministration Tools Trace

    コントロールセンター、アラートセンター、コマンドセンターなど管理ツールのトレースを収集しますddcsトレース

    DB2 Connectのトレースです。ホストDB2への接続時の問題判別に有効です。DB2 Connect使用者の手引きに使い方がありますdb2drdat

    DRDA 接続時に交換されるデータストリーム上の問題判別やパフォーマンスチューニングに有効ですSNAトレース

    SNA接続のホストDB2との通信に関してDB2がSNAアラートを生成する機能です同様にDB2はSNMPアラートも生成します

    CLIトレースのその他のトレース用キーワードTRACECOMM=0¦1 1でCLI要求・応答がネットワークを通った情報が載りますTRACETIMESTAMP= 3 タイムスタンプ(秒)がトレースに載ります              2 年月日秒マイクロ秒がトレースに載ります              1 タイムスタンプ(秒)と年月日秒マイクロ秒の両方がトレースに載りますTRACEPIDTID=0¦1  1 プロセスIDとスレッドIDがトレースに載ります

    JDBCトレースJDBCメソッドについてのトレースを収集します、db2cli.iniに以下のパラメータを指定しますJDBCTRACE=1JDBCTRACEPATHNAME=C:¥CLITRACEJDBCFLUSH=1

    ODBCドライバーマネジャートレースODBCドライバーマネジャートレースはアプリケーションがODBCドライバーマネジャーを呼び出す部分のトレースです(ODBCの場合CLIトレースはその後に、ODBCドライバーマネジャーからDB2クライアントが呼び出された部分のトレースです)これについてははMicrosoft ODBC3.0 SDKプログラマーズレファレンスを参照してください

    OSその他のトレースアプリケーションサーバーとデータベースサーバー間の問題判別の際にOSの持つIPトレースの機能やスニファーなどネットワーク上のトレースツールが有効な場合もあります。

    終わりに

    Systems Solution & Web Server Competence Center No.1 DM Group

    着眼点:列値を取り出そうとしてエラーとなった元のSELECT文はどんなものか?この操作はステートメントハンドル1:2を使ってSQLを発行して結果を操作しています、トレースを上にたどり、ステートメントハンドル1:2が(フリーされ再割り振りされたりせずに)有効な範囲でステートメントハンドル1:2のSQL文を探すとSELECT文のPrepareが見つかります

    付録 CLIトレースの追求例

    SQLDescribeColW( hStmt=1:2, iCol=1, pszColName=NULL, cbColNameMax=0, pcbColName=NULL, pfSQLType=&0ab2fb08, pcbColDef=&0ab2fb0c, pibScale=NULL, pfNullable=NULL ) ---> Time elapsed - +6.798000E-003 seconds

    SQLDescribeColW( pfSQLType=SQL_LONGVARCHAR, pcbColDef=10485760 ) Time elapsed - +6.043000E-003 seconds

    SQLGetDataInternal( ) Time elapsed - +3.798000E-003 seconds( StmtOut="select class_source from sysibm.sysjarcontents where jarschema = ? and jar_id = ? and class = ?" )

    SQLPrepareW( )

  • Systems Solution & Web Server Competence Center No.1 DM Group

    着眼点:問題のSELECTの列1はどんなものか?表名がsysibm.sysjarcontents で問題の列名がclass_sourceであることがわかりましたからDESCRIBE TABLEコマンドでCLASS_SOURCE列の列属性がわかります一方、問題発生直前のSQLDescribeCol関数は(第一列の)列属性をDB2に聞くためのものですが、ここではlong型10485760バイトとDB2から返されていますこの不一致はなぜでしょう?

    付録 CLIトレースの追求例

    SQLDescribeColW( hStmt=1:2, iCol=1, pszColName=NULL, cbColNameMax=0, pcbColName=NULL, pfSQLType=&0ab2fb08, pcbColDef=&0ab2fb0c, pibScale=NULL, pfNullable=NULL ) ---> Time elapsed - +6.798000E-003 seconds

    SQLDescribeColW( pfSQLType=SQL_LONGVARCHAR, pcbColDef=10485760 ) Time elapsed - +6.043000E-003 seconds

    SQLGetDataInternal( ) Time elapsed - +3.798000E-003 seconds

    ( StmtOut="select class_source from sysibm.sysjarcontents where jarschema = ? and jar_id = ? and class = ?" )

    SQLPrepareW( ) Time elapsed - +9.634000E-003 seconds( DBMS NAME="DB2/NT", Version="07.02.0000", Fixpack="0x23010105" )( Application Codepage=943, Database Codepage=943, Char Send/Recv Codepage=943, Graphic Send/Recv Codepage=941, iGraphic Codepage=941 )

    SQLDriverConnectW( )