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

このトピックには、次の項があります。

• アプリケーションのモニター方法
  
• システム・データとアプリケーション・データのモニター
  
• 起動と停止に関する一般的な問題
  
• 適切なモニタリング・ツールを選択する
  
• コマンド行ユーティリティを使用してアプリケーションをモニターする
  
• tmadminセッションのしくみ
  
• イベント・ブローカを使用してアプリケーションをモニターする
  
• ログ・ファイルを使用してアクティビティをモニターする
  
• トランザクション・ログ(TLOG)とは
  
• ユーザー・ログ(ULOG)とは
  
• ログを使用してエラーを検出する
  
• アプリケーション・サービス・ログを使用してサービスの作業負荷を予測する
  
• ud32を使用してMIBの問合せと更新を行う
  
• 実行時およびユーザー・レベルのトレース機能を使用する
  
• MIBを使用してアプリケーションをモニターする
  
• DBBLおよびBBLを使用してエラーを管理する
  
• ATMIを使用してシステム・エラーとアプリケーション・エラーを処理する
  
• マルチスレッド化またはマルチコンテキスト化されたアプリケーションをモニタリングする
  

2.1 アプリケーションのモニター方法

システム管理者は、一度アプリケーションが起動して実行されたら、そのアプリケーションが実行中は企業の求めるパフォーマンス、可用性、セキュリティの各条件を満たすように管理する必要があります。このため、資源(共有メモリーなど)、アクティビティ(トランザクション処理など)、および発生する可能性のある問題(セキュリティ違反など)についてモニターし、必要に応じて適切な処理を実行する必要があります。

管理者のこのような責務を実行するため、Oracle Tuxedoシステムには、システム・イベントおよびアプリケーション・イベントをモニタリングし、システムを再構成してパフォーマンスを向上させるための方法が用意されています。システムがどのように動作しているかをモニターするには、以下の機能を使用します。

• コマンド行ユーティリティ
• ログ・ファイル
• ATMI
• MIB
• 実行時およびユーザー・レベルのトレース機能

これらのツールを使用すると、変化し続けるビジネス上のニーズや、システムで発生した障害に対して、迅速かつ効率的に対応できます。また、これらのツールを使用して、アプリケーションのパフォーマンスやセキュリティを管理することもできます。

次の図は、モニタリング・ツールを示しています。

図2-1 モニタリング・ツール

Oracle Tuxedoシステムには、アプリケーションをモニターするための次のようなツールが用意されています。

• コマンド行ユーティリティ - アプリケーションのアクティブ化、非アクティブ化、構成および管理に使用するためのコマンド群で、tmboot(1)、tmadmin(1)、tmshutdown(1)などがあります。
• イベント・ブローカ - システム・フォルトや例外的な問題(ネットワーク障害など)を管理者に通知するメカニズム。クライアントまたはサーバーからイベントがポストされると、イベント・ブローカはポストされたイベント名をそのイベント用のサブスクライバ・リストと照合し、サブスクリプションで定義されている適切なアクションを実行します。
• ログ・ファイル - エラー・メッセージ、警告メッセージ、デバッグ・メッセージ、および通知メッセージが格納されたファイル群。システムで発生した問題を追跡し、解決するときに参照します。
• MIB - MIB内の情報にアクセスしたり、これらの情報を変更するためのプロシージャに対するインタフェース。MIBを使用すると、実行時のアプリケーションをモニターするためのプログラムを作成できます。
• 実行時およびユーザー・レベルのトレース機能 - アプリケーションの実行処理を追跡するソフトウェアであり、追跡した情報を使用してシステムの問題を解決できます

関連項目

• システム・データとアプリケーション・データのモニター
• 適切なモニタリング・ツールを選択する
• コマンド行ユーティリティを使用してアプリケーションをモニターする
• イベント・ブローカを使用してアプリケーションをモニターする
• ログ・ファイルを使用してアクティビティをモニターする
• ATMIを使用してシステム・エラーとアプリケーション・エラーを処理する
• MIBを使用してアプリケーションをモニターする
• 『Oracle Tuxedo ATMIの紹介』のMIBを使用した操作の管理に関する項
• 実行時およびユーザー・レベルのトレース機能を使用する
• 『Oracle Tuxedoコマンド・リファレンス』のtmshutdown(1)に関する項
• 『Oracle Tuxedo ATMIの紹介』のOracle Tuxedoの管理ツールに関する項

2.2 システム・データとアプリケーション・データのモニター

Oracle Tuxedoシステムを使用すると、システム・データおよびアプリケーション・データのモニターを行うことができます。

システム・データをモニタリングする

実行中のシステムをモニターするため、Oracle Tuxedoシステムでは、次のシステム・コンポーネントに関するパラメータ設定を管理し、統計情報を生成します。

• クライアント
• 会話
• グループ
• メッセージ・キュー
• ネットワーク
• サーバー
• サービス
• CORBAインタフェース
• トランザクション

これらのコンポーネントには、MIBまたはtmadminを使用してアクセスできます。また、管理者側で操作は行わず、掲示板の統計情報に基づいてシステム・コンポーネントが動的に変更されるようにシステムを設定することもできます。システムが正しく構成されている場合は、次の機能を実行できます(掲示板で次の機能が指定されている場合)。

