9 Oracle Tuxedoアプリケーションのトラブルシューティング

このトピックには、次の項があります。

• 障害の種類の判別
  
• 非請求メッセージのブロードキャスト
  
• システム・ファイルの保守
  
• リカバリ時の注意事項
  
• 分断されたネットワークの修復
  
• 障害が発生したマシンの復元
  
• システム・コンポーネントの置換
  
• アプリケーション・コンポーネントの置換
  
• 手動によるサーバーのクリーンアップと再起動
  
• Oracle Tuxedo CORBAクライアントの起動失敗の原因
  
• トランザクションの中断とコミット
  
• トランザクション使用時における障害回復
  
• アプリケーションが正しく停止しない場合のIPCツールの使用
  
• マルチスレッド化またはマルチコンテキスト化されたアプリケーションのトラブルシューティング
  

9.1 障害の種類の判別

トラブルシューティングの最初のステップとして、まずどこで障害が発生したかを判別します。ほとんどのアプリケーションでは、障害の発生源として以下の6か所が考えられます。

障害が発生した場所を特定できたら、各箇所の担当者と協力して障害を解決してください。たとえば、ネットワーキングに関する障害が発生した場合は、ネットワーク管理者と協力して解決してください。

• アプリケーション障害の原因の判別
  
• Oracle Tuxedoシステムでの障害の原因の判別
  

9.1.1 アプリケーション障害の原因の判別

アプリケーション障害の原因を検出するには、次のステップに従います。

1. ユーザー・ログ(ULOG)内で、Oracle Tuxedoシステムの警告メッセージとエラー・メッセージを調べます。
2. 発生した問題を反映していると思われる内容のメッセージをいくつか選択します。

   ノート:

   各メッセージのカタログ名とメッセージ番号。これにより、該当するメッセージをシステム・メッセージで調べることができます。マニュアルの各項目には次の情報が含まれています。
   • メッセージが示すエラーの詳細内容
   • エラーを解決するための推奨措置
3. ULOG内でアプリケーションの警告メッセージとエラー・メッセージを調べます。
4. アプリケーション・サーバーおよびアプリケーション・クライアントによって生成された警告とエラーを調べます。このようなメッセージは通常、標準出力ファイルおよび標準エラー・ファイルに送られます(デフォルト名はそれぞれstdoutおよびstderr)。
   • stdoutファイルおよびstderrファイルはAPPDIR変数で定義されたディレクトリにあります。
   • クライアント側とサーバー側に設定されているstdoutファイルおよびstderrファイルの名前は、変更されている場合があります。stdoutファイルとstderrファイルの名前を変更するには、構成ファイル内で、該当するクライアントとサーバーの定義にそれぞれ-eまたは-oを指定します。詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のservopts(5)に関する項を参照してください。
5. APPDIR変数で定義されたディレクトリにコア・ダンプがないかどうかを調べます。dbxなどのデバッガを使用してスタック・トレースを実行します。コア・ダンプが見つかった場合は、アプリケーション開発者に通知します。
6. たとえば、sar(1)などのコマンドを実行してシステム・アクティビティ・レポートを調べ、システムが正しく機能しない原因を調べます。以下の原因が考えられます。
   • システムのメモリーが不足しています。
   • カーネルが正しくチューニングされていません。

9.1.2 Oracle Tuxedoシステムでの障害の原因の判別

システム障害の原因を検出するには、次のステップに従います。

1. ユーザー・ログ()内で、Oracle Tuxedoシステムの警告メッセージとエラー・メッセージを調べます:
   • TPEOSメッセージは、オペレーティング・システムにエラーが発生したことを示します。
   • TPESYSTEMメッセージは、Oracle Tuxedoシステムにエラーが発生したことを示します。
2. 発生した問題を反映していると思われる内容のメッセージをいくつか選択します。

   ノート:

   各メッセージのカタログ名とメッセージ番号。これにより、該当するメッセージを システム・メッセージで調べることができます。マニュアルの各項目には次の情報が含まれています。

   • メッセージが示すエラーの詳細内容
   • エラーを解決するための推奨措置
