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

このトピックには次の項が含まれます:

•

障害の種類の判別

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

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

•	リカバリ時の注意事項

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

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

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

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

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

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

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

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

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

障害の種類の判別

トラブルシューティングの最初のステップとして、障害が発生した場所を特定します。ほとんどのアプリケーションでは、次の6つの発生原因が考えられます。

•

アプリケーション

•	Oracle Tuxedoシステム

•	データベース管理ソフトウェア

•

ネットワーク

•	オペレーティング・システム

•

ハードウェア

障害の領域を特定できたら、適切な管理者と協力して障害を解決してください。たとえば、ネットワークの問題が原因で障害が発生した場合は、ネットワーク管理者と協力してください。

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

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

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)などのコマンドを実行してシステム・アクティビティ・レポートを調べ、システムが正しく機能しない原因を調べます。以下の原因が考えられます。

•	システムのメモリーが不足しています。

•	カーネルが正しくチューニングされていません。

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

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

1.	ユーザー・ログ(ULOG)内で、Oracle Tuxedoシステムの警告メッセージとエラー・メッセージを調べます。

•	TPEOSメッセージは、オペレーティング・システムにエラーが発生したことを示します。

•	TPESYSTEMメッセージは、Oracle Tuxedoシステムにエラーが発生したことを示します。

2.	現在の問題を最も反映していると思われるメッセージを選択します。メッセージをシステム・メッセージで調べられるように、カタログ名と各メッセージの番号を書き留めます。マニュアルの各項目には次の情報が含まれています。

•	メッセージが示すエラーの詳細内容

•	エラーを解決するための推奨措置

3.	次の手順でデバッグの準備をします。

•	suspendサービスを停止します。

•	tmboot -n -s(server) -d1を使用します。(このコマンドを実行してもサーバーは起動しませんが、サーバーを起動するためのコマンド行が出力されます。)dbxなどのデバッガを指定して、このコマンド行を使用してください。

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

イベント・ブローカでは、システム全体のイベント・サマリーおよびイベントにより通知をトリガーするメカニズムを提供することでトラブルシューティングの機能が拡張されます。イベント・ブローカは、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の紹介』のイベント・ブローカを使用したイベントの管理に関する項

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

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

•	汎用デバイス・リストの出力

•

VTOC情報の出力

•

デバイスの再初期化

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

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

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

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

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

1.	tmadmin -cを実行します。

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

lidl

3.	UDLを取得するデバイスを指定する方法は、次の2つです。

•	lidlコマンド行でデバイスを指定します。

-z device_name [devindx]

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

VTOC情報の出力

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

1.	tmadmin -cを実行します。

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

livtoc

3.	VTOCを取得するデバイスを指定する方法は、次の2つです。

•	lidlコマンド行で次のように指定します。

-z device name [devindx]

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

デバイスの再初期化

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

1.	tmadmin -cを実行します。

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

initdl [-z devicename] [-yes] devindx

注意:	devindxには、破棄するファイルのインデックスを指定します。

3.	次の方法のいずれかでデバイスを指定できます。

•	ここで示すように-zオプションの後にデバイス名を指定します

•	デバイス名に環境変数FSCONFIGを指定します

4.	コマンド行で-yesオプションを指定すると、ファイルを実際に破棄する前に、ファイルを破棄するかどうかを確認するプロンプトが表示されません。

デバイス・リストの作成

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

1.	tmadmin -cを実行します。

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

crdl [-z devicename] [-b blocks]

•	devicename [devindx]には、希望するデバイス名を指定します。(新しいデバイスに名前を割り当てる別の方法として、環境変数FSCONFIGに希望するデバイス名を設定することもできます。)

•	blocksには、必要なブロックの数を指定します。デフォルトは1000です。

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

デバイス・リストの破棄

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

1.	tmadmin -cを実行します。

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

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

注意:	devindxには、破棄するファイルのインデックスを指定します。

3.	次の方法のいずれかでデバイスを指定できます。

•	ここで示すように-zオプションの後にデバイス名を指定します

•	デバイス名に環境変数FSCONFIGを指定します

4.	コマンド行でyesオプションを指定すると、ファイルを破棄するかどうかを確認するプロンプトは表示されません。

リカバリ時の注意事項

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つの領域で障害が発生した場合でも操作を継続できます。

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

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

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

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

•	MASTERマシンまたは非マスター・マシンで発生するマシンの障害

•

BRIDGEの障害

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

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

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

•	ユーザー・ログ(ULOG)内のメッセージを調べ、問題の原因に相当する内容を探します。

•	この目的に沿ったtmadminのコマンドを実行して、ネットワーク、サーバー、およびサービスに関する情報を収集します。

ULOGのチェック

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

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

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

151804.gumby!DBBL.28446: ... : エラー: BBLがパーティション化されています。machine=SITE2

 

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

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

•	pnw (printnetworkコマンド)

