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

ドキュメントのダウンロード

サイトマップ

用語集

検索

e-docs > Tuxedo > Tuxedo アプリケーション実行時の管理 > BEA Tuxedo アプリケーションのトラブルシューティング

Tuxedo アプリケーション実行時の管理

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

ここでは、次の内容について説明します。

障害の種類の判別

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

アプリケーション
BEA Tuxedo システム
データベース管理ソフトウェア
ネットワーク
オペレーティング・システム
ハードウェア

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

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

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

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

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

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

ユーザ・ログ (ULOG) 内で、BEA Tuxedo システムの警告メッセージとエラー・メッセージを調べます。
- TPEOS メッセージは、オペレーティング・システムにエラーが発生したことを示します。
- TPESYSTEM メッセージは、BEA Tuxedo システムにエラーが発生したことを示します。
発生した問題を反映していると思われる内容のメッセージをいくつか選択します。各メッセージのカタログ名とメッセージ番号を書き留めておき、該当するメッセージを『システム・メッセージ』で調べます。マニュアルの各項目には次の情報が含まれています。
- メッセージが示すエラーの詳細内容
- エラーを解決するための推奨措置
次の手順でデバッグの準備をします。
- suspend サービスをシャットダウンします。
- tmboot -n -s(server) -d1 を実行します(このコマンドを実行してもサーバは起動しませんが、サーバを起動するためのコマンド行が出力されます)。dbx などのデバッガを指定して、このコマンド行を使用してください。

任意通知型メッセージのブロードキャスト

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

任意通知型メッセージを送信するには、次のコマンドを入力します。
```
broadcast (bcst) [-m machine] [-u usrname] [-c cltname] [text] 
```
注記デフォルトでは、メッセージはすべてのクライアントに送信されます。
ただし、メッセージの送信先を次のいずれかに制限することもできます。

メッセージは、80 文字以内で記述します。システムは STRING バッファ型でメッセージを送信します。つまり、クライアントの任意通知型メッセージ処理関数 (tpsetunsol(0) で指定) では、この型のメッセージを処理できなければなりません。この場合、 tptypes() 関数を使用すると便利です。

関連項目

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

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

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

汎用デバイス・リスト (UDL: Universal Device List) の出力

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

tmadmin -c を実行します。
次のコマンドを入力します。
```
lidl
```
UDL を取得するデバイスを指定する方法は、次の 2 つです。
- lidl コマンド行で次のように指定します。
```
-z device_name [devindx]
```
- 希望するデバイスの名前に環境変数 FSCONFIG を指定します。

VTOC 情報の出力

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

tmadmin -c を実行します。
すべての VTOC テーブル・エントリの情報を取得するには、次のコマンドを入力します。
```
livtoc
```
VTOC を取得するデバイスを指定する方法は、次の 2 つです。
- lidl コマンド行で次のように指定します。
```
-z device name [devindx]
```
- 希望するデバイスの名前に環境変数 FSCONFIG を指定します。

デバイスの再初期化

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

tmadmin -c を実行します。
次のコマンドを入力します。
```
initdl [-z devicename] [-yes] devindx
```
注記 devindx には、破棄するファイルのインデックスを指定します。
次の方法のいずれかでデバイスを指定できます。
- -z オプションの後にデバイス名を指定します (上記を参照)。
- デバイス名に環境変数 FSCONFIG を指定します。
コマンド行で -yes オプションを指定すると、ファイルを削除するかどうかを確認するプロンプトは表示されません。

デバイス・リストの作成

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

tmadmin -c を実行します。
次のコマンドを入力します。
```
crdl [-z devicename] [-b blocks]
```
- devicename [devindx] には、希望するデバイス名を指定します。新しいデバイスに名前を割り当てる別の方法として、環境変数 FSCONFIG に希望するデバイス名を設定することもできます。
- blocks には、必要なブロックの数を指定します。デフォルト値は 1000 です。
注記 TLOG に関連する管理オーバーヘッド用に 35 ブロックが必要なため、TLOG を作成する場合は、35 より大きい値を割り当てます。

デバイス・リストの破棄

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

tmadmin -c を実行します。
次のコマンドを入力します。
```
dsdl [-z devicename] [yes] [devindx]
```
注記 devindx には、破棄するファイルのインデックスを指定します。
次の方法のいずれかでデバイスを指定できます。
- -z オプションの後にデバイス名を指定します (上記を参照)。
- デバイス名に環境変数 FSCONFIG を指定します。
コマンド行で yes オプションを指定すると、ファイルを破棄するかどうかを確認するプロンプトは表示されません。

