|
|
システム管理者は、一度アプリケーションが起動して実行されたら、そのアプリケーションが実行中は企業の求めるパフォーマンス、可用性、セキュリティの各条件を満たすように管理する必要があります。このため、資源 (共有メモリなど)、アクティビティ (トランザクション処理など)、および発生する可能性のある問題 (セキュリティ違反など) についてモニタし、必要に応じて適切な処理を実行する必要があります。
管理者のこのような責務を実行するため、Oracle Tuxedo システムには、システム イベントおよびアプリケーション イベントをモニタし、システムを再コンフィグレーションして性能を高めるための方法が用意されています。システムがどのように動作しているかをモニタするには、以下の機能を使用します。
これらのツールを使用すると、変化し続けるビジネス上のニーズや、システムで発生した障害に対して、迅速かつ効率的に対応できます。また、これらのツールを使用して、アプリケーションの性能やセキュリティを管理することもできます。
Oracle Tuxedo システムには、アプリケーションをモニタするための次のようなツールが用意されています。
Oracle Tuxedo システムを使用すると、システム データおよびアプリケーション データのモニタを行うことができます。
実行中のシステムをモニタするため、Oracle Tuxedo システムでは、次のシステム コンポーネントに関するパラメータ設定を管理し、統計情報を生成します。
これらのコンポーネントには、MIB または tmadmin を使用してアクセスできます。また、管理者側で操作は行わず、掲示板の統計情報に基づいてシステム コンポーネントが動的に変更されるようにシステムを設定することもできます。システムが正しくコンフィグレーションされている場合は、次の機能を実行できます (掲示板で次の機能が指定されている場合)。
システムの管理データをモニタすることにより、アプリケーションの性能、可用性、およびセキュリティの低下の原因となる問題を防止したり、解決することができます。
システムをモニタするために必要な情報を格納する場所として、Oracle Tuxedo システムには次の 3 つのデータ リポジトリが用意されています。
実行中の Oracle Tuxedo システムでは、静的データと動的データという 2 種類の管理データをモニタできます。
コンフィグレーションの静的データとは、システムとアプリケーションを最初にコンフィグレーションしたときに割り当てる設定値のことです。これらの設定値は変更されません (ただし、リアルタイムで変更したり、プログラムを使用して変更する場合は例外)。たとえば、システム全体に関するパラメータ (使用するマシン数など) やローカル マシンのシステムに割り当てられた IPC 資源 (共有メモリなど) の容量は静的データです。静的データは、UBBCONFIG ファイルと掲示板に格納されます。
コンフィグレーションに関する静的データの確認が必要な場合があります。たとえば、コンフィグレーション (または掲示板のマシン テーブル) で許可されている最大マシン数の範囲内で、できるだけ多くのマシンを追加したい場合などです。この場合、システム全体に関するパラメータ (MAXMACHINES など) の現在の値を確認して、マシンの最大数を調べることができます。
システムをチューニングして、アプリケーションの性能を向上することもできます。チューニングが必要かどうかを決定するには、現在利用可能なローカル IPC 資源の容量を確認します。
コンフィグレーションの動的データとは、アプリケーションの実行中にリアル タイムで変更される情報のことです。たとえば、負荷 (サーバに送信されたリクエスト数) やコンフィグレーションでのコンポーネント (サーバなど) の状態は、頻繁に変化します。動的データは、掲示板に格納されます。
コンフィグレーションの動的データは、管理上の問題を解決する場合に便利です。次に、具体的な例を 2 つ挙げます。
たとえば、スループットが低下し、現在接続中のクライアント数に対応できる十分なサーバが稼動しているかどうかを調べるとします。この場合、まず、実行中のサーバ数、接続されているクライアント数、および 1 つまたは複数のサーバの負荷を確認します。これらの値を確認すると、サーバの追加により性能を向上できるかどうかを判断できます。
また、アプリケーションに対して特定の要求を行ったときの応答が遅いというクレームを複数受け取ったとします。この場合は、負荷に関する統計情報を確認することにより、BLOCKTIME パラメータの値を増やして応答時間を短縮できるかどうかを判断することができます。
Oracle Tuxedo システムが正常に動作しているかどうかを確認する場合は、起動と停止に関する次の問題を考慮し、定期的にシステムをモニタする必要があります。
実行中のアプリケーションをモニタするには、コンフィグレーションの動的な局面を継続的に追跡し、静的なデータを不定期的に調査する必要があります。つまり、基本的には掲示板の情報に注目し、必要に応じて UBBCONFIG ファイルを参照します。次の要素を考慮した上で、適切な方法を選択してください。
TMTRACE 実行時および TMUTRACE ユーザレベル環境変数を有効にします。詳細については、「実行時およびユーザ レベルのトレース機能を使用する」を参照してください。
|
Oracle Administration Console は、アプリケーションをチューニングしたり、変更するときに使用する MIB 用のグラフィカル ユーザ インタフェースです。World Wide Web 経由でアクセスし、Web ブラウザを使用して表示します。管理者は、サポートされているブラウザを使用して Oracle Tuxedo アプリケーションをモニタできます。
ツールバーには、管理やモニタを行うツールを実行するための 12 のボタンが用意されています。各ボタンには、アイコンと名前が付いています。モニタ用のボタンは次のとおりです。
コマンドライン インタフェースからアプリケーションをモニタするには、tmadmin(1) コマンドまたは txrpt(1) コマンドを使用します。
tmadmin コマンドは、掲示板とその関連エンティティを表示したり、変更するための 53 種類のコマンドのインタプリタです。tmadmin コマンドを使用すると、サービスの状態などのシステムの統計情報、実行済みのリクエスト数、キューに登録されているリクエスト数などをモニタできます。
tmadmin コマンドを使用すると、Oracle Tuxedo システムを動的に変更できます。たとえば、システムの実行中に次のような変更を行うことができます。
tmadmin セッションの開始時には、そのセッションの動作モードを選択できます。動作モードには、動作モード (デフォルト)、読み取り専用モード、コンフィグレーション モードがあります。
tmadmin セッション中に掲示板のデータを表示したり、変更することができます。tmadmin によって拘束されないことです。tmadmin プロセスはクライアントとして掲示板を参照するため、管理者用のスロットはほかの作業に使用できます。 tmadmin セッションの開始は、どのマシン (非アクティブなマシンも含む) からでも行えます。非アクティブなマシンでは通常、tmadmin を実行するためコンフィグレーション モードである必要があります (コンフィグレーション モードを指定せずに tmadmin セッションを開始できる非アクティブなマシンは、MASTER マシンだけです)。| 注意 : | Oracle Tuxedo のバージョンとライセンス数に関するレポートを作成することもできます。 |
txrpt コマンドを実行すると、Oracle Tuxedo サーバの標準エラー出力の分析が行われ、そのサーバでサービス処理にかかる時間のサマリが生成されます。レポートには、指定した期間内に各サービスのディスパッチが何回行われたか、また、各サービスではリクエストの処理にどれだけの時間がかかったかが記録されます。txrpt は、標準入力または入力用にリダイレクトされた標準エラー ファイルからの入力を読み込みます。標準エラー ファイルを作成するには、servopts(5) の選択肢から -r オプションを使用してサーバを起動します。-e servopts オプションを使用すると、ファイル名を指定できます。複数のファイルを、txrpt 用に 1 つの入力ストリームに連結することができます。
サービス X と、そのサービスが格納されたサーバ Y の情報がファイルに蓄積されます。txrpt を使用してこのファイルを処理すると、サービスのアクセス状況とサーバの処理時間に関するレポートが生成されます。
tmadmin コマンドは、掲示板とその関連エンティティを表示したり、変更するための 53 種類のコマンドのインタプリタです。次の図は、典型的な tmadmin セッションの動作の例です。
以下は、tmadmin コマンドを使用してモニタできる、実行時のシステムの機能の一覧です。
Oracle Tuxedo のイベント ブローカは、実行中のアプリケーションで発生するイベントをモニタします。イベントとは、たとえば、クライアントの状態がアクティブから非アクティブに変わる、という MIB オブジェクトの状態の変化のことです。イベント ブローカがイベントを検出すると、そのイベントはレポート (ポスト) され、イベントの発生がサブスクライバに通知されます。MIB オブジェクトを表す FML データ バッファを受け取って、MIB でのイベントの発生通知を自動的に受け取ることもできます。イベントをポストしてサブスクライバにレポートする場合、イベント ブローカは tppost(3c) を使用します。管理者もアプリケーション プロセスもイベントをサブスクライブできます。
イベント ブローカは、MIB オブジェクトの 100 種類以上の状態の変化をシステム イベントとして認識します。ポストされたシステム イベントは、イベントが発生した MIB オブジェクトの表現と、発生したイベントを識別するイベント固有のフィールドで構成されます。たとえば、マシンが分断された場合、ポストされるイベントには次の情報が含まれます。
システム イベントにサブスクライブするだけで、イベント ブローカを使用できます。
エラー状況を迅速かつ正確に識別するため、Oracle Tuxedo システムには次のログ ファイルが用意されています。
TLOG は、Oracle Tuxedo のグローバル トランザクションに参加したマシンでのみ作成されます。ULOGMILISEC 環境変数は、ulog メッセージの出力間隔のタイム スタンプを秒単位ではなくミリ秒単位で記録するために使用します。ULOGRTNSIZE 環境変数は、ローテーション ファイルのサイズを指定するために使用します。ULOGMILISEC および ULOGRTNSIZE の詳細については、『Tuxedo コマンド リファレンス』の「userlog(3c)」を参照してください。
これらのログ ファイルの管理と更新は、アプリケーションの実行中に常に行われます。
トランザクション ログ (TLOG) には、コミット フェーズのグローバル トランザクションが記録されます。2 フェーズ コミット プロトコルのうち、第 1 フェーズの終了時に、グローバル トランザクションの参加リソースは、グローバル トランザクションをコミットするか、またはロールバックするかを決める応答を発行します。この応答は、TLOG に記録されます。
TLOG ファイルを使用するのは、グローバル トランザクションを調整するトランザクション マネージャ サーバ (TMS) だけです。管理者は参照しません。TLOG のロケーションとサイズは、UBBCONFIG ファイルの MACHINES セクションにある 4 つのパラメータで指定します。
グローバル トランザクションに参加する各マシンに TLOG を作成する必要があります。
ユーザ ログ (ULOG) は、Oracle Tuxedo システムによって生成されるすべてのメッセージ、つまりエラー メッセージ、警告メッセージ、情報メッセージ、デバッグ メッセージが書き込まれるファイルです。アプリケーションのクライアントおよびサーバも、ユーザ ログへの書き込みが可能です。ログは毎日新しく作成されます。そのため、マシンごとにログが異なる場合もあります。ただし、リモート ファイル システムが使用されている場合、ULOG を複数のマシンで共有できます。
ULOG によって管理者に提供されるシステム イベントの記録から、Oracle Tuxedo システムおよびアプリケーションのほとんどの障害の原因を特定できます。ULOG はテキスト ファイルなので、任意のテキスト エディタで表示できます。ULOG には、tlisten プロセスによって生成されるメッセージも挿入されています。tlisten プロセスにより、アプリケーション内のほかのマシンにあるリモート サービスに接続できます。マスタ マシンを含め各マシンで tlisten プロセスが実行されていることが必要です。
Oracle Tuxedo のログ ファイルを使用して、アプリケーション エラーおよびシステム エラーを検出できます。
TLOG は、コミット処理中のグローバル トランザクションに関するメッセージのみを含むバイナリ形式のファイルです。TLOG を表示するには、まずテキスト形式に変換する必要があります。Oracle Tuxedo システムでは、tmadmin を使った 2 つの方法で TLOG を変換できます。
dumptlog コマンドおよび loadtlog コマンドは、サーバ グループやマシンを移行するときに、マシン間で TLOG を移動する場合にも便利です。
MIB T_TRANSACTION クラスを使用して、システム内の実行時のトランザクション属性を取得できます。この情報は、tmadmin コマンドの printtrans (pt) を使用して表示することもできます。トランザクション内の各グループに関する情報は、tmadmin を冗長モードで実行した場合にのみ表示されます。冗長モードで実行するには、それ以前に verbose (v) コマンドを実行しておく必要があります。
トランザクションのコミット プロセスの間に発生した重大なエラー (TLOG への書き込みの失敗など) は、USERLOG に書き込まれます。
Oracle Tuxedo システムでは、アプリケーション内のアクティブなマシンにログ ファイルが置かれます。このログ ファイルには、Oracle Tuxedo システムのエラー メッセージ、警告メッセージ、デバッグ メッセージ、またはそれ以外の役立つ情報が含まれています。このファイルをユーザ ログ (ULOG) と呼びます。ULOG を使用すると、Oracle Tuxedo ATMI によって返されるエラーを簡単に見つけることができます。また、ULOG は、Oracle Tuxedo システムとアプリケーションで生成されたエラー情報の主要な格納先となります。
ULOG の情報を使用すると、システムやアプリケーションの障害の原因を特定できます。ユーザ ログには、1 つの問題に対して複数のメッセージを記録できます。一般的には、先に記述されたメッセージの方が有益な診断情報を説明しています。
次の例では、LIBTUX_CAT カタログのメッセージ 358 が、その後のメッセージで報告される問題の原因を説明しています。つまり、UNIX システム セマフォの不足が、アプリケーションを起動できない原因であることを示しています。
151550.gumby!BBL.28041.1.0:LIBTUX_CAT:262: サーバの main() が起動しました
151550.gumby!BBL.28041.1.0:LIBTUX_CAT:358: セマフォ ID の数が UNIX システムの制限値に達しました。
151550.gumby!BBL.28041.1.0:LIBTUX_CAT:248: システム初期化関数が異常終了しました...
151550.gumby!BBL.28040.1.0:CMDTUX_CAT:825: プロセス BBL が SITE1 で異常終了しました ...
151550.gumby!BBL.28040.1.0:WARNING: SITE1 サイトでは BBL が使用可能ではありません。
このサイトではサーバ プロセスはブートできません。
| 注意 : | ユーザ ログ メッセージの詳細と、問題に対する適切な対応策については、システム メッセージを参照してください。 |
ULOG には、tlisten プロセスのエラー メッセージも記録されます。tlisten プロセスのメッセージは、任意のテキスト エディタを使用して表示できます。MASTER マシンを含む各マシン上で、個別に tlisten プロセスが実行されます。それぞれの tlisten プロセスのログは、各マシン上の ULOG に記録されますが、リモート ファイル システムから共有で使用することもできます。
ULOG は、tlisten プロセスのエラーを記録します。tlisten が使用されるのは、tmboot を使用してシステムを起動するとき、およびアプリケーションの実行中に tmadmin を実行するときです。tlisten のメッセージは、tlisten プロセスの実行後、直ちに作成されます。tlisten プロセスでエラーが発生すると、メッセージが ULOG に記録されます。
| 注意 : | アプリケーションの管理者には ULOG の tlisten メッセージを分析する責任がありますが、プログラマも ULOG のメッセージを活用できます。 |
Oracle Tuxedo システム メッセージの「CMDTUX カタログ」には、tlisten のメッセージに関する次の情報が説明されています。
ULOG 内の次の tlisten メッセージを例に取ります。
121449.gumby!simpserv.27190.1.0: LIBTUX_CAT:262: サーバの main() が起動しました
ULOG のメッセージは、タグとテキストで構成されています。タグは、次の情報で構成されています。
uname -n コマンドを実行すると返される名前)。| 注意 : | シングルスレッドおよびシングルコンテキストのアプリケーションの場合、thread_ID フィールドと context_ID フィールドにプレースホルダが出力されます。アプリケーションがマルチスレッドであるかどうかは、複数のスレッドを使用するまでわかりません。 |
| 注意 : | このメッセージについては、Oracle Tuxedo システム メッセージの「LIBTUX カタログ」を参照してください。 |
Oracle Tuxedo アプリケーション サーバでは、処理対象のサービス要求のログを生成することができます。このログは、サーバの標準出力 (stdout) に表示されます。各レコードには、サービス名、開始時刻、および終了時刻が記録されます。
このログは、サーバの起動後に要求できます。txrpt 機能を使用してサーバの実行時間に関するサマリを生成し、ログの出力結果を分析できます。このデータを使用すると、サービスごとの相対的な作業負荷を見積もることができ、MIB 内の該当するサービスに対して作業負荷パラメータを適切に設定できます。
MIB を使用して実行できる操作は 2 つあります。1 つ目は、get 操作を使用した MIB からの情報の取得です。2 つ目は、set 操作を使用した MIB の情報の更新です。これらの操作は、ATMI 関数 (tpalloc(3c)、tprealloc(3c)、tpcall(3c)、tpacall(3c)、tpgetrply(3c)、tpenqueue(3c)、および tpdequeue(3c) など) を使用していつでも実行できます。
get 操作を使って MIB をクエリすると、MIB は一致したオブジェクトをいくつか返し、そのほかの候補数を示します。MIB は、残りのオブジェクトを取得するためのハンドル (カーソル) を返します。次のオブジェクトのセットを取得する操作は、getnext です。クエリしたオブジェクトが複数のバッファに渡ると、3 つ目の操作が発生します。
仮想データベースである MIB をクエリするとは、データベース テーブルからレコードのセットを選択することです。データベース テーブルのサイズを制限する方法は 2 つあります。つまり、クエリに対して返すオブジェクト数を制限するか、または各オブジェクトの情報量を制限します。キー フィールドとフィルタを使用して、リクエストのスコープを必要なデータだけに制限することもできます。制限を多く指定すればするほど、アプリケーションから要求される情報は少なくなり、応答は早くなります。
MIB のデータは、いくつかの場所に分けて保存されています。分散アプリケーションでは、複数のマシンに複製されているデータもあります。また、複製はされず、データの属性やデータが表すオブジェクトにより、特定のマシンのローカル データになるデータもあります。
グローバル データとは、サーバなどのアプリケーション コンポーネントに関する情報で、アプリケーション内のすべてのマシン上に複製されます。サーバに関するほとんどのデータ (コンフィグレーションや状態に関する情報など) は、アプリケーションにグローバルに複製され、特にすべての掲示板に複製されます。Oracle Tuxedo アプリケーションでは、どこからでもこの情報にアクセスできます。
たとえば、管理者は、Customer Orders という名前のアプリケーション内の任意のマシンから、サーバ B6 が Group1 に属しており、CustOrdA というマシン上で起動しており、アクティブであることを確認できます。
ローカル データとは、グローバルには複製されない、エンティティに対してローカルなデータ (サーバの統計など) のことです。ローカルな属性の例は TA_TOTREQC です。この属性は、特定のサーバ上でサービスが処理される回数を定義します。この統計は、ホスト マシン上のサーバに保存されます。サーバがサービス要求を受信し、そのサービスが処理されると、カウンタの値が増えます。この種の情報はローカルで管理されるため、複製するとシステムの性能が低下します。
MIB には、ローカル (クライアントなど) にしかないクラスもあります。クライアントがログインすると、掲示板にクライアント用のエントリが作成され、ここにクライアントに関する追跡情報が記録されます。MIB は、このエントリを調べることにより、いつでもクライアントの状態を判別できます。
Oracle Tuxedo システムには、アプリケーションが稼動していない場合に MIB に直接アクセスするためのプログラミング インタフェースが用意されています。これが tpadmcall 関数であり、MIB を構成するデータにアプリケーションから直接アクセスするときに使用します。tpadmcall を使用すると、ローカル情報のサブセットにアクセスできます。
tpadmcall は、システムが稼動していないときに、システムをクエリしたり、管理上の変更を行う場合に使用してください。tpadmcall は、リクエストを送信する代わりに TUXCONFIG ファイルをクエリします。送信用と受信用のデータ バッファ (クエリと応答の内容を格納) は、まったく同じです。
ud32 は、Oracle Tuxedo システムに付属のクライアント プログラムであり、FML バッファ型のテキスト表現で構成される入力情報を読み込みます。ud32 は、MIB に対して特殊なクエリを行ったり、MIB を更新するときに使用できます。ud32 を実行すると、FML32 バッファが作成され、バッファを指定したサービス呼び出しが行われます。サービス呼び出しに対する応答 (FML32 バッファ型) を受信すると、結果は画面上またはテキスト ファイルに出力されます。
ud32 は、テキスト形式の FML フィールドと値を使用して FML32 型のバッファを作成し、バッファ内で指定されたサービスを呼び出して、応答を待ちます。応答は、レポートとして FML32 形式で返されます。MIB は FML32 をベースにしているため、ud32 は MIB のスクリプト作成用ツールになります。
たとえば、次のテキストを含む小さいファイルを作成するとします。
service name=.tmib and ta_operation=get, TACLASSES=T_SERVER
ud32 にこのファイルを入力すると、サーバに関するすべてのシステム データが一覧表示された FML 出力バッファが返されます。
Oracle Tuxedo システムには、分散型ビジネス アプリケーションの実行を追跡する実行時およびユーザレベルのトレース機能があります。システムには、さまざまなカテゴリの関数の呼び出しを記録するためのトレース ポイントが組み込まれています。たとえば、アプリケーションによって発行された ATMI 関数、X/Open 準拠のリソース マネージャに対する Oracle Tuxedo システムからの XA 関数などです。
トレース機能を有効にするには、カテゴリ、フィルタ式、およびアクションを含むトレース式を指定する必要があります。カテゴリには、トレース対象の関数の種類 (ATMI など) を指定します。フィルタ式には、アクションをトリガした特定の関数を指定します。アクションには、Oracle Tuxedo システムによって指定された関数に対する応答を指定します。
たとえば、ULOG へのレコードの書き込み、システム コマンドの実行、トレース処理の終了、などのアクションを指定できます。クライアント プロセスでは、リクエストを使用してトレース機能を伝播することもできます。 この機能は「ダイイング」と呼ばれます。つまり、トレース処理により、クライアントから呼び出されたすべてのサービスを「色付けする」ことを意味します。
TMTRACE 実行時環境変数の設定
トレース式を簡単に指定するには、クライアント環境で TMTRACE=on と定義します。この式により、クライアントまたはクライアントの代わりにサービスを実行する任意のサーバで、ATMI 関数をトレースできます。トレース レコードは ULOG ファイルに書き込まれます。
また、ulog または utrace tmtrace(5) の受信側を使用して、サーバ環境でトレース式を指定することもできます。たとえば、次のように入力したとします。
TMTRACE=atmi:/tpservice/ulog。この設定をサーバ環境内でエクスポートすると、そのサーバ上でサービス要求が実行されるたびに、一般的な実行時トレースの情報に関するレコードが ULOG ファイルに記録されます。 TMTRACE=atmi:utrace。utrace の受信側を指定すると、ユーザ定義の tputrace(3c) が自動的に呼び出されます。この設定をサーバ環境内でエクスポートすると、そのサーバで実行されている ATMI 関数のトレース情報とユーザ定義の出力場所に関するレコードが作成されます。
tmadmin の changetrace コマンドを使用すると、トレース オプションをアクティブにしたり非アクティブにできます。このコマンドを使用すると、アクティブなクライアント プロセスまたはサーバ プロセスのトレース式を上書きできます。管理者は、すべてのクライアントとサーバに対してグローバルなトレース機能を許可することも、特定のマシン、グループ、またはサーバだけがトレース機能を実行できるように設定することもできます。
Oracle Tuxedo システムでは、次の 2 つの管理サーバを使用して、掲示板にある情報をアプリケーション内のすべのマシンに分散します。
どちらのサーバにも障害を管理する役割があります。DBBL はアプリケーション内のほかのアクティブ マシンの状態を調整します。各 BBL は、MIB の状態の変更についての通信を行い、不定期的に DBBL にホスト マシン上のすべてが順調であることを示すメッセージを送信します。
Oracle Tuxedo のランタイム システムは、ユーザ ログ (ULOG) にイベント (システム エラー、警告、トレース イベントも含む) を記録します。プログラマは、ULOG を使用して、アプリケーションをデバッグしたり、認可の失敗などの特別な状況や検出した状態を管理者に通知します。
ATMI を使用すると、プログラマは通信に関するよりグローバルな問題を管理できます。ATMI には、アプリケーションとシステムの両方に関連するエラーを処理する機能があります。サービス ルーチンで、アプリケーション エラー (無効なアカウント番号が使用された場合など) が発生すると、アプリケーション エラーが返され、サービスは実行されたがリクエストは完了しなかったことがクライアントに通知されます。
システム障害 (リクエストの実行中にサーバがクラッシュするなど) が発生すると、システム エラーが返され、サービス ルーチンによりタスクが実行されなかったことがクライアントに通知されます。Oracle Tuxedo システムは、アプリケーションの動作およびシステム自体の動作をモニタし、プログラムに対してシステム エラーを発行します。
リクエストの処理中に、サービスが無限ループに陥る場合があります。この場合、クライアントサイドで待機しても応答は戻りません。クライアントが無限に待機しないようにするため、Oracle Tuxedo システムには、ブロッキング タイムアウトとトランザクション タイムアウトという 2 つの設定可能なタイムアウトのメカニズムがあります。これらのタイムアウト メカニズムの詳細については、『Oracle Tuxedo Domains コンポーネント』の「Domains のトランザクション タイムアウトとブロッキング タイムアウトの指定」を参照してください。
ブロッキング タイムアウトは、ブロックされたプログラムが、何らかのイベント発生後に指定の時間を超えて待機しないようにするメカニズムです。いったんタイムアウトが検出されると、待機中のプログラムは、ブロッキング タイムアウトが発生したことを通知するシステム エラーを受信します。ブロッキング タイムアウトは、サービス要求の有効期間、つまりアプリケーションがサービス要求に対する応答を待機する時間を定義します。タイムアウト値は、TUXCONFIG ファイルの RESOURCES セクションの BLOCKTIME フィールドで定義されるグローバルな値です。
トランザクション タイムアウトは、アクティブなトランザクションでリソースが集中することが原因で発生するタイムアウトです。トランザクション タイムアウトは、トランザクション (その中で複数のサービス要求が行われる場合もあり) の有効期間を定義します。このタイムアウト値は、tpbegin(3c) を呼び出して、トランザクションを開始するときに定義されます。トランザクション タイムアウトは、リソースを最大化する場合に便利です。たとえば、トランザクション処理中にデータベースがロックされた場合に、アプリケーションのトランザクション用のリソースが停止状態になる時間を制限することができます。トランザクション タイムアウトは、常にブロッキング タイムアウトをオーバーライドします。
UBBCONFIG ファイルのトランザクション ライムアウト パラメータには次の 2 つがあります。
UBBCONFIG の SERVICES セクションで指定する TRANTIME。特定の AUTOTRAN サービスのタイムアウト値を制御します。UBBCONFIG の RESOURCES セクションで指定する MAXTRANTIME。管理者が、tpbegin(3c) または AUTOTRAN サービスの呼び出しによって開始したトランザクションのタイムアウト値の上限値を設定するために使用します。
これらのトランザクション タイムアウト パラメータの詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「UBBCONFIG(5)」を参照してください。
冗長サーバと自動再起動機能をアプリケーションに設定して、障害に対処することもできます。冗長サーバを設定すると、可用性が高まり、大量の処理、サーバ障害、またはマシン障害を処理できるようになります。Oracle Tuxedo システムは、アクティブなサーバの状態を定期的に調べ、再起動可能なサーバの障害を検出すると、自動的にサーバの新しいインスタンスを生成します。
サーバに自動再起動のプロパティを設定すると、個々のサーバの障害を処理できます。また、システムによる再起動の回数を指定することもできます。この機能により、サーバの再起動回数の制限が原因で度々発生するアプリケーション エラーを回避できます。
Oracle Tuxedo システムは、アクティブなマシンの可用性を頻繁に調べます。マシンにアクセスできない場合は、そのマシンを「分断されたマシン (partitioned)」とマークします。この場合は、システム イベントが生成されます。マシンの分断は、ネットワーク障害、マシン障害、またはサーバの性能低下が原因で発生する場合もあります。
したがって、プログラマは、プロセス内の個々のスレッドが異常終了した可能性があることを認識する必要があります。1 つのスレッドが異常終了してシグナルが出されると、通常、そのスレッドが属する全体のプロセスが異常終了しているため、BBL により異常終了が検出されます。
ただし、スレッドの exit 関数を誤って呼び出したためにスレッドが異常終了した場合、シグナルは生成されません。スレッドが tpterm() を呼び出す前にこの種の異常終了が発生すると、BBL では異常終了を検出できず、異常終了したスレッドに関連するコンテキストの登録テーブル スロットの割り当ては解除されません (スレッドの異常終了を検出できても、BBL は通常この登録テーブルのスロットの割り当て解除は行いません。スレッドが異常終了すると別のスレッドがコンテキストに関連付けられる、というアプリケーション モデルがあるためです)。
| 注意 : | ここで説明する機能は、使用する管理ツールに関係なく、マルチスレッド化またはマルチコンテキスト化されたすべてのアプリケーションに適用されます。ここでは、MIB の呼び出しを使用する管理者の観点で機能を説明しています。MIB 用のインタフェース (tmadmin(1) または Oracle Administration Console) を使用する管理者も適用できます。 |
マルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータは、次の方法で取得できます。
TPMULTICONTEXTS モードで tpinit() が呼び出され、新しいコンテキストが作成されるたびに、Oracle Tuxedo システムによって自動的に作成されます。TM_MIB の T_SERVERCTXT クラス。複数のサーバ ディスパッチ スレッドが同時に実行されている場合、このクラスの 14 のフィールドには、複数のインスタンスが提供されます。つまり、T_SERVERCTXT セクションには、実行中のサーバ ディスパッチ スレッドごとに次のフィールドが用意されています。TA_CONTEXTID (キー フィールド)TA_SRVGRP (キー フィールド)TA_SRVID (キー フィールド)TA_CLTLMIDTA_CLTPIDTA_CLTREPLYTA_CMTRETTA_CURCONVTA_CURREQTA_CURRSERVICETA_LASTGRPTA_SVCTIMEOUTTA_TIMELEFTTA_TRANLEV
たとえば、12 のサーバ ディスパッチ スレッドが同時に実行されている場合、このアプリケーション用の MIB の T_SERVERCTXT クラスには、12 のオカレンスを含む TA_CONTEXTID フィールド、12 のオカレンスを含む TA_SRVGRP フィールド、などが設定されます。
T_SERVER クラス内のフィールドに複数のインスタンスがあり、これらのインスタンスの値がマルチコンテキスト化されたサーバのコンテキストごとに異なる場合、T_SERVER クラスのフィールドにはダミーの値が指定され、T_SERVERCTXT フィールドには、各コンテキストの実際の値が指定されます。
  
|