目次 前 次 PDF


Oracle Tuxedoアプリケーションのモニタリング

Oracle Tuxedoアプリケーションのモニタリング
このトピックには次の項が含まれます:
アプリケーションのモニター方法
管理者は、アプリケーションを稼働させた後、それによって、会社が設定したパフォーマンス、可用性、セキュリティの要件が継続的に満たされるようにする必要があります。このタスクを実行するには、リソース(共有メモリーなど)、アクティビティ(トランザクション処理など)、および発生する可能性のある問題(セキュリティ違反など)についてモニターし、必要に応じて適切な修正処理を実施する必要があります。
管理者のこのような責務を実行するために、Oracle Tuxedoシステムには、システム・イベントおよびアプリケーション・イベントをモニタリングし、システムを動的に再構成してパフォーマンスを高める方法が用意されています。次の機能により、システムがどのように動作しているかを確認できます。
これらのツールを使用すると、変化し続けるビジネス上のニーズや、システムで発生した障害に対して、迅速かつ効率的に対応できます。これらを使用して、アプリケーションのパフォーマンスやセキュリティを管理することもできます。
図2-1に、モニタリング・ツールを示します。
図2-1 モニタリング・ツール
Oracle Tuxedoシステムには、アプリケーションをモニターするための次のようなツールが用意されています。
コマンド行ユーティリティ - アプリケーションのアクティブ化、非アクティブ化、構成および管理に使用するためのコマンド群で、tmboot(1)tmadmin(1)tmshutdown(1)などがあります。
イベント・ブローカ - システム・フォルトや例外的な問題(ネットワーク障害など)を管理者に通知するメカニズム。クライアントまたはサーバーからイベントがポストされると、イベント・ブローカはポストされたイベント名をそのイベント用のサブスクライバ・リストと照合し、サブスクリプションで定義されている適切なアクションを実行します。
ログ・ファイル - エラー・メッセージ、警告メッセージ、デバッグ・メッセージ、および通知メッセージが格納されたファイル群。システムで発生した問題を追跡し、解決するときに参照します。
MIB - MIB内の情報にアクセスしたり、これらの情報を変更するためのプロシージャに対するインタフェース。MIBを使用すると、実行時のアプリケーションをモニターするためのプログラムを作成できます。
実行時およびユーザー・レベルのトレース機能 - アプリケーションの実行処理を追跡するソフトウェアであり、追跡した情報を使用してシステムの問題を解決できます。
関連項目
『Oracle Tuxedo ATMIの紹介』MIBを使用した操作の管理に関する項
『Oracle Tuxedoコマンド・リファレンス』tmshutdown(1)に関する項
『Oracle Tuxedo ATMIの紹介』Oracle Tuxedoの管理ツールに関する項
システム・データとアプリケーション・データのモニター
Oracle Tuxedoシステムを使用すると、システム・データおよびアプリケーション・データのモニターを行うことができます。
システム・データをモニタリングする
実行中のシステムをモニターするため、Oracle Tuxedoシステムでは、次のシステム・コンポーネントに関するパラメータ設定を管理し、統計情報を生成します。
これらのコンポーネントには、MIBまたはtmadminを使用してアクセスできます。また、管理者側で操作は行わず、掲示板の統計情報に基づいてシステム・コンポーネントが動的に変更されるようにシステムを設定することもできます。システムが正しく構成されている場合は、次の機能を実行できます(掲示板で次の機能が指定されている場合)。
システムの管理データをモニタリングすることにより、アプリケーションのパフォーマンス、可用性、およびセキュリティの低下の原因となる問題を防止したり、解決することができます。
システム・データの格納場所
システムのモニターに必要な情報を入手できるように、Oracle Tuxedoシステムには次の3つのデータ・リポジトリが用意されています。
掲示板 - ネットワーク上の各マシンにある共有メモリーのセグメント。構成のコンポーネントやアクティビティに関する統計情報はここに書き込まれます
ログ・ファイル - システム生成されたメッセージが書き込まれるファイル
UBBCONFIG - システムとアプリケーションのパラメータを定義するテキスト形式のファイル
静的および動的な管理データをモニタリングする
実行中のOracle Tuxedoシステムでは、静的データ動的データという2種類の管理データをモニターできます。
静的データとは
構成に関する静的データは、システムとアプリケーションを最初に構成するときに割り当てる構成設定で構成されます。これらの設定は、(リアルタイムまたは提供したプログラムによる)介入なしでは変更されません。例として、システム全体のパラメータ(使用するマシン数など)やローカル・マシンのシステムに割り当てられたプロセス間通信(IPC)リソース(共有メモリーなど)があります。静的データは、UBBCONFIGファイルと掲示板に格納されます。
静的データの確認
構成に関する静的データを確認することが必要な場合があります。たとえば、構成で許可されている(または掲示板のマシン表で許可されている)マシンの最大数を超えずに多数のマシンを追加する場合があります。構成のシステム全体のパラメータ(MAXMACHINESなど)の現在の値を確認すると、許可されているマシンの最大数を調べることができます。
システムをチューニングすることによって、アプリケーションのパフォーマンスを高めることができます。チューニングが必要かどうかを決定するには、現在使用可能なローカルIPCリソースの容量を確認します。
動的データとは
構成に関する動的データは、リアルタイムで、つまり、アプリケーションの実行中に変更される情報で構成されます。たとえば、負荷(サーバーに送信されたリクエスト数)や様々な構成コンポーネント(サーバーなど)の状態は、頻繁に変化します。動的データは、掲示板に格納されます。
動的データの確認
構成の動的データは、管理上の問題を解決する場合に便利です。次に、具体的な例を2つ挙げます。
たとえば、スループットが低下したため、現在接続中のクライアント数に対応できる十分なサーバーが稼働しているかどうかを調べるとします。稼働しているサーバー数、接続されているクライアント数および1台以上のサーバーの負荷を確認します。これらの数値は、サーバーを追加することでパフォーマンスが向上するかどうかを判断するために役立ちます。
また、アプリケーションに対して特定のリクエストを行ったときのレスポンスが遅いというクレームを複数受け取ったとします。負荷の統計情報を確認することによって、BLOCKTIMEパラメータの値を増やすことでレスポンス時間が短縮されるかどうかを判断できます。
起動と停止に関する一般的な問題
Oracle Tuxedoシステムが正常に動作しているかどうかを確認する場合は、起動と停止に関する次の問題を考慮し、定期的にシステムをモニターする必要があります。
起動時の一般的な問題
IPCKEYがすでに使用されています
UBBCONFIGファイルで指定されている上限値に到達しました
TLOGファイルが作成されません
停止時の一般的な問題
適切なモニタリング・ツールを選択する
実行中のアプリケーションをモニターするには、構成の動的な局面を継続的に追跡し、静的なデータを不定期的に調査する必要があります。つまり、基本的には掲示板の情報に注目し、必要に応じてUBBCONFIGファイルを参照します。次の要素を考慮した上で、適切な方法を選択してください。
表示する情報の種類。tmadminコマンドを実行してUBBCONFIGファイルのRESOURCESセクションを調べ、アプリケーションをモニターする場合、現在値にのみアクセスでます。
表2-1に、各モニタリング・ツールの使用方法を示します。
 