•	psr (printserverコマンド)

•	psc (printserviceコマンド)

リスト9-2 tmadminセッションの例

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

1.	MASTERマシンでtmadmin(1)セッションを開始します。

2.	reconnectコマンド(rco)を実行し、分断されていないマシンと分断されたマシンの名前を指定します。

rco non-partioned_node1 partioned_node2

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

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

1.	MASTERマシンでtmadminセッションを開始します。

2.	pcleanコマンドを実行して、分断されたマシンの名前を指定します。

pcl partioned_machine

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

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

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

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

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

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

1.	MASTERマシンでtmadminセッションを開始します。

2.	pcleanを実行し、分断されたマシンをコマンド行で指定します。

3.	マシンの問題を修正します。

4.	MASTERマシンからBBLを起動して、障害の発生したマシンを復元します。

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

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

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

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

> pclean SITE2
Cleaning the DBBL.

システムが安定するまで10秒間お待ちください。
掲示板から3個のSITE2サーバーを削除しました

> boot -B SITE2
管理プロセスを起動しています

Exec BBL -A :

on SITE2 -> プロセスID=22923を起動しました。
1個のプロセスを起動しました。
> q

 

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

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

1.	置換したいOracle Tuxedoシステム・ソフトウェアをインストールします。

2.	変更によって影響を受ける次のアプリケーションの部分を停止します。

•	ライブラリが更新された場合は、Oracle Tuxedoシステム・サーバーを停止します。

•	関連するOracle Tuxedoシステムのヘッダー・ファイルまたは静的ライブラリが置換された場合は、アプリケーションのクライアントとサーバーを停止して再度ビルドする必要があります。(Oracle Tuxedoシステムのメッセージ・カタログ、システム・コマンド、管理サーバーまたは共有オブジェクトが置換された場合、アプリケーションのクライアントとサーバーを再度ビルドする必要はありません。)

3.	関連するOracle Tuxedoシステムのヘッダー・ファイルおよび静的ライブラリが置換される場合は、アプリケーションのクライアントとサーバーを再度ビルドします。

4.	停止したアプリケーション部分を再起動します。

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

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

1.	アプリケーション・ソフトウェアをインストールします。アプリケーション・ソフトウェアの構成要素には、アプリケーション・クライアント、アプリケーション・サーバーおよび管理ファイル(FMLフィールド表など)があります。

2.	置換するアプリケーション・サーバーを停止します。

3.	必要に応じて、新しいアプリケーション・サーバーをビルドします。

4.	新しいアプリケーション・サーバーを起動します。

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

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

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

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

1.	tmadminセッションを開始します。

2.	bbclean machineを入力します。

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

 

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

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

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

1.	tmadminセッションを開始します。

2.	pclean machineを入力します。

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

 

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

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

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++サーバーの起動順序に関する項を参照してください。

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

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

エラー: クライアントからの非公式の接続(アドレス<tcp/ip address>/<port-number>)です

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

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

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

Oracle Tuxedo CORBAアプリケーションを実行するWindowsサーバーで、一部のインターネットORB間プロトコル(IIOP)クライアントを起動した後、//host:portが正しく指定されているにもかかわらず、一部のクライアントでBootstrapオブジェクトを作成できず、InvalidDomainメッセージが返される場合は、次の手順を実行できます。(関連情報については、9-14ページの「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リスナーでは受け付けられません。Microsoftでは、最小値20、間隔10という値を推奨しています。最大値はマシンによって異なります。ただし、Microsoft社では、Windowsサーバーでは最大値が5000を超えないようにすることを推奨しています。

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

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

トランザクションの中断

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

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

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

2.	tranindexの値を確認するために、printtransコマンド(tmadminコマンド)を実行します。

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

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

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

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

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

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

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

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

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

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

•	トランザクション・コーディネータのTMSが、ある期間トランザクションを回復できなくなります。

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

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

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

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

1.	Oracle Tuxedoアプリケーションを停止します。(手順は、『Oracle Tuxedoアプリケーションの設定』の1-1ページのアプリケーションの起動と停止に関する項を参照してください。)

2.	データベースの最新のフル・バックアップを取得し、ファイルを復元します。たとえば、先週の日曜日12:01 A.M.現在のデータベースのフル・バックアップ・バージョンを復元します。

3.	月曜日、火曜日、の順に、増分バックアップ・ファイルを適用します。たとえば、この場合は火曜日の11:00 P.M.までのデータベースを復元するとします。

4.	火曜日の11:15 P.M.から水曜日の2:50 P.M. までのトランザクションを含むトランザクション・ジャーナル・ファイル(AIJ)を適用します。

5.	データベースを再度オープンします。

6.	Oracle Tuxedoアプリケーションを再起動します。

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

アプリケーションが正しく停止しない場合の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ファイルを指定しないと利用できません。

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

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

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

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

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

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

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