• ロード・バランシングの有効化
• 新しいサーバーの起動
• 使用されていないサーバーの停止

システムの管理データをモニタリングすることにより、アプリケーションのパフォーマンス、可用性、およびセキュリティの低下の原因となる問題を防止したり、解決することができます。

システム・データの格納場所

システムのモニターに必要な情報を入手できるように、Oracle Tuxedoシステムには次の3つのデータ・リポジトリが用意されています。

• 掲示板 - ネットワーク上の各マシンにある共有メモリーのセグメント。構成のコンポーネントやアクティビティに関する統計情報はここに書き込まれます
• ログ・ファイル - システム生成されたメッセージが書き込まれるファイル
• UBBCONFIG - システムとアプリケーションのパラメータを定義するテキスト形式のファイル

• 静的および動的な管理データをモニタリングする
  

2.2.1 静的および動的な管理データをモニタリングする

実行中のOracle Tuxedoシステムでは、静的データと動的データという2種類の管理データをモニターできます。

図2-2 Oracle Tuxedoシステム: 静的および動的

• 静的データとは
  
• 動的データとは
  

2.2.1.1 静的データとは

構成の静的データとは、システムとアプリケーションを最初に構成したときに割り当てる設定値のことです。これらの設定値は変更されません(ただし、リアルタイムで変更したり、プログラムを使用して変更する場合は例外)。たとえば、システム全体に関するパラメータ(使用するマシン数など)やローカル・マシンのシステムに割り当てられたIPC資源(共有メモリーなど)の容量は静的データです。静的データは、UBBCONFIGファイルと掲示板に格納されます。

• 静的データの確認
  

2.2.1.1.1 静的データの確認

構成に関する静的データの確認が必要な場合があります。たとえば、構成(または掲示板のマシン表)で許可されている最大マシン数の範囲内で、できるだけ多くのマシンを追加したい場合などです。この場合、システム全体に関するパラメータ(MAXMACHINESなど)の現在の値を確認して、マシンの最大数を調べることができます。

システムをチューニングして、アプリケーションのパフォーマンスを向上させることもできます。チューニングが必要かどうかを決定するには、現在利用可能なローカルIPC資源の容量を確認します。

2.2.1.2 動的データとは

構成の動的データとは、アプリケーションの実行中にリアル・タイムで変更される情報のことです。たとえば、負荷(サーバーに送信されたリクエスト数)や構成でのコンポーネント(サーバーなど)の状態は、頻繁に変化します。動的データは、掲示板に格納されます。

• 動的データの確認
  

2.2.1.2.1 動的データの確認

構成の動的データは、管理上の問題を解決する場合に便利です。次に、具体的な例を2つ挙げます。

たとえば、スループットが低下し、現在接続中のクライアント数に対応できる十分なサーバーが稼働しているかどうかを調べるとします。この場合、まず、実行中のサーバー数、接続されているクライアント数、および1つまたは複数のサーバーの負荷を確認します。これらの値を確認すると、サーバーの追加によりパフォーマンスを向上できるかどうかを判断できます。

また、アプリケーションに対して特定のリクエストを行ったときのレスポンスが遅いというクレームを複数受け取ったとします。この場合は、負荷に関する統計情報を確認することにより、BLOCKTIMEパラメータの値を増やしてレスポンス時間を短縮できるかどうかを判断することができます。

2.3 起動と停止に関する一般的な問題

Oracle Tuxedoシステムが正常に動作しているかどうかを評価する場合は、起動と停止に関する次の一般的な問題を考慮し、定期的にシステムをモニターする必要があります。

• 起動時の一般的な問題
  
• 停止時の一般的な問題
  

2.3.1 起動時の一般的な問題

• アプリケーション・サーバーが正常に起動しない、または初期化中にコア・ダンプが発生します。
• アプリケーション・サーバー・ファイルが見つからない、または実行できません。
• サーバー・グループが自動的に移行されます。
• デフォルトの起動手順が最適ではありません。
• 環境変数が設定されていない、または正しく設定されていません。
• IPCKEYがすでに使用されています
• ネットワーク・アドレスが無効です
• UBBCONFIGファイルで指定されている上限値に到達しました
• ネットワーク・ポートがすでに使用されています。
• システム・リソースの制限に達した
• サーバー起動時の依存関係に問題があります
• TLOGファイルが作成されません

2.3.2 停止時の一般的な問題

• クライアントが接続されたままの状態になっています
• サーバーが停止しています
• 停止の順序に問題があります

2.4 適切なモニタリング・ツールを選択する

実行中のアプリケーションをモニターするには、構成の動的な局面を継続的に追跡し、静的なデータを不定期的に調査する必要があります。つまり、基本的には掲示板の情報に注目し、必要に応じてUBBCONFIGファイルを参照します。次の要素を考慮した上で、適切な方法を選択してください。