3. 次の手順でデバッグの準備をします。
   • suspendサービスを停止します。
   • tmboot -n -s(server) -d1を使用します。(このコマンドを実行してもサーバーは起動しませんが、サーバーを起動するためのコマンド行が出力されます。)dbxなどのデバッガを指定して、このコマンド行を使用してください。

9.2 非請求メッセージのブロードキャスト

イベント・ブローカのイベント・サマリー(システム全体に渡るサマリー)生成機能とメカニズム(イベントにより通知を発行)により、トラブルシューティングの機能が拡張されます。イベント・ブローカは、Oracle Tuxedoのシステム・イベント(サーバーの停止やネットワークの障害など)やアプリケーション・イベント(ATM機のメモリー不足など)の詳細を報告します。あるイベントに関する非請求通知を受信したOracle Tuxedoクライアントは、呼び出すサービス・ルーチンを指定したり、以降のデータの格納先とするアプリケーション・キューを指定することができます。また、非請求通知を受信したOracle Tuxedoサーバーは、サービス・リクエストを指定したり、データの格納先とするアプリケーション・キューを指定できます。

1. 非請求メッセージを送信するには、次のコマンドを入力します。

   broadcast (bcst) [-m machine] [-u usrname] [-c cltname] [text]

   ノート:

   デフォルトでは、メッセージはすべてのクライアントに送信されます。
2. ただし、メッセージの送信先を次のいずれかに制限することもできます。
   • 特定のマシン( -m machine )
   • 特定のクライアント・グループ(-c client_group)
   • 特定のユーザー(-u user)
   メッセージは、80文字以内で記述します。システムはSTRINGバッファ型でメッセージを送信します(つまり、クライアントの非請求メッセージ処理関数(tpsetunsol(0)で指定)では、この型のメッセージを処理できなければなりません)。この場合、tptypes()関数を使用すると便利です。

関連項目

『Oracle Tuxedo ATMIの紹介』の非請求通信に関する項

『Oracle Tuxedo ATMIの紹介』のイベント・ブローカを使用したイベントの管理に関する項

9.3 システム・ファイルの保守

ファイル・システムを保守するため、次のタスクを定期的に行う必要があります。

ノート:

このファイル形式は、TUXCONFIG、TLOGおよび/Qで使用されます。

• 汎用デバイス・リスト(UDL)の出力
  
• VTOC情報の出力
  
• デバイスの再初期化
  
• デバイス・リストの作成
  
• デバイス・リストの破棄
  

9.3.1 汎用デバイス・リスト(UDL)の出力

UDLを出力するには、次の手順に従います。

1. tmadmin -cを実行します
2. 次のコマンドを入力します。

   lidl

3. UDLを取得するデバイスを指定する方法は、次の2つです。
   • lidlコマンド行でデバイスを指定します。

     -z device_name [devindx]

   • 希望するデバイスの名前に環境変数FSCONFIGを指定します。

9.3.2 VTOC情報の出力

VTOC情報を出力するには、次の手順に従います。

1. tmadmin -cを実行します
2. すべてのVTOC表エントリの情報を取得するには、次のコマンドを入力します。

   livtoc

3. VTOCを取得するデバイスを指定する方法は、次の2つです。
   • lidlコマンド行で次のように指定します。

     -z device name [devindx ]

   • 希望するデバイスの名前に環境変数FSCONFIGを指定します。

9.3.3 デバイスの再初期化

デバイス・リスト内のデバイスを再初期化するには、次の手順に従います。

1. tmadmin -cを実行します
2. 次のコマンドを入力します。
   initdl [-z devicename] [-yes] devindx

   ノート:

   devindxには、破棄するファイルのインデックスを指定します。
3. 次の方法のいずれかでデバイスを指定できます。
   • ここで示すように-z オプションの後にその名前を入力するか、
   • デバイス名に環境変数FSCONFIGを指定します
4. コマンド行で-yesオプションを指定すると、ファイルを実際に破棄する前に、ファイルを破棄するかどうかを確認するプロンプトが表示されません。

9.3.4 デバイス・リストの作成

デバイス・リストを作成するには、次の手順に従います。

