システム管理者は、一度アプリケーションが起動して実行されたら、そのアプリケーションが実行中は企業の求めるパフォーマンス、可用性、セキュリティの各条件を満たすように管理する必要があります。このため、資源(共有メモリーなど)、アクティビティ(トランザクション処理など)、および発生する可能性のある問題(セキュリティ違反など)についてモニターし、必要に応じて適切な処理を実行する必要があります。
管理者のこのような責務を実行するため、Oracle Tuxedoシステムには、システム・イベントおよびアプリケーション・イベントをモニタリングし、システムを再構成してパフォーマンスを向上させるための方法が用意されています。システムがどのように動作しているかをモニターするには、以下の機能を使用します。
これらのツールを使用すると、変化し続けるビジネス上のニーズや、システムで発生した障害に対して、迅速かつ効率的に対応できます。また、これらのツールを使用して、アプリケーションのパフォーマンスやセキュリティを管理することもできます。
図2-1に、モニタリング・ツールを示します。
Oracle Tuxedoシステムには、アプリケーションをモニターするための次のようなツールが用意されています。
Oracle Tuxedoシステムを使用すると、システム・データおよびアプリケーション・データのモニターを行うことができます。
実行中のシステムをモニターするため、Oracle Tuxedoシステムでは、次のシステム・コンポーネントに関するパラメータ設定を管理し、統計情報を生成します。
これらのコンポーネントには、MIBまたはtmadmin
を使用してアクセスできます。また、管理者側で操作は行わず、掲示板の統計情報に基づいてシステム・コンポーネントが動的に変更されるようにシステムを設定することもできます。システムが正しく構成されている場合は、次の機能を実行できます(掲示板で次の機能が指定されている場合)。
システムの管理データをモニタリングすることにより、アプリケーションのパフォーマンス、可用性、およびセキュリティの低下の原因となる問題を防止したり、解決することができます。
システムのモニターに必要な情報を入手できるように、Oracle Tuxedoシステムには次の3つのデータ・リポジトリが用意されています。
実行中のOracle Tuxedoシステムでは、静的データと動的データという2種類の管理データをモニターできます。
構成の静的データとは、システムとアプリケーションを最初に構成したときに割り当てる設定値のことです。これらの設定値は変更されません(ただし、リアルタイムで変更したり、プログラムを使用して変更する場合は例外)。たとえば、システム全体に関するパラメータ(使用するマシン数など)やローカル・マシンのシステムに割り当てられたIPC資源(共有メモリーなど)の容量は静的データです。静的データは、UBBCONFIG
ファイルと掲示板に格納されます。
構成に関する静的データの確認が必要な場合があります。たとえば、構成(または掲示板のマシン表)で許可されている最大マシン数の範囲内で、できるだけ多くのマシンを追加したい場合などです。この場合、システム全体に関するパラメータ(MAXMACHINES
など)の現在の値を確認して、マシンの最大数を調べることができます。
システムをチューニングして、アプリケーションのパフォーマンスを向上させることもできます。チューニングが必要かどうかを決定するには、現在利用可能なローカルIPC資源の容量を確認します。
構成の動的データとは、アプリケーションの実行中にリアル・タイムで変更される情報のことです。たとえば、負荷(サーバーに送信されたリクエスト数)や構成でのコンポーネント(サーバーなど)の状態は、頻繁に変化します。動的データは、掲示板に格納されます。
構成の動的データは、管理上の問題を解決する場合に便利です。次に、具体的な例を2つ挙げます。
たとえば、スループットが低下し、現在接続中のクライアント数に対応できる十分なサーバーが稼働しているかどうかを調べるとします。この場合、まず、実行中のサーバー数、接続されているクライアント数、および1つまたは複数のサーバーの負荷を確認します。これらの値を確認すると、サーバーの追加によりパフォーマンスを向上できるかどうかを判断できます。
また、アプリケーションに対して特定のリクエストを行ったときのレスポンスが遅いというクレームを複数受け取ったとします。この場合は、負荷に関する統計情報を確認することにより、BLOCKTIME
パラメータの値を増やしてレスポンス時間を短縮できるかどうかを判断することができます。
Oracle Tuxedoシステムが正常に動作しているかどうかを確認する場合は、起動と停止に関する次の問題を考慮し、定期的にシステムをモニターする必要があります。
IPCKEY
がすでに使用されています。UBBCONFIG
ファイルで指定されている上限値に到達した。TLOG
ファイルが作成されません。
実行中のアプリケーションをモニターするには、構成の動的な局面を継続的に追跡し、静的なデータを不定期的に調査する必要があります。つまり、基本的には掲示板の情報に注目し、必要に応じてUBBCONFIG
ファイルを参照します。次の要素を考慮した上で、適切な方法を選択してください。
表2-1では、各モニタリング・ツールの使用方法を説明します。
トレース式(カテゴリ、フィルタリング式、アクション)を指定し、
TMTRACE 実行時およびTMUTRACE ユーザー・レベル環境変数を有効にします。詳細は、「実行時およびユーザー・レベルのトレース機能を使用する」を参照してください。
|
Oracle管理コンソールは、アプリケーションのチューニングや変更に使用する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種類のコマンドのインタプリタです。図2-2は、典型的なtmadmin
セッションの動作の例です。
tmadmin
コマンドでモニターできるランタイム・システム機能のリストを次に示します。
Oracle Tuxedoのイベント・ブローカは、実行中のアプリケーションで発生するイベントをモニターします。イベントとは、たとえば、クライアントの状態がアクティブから非アクティブに変わる、というMIBオブジェクトの状態の変化のことです。イベント・ブローカがイベントを検出すると、そのイベントはレポート(ポスト)され、イベントの発生がサブスクライバに通知されます。MIBオブジェクトを表すFML
データ・バッファを受け取って、MIBでのイベントの発生通知を自動的に受け取ることもできます。イベントをポストしてサブスクライバにレポートする場合、イベント・ブローカはtppost(3c)を使用します。管理者もアプリケーション・プロセスもイベントをサブスクライブできます。
イベント・ブローカは、MIBオブジェクトの100種類以上の状態の変化をシステム・イベントとして認識します。システム・イベントをポストすると、イベントが発生した現在のMIBとしてのオブジェクト、および発生したイベントを識別するイベント固有のフィールドの情報が提供されます。たとえば、マシンがパーティション化されている場合、ポストされるイベントには次が含まれます:
システム・イベントにサブスクライブするだけで、イベント・ブローカを使用できます。
エラー状況を迅速かつ正確に識別するため、Oracle Tuxedoシステムには次のログ・ファイルが用意されています。
TLOG
は、Oracle Tuxedoのグローバル・トランザクションに参加したマシンでのみ作成されます。ULOGMILLISEC
環境変数は、ulogメッセージ出力間隔のタイム・スタンプを秒単位ではなくミリ秒単位で記録するために使用されます。ULOGRTNSIZE
環境変数は、ローテーション・ファイルのサイズを指定するために使用します。ULOGMILLISEC
およびULOGRTNSIZE
の詳細については、『Oracle 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つあります。
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つの問題に対して複数のメッセージを記録できます。一般的には、先に記述されたメッセージの方が有益な診断情報を説明しています。
リスト2-1の例では、LIBTUX_CAT
カタログのメッセージ358が、その後のメッセージで報告される問題の原因を説明しています(つまり、UNIXシステム・セマフォの不足が、アプリケーションを起動できない原因であることを示しています)。
151550.gumby!BBL.28041.1.0:
LIBTUX_CAT:262: std main starting
151550.gumby!BBL.28041.1.0:
LIBTUX_CAT:358: reached UNIX limit on semaphore ids
151550.gumby!BBL.28041.1.0:
LIBTUX_CAT:248: fatal: system init function ...
151550.gumby!BBL.28040.1.0:
CMDTUX_CAT:825: Process BBL at SITE1 failed ...
151550.gumby!BBL.28040.1.0:
WARNING: No BBL available on site SITE1.
Will not attempt to boot server processes on that site.
注: | ユーザー・ログ・メッセージの詳細と、問題に対する適切な対応策については、システム・メッセージを参照してください。 |
ULOG
には、tlisten
プロセスのエラー・メッセージも記録されます。tlisten
プロセスのメッセージは、任意のテキスト・エディタを使用して表示できます。MASTER
マシンを含む各マシン上で、個別にtlisten
プロセスが実行されます。それぞれのtlisten
プロセスのログは、各マシン上のULOG
に記録されますが、リモート・ファイル・システムから共有で使用することもできます。
ULOG
は、tlisten
プロセスの失敗を記録します。tlisten
は、起動プロセス中はtmboot
によって、アプリケーションの実行中はtmadmin
によって使用されます。tlisten
メッセージは、tlisten
プロセスが起動されるとすぐに作成されます。tlisten
プロセスが失敗するときに、メッセージがULOG
に記録されます。
注: | アプリケーションの管理者にはULOG のtlisten メッセージを分析する責任がありますが、プログラマもULOGのメッセージを活用できます。 |
Oracle Tuxedoシステム・メッセージの「CMDTUXカタログ」には、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)など)を使用していつでも実行できます。
MIBをget
操作で問い合わせると、MIBは一致数を返信し、リクエストに一致する残りのオブジェクト数を示します。MIBは、残りのオブジェクトの取得に使用できるハンドル(つまり、カーソル)を返します。次のオブジェクト・セットの取得に使用する操作はgetnext
です。3番目の操作は問合せが複数のバッファにまたがる場合に実行されます。
仮想データベースであるMIBを問合せするとは、データベース表からレコードのセットを選択することです。データベース表のサイズを制限する方法は2つあります。つまり、問合せに対して返すオブジェクト数を制限するか、または各オブジェクトの情報量を制限します。キー・フィールドとフィルタを使用して、リクエストのスコープを必要なデータだけに制限することもできます。制限を多く指定すればするほど、アプリケーションから要求される情報は少なくなり、応答は早くなります。
MIBのデータは、いくつかの場所に分けて保存されています。分散アプリケーションでは、複数のマシンにレプリケートされているデータもあります。また、レプリケートはされず、データの属性やデータが表すオブジェクトにより、特定のマシンのローカル・データになるデータもあります。
グローバル・データとは、サーバーなどのアプリケーション・コンポーネントに関する情報で、アプリケーション内のすべてのマシン上にレプリケートされます。サーバーに関するほとんどのデータ(構成や状態に関する情報など)は、アプリケーションにグローバルにレプリケートされ、特にすべての掲示板にレプリケートされます。Oracle Tuxedoアプリケーションでは、どこからでもこの情報にアクセスできます。
たとえば、Customer Ordersというアプリケーション内のマシンから、管理者は、グループ1に属し、マシンCustOrdAで実行されているアクティブになっているサーバーB6を調べることができます。
ローカル・データとは、グローバルにはレプリケートされない、エンティティに対してローカルなデータ(サーバーの統計など)のことです。ローカルな属性の例として、指定されたサーバー上でサービスが処理される回数を定義するTA_TOTREQC
があります。この統計は、ホスト・マシン上のサーバーに保存されます。サーバーがサービス・リクエストを受信して処理すると、カウンタの値が1つ増えます。この種の情報はローカルで管理されるため、レプリケートするとシステムのパフォーマンスが低下します。
MIBには、クライアントなど、ローカルのみのクラスもあります。クライアントがログインすると、Oracle Tuxedoシステムは掲示板にそのエントリを作成し、クライアントに関するすべての追跡情報をそのエントリに記録します。MIBは、このエントリをチェックすることでクライアントの状態をいつでも判断できます。
Oracle Tuxedoシステムには、アプリケーションが稼動していない場合にMIBに直接アクセスするためのプログラミング・インタフェースが用意されています。このインタフェースつまりtpadmcall
関数は、MIBを構成するデータにアプリケーションから直接アクセスするときに使用します。tpadmcall
を使用すると、ローカル情報のサブセットにアクセスできます。
tpadmcall
は、システムが稼動していないときに、システムを問合せしたり、管理上の変更を行う場合に使用してください。tpadmcall
は、リクエストを送信する代わりにTUXCONFIG
ファイルを問合せします。送信用と受信用のデータ・バッファ(問合せと応答の内容を格納)は、まったく同じです。
ud32
は、Oracle Tuxedoシステムで配布されるクライアント・プログラムであり、FML
バッファのテキスト表現から構成される入力を読み取ります。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つの管理サーバーを使用して、掲示板にある情報をアプリケーション内のすべのマシンに分散します。
図2-3に、DBBLおよびBBLを使用した診断と修復を示します。
どちらのサーバーにもフォルトを管理する役割があります。DBBLはアプリケーション内のほかのアクティブ・マシンの状態を調整します。各BBLは、MIBの状態の変更についての通信を行い、不定期的にDBBLにホスト・マシン上のすべてが順調であることを示すメッセージを送信します。
Oracle Tuxedoのランタイム・システムは、ユーザー・ログ(ULOG
)にイベント(システム・エラー、警告、トレース・イベントも含む)を記録します。プログラマは、ULOG
を使用して、アプリケーションをデバッグしたり、認可の失敗などの特別な状況や検出した状態を管理者に通知します。
ATMIを使用すると、プログラマは通信に関するよりグローバルな問題を管理できます。ATMIには、アプリケーションとシステムの両方に関連するエラーを処理する機能があります。サービス・ルーチンで、アプリケーション・エラー(無効なアカウント番号が使用された場合など)が発生すると、アプリケーション・エラーが返され、サービスは実行されたがリクエストは完了しなかったことがクライアントに通知されます。
システム障害(リクエストの実行中にサーバーがクラッシュするなど)が発生すると、システム・エラーが返され、サービス・ルーチンによりタスクが実行されなかったことがクライアントに通知されます。Oracle Tuxedoシステムは、アプリケーションの動作およびシステム自体の動作をモニターし、プログラムに対してシステム・エラーを通知します。
リクエストの処理中にサービスが無限ループに入ることがあります。クライアントは待機しますが、応答は戻りません。無限の待機からクライアントを保護するために、Oracle Tuxedoシステムには、ブロッキング・タイムアウトおよびトランザクション・タイムアウトという2種類の構成可能なタイムアウト・メカニズムがあります。Oracle Tuxedo Domainsコンポーネントの使用のドメインのトランザクション・タイムアウトとブロッキング・タイムアウトの指定に関する項を参照してください。
ブロッキング・タイムアウトは、ブロックされたプログラムが、何らかのイベント発生後に指定の時間を超えて待機しないようにするメカニズムです。いったんタイムアウトが検出されると、待機中のプログラムは、ブロッキング・タイムアウトが発生したことを通知するシステム・エラーを受信します。ブロッキング・タイムアウトは、サービス・リクエストの有効期間、つまりアプリケーションがサービス・リクエストに対する応答を待機する時間を定義します。タイムアウト値は、TUXCONFIG
ファイルのRESOURCES
セクションのBLOCKTIME
フィールドで定義されるグローバルな値です。
トランザクション・タイムアウトは、アクティブなトランザクションでリソースが集中することが原因で発生するタイムアウトです。トランザクション・タイムアウトは、トランザクション(その中で複数のサービス・リクエストが行われる場合もあります)の有効期間を定義します。このタイムアウト値は、tpbegin(3c)を呼び出してトランザクションを開始するときに定義されます。トランザクション・タイムアウトは、リソースを最大化する場合に便利です。たとえば、トランザクション処理中にデータベースがロックされた場合に、アプリケーションのトランザクション用のリソースが停止状態になる時間を制限できます。トランザクション・タイムアウトは、常にブロッキング・タイムアウトをオーバーライドします。
UBBCONFIG
ファイルのトランザクション・ライムアウト・パラメータには次の2つがあります。
UBBCONFIG
のSERVICES
セクションで指定するTRANTIME
。特定のAUTOTRAN
サービスのタイムアウト値を制御します。UBBCONFIG
のRESOURCES
セクションで指定され、tpbegin(3c)またはAUTOTRAN
サービス呼出しを介して開始されたトランザクションのタイムアウト値に上限を設定するために管理者によって使用されるMAXTRANTIME
。これらのトランザクション・タイムアウト・パラメータの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「UBBCONFIG(5)」を参照してください。
冗長サーバーと自動再起動機能をアプリケーションに設定して、障害に対処することもできます。冗長サーバーを設定すると、高可用性が得られ、大量の処理、サーバー障害、またはマシン障害を処理できるようになります。Oracle Tuxedoシステムは、アクティブなサーバーのステータスを定期的に調べ、再起動可能なサーバーの障害を検出すると、自動的にサーバーの新しいインスタンスを生成します。
サーバーに自動再起動のプロパティを設定すると、個々のサーバーの障害を処理できます。また、システムによる再起動の回数を指定することもできます。この機能により、サーバーの再起動回数の制限が原因で度々発生するアプリケーション・エラーを回避できます。
Oracle Tuxedoシステムは、アクティブなマシンの可用性を頻繁に調べます。マシンにアクセスできない場合は、そのマシンを「分断されたマシン(partitioned)」とマークします。この場合は、システム・イベントが生成されます。マシンの分断は、ネットワーク障害、マシン障害、またはサーバーのパフォーマンス低下が原因で発生する場合もあります。
したがって、プログラマは、プロセス内の個々のスレッドが異常終了した可能性があることを認識する必要があります。1つのスレッドが異常終了してシグナルが出されると、通常、そのスレッドが属する全体のプロセスが異常終了しているため、BBLにより異常終了が検出されます。
ただし、スレッドのexit関数を誤って呼び出したためにスレッドが異常終了した場合、シグナルは生成されません。スレッドがtpterm()
を呼び出す前にこの種の異常終了が発生すると、BBLでは異常終了を検出できず、異常終了したスレッドに関連するコンテキストの登録表スロットの割当ては解除されません。(スレッドの異常終了を検出できても、BBLがこの登録表のスロットの割当て解除するのは適切ではありません。これは、アプリケーション・モデルによっては、スレッドが異常終了すると別のスレッドがコンテキストに関連付けられるからです。)
注: | ここで説明する機能は、使用する管理ツールに関係なく、マルチスレッド化またはマルチコンテキスト化されたすべてのアプリケーションに適用されます。ここでは、MIBの呼出しを使用する管理者の観点で機能を説明しています。MIB用のインタフェース(tmadmin(1)またはOracle管理コンソール)を使用する管理者も適用できます。 |
マルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータは、次の方法で取得できます。
TPMULTICONTEXTS
モードでtpinit
()が呼び出され、新しいコンテキストが作成されるたびに、Oracle Tuxedoシステムによって自動的に作成されます。)TM_MIB
のT_SERVERCTXT
クラス。複数のサーバー・ディスパッチ・スレッドが同時に実行されている場合、このクラスの14のフィールドには、複数のインスタンスが提供されます。つまり、T_SERVERCTXT
セクションには、実行中のサーバー・ディスパッチ・スレッドごとに次のフィールドが用意されています。TA_CONTEXTID
(キー・フィールド)TA_SRVGRP
(キー・フィールド)TA_SRVID
(キー・フィールド)TA_CLTLMID
TA_CLTPID
TA_CLTREPLY
TA_CMTRET
TA_CURCONV
TA_CURREQ
TA_CURRSERVICE
TA_LASTGRP
TA_SVCTIMEOUT
TA_TIMELEFT
TA_TRANLEV
たとえば、12のサーバー・ディスパッチ・スレッドが同時に実行されている場合、このアプリケーション用のMIBのT_SERVERCTXT
クラスには、12のオカレンスを含むTA_CONTEXTID
フィールド、12のオカレンスを含むTA_SRVGRP
フィールド、などが設定されます。
T_SERVER
クラス内のフィールドに複数のインスタンスがあり、これらのインスタンスの値がマルチコンテキスト化されたサーバーのコンテキストごとに異なる場合、T_SERVER
クラスのフィールドにはダミーの値が指定され、T_SERVERCTXT
フィールドには、各コンテキストの実際の値が指定されます。