• Oracle Tuxedoシステムの管理者としての経験。管理者としての経験が十分あり、シェル・プログラミングの専門知識がある場合は、頻繁に実行するコマンドを自動化するプログラムを作成して、アプリケーションをモニターします。
• 表示する情報の種類。tmadminコマンドを実行してUBBCONFIGファイルのRESOURCESセクションを調べ、アプリケーションをモニターする場合、現在値にのみアクセスでます。

次の表では、各モニタリング方法の使用方法を説明します。

方法	使用方法
txrptやtmadminなどのコマンド行ユーティリティ	プロンプトの後にコマンドを入力します。
イベント・ブローカ	サーバーの異常終了やネットワーク障害などのOracle Tuxedoシステムのイベントをサブスクライブします。
ログ・ファイル(ULOG、TLOGなど)	任意のテキスト・エディタでULOGを表示し、 ULOGでtlisten メッセージを参照します。次に、tmadmin dumptlog (TLOGをテキスト形式にダウンロード)を実行して、バイナリ形式のTLOGをテキスト形式のファイルに変換します。
MIB	ランタイム・アプリケーションをモニターするプログラムを作成します。
実行時およびユーザー・レベルのトレース・ユーティリティ	トレース式(カテゴリ、フィルタリング式、アクション)を指定し、TMTRACE実行時およびTMUTRACEユーザー・レベル環境変数を有効にします。詳細は、「実行時およびユーザー・レベルのトレース機能を使用する」を参照してください。

2.5 コマンド行ユーティリティを使用してアプリケーションをモニターする

コマンド行インタフェースからアプリケーションをモニターするには、tmadmin(1)コマンドまたはtxrpt(1)コマンドを使用します。

• tmadminを使用して構成を調べる
  
• txrptを使用してサーバーとサービスに関するレポートを作成する
  

2.5.1 tmadminを使用して構成を調べる

tmadminコマンドは、掲示板とその関連エンティティを表示および変更するための53種類のコマンドのインタプリタです。tmadminコマンドを使用すると、サービスの状態などのシステムの統計情報、実行済リクエスト数、キューに登録されているリクエスト数などをモニターできます。

tmadminコマンドを使用すると、Oracle Tuxedoシステムを動的に変更できます。たとえば、システムの実行中に次のような変更を行うことができます。

• サービスの中断および再開
• サービスの通知および通知解除
• サービス・パラメータの変更
• AUTOTRANのタイムアウト値の変更

tmadminセッションの開始時には、そのセッションの動作モードを選択できます。動作モードには、動作モード(デフォルト)、読取り専用モード、構成モードがあります。

• デフォルトの動作モードでは、管理者権限(管理者用の有効なUIDまたはGID)があれば、tmadminセッション中に掲示板のデータを表示したり、変更することができます。
• 読取り専用モードでは、掲示板のデータを表示することはできますが、データを変更することはできません。読取り専用モードの利点は、管理者のプロセスがtmadminによって拘束されないことです。tmadminプロセスはクライアントとして掲示板を参照するため、管理者用のスロットはほかの作業に使用できます。
• 構成モードでは、掲示板のデータを表示できます。また、Oracle Tuxedoアプリケーションの管理者であれば、データを変更できます。構成モードでのtmadminセッションは、どのマシン(非アクティブなマシンも含む)からでも開始できます。非アクティブなマシンでは通常、tmadminを実行するため構成モードである必要があります。(構成モードを指定せずにtmadminセッションを開始できる非アクティブなマシンは、MASTERマシンのみです。)

ノート:

Oracle Tuxedoのバージョンとライセンス数に関するレポートを作成することもできます。

2.5.2 txrptを使用してサーバーとサービスに関するレポートを作成する

txrptコマンドを実行すると、Oracle Tuxedoサーバーの標準エラー出力の分析が行われ、そのサーバーでサービス処理にかかる時間のサマリーが生成されます。レポートには、指定した期間内に各サービスのディスパッチが何回行われたか、また、各サービスではリクエストの処理にどれだけの時間がかかったかが記録されます。txrptは、標準入力または入力用にリダイレクトされた標準エラー・ファイルからの入力を読み込みます。標準エラー・ファイルを作成するには、servopts(5)の選択肢から-rオプションを使用してサーバーを起動します。-e servoptsオプションを使用すると、ファイル名を指定できます。複数のファイルを、txrpt用に1つの入力ストリームに連結することができます。

サービスXと、そのサービスが格納されたサーバーYの情報がファイルに蓄積されます。txrptを使用してこのファイルを処理すると、サービスのアクセス状況とサーバーの処理時間に関するレポートが生成されます。

関連項目

• アプリケーションのモニター方法
• tmadminセッションのしくみ
• tmadminコマンドを使用してシステムをモニタリングする
• 『Oracle Tuxedo ATMIの紹介』のコマンド行ユーティリティを使用した操作の管理に関する項

2.6 tmadminセッションのしくみ

tmadminコマンドは、掲示板とその関連エンティティを表示および変更するための53種類のコマンドのインタプリタです。図2-2は、典型的なtmadminセッションの動作の例です。

次に、典型的なtmadminセッションを示します

図2-3 典型的なtmadminセッション

• tmadminコマンドを使用してシステムをモニタリングする
  

2.6.1 tmadminコマンドを使用してシステムをモニタリングする