1. tmadmin -cを実行します
2. 次のコマンドを入力します。

   crdl [-z devicename] [-b blocks]

   • devicename [devindx]には、希望するデバイス名を指定します。(新しいデバイスに名前を割り当てる別の方法として、環境変数FSCONFIGに希望するデバイス名を設定することもできます。)
   • blocksの値には、必要なブロックの数を指定します。デフォルトは1000です。

   ノート: TLOGに関連する管理オーバーヘッド用に35ブロックが必要なため、TLOGを作成する場合は、35より大きい値を割り当てます。

9.3.5 デバイス・リストの破棄

devindxのインデックスを持つデバイス・リストを破棄するには、次の手順に従います。

1. tmadmin -cを実行します
2. 次のコマンドを入力します。

   dsdl [-z devicename] [yes] [devindx]

   ノート: devindxの値には、破棄するファイルの索引を指定します。
3. 次の方法のいずれかでデバイスを指定できます。
   • ここで示すように-zオプションの後にデバイス名を指定します
   • デバイス名に環境変数FSCONFIGを指定します
4. コマンド行でyesオプションを指定すると、ファイルを破棄するかどうかを確認するプロンプトは表示されません。

9.4 リカバリ時の注意事項

Oracle Tuxedoシステムの機能性を最適にするには、環境がある程度安定している必要があります。Oracle Tuxedoの管理サブシステムには、ネットワーク、マシン、およびアプリケーション・プロセスの障害から回復するための優れた機能が用意されていますが、これらも完璧ではありません。Oracle Tuxedoシステムが以下のように機能することを理解しておいてください。

SYSTEM_ACCESSのFASTPATHモデル(デフォルト)を使用するアプリケーション・クライアントおよびアプリケーション・サーバーは、Oracle Tuxedo共有データ構造へのダイレクト・メモリー・アクセスが可能です。FASTPATHモデルを使用すると、Oracle Tuxedoシステムのパフォーマンスを最大限に引き出すことができます。Oracle Tuxedoシステムでは、オペレーティング・システムが提供するIPC (InterProcess Communication)機能とファイル・システム機能を使用します。

アプリケーションで、これらの機能を誤って使用してOracle Tuxedo共有メモリーまたはOracle Tuxedoファイル記述子に書込みを行った場合や、誤ってほかのOracle Tuxedoシステム・リソースを使用した場合は、データが破壊されたり、Oracle Tuxedoの機能が損なわれたり、アプリケーションが停止したりするおそれがあります。

アプリケーション・クライアント、アプリケーション・サーバー、およびOracle Tuxedo管理プロセスは、重要な部分(つまり、共有メモリー内の共有情報の更新)で実行されている可能性があるため、ユーザーや管理者がこれらのプロセスを直接終了するのは適切ではありません。メモリーの更新中に重要な部分への割込みを行うと、内部データ構造に矛盾が生じるおそれがあります。(これは、Oracle Tuxedoシステム固有の問題ではなく、共有データを使用するすべてのシステムに共通の問題です。)Oracle Tuxedoユーザー・ログ内のエラー・メッセージがロックやセマフォを参照している場合、このようなデータの破壊が発生したことを示している可能性があります。

アプリケーションの可用性を最大にするには、Oracle Tuxedoシステムの冗長性管理機能(複数サーバー、マルチ・マシン、マルチ・ドメインなどの機能)を活用します。アプリケーションの機能を分散しておくと、1つの領域で障害が発生した場合でも操作を継続できます。

9.5 分断されたネットワークの修復

この項では、ネットワーク分断の原因を見つけ、回復するためのトラブルシューティングについて説明します。1つまたは複数のマシンからMASTERマシンにアクセスできない場合は、ネットワークが分断されています。アプリケーションの管理者は、ネットワークの分断を見つけ、回復する責任があります。

ネットワークの分断は、次のいずれかの失敗で発生します。

• ネットワークの障害 - 一時的な障害と重大な障害があります。一時的な障害は、発生後、数分で自動的に回復しますが、重大な障害では、分断されたマシンをネットワークから外す必要があります。
• MASTERマシンまたは非マスター・マシンで発生するマシンの障害
• BRIDGEの障害

分断されたネットワークのリカバリ手順は、分断された原因によって異なります。

• 分断されたネットワークの検出
  
• ネットワーク接続の回復
  

9.5.1 分断されたネットワークの検出

分断されたネットワークは、次のいずれかの方法で検出できます。