txrpttmadminなどのコマンド行ユーティリティ
任意のテキスト・エディタでULOGを表示し、ULOGtlistenメッセージを参照します。次に、tmadmin dumptlog (TLOGをテキスト形式にダウンロード)を実行して、バイナリ形式のTLOGをテキスト形式のファイルに変換します。
トレース式(カテゴリ、フィルタリング式、アクション)を指定し、TMTRACE実行時およびTMUTRACEユーザー・レベル環境変数を有効にします。詳細は、「実行時およびユーザー・レベルのトレース機能を使用する」を参照してください。
コマンド行ユーティリティを使用してアプリケーションをモニターする
コマンド行インタフェースからアプリケーションをモニターするには、tmadmin(1)コマンドまたはtxrpt(1)コマンドを使用します。
tmadminを使用して構成を調べる
tmadminコマンドは、掲示板とその関連エンティティを表示および変更するための53種類のコマンドのインタプリタです。tmadminコマンドを使用すると、サービスの状態などのシステムの統計情報、実行済リクエスト数、キューに登録されているリクエスト数などをモニターできます。
tmadminコマンドを使用すると、Oracle Tuxedoシステムを動的に変更できます。たとえば、システムの実行中に次のような変更を行うことができます。
AUTOTRANのタイムアウト値の変更
tmadminセッションの開始時には、そのセッションの動作モードを選択できます。動作モードには、動作モード(デフォルト)、読取り専用モード、構成モードがあります。
デフォルトの動作モードでは、管理者権限(管理者用の有効なUIDまたはGID)があれば、tmadminセッション中に掲示板のデータを表示したり、変更することができます。
読取り専用モードでは、掲示板のデータを表示できますが、変更することはできません。読取り専用モードの利点は、管理者のプロセスがtmadminによって拘束されないことです。tmadminプロセスはクライアントとして掲示板を参照するため、管理者用のスロットは他の作業に使用できます。
構成モードでは、掲示板のデータを表示できます。また、Oracle Tuxedoアプリケーションの管理者であれば、データを変更できます。構成モードのtmadminセッションは、非アクティブなマシンを含め、任意のマシンで開始できます。非アクティブなマシンでは通常、tmadminを実行するため構成モードである必要があります。(構成モードを指定せずにtmadminセッションを開始できる非アクティブなマシンは、MASTERマシンのみです。)
注意:
txrptを使用してサーバーとサービスに関するレポートを作成する
txrptコマンドを実行すると、Oracle Tuxedoサーバーの標準エラー出力の分析が行われ、そのサーバーでサービス処理にかかる時間のサマリーが生成されます。レポートには、指定した期間内に各サービスのディスパッチが何回行われたか、また、各サービスではリクエストの処理にどれだけの時間がかかったかが記録されます。txrptは、標準入力または入力用にリダイレクトされた標準エラー・ファイルからの入力を読み込みます。標準エラー・ファイルを作成するには、servopts(5)の選択肢から-rオプションを使用してサーバーを起動します。-e servoptsオプションを使用すると、ファイル名を指定できます。複数のファイルを、txrpt用に1つの入力ストリームに連結することができます。
サービスXと、そのサービスが格納されたサーバーYの情報がファイルに蓄積されます。txrptを使用してこのファイルを処理すると、サービスのアクセス状況とサーバーの処理時間に関するレポートが生成されます。
関連項目
tmadminセッションのしくみ
tmadminコマンドは、掲示板とその関連エンティティを表示および変更するための53種類のコマンドのインタプリタです。図2-2に、典型的なtmadminセッションの動作の例を示します。
図2-2 典型的なtmadminセッション
tmadminコマンドを使用してシステムをモニタリングする
tmadminコマンドでモニターできるランタイム・システム機能のリストを次に示します。
関連項目
『Oracle Tuxedoコマンド・リファレンス』tmadmin(1)に関する項
イベント・ブローカを使用してアプリケーションをモニターする
Oracle Tuxedoのイベント・ブローカは、実行中のアプリケーションでイベント(たとえば、クライアントがアクティブから非アクティブに遷移するなどの、MIBオブジェクトの状態の変化など)をモニターします。イベント・ブローカはイベントを検出するとイベントをレポートまたはポストし、関連するサブスクライバにイベントの発生を通知します。MIBオブジェクトを表すFMLデータ・バッファを受信することによって、MIBでイベントが発生したときに自動的に通知を受け取ることもできます。イベントをポストしてサブスクライバにレポートする場合、イベント・ブローカはtppost(3c)関数を使用します。管理者もアプリケーション・プロセスもイベントをサブスクライブできます。
イベント・ブローカは、MIBオブジェクトの100種類以上の状態遷移をシステム・イベントとして認識します。システム・イベントをポストすると、イベントが発生したオブジェクトの現在のMIB表現、および発生したイベントを識別するイベント固有のフィールドが提供されます。たとえば、マシンが分断された場合、ポストされるイベントには次が含まれます。
T_MACHINEクラスで指定されている影響を受けるマシンの名前、およびそのマシンのすべての属性
イベントをマシンの分断として識別するいくつかのイベント属性
システム・イベントにサブスクライブするだけで、イベント・ブローカを使用できます。
関連項目
ログ・ファイルを使用してアクティビティをモニターする
エラー状況を迅速かつ正確に識別するため、Oracle Tuxedoシステムには次のログ・ファイルが用意されています。
トランザクション・ログ(TLOG) - トランザクション・マネージャ・サーバー(TMS)で使用されるバイナリ形式のファイルであり、通常、管理者が読むことはありません。TLOGは、Oracle Tuxedoのグローバル・トランザクションに参加したマシンでのみ作成されます。
ユーザー・ログ(ULOG) - アプリケーションの実行中にOracle Tuxedoシステムが生成するメッセージのログ・ファイルです。ULOGMILLISEC環境変数は、ulogメッセージ出力間隔のタイム・スタンプを秒単位ではなくミリ秒単位で記録するために使用されます。ULOGRTNSIZE環境変数は、ローテーション・ファイルのサイズを指定するために使用します。ULOGMILLISECおよびULOGRTNSIZEの詳細は、『Oracle Tuxedoコマンド・リファレンス』userlog(3c)に関する項を参照してください。
これらのログ・ファイルの管理と更新は、アプリケーションの実行中に常に行われます。
関連項目
トランザクション・ログ(TLOG)とは
トランザクション・ログ(TLOG)には、コミット・フェーズのグローバル・トランザクションが記録されます。2フェーズ・コミット・プロトコルのうち、第1フェーズの終了時に、グローバル・トランザクションの参加リソースは、グローバル・トランザクションをコミットするか、またはロールバックするかを決める応答を発行します。この応答は、TLOGに記録されます。
TLOGファイルは、グローバル・トランザクションを調整するトランザクション・マネージャ・サーバー(TMS)によってのみ使用されます。管理者は参照しません。TLOGのロケーションとサイズは、UBBCONFIGファイルのMACHINESセクションにある4つのパラメータで指定します。
グローバル・トランザクションに参加する各マシンにTLOGを作成する必要があります。
関連項目
ユーザー・ログ(ULOG)とは
ユーザー・ログ(ULOG)は、Oracle Tuxedoシステムによって生成されるすべてのメッセージ、つまりエラー・メッセージ、警告メッセージ、情報メッセージ、デバッグ・メッセージが書き込まれるファイルです。アプリケーションのクライアントおよびサーバーも、ユーザー・ログへの書込みが可能です。ログは毎日新しく作成されます。そのため、マシンごとにログが異なる場合もあります。ただし、リモート・ファイル・システムが使用されている場合、ULOGを複数のマシンで共有できます。
ULOGによって管理者に提供されるシステム・イベントの記録から、Oracle Tuxedoシステムおよびアプリケーションのほとんどの障害の原因を特定できます。ULOGはテキスト・ファイルなので、任意のテキスト・エディタで表示できます。ULOGには、tlistenプロセスによって生成されるメッセージも挿入されています。tlistenプロセスにより、アプリケーション内のほかのマシンにあるリモート・サービスに接続できます。マスター・マシンを含め各マシンでtlistenプロセスが実行されていることが必要です。
ログを使用してエラーを検出する
Oracle Tuxedoログ・ファイルは、アプリケーションとシステムの両方で次の方法を使用して障害を検出するのに役立ちます。
トランザクション・ログ(TLOG)を分析する
TLOGは、コミット処理中のグローバル・トランザクションに関するメッセージのみを含むバイナリ形式のファイルです。TLOGを表示するには、まずテキスト形式に変換する必要があります。Oracle Tuxedoシステムでは、tmadmin操作を使ってこれを行う方法が2つあります。
dumptlog (dl)を実行します。バイナリ形式のTLOGはテキスト・ファイルにダウンロード(ダンプ)されます。
loadtlogを実行します。テキスト形式のTLOGは、既存のバイナリ形式のTLOGにアップロード(ロード)されます。
dumptlogコマンドおよびloadtlogコマンドは、サーバー・グループやマシンを移行するときに、マシン間でTLOGを移動する場合にも便利です。
トランザクション・エラーを検出する
MIB T_TRANSACTIONクラスを使用して、システム内の実行時のトランザクション属性を取得できます。この情報は、tmadminコマンドのprinttrans (pt)を使用して表示することもできます。トランザクション内の各グループに関する情報は、tmadminを冗長モードで実行した場合にのみ表示されます。冗長モードで実行するには、それ以前にverbose (v)コマンドを実行しておく必要があります。
トランザクションのコミット・プロセスの間に発生した重大なエラー(TLOGへの書込みの失敗など)は、USERLOGに書き込まれます。
ユーザー・ログ(ULOG)を分析する
Oracle Tuxedoシステムでは、アプリケーション内のアクティブなマシンにログ・ファイルが置かれます。このログ・ファイルには、Oracle Tuxedoシステムのエラー・メッセージ、警告メッセージ、デバッグ・メッセージまたはそれ以外の役立つ情報が含まれています。このファイルは、ユーザー・ログまたはULOGと呼ばれます。ULOGを使用すると、Oracle Tuxedo ATMIによって返されるエラーを簡単に見つけることができます。また、ULOGは、Oracle Tuxedoシステムとアプリケーションで生成されたエラー情報の主要な格納先となります。
ULOGの情報を使用すると、システムやアプリケーションの障害の原因を特定できます。ユーザー・ログには、1つの問題に対して複数のメッセージを記録できます。一般的には、先に記述されたメッセージの方が有益な診断情報を説明しています。
ULOGメッセージの例
リスト2-1の例では、LIBTUX_CATカタログのメッセージ358が、その後のメッセージで報告される問題の原因を説明しています(つまり、UNIXシステム・セマフォの不足が、アプリケーションを起動できない原因であることを示しています)。
リスト2-1 ULOGメッセージの例
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メッセージを分析する
ULOGには、tlistenプロセスのエラー・メッセージも記録されます。tlistenプロセスのメッセージは、任意のテキスト・エディタを使用して表示できます。MASTERマシンを含む各マシン上で、個別にtlistenプロセスが実行されます。それぞれのtlistenプロセスのログは、各マシン上のULOGに記録されますが、リモート・ファイル・システムから共有で使用することもできます。
ULOGは、tlistenプロセスの失敗を記録します。tlistenは、起動プロセス中はtmbootによって、アプリケーションの実行中はtmadminによって使用されます。tlistenメッセージは、tlistenプロセスが起動されるとすぐに作成されます。tlistenプロセスが失敗するときに、メッセージがULOGに記録されます。
注意:
アプリケーションの管理者にはULOGtlistenメッセージを分析する責任がありますが、プログラマもULOGのメッセージを活用できます。
Oracle Tuxedoシステム・メッセージのCMDTUXカタログには、tlistenのメッセージに関する次の情報が説明されています。
tlistenメッセージの例
ULOG内の次のtlistenメッセージを例に取ります。
121449.gumby!simpserv.27190.1.0: LIBTUX_CAT:262:サーバーのmain()が起動しました
ULOGメッセージは、タグとテキストから構成されます。タグは次の項目から構成されます。
マシン名(UNIXシステムでuname -nコマンドを実行すると返される名前)。
注意:
シングル・スレッドおよびシングル・コンテキストのアプリケーションの場合、thread_IDフィールドとcontext_IDフィールドにプレースホルダが出力されます。(アプリケーションがマルチスレッドであるかどうかは、複数のスレッドを使用するまでわかりません。)
テキストは、次の情報で構成されています。
注意:
このメッセージについては、Oracle Tuxedoシステム・メッセージのLIBTUXカタログを参照してください。
関連項目
『Oracle Tuxedo ATMIアプリケーションの開発のためのチュートリアル』トランザクションの使用に関する項
アプリケーション・サービス・ログを使用してサービスの作業負荷を予測する
Oracle Tuxedoアプリケーション・サーバーでは、処理対象のサービス・リクエストのログを生成できます。ログは、サーバーの標準出力(stdout)に表示されます。各レコードには、サービス名、開始時刻、終了時刻が記録されます。
このようなログは、サーバーがアクティブになるとリクエストできます。txrpt機能を使用してサーバーの実行時間に関するサマリーを生成し、ログの出力結果を分析できます。このデータを使用すると、サービスごとの相対的な作業負荷を見積もることができ、MIB内の該当するサービスに対して作業負荷パラメータを適切に設定できます。
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を問い合せる
仮想データベースであるMIBを問い合せる場合、データベース表からレコードのセットを選択します。データベース表のサイズは2つの方法で制御できます。情報を取得するオブジェクトの数を制御するか、または各オブジェクトに関する情報の量を制御します。キー・フィールドフィルタを使用して、リクエストの範囲を必要なデータに制限できます。制限を多く指定すればするほど、アプリケーションから要求される情報は少なくなり、応答は早くなります。
グローバル・データおよびローカル・データを問い合せる
MIBのデータは、いくつかの異なる場所に保存されます。一部のデータは、分散アプリケーションの複数のマシンに複製されます。また、複製されず、データの性質やデータが表すオブジェクトに基づいて、特定のマシンのローカルになるデータもあります。
グローバル・データとは
グローバル・データとは、サーバーなどのアプリケーション・コンポーネントに関する情報で、アプリケーション内のすべてのマシンに複製されます。サーバーに関するほとんどのデータ、たとえば、構成や状態に関する情報などは、アプリケーションにグローバルに複製され、特にすべての掲示板に複製されます。Oracle Tuxedoアプリケーションは、どこからでもこの情報にアクセスできます。
たとえば、Customer Ordersというアプリケーション内のマシンから、管理者は、グループ1に属し、マシンCustOrdAで実行されているアクティブになっているサーバーB6を調べることができます。
ローカル・データとは
他の情報はグローバルには複製されませんが、エンティティに対してローカルです(サーバーの統計情報など)。ローカルな属性の例として、指定されたサーバー上でサービスが処理される回数を定義するTA_TOTREQCがあります。この統計は、ホスト・マシン上のサーバーに保存されます。サーバーがサービス・リクエストを受信して処理すると、カウンタの値が1つ増えます。この種の情報はローカルで管理されるため、レプリケートするとシステムのパフォーマンスが低下します。
MIBには、クライアントなど、ローカルのみのクラスもあります。クライアントがログインすると、Oracle Tuxedoシステムは掲示板にそのエントリを作成し、クライアントに関するすべての追跡情報をそのエントリに記録します。MIBは、このエントリをチェックすることでクライアントの状態をいつでも判断できます。
tmadmcallを使用して情報にアクセスする
Oracle Tuxedoシステムには、アプリケーションが稼働していない場合にMIBに直接アクセスするためのプログラミング・インタフェースが用意されています。このインタフェースつまりtpadmcall関数は、MIBを構成するデータにアプリケーションから直接アクセスするときに使用します。tpadmcallを使用すると、ローカル情報のサブセットにアクセスできます。
tpadmcallは、システムが稼働していないときに、システムを問い合せたり、管理上の変更を行う場合に使用してください。tpadmcallは、リクエストにかわってTUXCONFIGファイルを問い合せます。送信用と受信用のデータ・バッファ(問合せと応答の内容を格納)は、まったく同じです。
関連項目
『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』MIB(5)に関する項
ud32を使用してMIBの問合せと更新を行う
 