tmadminコマンドでモニターできるランタイム・システム機能のリストを次に示します。

• サービスにインストールされたサーバーの数
• 負荷分散が適切であるかどうか
• 特定のサービスが実行中かどうか
• 非アクティブなクライアントがあるかどうか
• 作業は、システム全体でスムーズに流れるように分散されているか
• クライアントが接続を占有しているために、サーバーがほかのクライアントの処理を行えないかどうか
• ネットワークが安定しているかどうか
• 手動でトランザクションをコミットまたは中断する必要があるかどうか
• ローカル・マシン上の共有メモリーやセマフォなどのオペレーティング・システムの資源が十分かどうか

関連項目

『Oracle Tuxedoコマンド・リファレンス』のtmadmin(1)に関する項)

2.7 イベント・ブローカを使用してアプリケーションをモニターする

Oracle Tuxedoのイベント・ブローカは、実行中のアプリケーションで発生するイベントをモニターします。イベントとは、たとえば、クライアントの状態がアクティブから非アクティブに変わる、というMIBオブジェクトの状態の変化のことです。イベント・ブローカがイベントを検出すると、そのイベントはレポート(ポスト)され、イベントの発生がサブスクライバに通知されます。MIBオブジェクトを表すFMLデータ・バッファを受け取って、MIBでのイベントの発生通知を自動的に受け取ることもできます。イベントをポストしてサブスクライバにレポートする場合、イベント・ブローカはtppost(3c)関数を使用します。管理者もアプリケーション・プロセスもイベントをサブスクライブできます。

イベント・ブローカは、MIBオブジェクトの100種類以上の状態の変化をシステム・イベントとして認識します。システム・イベントをポストすると、イベントが発生した現在のMIBとしてのオブジェクト、および発生したイベントを識別するイベント固有のフィールドの情報が提供されます。たとえば、マシンが分断された場合、ポストされるイベントには次の情報が含まれます。

• T_MACHINEクラスで指定されている影響を受けるマシンの名前、およびそのマシンのすべての属性
• イベントをマシンの分断として識別するいくつかのイベント属性

システム・イベントにサブスクライブするだけで、イベント・ブローカを使用できます。

関連項目

• 『Oracle Tuxedo ATMIの紹介』のイベント・ブローカを使用したイベントの管理に関する項

2.8 ログ・ファイルを使用してアクティビティをモニターする

エラー状況を迅速かつ正確に識別するため、Oracle Tuxedoシステムには次のログ・ファイルが用意されています。

• トランザクション・ログ(TLOG) - トランザクション・マネージャ・サーバー(TMS)で使用されるバイナリ形式のファイルであり、通常、管理者が読むことはありません。TLOGは、Oracle Tuxedoのグローバル・トランザクションに参加したマシンでのみ作成されます。
• ユーザー・ログ(ULOG) - アプリケーションの実行中にOracle Tuxedoシステムによって生成されるメッセージのログです。ULOGMILLISEC環境変数は、ulogメッセージ出力間隔のタイム・スタンプを秒単位ではなくミリ秒単位で記録するために使用されます。ULOGRTNSIZE環境変数は、ローテーション・ファイルのサイズを指定するために使用します。ULOGMILLISECおよびULOGRTNSIZEの詳細は、『Oracle Tuxedoコマンド・リファレンス』のuserlog(3c)に関する項を参照してください。

  これらのログ・ファイルの管理と更新は、アプリケーションの実行中に常に行われます。

2.9 トランザクション・ログ(TLOG)とは

トランザクション・ログ(TLOG)には、コミット・フェーズのグローバル・トランザクションが記録されます。2フェーズ・コミット・プロトコルのうち、第1フェーズの終了時に、グローバル・トランザクションの参加リソースは、グローバル・トランザクションをコミットするか、またはロールバックするかを決める応答を発行します。この応答は、TLOGに記録されます。

TLOGファイルは、グローバル・トランザクションを調整するトランザクション・マネージャ・サーバー(TMS)によってのみ使用されます。管理者は参照しません。TLOGのロケーションとサイズは、UBBCONFIGファイルのMACHINESセクションにある4つのパラメータで指定します。

グローバル・トランザクションに参加する各マシンにTLOGを作成する必要があります。

関連項目

ログを使用してエラーを検出する

2.10 ユーザー・ログ(ULOG)とは

ユーザー・ログ(ULOG)は、Oracle Tuxedoシステムによって生成されるすべてのメッセージ、つまりエラー・メッセージ、警告メッセージ、情報メッセージ、デバッグ・メッセージが書き込まれるファイルです。アプリケーションのクライアントおよびサーバーも、ユーザー・ログへの書込みが可能です。ログは毎日新しく作成されます。そのため、マシンごとにログが異なる場合もあります。ただし、リモート・ファイル・システムが使用されている場合、ULOGを複数のマシンで共有できます。

ULOGによって管理者に提供されるシステム・イベントの記録から、Oracle Tuxedoシステムおよびアプリケーションのほとんどの障害の原因を特定できます。ULOGはテキスト・ファイルなので、任意のテキスト・エディタで表示できます。ULOGには、tlistenプロセスによって生成されるメッセージも挿入されています。tlistenプロセスにより、アプリケーション内のほかのマシンにあるリモート・サービスに接続できます。マスター・マシンを含め各マシンでtlistenプロセスが実行されていることが必要です。