• ユーザー・ログ(ULOG) (ULOG)で、問題の原因を明らかにする可能性のあるメッセージを確認します。
• この目的に沿った tmadminのコマンドを実行して、ネットワーク、サーバー、およびサービスに関する情報を収集します。

• ULOGのチェック
  

9.5.1.1 ULOGのチェック

ネットワークで問題が発生すると、Oracle Tuxedoシステムの管理サーバーはULOGへメッセージを送り始めます。ULOGがリモート・ファイル・システム上で設定されている場合、すべてのメッセージは同じログに書き込まれます。したがって、1つのファイルでtail(1)コマンドを実行し、画面に表示される障害メッセージを調べることができます。

ただし、リモート・ファイル・システムが、障害のあるネットワークを使用している場合、リモート・ファイル・システムが使用できない場合があります。

リスト9-1 ULOGエラー・メッセージの例

151804.gumby!DBBL.28446: ... : ERROR: BBL partitioned,machine=SITE2

ネットワーク、サーバー、およびサービスに関する情報の収集

次のリストは、分断されたネットワークおよびそのネットワーク上のサーバーとサービスに関する情報を収集するtmadminセッションの例です。次の3つのtmadminコマンドが実行されます。

• pnw (printnetworkコマンド)
• psr (printserverコマンド)
• psc (printserviceコマンド)

tmadminセッションの例

$ tmadmin
> pnw SITE2
Could not retrieve status from SITE2

>psr -m SITE1 
a.out Name Queue Name Grp Name ID Rq Done Load Done Current Service 
BBL 30002.00000 SITE1 0 - - ( - ) 
DBBL 123456 SITE1 0 121 6050 MASTERBB 
simpserv 00001.00001 GROUP1 1 - - ( - ) 
BRIDGE 16900672 SITE1 0 - - ( DEAD )
>psc -m SITE1 
Service Name Routine Name a.out Grp Name ID Machine # Done Status
------------ ------------ -------- -------- -- ------- ------------
ADJUNCTADMIN ADJUNCTADMIN BBL SITE1 0 SITE1 - PART
ADJUNCTBB ADJUNCTBB BBL SITE1 0 SITE1 - PART
TOUPPER TOUPPER simpserv GROUP1 1 SITE1 - PART
BRIDGESVCNM BRIDGESVCNM BRIDGE SITE1 1 SITE1 - PART

9.5.2 ネットワーク接続の回復

この項では、一時的なネットワーク障害および重大なネットワーク障害からの回復方法を説明します。

• 一時的なネットワーク障害からの回復
  
• 重大なネットワーク障害からの回復
  

9.5.2.1 一時的なネットワーク障害からの回復

一時的なネットワーク障害は、BRIDGEによって自動的にリカバリされ、再接続されるため、通常ユーザー側ではこの障害の発生はわかりません。ただし、一時的なネットワーク障害を手動でリカバリする必要がある場合は次の手順に従います。

1. MASTERマシンでtmadmin(1)セッションを開始します。
2. reconnectコマンド(rco)を実行し、分断されていないマシンと分断されたマシンの名前を指定します:

   rco non-partioned_node1 partioned_node2

9.5.2.2 重大なネットワーク障害からの回復

重大なネットワーク障害を回復するには、次の手順に従います。

1. MASTERマシンでtmadminセッションを開始します。
2. pcleanコマンドを実行して、分断されたマシンの名前を指定します。

   pcl partioned_machine

3. アプリケーション・サーバーを移行するか、または障害の修復後にマシンを再起動します。

9.6 障害が発生したマシンの復元

障害が発生したマシンを復元する手順は、マシンがMASTERマシンであるかどうかによって異なります。

• 障害が発生したMASTERマシンの復元
  
• 障害が発生した非マスター・マシンの復元
  

9.6.1 障害が発生したMASTERマシンの復元

障害が発生したMASTERマシンを復元するには、次の手順に従います。

1. Oracle Tuxedoのプロセスに対するIPC資源がすべて除去されていることを確認します。
2. ACTING MASTER (SITE2)でtmadminセッションを開始します:

   tmadmin

3. 次のコマンドを入力してMASTER (SITE1)でBBLを起動します:

   boot -B SITE1

   (SITE1でpcleanを実行していない場合、BBLは起動できません。)