障害回復時の注意事項

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

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

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

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

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

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

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

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

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

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

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

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

ユーザ・ログ (ULOG) 内のメッセージを調べ、問題の原因に相当する内容を探します。
この目的に沿った tmadmin のコマンドを実行して、ネットワーク、サーバ、およびサービスに関する情報を収集します。

ULOG のチェック

ネットワークで問題が発生すると、BEA 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 コマンド)

コードリスト9-2 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

ネットワーク接続の回復

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

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

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

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

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

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

MASTER マシンで tmadmin セッションを開始します。
pclean コマンドを実行して、分断されたマシンの名前を指定します。
```
pcl partioned_machine
```
アプリケーション・サーバを移行するか、または障害の修復後にマシンを再起動します。

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

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

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

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

BEA Tuxedo のプロセスに対する IPC 資源がすべて除去されていることを確認します。
ACTING MASTER (SITE2) で tmadmin セッションを開始します。
```
tmadmin
```
次のコマンドを入力して MASTER (SITE1) で BBL を起動します。
```
boot -B SITE1
```
SITE1 で pclean を実行していない場合、BBL は起動できません。
tmadmin セッションで、以下のように入力して、MASTER サイト (SITE1) で再度 DBBL を実行します。
```
MASTER
```
障害が発生したマシンからアプリケーション・サーバとデータを移行した場合は、再起動するか、または移行を元に戻します。

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

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

MASTER マシンで tmadmin セッションを開始します。
pclean を実行し、分断されたマシンをコマンド行で指定します。
マシンの問題を修正します。
MASTER マシンから BBL を起動して、障害の発生したマシンを復元します。
障害が発生したマシンからアプリケーション・サーバとデータを移行した場合は、再起動するか、または移行を元に戻します。

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

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

$ tmadmin
tmadmin - Copyright  1987-1990 AT&T; 1991-1993 USL. All rights reserved

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

ほかの資源のクリーンナップ

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

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

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

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

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

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

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

サーバの起動順序

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

詳細については、『BEA Tuxedo アプリケーションの設定』の 3-85 ページの「CORBA C++ サーバの起動順序」を参照してください。

BEA 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 2000 システムでは、ホスト・システムでコントロールパネルの [ネットワーク] を使用して大文字/小文字を指定します。

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

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

regedt32 (レジストリ・エディタ) を起動します。
[ローカルマシン上の HKEY_LOCAL_MACHINE] ウィンドウを表示します。
以下のキーを選択します。

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥Afd¥Parameters

[編集] メニューの [値の追加] を使って以下の値を追加します。

DynamicBacklogGrowthDelta:REG_DWORD :0xa

EnableDynamicBacklog:REG_DWORD:0x1

MaximumDynamicBacklog:REG_DWORD:0x3e8

MinimumDynamicBacklog:REG_DWORD:0x14
Windows 2000 を再起動し、変更を有効にします。

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

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

トランザクションのアボートとコミット

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

トランザクションのアボート

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

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

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

tranindex の値を決定するために、printtrans コマンド (tmadmin コマンド) を実行します。
groupname が指定されると、メッセージがそのグループの TMS に送信され、そのグループのトランザクションに「アボート済み」のマークが付けられます。グループが指定されないと、メッセージはトランザクション・コーディネータの TMS に送信され、トランザクションのアボートを要求します。アボート処理を制御するには、トランザクション内のすべてのグループにアボート・メッセージを送信する必要があります。

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

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

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

次のコマンドを入力します。
```
committrans (commit) [-yes] [-g groupname] tranindex
```
注記 groupname および tranindex は必須引数です。

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

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

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

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

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

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

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

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

BEA Tuxedo アプリケーションをシャットダウンします。シャットダウン方法については、『BEA Tuxedo アプリケーションの設定』のアプリケーションの起動とシャットダウンを参照してください。
データベースの最新のフル・バックアップを取得し、ファイルを復元します。たとえば、先週の日曜日午前 12 時 1 分現在のデータベースのフル・バックアップ・バージョンを復元します。
月曜日、火曜日、の順に、インクリメンタル・バックアップ・ファイルを適用します。たとえば、この場合は火曜日の午後 11 時までのデータベースを復元するとします。
火曜日の午後 11 時 15 分から水曜日の午後 2 時 50 分までのトランザクションを含むトランザクション・ジャーナル・ファイル (AIJ) を適用します。
データベースを再度オープンします。
BEA Tuxedo アプリケーションを再起動します。

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

アプリケーションが正しくシャットダウンされない場合の IPC ツールの使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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