2.11 ログを使用してエラーを検出する

Oracle Tuxedoログ・ファイルは、アプリケーションとシステムの両方で次の方法を使用して障害を検出するのに役立ちます。

• トランザクション・ログ(TLOG)を分析する
  
• ユーザー・ログ(ULOG)を分析する
  
• ULOG内のtlistenメッセージを分析する
  

2.11.1 トランザクション・ログ(TLOG)を分析する

TLOGは、コミット処理中のグローバル・トランザクションに関するメッセージのみを含むバイナリ形式のファイルです。TLOGを表示するには、まずテキスト形式に変換する必要があります。Oracle Tuxedoシステムでは、tmadmin操作を使ってこれを行う方法が2つあります。

• dumptlog (dl)を実行します。バイナリ形式のTLOGはテキスト・ファイルにダウンロード(ダンプ)されます。
• loadtlogを実行します。テキスト形式のTLOGは、既存のバイナリ形式のTLOGにアップロード(ロード)されます。

dumptlogコマンドおよびloadtlogコマンドは、サーバー・グループやマシンを移行するときに、マシン間でTLOGを移動する場合にも便利です。

• トランザクション・エラーを検出する
  

2.11.1.1 トランザクション・エラーを検出する

MIB T_TRANSACTIONクラスを使用して、システム内の実行時のトランザクション属性を取得できます。この情報は、tmadminコマンドのprinttrans (pt)を使用して表示することもできます。トランザクション内の各グループに関する情報は、tmadminを冗長モードで実行した場合にのみ表示されます。冗長モードで実行するには、それ以前にverbose (v)コマンドを実行しておく必要があります。

トランザクションのコミット・プロセスの間に発生した重大なエラー(TLOGへの書込みの失敗など)は、USERLOGに書き込まれます。

2.11.2 ユーザー・ログ(ULOG)を分析する

Oracle Tuxedoシステムでは、アプリケーション内のアクティブなマシンにログ・ファイルが置かれます。このログ・ファイルには、Oracle Tuxedoシステムのエラー・メッセージ、警告メッセージ、デバッグ・メッセージ、またはそれ以外の役立つ情報が含まれています。このファイルをユーザー・ログ(ULOG)と呼びます。ULOGを使用すると、Oracle Tuxedo ATMIによって返されるエラーを簡単に見つけることができます。また、ULOGは、Oracle Tuxedoシステムとアプリケーションで生成されたエラー情報の主要な格納先となります。

ULOGの情報を使用すると、システムやアプリケーションの障害の原因を特定できます。ユーザー・ログには、1つの問題に対して複数のメッセージを記録できます。一般的には、先に記述されたメッセージの方が有益な診断情報を説明しています。

• ULOGメッセージの例
  

2.11.2.1 ULOGメッセージの例

次の例では、LIBTUX_CATカタログのメッセージ358が、その後のメッセージで報告される問題の原因を説明しています(つまり、UNIXシステム・セマフォの不足が、アプリケーションを起動できない原因であることを示しています)。

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.

ノート:

ユーザー・ログ・メッセージの詳細と、示された問題に対する適切な対応策は、システム・メッセージを参照してください。

2.11.3 ULOG内のtlistenメッセージを分析する

ULOGには、tlistenプロセスのエラー・メッセージも記録されます。tlistenプロセスのメッセージは、任意のテキスト・エディタを使用して表示できます。MASTERマシンを含む各マシン上で、個別にtlistenプロセスが実行されます。それぞれのtlistenプロセスのログは、各マシン上のULOGに記録されますが、リモート・ファイル・システムから共有で使用することもできます。

ULOGは、tlistenプロセスの失敗を記録します。tlistenは、起動プロセス中はtmbootによって、アプリケーションの実行中はtmadminによって使用されます。tlistenメッセージは、tlistenプロセスが起動されるとすぐに作成されます。tlistenプロセスが失敗するときに、メッセージがULOGに記録されます。

ノート:

アプリケーションの管理者にはULOGのtlistenメッセージを分析する責任がありますが、プログラマもULOGのメッセージを活用できます。

Oracle Tuxedoシステム・メッセージのCMDTUXカタログには、tlistenのメッセージに関する次の情報が説明されています。

• すべてのメッセージの説明
• メッセージ内で報告されたエラー状況に対し、管理者(またはプログラマ)が行うよう推奨されている処理

• tlistenメッセージの例
  

2.11.3.1 tlistenメッセージの例

ULOG内の次のtlistenメッセージを例に取ります。

121449.gumby!simpserv.27190.1.0: LIBTUX_CAT:262:サーバーのmain()が起動しました

ULOGメッセージは、タグとテキストから構成されます。タグは次の項目から構成されます。

• 時刻を表す6桁の文字列(hhmmss)。先頭から順に、時、分、秒を表します
• マシン名(UNIXシステムでuname -nコマンドを実行すると返される名前)
• メッセージを記録しているプロセスの名前と識別子。(このプロセスIDには、オプションでトランザクションIDを含めることもできます。)スレッドID (1)とコンテキストID (0)も含まれます。