4. tmadminセッションで、次のように入力して、MASTERサイト((SITE1))で再度DBBLを実行します:

   MASTER

5. 障害が発生したマシンからアプリケーション・サーバーとデータを移行した場合は、再起動するか、または移行を元に戻します。

9.6.2 障害が発生した非マスター・マシンの復元

障害が発生した非マスター・マシンを復元するには、次の手順に従います。

1. MASTERマシンでtmadminセッションを開始します
2. pcleanを実行し、分断されたマシンをコマンド行で指定します。
3. マシンの問題を修正します。
4. MASTERマシンからBBLを起動して、障害の発生したマシンを復元します。

次のリストに、非マスター・マシンSITE2を復元する例を示します。

リスト9-3 障害が発生した非マスター・マシンの復元の例

$ tmadmin 
tmadmin - .......................; ..................

> pclean SITE2 
Cleaning the DBBL. 

Pausing 10 seconds waiting for system to stabilize.
3 SITE2 servers removed from bulletin board

> boot -B SITE2 
Booting admin processes ... 

Exec BBL -A : 

on SITE2 -> process id=22923 ... Started. 
1 process started. 
> q

9.7 システム・コンポーネントの置換

Oracle Tuxedoシステムのコンポーネントを置換するには、次の手順に従います。

1. 置換したいOracle Tuxedoシステム・ソフトウェアをインストールします。
2. 変更によって影響を受ける次のアプリケーションの部分を停止します。
   • ライブラリが更新された場合は、Oracle Tuxedoシステム・サーバーを停止します
   • 関連するOracle Tuxedoシステムのヘッダー・ファイルまたは静的ライブラリが置換された場合は、アプリケーションのクライアントとサーバーを停止して再度ビルドする必要があります。(ただし、Oracle Tuxedoシステムのメッセージ・カタログ、システム・コマンド、管理サーバー、または共有オブジェクトが置換された場合、アプリケーションのクライアントとサーバーのビルドは必要ありません。)
3. 関連するOracle Tuxedoシステムのヘッダー・ファイルおよび静的ライブラリが置換される場合は、アプリケーションのクライアントとサーバーを再度ビルドします。
4. 停止したアプリケーション部分を再起動します。

9.8 アプリケーション・コンポーネントの置換

アプリケーションのコンポーネントを置換するには、次の手順に従います。

1. アプリケーション・ソフトウェアをインストールします。アプリケーション・ソフトウェアの構成要素には、アプリケーション・クライアント、アプリケーション・サーバー、および管理ファイル(FMLフィールド表など)があります。
2. 置換するアプリケーション・サーバーを停止します。
3. 必要に応じて、新しいアプリケーション・サーバーをビルドします。
4. 新しいアプリケーション・サーバーを起動します。

9.9 手動によるサーバーのクリーンアップと再起動

デフォルトでは、Oracle Tuxedoシステムはデッド・プロセスに関連付けられた資源(キューなど)をクリーンアップし、BBLスキャン中に定期間隔で掲示板(BB)から再起動可能な停止したサーバーを再起動します。ただし、ほかの時点でもクリーンアップをリクエストできます。

• デッド・プロセスに関連付けられた資源のクリーンアップ
  
• ほかの資源のクリーンアップ
  
• Oracle Tuxedo CORBAサーバーの起動順序の確認
  
• Oracle Tuxedo CORBAサーバーのホスト名形式と大文字/小文字の確認
  

9.9.1 デッド・プロセスに関連付けられた資源のクリーンアップ

デッド・プロセスに関連付けられた資源を直ちにクリーンアップするには、次の手順に従います。

1. tmadminセッションを開始します。
2. bbclean machineを入力します。

   bbcleanコマンドには、オプションの引数として、クリーンアップされるマシンの名前を指定できます。

オプション	結果
マシンを指定しない場合	デフォルト設定のマシン上の資源がクリーンアップされます。
マシンを指定する場合	指定したマシン上の資源がクリーンアップされます。
DBBL	DBBL (Distinguished Bulletin Board Liaison)およびすべてのサイトの掲示板の資源がクリーンアップされます。

9.9.2 ほかの資源のクリーンアップ

