未確定スレッドの問題を解決するためのシナリオ

未確定スレッドは、さまざまな問題の原因になる可能性がありますが、そのような問題からリカバリーできます。

未確定スレッドのリカバリー・シナリオは、このトピックで説明するサンプル環境に基づいています。 個々の例について、必要に応じて、システム・プログラマー、オペレーター、データベース管理者のアクションが示されています。 以下の説明では、「管理者」という用語は、特に断りがない限りデータベース管理者 (DBA) を指します。

構成
地理的に 3 つの場所のある 4 つのシステムから構成されます。 場所は Seattle (SEA)、San Jose (SJ)、および Los Angeles (LA) です。 システムの説明は、次のとおりです。
  • Db2 シアトルのサブシステム、場所名 =、ネットワーク名 = IBMSEADB20001 IBM®.SEADB21
  • Db2 サンノゼのサブシステム、場所名 =、ネットワーク名 = IBMSJ0DB20001 IBM.SJDB21
  • Db2 ロサンゼルスのサブシステム、ロケーション名 =、ネットワーク名 = IBMLA0DB20001 IBM.LADB21
  • Seattle の IMS サブシステム、接続名 = SEAIMS01
アプリケーション
次の IMS および TSO アプリケーションは Seattle で実行されており、ローカル・データとリモート・データの両方にアクセスします。
  • IMS アプリケーション、、シアトルでは、DRDAアクセスによりローカルデータとリモートデータにアクセスし、サンノゼでは、シアトルに代わってリモートデータにアクセスする プライベートプロトコルアクセスにより、ロサンゼルスでアクセスします。 IMSAPP01 Db2
  • シアトルのTSOアプリケーション（ TSOAPP01 ）は、サンノゼとロサンゼルスでDRDAアクセスによりデータをアクセスします。
スレッド数
以下のスレッドについて説明し、 図1 にキーを付けます。 データベース・アクセス・スレッド (DBAT) は、 リモート・リクエスターにあるスレッド (関連スレッドまたは DBAT スレッド) に変わって、データにアクセスします。
  • シアトルのAllied IMS スレッドAが、DRDAアクセスによりサンノゼのデータにアクセスする。
    • サンノゼのDBATは、DR DAアクセス1 によりシアトルのデータにアクセスし、 Db2 のプライベートプロトコルアクセス 2 によりロサンゼルスのデータを要求します。
    • Los Angeles の DBAT は、Db2 プライベート・プロトコル・アクセスの 2 によって San Jose のデータにアクセスする。
  • シアトルのTSO スレッドB は、DRDAアクセスにより、サンノゼとロサンゼルスのローカルデータおよびリモートデータにアクセスします。
    • サンノゼのDBATは、DR DAアクセス3 によりシアトルのデータにアクセスする。
    • ロサンゼルスにあるDBATは、DRDA アクセス4 によりシアトルのデータにアクセスする。
図1： 疑わしいスレッドの解決。 Db2 サブシステムごとに DISPLAY THREAD TYPE(ACTIVE) を発行した結果。
図の説明の開始 この図は、3 つの異なるロケーションに配置された 4 つのシステムの間のスレッドを表すフローチャートです。 図の説明の終わり。

DISPLAY THREAD TYPE(ACTIVE) コマンドを発行して、すべての Db2 ロケーションのスレッドの状態を表示した結果は、前出の図のボックスに要約されています。 作業論理単位 ID (LUWID) は、読みやすくするために、次のように短縮形を使用しています。

  • LUWID=15 IBM.SEADB21.15A86A876789.0010 です。
  • LUWID=16 IBM.SEADB21.16B57B954427.0003 です。

この構成に基づいた手順では、両アプリケーションともすべての Db2 ロケーションのデータを更新したと想定します。 以下の問題シナリオでは、エラーは、 コーディネーターがコミット決定を記録してから、 影響を受ける参加プログラムがコミット決定を記録するまでの間に発生します。 そのため、参加プログラムは未確定になります。

1 つ以上のシナリオを読んで、ユーザー自身の環境の未確定スレッド問題に対処するための最良の方法を確認してください。