ノート:

シングル・スレッドおよびシングル・コンテキストのアプリケーションの場合、thread_IDフィールドとcontext_IDフィールドにプレースホルダーが出力されます。(アプリケーションがマルチスレッドであるかどうかは、複数のスレッドを使用するまでわかりません。)

テキストは、次の情報で構成されています。

• メッセージ・カタログの名前
• メッセージ番号
• Oracle Tuxedoシステム・メッセージ

ノート:

このメッセージについては、Oracle Tuxedoシステム・メッセージのLIBTUXカタログを参照してください

関連項目

• TLOGデバイスの作成
• アプリケーションの起動
• 『Oracle Tuxedo ATMIの紹介』のOracle Tuxedoトランザクション管理サーバーに関する項
• 『Oracle Tuxedo ATMIアプリケーションの開発のためのチュートリアル』のトランザクションの使用に関する項

2.12 アプリケーション・サービス・ログを使用してサービスの作業負荷を予測する

Oracle Tuxedoアプリケーション・サーバーでは、処理対象のサービス・リクエストのログを生成できます。このログは、サーバーの標準出力(stdout)に表示されます。各レコードには、サービス名、開始時刻、終了時刻が記録されます。

このログは、サーバーの起動後にリクエストできます。txrpt機能を使用してサーバーの実行時間に関するサマリーを生成し、ログの出力結果を分析できます。このデータを使用すると、サービスごとの相対的な作業負荷を見積もることができ、MIB内の該当するサービスに対して作業負荷パラメータを適切に設定できます。

2.13 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出力バッファが返されます。

2.14 実行時およびユーザー・レベルのトレース機能を使用する

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コマンドを使用すると、トレース・オプションをアクティブにしたり非アクティブにできます。このコマンドを使用すると、アクティブなクライアント・プロセスまたはサーバー・プロセスのトレース式を上書きできます。管理者は、すべてのクライアントとサーバーに対してグローバルなトレース機能を許可することも、特定のマシン、グループ、またはサーバーだけがトレース機能を実行できるように設定することもできます。

関連項目

• アプリケーションのモニター方法
• 『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のtmtrace(5)
• 『Oracle Tuxedo ATMI C関数リファレンス』のuserlog(3c)およびtputrace(3c)に関する項

2.15 MIBを使用してアプリケーションをモニターする

MIBを使用して実行できる操作は2つあります。1つ目は、get操作を使用したMIBからの情報の取得です。2つ目は、set操作を使用したMIBの情報の更新です。これらの操作は、ATMI関数(tpalloc(3c)、tprealloc(3c)、tpcall(3c)、tpacall(3c)、tpgetrply(3c)、tpenqueue(3c)など)を使用していつでも実行できます。

MIBをgetオペレーションで問い合せると、MIBは一致数を返信し、リクエストに一致する残りのオブジェクト数を示します。MIBは、残りのオブジェクトの取得に使用できるハンドル(カーソル)を戻します。次のオブジェクト・セットの取得に使用するオペレーションはgetnextと呼ばれます。3番目の操作は問合せが複数のバッファにまたがる場合に実行されます。

• 制限を指定してMIBを問い合せる
  
• グローバル・データおよびローカル・データを問い合せる
  
• tmadmcallを使用して情報にアクセスする
  

2.15.1 制限を指定してMIBを問い合せる

仮想データベースであるMIBを問合せするとは、データベース表からレコードのセットを選択することです。データベース表のサイズを制限する方法は2つあります。つまり、問合せに対して返すオブジェクト数を制限するか、または各オブジェクトの情報量を制限します。キー・フィールドとフィルタを使用して、リクエストのスコープを必要なデータだけに制限することもできます。制限を多く指定すればするほど、アプリケーションから要求される情報は少なくなり、応答は早くなります。

2.15.2 グローバル・データおよびローカル・データを問い合せる

MIBのデータは、いくつかの場所に分けて保存されています。分散アプリケーションでは、複数のマシンにレプリケートされているデータもあります。また、レプリケートはされず、データの属性やデータが表すオブジェクトにより、特定のマシンのローカル・データになるデータもあります。

• グローバル・データとは
  
• ローカル・データとは
  

2.15.2.1 グローバル・データとは

グローバル・データとは、サーバーなどのアプリケーション・コンポーネントに関する情報で、アプリケーション内のすべてのマシン上にレプリケートされます。サーバーに関するほとんどのデータ(構成や状態に関する情報など)は、アプリケーションにグローバルにレプリケートされ、特にすべての掲示板にレプリケートされます。Oracle Tuxedoアプリケーションでは、どこからでもこの情報にアクセスできます。

たとえば、Customer Ordersというアプリケーション内のマシンから、管理者は、グループ1に属し、マシンCustOrdAで実行されているアクティブになっているサーバーB6を調べることができます。

2.15.2.2 ローカル・データとは