ほかの資源をクリーンアップするには、次の手順に従います。

1. tmadminセッションを開始します。
2. pclean machine を入力します。

   ノート:

   machineには値を指定する必要があります。これは必須引数です。

指定されたマシン	結果
分断されていないマシン	pcleanはbbcleanを呼び出します。
分断されたマシン	pcleanは、分断されていないすべての掲示板からサーバーとサービスの全エントリを削除します。

このコマンドは、不意に分断が生じた後でシステムを正常に復元する場合に便利です。

9.9.3 Oracle Tuxedo CORBAサーバーの起動順序の確認

Oracle Tuxedo CORBAアプリケーションの起動に失敗した場合は、テキスト・エディタでアプリケーションのUBBCONFIGファイルを開き、SERVERSセクションでサーバーが正しい順序で起動されているかどうかを確認します。Oracle Tuxedo CORBA環境でのサーバーの正しい起動順序は次のとおりです。この規則に違反した場合、Oracle Tuxedo CORBAアプリケーションは起動しません。

サーバーの起動順序

1. システムのイベント・ブローカであるTMSYSEVT。
2. -N および-M オプションが設定されたTMFFNAMEサーバー。NameManagerサービスを(MASTERとして)起動します。このサービスは、アプリケーション側で提供される名前とオブジェクト参照のマッピングを維持します。
3. -Nオプションのみが設定された TMFFNAME サーバー。スレーブNameManagerサービスを起動します。
4. -Fオプションが設定されたTMFFNAMEサーバー。FactoryFinderを起動します。
5. ファクトリを通知するアプリケーション・サーバー。

詳細な例は、『Oracle Tuxedoアプリケーションの設定』のCORBA C++サーバーの起動順序に関する項を参照してください

9.9.4 Oracle Tuxedo CORBAサーバーのホスト名形式と大文字/小文字の確認

プログラマがBootstrapオブジェクト・コンストラクタまたはTOBJADDRで指定したネットワーク・アドレスは、サーバー・アプリケーションのUBBCONFIGファイルにあるネットワーク・アドレスと完全に一致している必要があります。アドレスの形式や、大文字/小文字も一致する必要があります。アドレスが一致しない場合は、Bootstrapオブジェクト・コンストラクタの呼出しが失敗し、一見無関係と思われる次のエラー・メッセージが表示されます。

ERROR: Unofficial connection from client at

<tcp/ip address>/<port-number>:

たとえば、ネットワーク・アドレスが、サーバー・アプリケーションのUBBCONFIGファイルにあるISLコマンド行のオプション文字列で//TRIXIE:3500に指定されている場合、Bootstrapオブジェクト・コンストラクタやTOBJADDRで//192.12.4.6:3500または//trixie:3500のいずれかを指定すると、接続が失敗します。

UNIXシステムで大文字/小文字の区別を調べるには、ホスト・システムでuname -nコマンドを使用します。Windowsシステムでは、ホスト・システムで「コントロール・パネル」の「ネットワーク」を使用して大文字/小文字を指定します。

9.10 Oracle Tuxedo CORBAクライアントの起動失敗の原因

Oracle Tuxedo CORBAアプリケーションを実行するWindowsサーバーで、一部のインターネットORB間プロトコル(IIOP)クライアントを起動した後、//host:portが正しく指定されているにもかかわらず、一部のクライアントでBootstrapオブジェクトを作成できず、InvalidDomainメッセージが返される場合は、次のステップを実行できます。(関連情報については、「Oracle Tuxedo CORBAサーバーのホスト名形式と大文字/小文字の確認」という項を参照してください。)

1. regedt32 (レジストリ・エディタ)を起動します。
2. ローカル・マシンのHKEY_LOCAL_MACHINEウィンドウに移動します。
3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parametersを選択します
4. 「編集」->「値の追加」メニュー・オプションを使用して、次の値を追加します:
   • DynamicBacklogGrowthDelta: REG_DWORD : 0xa
   • EnableDynamicBacklog: REG_DWORD: 0x1
   • MaximumDynamicBacklog: REG_DWORD: 0x3e8
   • MinimumDynamicBacklog: REG_DWORD: 0x14
5. Windowsを再起動し、変更を有効にします。

