|
|
システム管理者は、一度アプリケーションが起動して実行されたら、そのアプリケーションが実行中は企業の求めるパフォーマンス、可用性、セキュリティの各条件を満たすように管理する必要があります。このため、資源(共有メモリーなど)、アクティビティ(トランザクション処理など)、および発生する可能性のある問題(セキュリティ違反など)についてモニターし、必要に応じて適切な処理を実行する必要があります。
管理者のこのような責務を実行するため、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のグローバル・トランザクションに参加したマシンでのみ作成されます。ULOGMILISEC環境変数は、ulogメッセージの出力間隔のタイム・スタンプを秒単位ではなくミリ秒単位で記録するために使用します。ULOGRTNSIZE環境変数は、ローテーション・ファイルのサイズを指定するために使用します。ULOGMILISECおよび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_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フィールドには、各コンテキストの実際の値が指定されます。
  
|