ローカル・データとは、グローバルにはレプリケートされない、エンティティに対してローカルなデータ(サーバーの統計など)のことです。ローカルな属性の例として、指定されたサーバー上でサービスが処理される回数を定義するTA_TOTREQCがあります。この統計は、ホスト・マシン上のサーバーに保存されます。サーバーがサービス・リクエストを受信して処理すると、カウンタの値が1つ増えます。この種の情報はローカルで管理されるため、レプリケートするとシステムのパフォーマンスが低下します。

MIBには、クライアントなど、ローカルのみのクラスもあります。クライアントがログインすると、Oracle Tuxedoシステムは掲示板にそのエントリを作成し、クライアントに関するすべての追跡情報をそのエントリに記録します。MIBは、このエントリをチェックすることでクライアントの状態をいつでも判断できます。

2.15.3 tmadmcallを使用して情報にアクセスする

Oracle Tuxedoシステムには、アプリケーションが稼動していない場合にMIBに直接アクセスするためのプログラミング・インタフェースが用意されています。このインタフェースつまりtpadmcall関数は、MIBを構成するデータにアプリケーションから直接アクセスするときに使用します。tpadmcallを使用すると、ローカル情報のサブセットにアクセスできます。

tpadmcallは、システムが稼働していないときに、システムを問い合せたり、管理上の変更を行う場合に使用してください。tpadmcallは、リクエストにかわってTUXCONFIGファイルを問い合せます。送信用と受信用のデータ・バッファ(問合せと応答の内容を格納)は、まったく同じです。

関連項目

• 『Oracle Tuxedo ATMIの紹介』のMIBを使用した操作の管理に関する項
• 『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のMIB(5)に関する項
• ud32を使用してMIBの問合せと更新を行う

2.16 DBBLおよびBBLを使用してエラーを管理する

Oracle Tuxedoシステムでは、次の2つの管理サーバーを使用して、掲示板にある情報をアプリケーション内のすべのマシンに分散します。

• DBBL - 特別掲示板連絡(DBBL)サーバーは、MIBに対するグローバルな変更を伝播し、MIBの静的な部分を保ちます。DBBLの特徴は次のとおりです:
  • MASTERマシン上に置かれ(アプリケーションごとにDBBLは1つのみ)、すべてのBBLに対して周期的にステータス・リクエストを送信します
  • サーバーの移行を調整します。
  • フォルトから回復させるために他のマシンに移行できます。
• BBL - Bulletin Board Liaisonの略。BBLサーバーは、ホスト・マシン上の掲示板を管理します。また、ローカルなMIBに対する変更を調整し、マシン上でアクティブな状態のアプリケーション・プログラムの整合性を検証します。掲示板の特徴は次のとおりです。
  • アプリケーションの各Oracle Tuxedoマシンに存在し、DBBLからのリクエストを実行し、サービス・リクエスト、リクエスト元への返信およびトランザクションのタイムアウトを管理します
  • 検出したサーバーの障害に対して、ユーザー定義されたリカバリ処理を開始し、自動的にサーバーを再起動します。
  • クライアントの障害を検出します
  • クライアントとサーバーのエントリ、および掲示板での会話型通信をクリーンアップします。
  • DBBLの障害を検出し、回復します(MASTERマシンのBBLの場合)

次の図は、DBBLおよびBBLを使用した診断と修復を示しています。

図2-4 DBBLとBBLを使用した診断および修復

どちらのサーバーにもフォルトを管理する役割があります。DBBLはアプリケーション内のほかのアクティブ・マシンの状態を調整します。各BBLは、MIBの状態の変更についての通信を行い、不定期的にDBBLにホスト・マシン上のすべてが順調であることを示すメッセージを送信します。

Oracle Tuxedoの実行時システムは、ユーザー・ログ(ULOG)にイベント(システム・エラー、警告、トレース・イベントも含む)を記録します。プログラマは、ULOGを使用して、アプリケーションをデバッグしたり、認可の失敗などの特別な状況や検出した状態を管理者に通知します。

2.17 ATMIを使用してシステム・エラーとアプリケーション・エラーを処理する

ATMIを使用すると、プログラマは通信に関するよりグローバルな問題を管理できます。ATMIには、アプリケーションとシステムの両方に関連するエラーを処理する機能があります。サービス・ルーチンで、アプリケーション・エラー(無効なアカウント番号が使用された場合など)が発生すると、アプリケーション・エラーが返され、サービスは実行されたがリクエストは完了しなかったことがクライアントに通知されます。

システム障害(リクエストの実行中にサーバーがクラッシュするなど)が発生すると、システム・エラーが原因でサービス・ルーチンによってタスクが実行されなかったことが、クライアントによって認識されます。Oracle Tuxedoシステムは、アプリケーションの動作およびシステム自体の動作をモニターし、プログラムに対してシステム・エラーを通知します。

• 設定可能なタイムアウトのメカニズムを使用する
  
• 冗長サーバーを設定して障害を処理する
  

2.17.1 設定可能なタイムアウトのメカニズムを使用する

リクエストの処理中にサービスが無限ループに入ることがあります。クライアントは待機しますが、応答は戻りません。無限の待機からクライアントを保護するために、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)に関する項を参照してください。

2.17.2 冗長サーバーを設定して障害を処理する