これらの値を追加することにより、5つの保留接続が保持される静的接続キュー(つまり、バックログ)が、動的接続バックログに置き換えられます。この動的接続バックログには、最小20エントリ(最小0x14)、最大1000エントリ(最大0x3e8)を格納でき、最小値から最大値の間で10ずつ増加できます(0xa間隔)。

これらの設定は、システムが受信した接続にのみ適用されますが、IIOPリスナーでは受け付けられません。マイクロソフトでは、最小値20、間隔10という値を推奨しています。最大値はマシンに依存します。ただし、Microsoftは、Windowsサーバーでは最大値が5000を超えないようにすることをお薦めします。

9.11 トランザクションの中断とコミット

この項では、トランザクションの中断とコミットの方法について説明します。

• トランザクションの中断
  
• トランザクションのコミット
  

9.11.1 トランザクションの中断

トランザクションを中断するには、次の手順に従います。

1. 次のコマンドを入力します。

   aborttrans (abort) [-yes] [-g groupname] tranindex

2. tranindexの値を確認するために、printtransコマンド(tmadminコマンド)を実行します。
3. groupnameが指定されると、メッセージがそのグループのTMSに送信され、そのグループのトランザクションにabortedのマークが付けられます。グループが指定されないと、メッセージはトランザクション・コーディネータのTMSに送信され、トランザクションの中断をリクエストします。中断処理を制御するには、トランザクション内のすべてのグループに中断メッセージを送信する必要があります。

このコマンドは、トランザクション・コーディネータのサイトが分断されているか、またはクライアントがコミットまたは中断を呼び出す前に終了してしまった場合に便利です。タイムアウト値が大きいと、トランザクションは、中断されるまでトランザクション表に残ります。

9.11.2 トランザクションのコミット

トランザクションをコミットするには、次のコマンドを入力します。

committrans (commit) [-yes] [-g groupname] tranindex

ノート:

groupnameおよびtranindexは必須引数です。

トランザクションがプリコミットされていないか、または中断済マークが付いている場合、操作は失敗します。トランザクションを完全にコミットするため、このメッセージはすべてのグループに送信しなければなりません。

• committransコマンドの使用上の注意
  

9.11.2.1 committransコマンドの使用上の注意

committransコマンドの使用には注意が必要です。このコマンドは、次の2つの条件に合致する場合にのみ実行できます。

• すべてのグループがコミット・メッセージを受信する前に、トランザクション・コーディネータのTMSがダウンした。
• トランザクション・コーディネータのTMSが、ある期間トランザクションを回復できなくなります。

また、クライアントがtpcommit()でブロックされることもありますが、これはタイムアウトになります。管理コミットを実行する場合には、そのことをクライアントに必ず知らせてください。

9.12 トランザクション使用時における障害回復

管理対象のアプリケーションにデータベース・トランザクションが含まれる場合は、ディスク破損の障害後に復元したデータベースにアフター・イメージ・ジャーナル(AIJ)を適用する必要があります。または、このリカバリ・アクティビティのタイミングをサイトのデータベース管理者(DBA)と調整することが必要になる可能性もあります。通常はエラーが発生すると、データベース管理ソフトウェアが自動的にトランザクションのロールバックを実行します。ただしデータベース・ファイルを格納するディスクが永久的に破損した場合は、システム管理者またはDBAが介入してロールフォワード操作を行うことが必要になることもあります。

データベースの一部を含むディスクが、水曜日の3:00 P.M.に破損したと想定します。この例では、シャドウ・ボリューム(ディスク・ミラーリング)が存在しないとします。

1. Oracle Tuxedoアプリケーションを停止します。(手順は、アプリケーションの起動と停止を参照してください。)
2. データベースの最新のフル・バックアップを取得し、ファイルを復元します。たとえば、先週の日曜日12:01 A.M.現在のデータベースのフル・バックアップ・バージョンを復元します。
3. 月曜日、火曜日、の順に、インクリメンタル・バックアップ・ファイルを適用します。たとえば、この場合は火曜日の午後11時までのデータベースを復元するとします。
4. 火曜日の11:15 P.M.から水曜日の2:50 P.M. までのトランザクションを含むトランザクション・ジャーナル・ファイル(AIJ)を適用します。
5. データベースを再度オープンします。
6. Oracle Tuxedoアプリケーションを再起動します。