ud32は、Oracle Tuxedoシステムで配布されるクライアント・プログラムであり、FMLバッファのテキスト表現から構成される入力を読み取ります。MIBに対する非定型問合せおよび更新にはud32を使用できます。これはFML32バッファを作成し、バッファでサービス・コールを行い、サービス・コールから応答(FML32バッファ内にもあります)を受信して、結果を画面に表示するかテキスト形式のファイルに保存します。
ud32は、テキスト形式のFMLフィールドと値を使用してFML32型のバッファを作成し、バッファ内で指定されたサービスを呼び出して、応答を待ちます。応答は、レポートとしてFML32形式で返されます。MIBはFML32をベースにしているため、ud32はMIBのスクリプト作成用ツールになります。
たとえば、次のテキストを含む小さいファイルを作成するとします。
SRVCNM .TMIB
TA_OPERATION GET
TA_CLASS 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:utraceutraceの受信側を指定すると、ユーザー定義のtputrace(3c)が自動的に呼び出されます。この設定をサーバー環境内でエクスポートすると、そのサーバーで実行されているATMI関数のトレース情報とユーザー定義の出力場所に関するレコードが作成されます。
tmadminchangetraceコマンドを使用すると、トレース・オプションをアクティブにしたり非アクティブにできます。このコマンドを使用すると、アクティブなクライアント・プロセスまたはサーバー・プロセスのトレース式を上書きできます。管理者は、すべてのクライアントとサーバーに対してグローバルなトレース機能を許可することも、特定のマシン、グループ、またはサーバーだけがトレース機能を実行できるように設定することもできます。
関連項目
『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』tmtrace(5)に関する項
『Oracle Tuxedo ATMI C関数リファレンス』userlog(3c)およびtputrace(3c)に関する項
DBBLおよびBBLを使用してエラーを管理する
Oracle Tuxedoシステムでは、次の2つの管理サーバーを使用して、掲示板にある情報をアプリケーション内のすべのマシンに分散します。
DBBL - 特別掲示板連絡(DBBL)サーバーは、MIBに対するグローバルな変更を伝播し、MIBの静的な部分を保ちます。DBBLの特徴は次のとおりです。
MASTERマシン上に置かれ(アプリケーションごとにDBBLは1つのみ)、すべてのBBLに対して周期的にステータス・リクエストを送信します
BBL - Bulletin Board Liaisonの略。BBLサーバーは、ホスト・マシン上の掲示板を管理します。また、ローカルなMIBに対する変更を調整し、マシン上でアクティブな状態のアプリケーション・プログラムの整合性を検証します。掲示板の特徴は次のとおりです。
DBBLの障害を検出し、回復します(MASTERマシンのBBLの場合)
図2-3に、DBBLおよびBBLを使用した診断と修復を示します。
図2-3 DBBLとBBLを使用した診断および修復
両方のサーバーが、フォルト管理における役割を担っています。DBBLはアプリケーション内の他のアクティブ・マシンの状態を調整します。各BBLは、MIBの状態の変化について通信し、不定期的に、DBBLにホスト・マシン上に問題がないことを示すメッセージを送信します。
Oracle Tuxedoの実行時システムは、ユーザー・ログ(ULOG)にイベント(システム・エラー、警告、トレース・イベントも含む)を記録します。プログラマは、ULOGを使用して、アプリケーションをデバッグしたり、認可の失敗などの特別な状況や検出した状態を管理者に通知します。
ATMIを使用してシステム・エラーとアプリケーション・エラーを処理する
プログラマは、ATMIを使用することで、通信のよりグローバルな側面を制御します。ATMIによって、アプリケーションとシステムの両方に関連するエラーを処理する機能が提供されます。サービス・ルーチンで、アプリケーション・エラー(無効なアカウント番号が使用された場合など)が発生すると、アプリケーション・エラーが原因で、サービスがタスクを実行したもののリクエストは完了しなかったことが、クライアントによって認識されます。
システム障害(リクエストの実行中にサーバーがクラッシュするなど)が発生すると、システム・エラーが原因でサービス・ルーチンによってタスクが実行されなかったことが、クライアントによって認識されます。Oracle Tuxedoシステムは、アプリケーションの動作およびシステム自体の動作をモニターし、プログラムに対してシステム・エラーを通知します。
設定可能なタイムアウトのメカニズムを使用する
リクエストの処理中にサービスが無限ループに入ることがあります。クライアントは待機しますが、応答は返されません。無限の待機からクライアントを保護するために、Oracle Tuxedoシステムには、ブロッキング・タイムアウトおよびトランザクション・タイムアウトという2種類の構成可能なタイムアウト・メカニズムがあります。これらのタイムアウト・メカニズムの詳細は、『Oracle Tuxedo Domainsコンポーネントの使用』ドメインのトランザクション・タイムアウトとブロッキング・タイムアウトの指定に関する項を参照してください。
ブロッキング・タイムアウトは、ブロックされたプログラムが、指定されたタイムアウト値よりも長く、なんらかのイベントの発生を待機しないようにするメカニズムです。いったんタイムアウトが検出されると、待機中のプログラムは、ブロッキング・タイムアウトが発生したことを通知するシステム・エラーを受信します。ブロッキング・タイムアウトは、サービス・リクエストの有効期間、つまりアプリケーションがサービス・リクエストに対する応答を待機する時間を定義します。タイムアウト値は、TUXCONFIGファイルのRESOURCESセクションのBLOCKTIMEフィールドで定義されるグローバルな値です。
トランザクション・タイムアウトは、アクティブなトランザクションでリソースが集中することが原因で発生するタイムアウトです。トランザクション・タイムアウトは、トランザクション(その中で複数のサービス・リクエストが行われる場合もあります)の有効期間を定義します。このタイムアウト値は、tpbegin(3c)を呼び出してトランザクションを開始するときに定義されます。トランザクション・タイムアウトは、リソースを最大化する場合に便利です。たとえば、トランザクション処理中にデータベースがロックされた場合に、アプリケーションのトランザクション用のリソースが停止状態になる時間を制限できます。トランザクション・タイムアウトは、常にブロッキング・タイムアウトをオーバーライドします。
UBBCONFIGファイルのトランザクション・ライムアウト・パラメータには次の2つがあります。
UBBCONFIGSERVICESセクションで指定するTRANTIME。特定のAUTOTRANサービスのタイムアウト値を制御します。
UBBCONFIGRESOURCESセクションで指定され、tpbegin(3c)またはAUTOTRANサービス呼出しを介して開始されたトランザクションのタイムアウト値に上限を設定するために管理者によって使用されるMAXTRANTIME
これらのトランザクション・タイムアウト・パラメータの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』UBBCONFIG(5)に関する項を参照してください。
冗長サーバーを設定して障害を処理する
冗長サーバーと自動再起動機能をアプリケーションに設定して、障害に対処することもできます。冗長サーバーを設定すると、高可用性が得られ、大量の処理、サーバー障害またはマシン障害を処理できるようになります。Oracle Tuxedoシステムは、アクティブなサーバーのステータスを定期的に調べ、再起動可能なサーバーの障害を検出すると、自動的にそのサーバーの新しいインスタンスを生成します。
サーバーに自動再起動のプロパティを設定すると、個々のサーバーの障害を処理できます。また、システムによる再起動の回数を指定することもできます。この機能により、サーバーの再起動回数の制限が原因で繰り返し発生するアプリケーション・エラーを回避できます。
Oracle Tuxedoシステムは、アクティブな各マシンの可用性を頻繁にチェックします。システムがアクセスできない場合、そのマシンはpartitionedとマークされます。この場合は、システム・イベントが生成されます。マシンの分断は、ネットワーク障害、マシン障害、またはサーバーのパフォーマンス低下が原因で発生する場合もあります。
関連項目
マルチスレッド化またはマルチコンテキスト化されたアプリケーションをモニタリングする
tmadmin(1)コマンド・インタプリタを実行すると、マルチスレッド化またはマルチコンテキスト化されたアプリケーションの様々な点に関するMIBの統計レポートを取得できます。たとえば、マルチスレッド化されたアプリケーションに関する以下の情報を取得できます。
このため、アプリケーション・プログラマは、プロセス内の個々のスレッドが異常終了する可能性があることに留意する必要があります。1つのスレッドが異常終了してシグナルが発行されると、通常、そのスレッドが属するプロセス全体が異常終了するため、BBLにより異常終了が検出されます。
ただし、スレッドのexit関数を誤って呼び出したためにスレッドが異常終了した場合、シグナルは生成されません。スレッドがtpterm()を呼び出す前にこの種の異常終了が発生すると、BBLでは異常終了を検出できず、異常終了したスレッドに関連するコンテキストの登録表スロットの割当ては解除されません。(スレッドの異常終了を検出できても、BBLがこの登録表のスロットの割当て解除するのは適切ではありません。これは、アプリケーション・モデルによっては、スレッドが異常終了すると別のスレッドがコンテキストに関連付けられるからです。)
この制限事項には適切な対応策がないため、プログラマはこの点を考慮してアプリケーションを設計する必要があります。
MIBを使用してマルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータを取得する
注意:
マルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータは、次の方法で取得できます。
選択されたtmadminコマンドを発行する
取得した情報は、以下の場所に格納されます。
掲示板のレジストリのクライアント・セクションには、コンテキストごとのエントリがあります。(エントリは、TPMULTICONTEXTSモードでtpinit()が呼び出され、新しいコンテキストが作成されるたびに、Oracle Tuxedoシステムによって自動的に作成されます。)
TM_MIBT_SERVERCTXTクラス。複数のサーバー・ディスパッチ・スレッドが同時に実行されている場合、このクラスの14のフィールドには、複数のインスタンスが提供されます。つまり、T_SERVERCTXTセクションには、実行中のサーバー・ディスパッチ・スレッドごとに次のフィールドが用意されています。
TA_CONTEXTID (キー・フィールド)
TA_SRVGRP (キー・フィールド)
TA_SRVID (キー・フィールド)
たとえば、12のサーバー・ディスパッチ・スレッドが同時に実行されている場合、このアプリケーション用のMIBのT_SERVERCTXTクラスには、12のオカレンスを含むTA_CONTEXTIDフィールド、12のオカレンスを含むTA_SRVGRPフィールド、などが設定されます。
T_SERVERクラス内のフィールドに複数のインスタンスがあり、これらのインスタンスの値がマルチコンテキスト化されたサーバーのコンテキストごとに異なる場合、T_SERVERクラスのフィールドにはダミーの値が指定され、T_SERVERCTXTフィールドには、各コンテキストの実際の値が指定されます。
関連項目
『Oracle Tuxedoコマンド・リファレンス』tmadmin(1)に関する項
『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』TM_MIB(5)に関する項
『C言語を使用したOracle Tuxedo ATMIアプリケーションのプログラミング』10-1ページのマルチスレッドおよびマルチコンテキストATMIアプリケーションのプログラミングに関する項

Copyright ©1994, 2017,Oracle and/or its affiliates. All rights reserved