冗長サーバーと自動再起動機能をアプリケーションに設定して、障害に対処することもできます。冗長サーバーを設定すると、高可用性が得られ、大量の処理、サーバー障害、またはマシン障害を処理できるようになります。Oracle Tuxedoシステムは、アクティブなサーバーのステータスを定期的に調べ、再起動可能なサーバーの障害を検出すると、自動的にサーバーの新しいインスタンスを生成します。

サーバーに自動再起動のプロパティを設定すると、個々のサーバーの障害を処理できます。また、システムによる再起動の回数を指定することもできます。この機能により、サーバーの再起動回数の制限が原因で度々発生するアプリケーション・エラーを回避できます。

Oracle Tuxedoシステムは、アクティブなマシンの可用性を頻繁に調べます。マシンにアクセスできない場合は、そのマシンを「分断されたマシン(partitioned)」とマークします。この場合は、システム・イベントが生成されます。マシンの分断は、ネットワーク障害、マシン障害、またはサーバーのパフォーマンス低下が原因で発生する場合もあります。

関連項目

• 『Oracle Tuxedo ATMIの紹介』のOracle Tuxedoシステムの管理とサーバー・プロセス
• システム・データとアプリケーション・データのモニター
• 静的および動的な管理データをモニタリングする

2.18 マルチスレッド化またはマルチコンテキスト化されたアプリケーションをモニタリングする

マルチスレッド化されたアプリケーションをモニタリングする間、管理者は個々のスレッドを認識できません。

• マルチスレッド化されたアプリケーションをモニタリングする間、管理者は個々のスレッドを認識できません。
• tmadmin(1)コマンド・インタプリタを実行すると、マルチスレッド化またはマルチコンテキスト化されたアプリケーションの様々な点に関するMIBの統計レポートを取得できます。たとえば、マルチスレッド化されたアプリケーションに関する以下の情報を取得できます。
  • サーバー・プロセス当たりのディスパッチ済サービスの数。オプションで、各コンテキストの情報を取得することもできます(tmadmin/psrを実行して取得。冗長モードでも可)。
  • クライアント・プロセス当たりのクライアント・コンテキストの数および各クライアント・コンテキストの個別のエントリ(tmadmin pcltコマンドを実行して取得)。
• BBLは、クライアントを調べる場合に、プロセスが実行中であることを確認します。プロセスが異常終了すると、BBLはプロセスの異常終了を検出します。ただし、プロセス内の個々のスレッドが異常終了しても、BBLはスレッドの異常終了を検出しません。

したがって、プログラマは、プロセス内の個々のスレッドが異常終了した可能性があることを認識する必要があります。1つのスレッドが異常終了してシグナルが出されると、通常、そのスレッドが属する全体のプロセスが異常終了しているため、BBLにより異常終了が検出されます。

ただし、スレッドのexit関数を誤って呼び出したためにスレッドが異常終了した場合、シグナルは生成されません。スレッドがtpterm()を呼び出す前にこの種の異常終了が発生すると、BBLでは異常終了を検出できず、異常終了したスレッドに関連するコンテキストの登録表スロットの割当ては解除されません。(スレッドの異常終了を検出できても、BBLがこの登録表のスロットの割当て解除するのは適切ではありません。これは、アプリケーション・モデルによっては、スレッドが異常終了すると別のスレッドがコンテキストに関連付けられるからです。)

この制限事項には適切な対応策がないため、プログラマはこの点を考慮してアプリケーションを設計する必要があります。

• MIBを使用してマルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータを取得する
  

2.18.1 MIBを使用してマルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータを取得する

ノート:

ここで説明する機能は、使用する管理ツールに関係なく、マルチスレッド化またはマルチコンテキスト化されたすべてのアプリケーションに適用されます。この機能については、MIB呼出しを使用する管理者の観点から説明しますが、MIBへのインタフェースを使用する管理者の場合でも同じです。

マルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータは、次の方法で取得できます。

• MIBに対して呼出しを行う
• 選択されたtmadminコマンドを発行する

取得した情報は、以下の場所に格納されます。

• 掲示板のレジストリのクライアント・セクション。コンテキストごとのエントリがあります。(エントリは、TPMULTICONTEXTSモードでtpinit()が呼び出され、新しいコンテキストが作成されるたびに、Oracle Tuxedoシステムによって自動的に作成されます。)
• TM_MIBのT_SERVERCTXTクラス。複数のサーバー・ディスパッチ・スレッドが同時に実行されている場合、このクラスの14のフィールドには、複数のインスタンスが提供されます。つまり、T_SERVERCTXTセクションには、実行中のサーバー・ディスパッチ・スレッドごとに次のフィールドが用意されています。
  • TA_CONTEXTID (キー・フィールド)
  • TA_SRVID (キー・フィールド)
  • TA_SRVID(キー・フィールド)
  • TA_CLTLMID
  • 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フィールドには、各コンテキストの実際の値が指定されます。

関連項目

• 『Oracle Tuxedoコマンド・リファレンス』のtmadmin(1)に関する項
• 『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のTM_MIB(5)に関する項
• マルチスレッドおよびマルチコンテキストATMIアプリケーションのプログラミング