データベースのロールフォワード・プロセスの具体的な説明については、リソース・マネージャ(データベース製品)のマニュアルを参照してください。

9.13 アプリケーションが正しく停止しない場合のIPCツールの使用

IPC資源とは、メッセージ・キュー、共有メモリー、セマフォなどのオペレーティング・システムの資源のことです。tmshutdownコマンドを使用してOracle Tuxedoアプリケーションを正常に停止すると、IPC資源はすべてシステムから削除されます。ただし、アプリケーションが正常に停止せず、システムにIPC資源が残る場合もあります。これが起こると、アプリケーションを再起動できなくなることがあります。

この問題の解決策として、IPCSコマンドを実行するスクリプトを使用してIPCリソースを削除し、特定のユーザーが保有するすべてのIPCリソースをスキャンする方法があります。しかし、この方法ではIPC資源の識別が困難です。たとえば、Oracle Tuxedoアプリケーションの資源か、特定のOracle Tuxedoアプリケーションに属する資源か、またはOracle Tuxedoシステムとは無関係の資源かを識別することができません。誤ってIPC資源を削除するとアプリケーションが破損する可能性があるため、資源の種類を識別できることは重要です。

Oracle TuxedoのIPCツール(tmipcrmコマンド)を使用すると、実行中のアプリケーションでOracle Tuxedoシステムによって割り当てられているIPCリソース(コア・システムとWorkstationコンポーネントのみ)を削除できます。

IPCリソースを削除するコマンドtmipcrmは、TUXDIR/binに格納されています。このコマンドは、バイナリ形式の構成ファイル(TUXCONFIG)を読み込み、このファイルの情報を使用して掲示板に書き込みます。tmipcrmを使用できるのは、ローカル・サーバー・マシンに対してのみです。Oracle Tuxedoの構成のリモート・マシンにあるIPCリソースは削除できません。

このコマンドを実行するには、次のコマンド行を入力します。

tmipcrm [-y] [-n] [TUXCONFIG_file]

IPCツールを使用すると、Oracle Tuxedoシステムで使用されるすべてのIPC資源を一覧表示したり、IPC資源を削除することができます。

ノート:

このコマンドは、TUXCONFIG環境変数を正確に設定するか、またはコマンド行で適切なTUXCONFIGファイルを指定しないと利用できません。

9.14 マルチスレッド化またはマルチコンテキスト化されたアプリケーションのトラブルシューティング

• マルチスレッド化またはマルチコンテキスト化されたアプリケーションのデバッグ
  
• マルチスレッド化されたアプリケーションでの保護モードの制限
  

9.14.1 マルチスレッド化またはマルチコンテキスト化されたアプリケーションのデバッグ

シングル・スレッドのアプリケーションと比較すると、マルチスレッド化されたアプリケーションのデバッグは困難です。そのため、管理者側で、マルチスレッド化されたアプリケーションの作成基準となるポリシーを決めておくと便利です。

9.14.2 マルチスレッド化されたアプリケーションでの保護モードの制限

実行中のアプリケーションが保護モードの場合、そのアプリケーションはATMI呼出しが実行されたときのみ共有メモリーにアタッチされます。保護モードにしておくと、Oracle Tuxedoの共有メモリーが不正なアプリケーション・ポインタによって誤って上書きされるのを防ぐことができます。

保護モードで実行中のマルチスレッド・アプリケーションには、アプリケーション・コードを実行するスレッドと、Oracle Tuxedoの関数呼出しにより掲示板の共有メモリーにアタッチされるスレッドが混在している場合があります。したがって、ATMI呼出しで掲示板にアタッチされたスレッドが少なくとも1つあると、保護モードを実行しても、アプリケーション・コードを実行するスレッドを不正なアプリケーション・ポインタから保護できず、Oracle Tuxedoの共有メモリーが上書きされる場合があります。つまり、マルチスレッド化されたアプリケーションでは、保護モードの効果が制限されています。

この制限を解除する方法はありません。マルチスレッド化されたアプリケーションを実行するときは、シングル・スレッドのアプリケーションのときほど、保護モードを信頼できない点に注意してください。