|
|
トラブルシューティングの最初のステップとして、まずどこで障害が発生したかを判別します。ほとんどのアプリケーションでは、障害の発生源として以下の 6 か所が考えられます。
障害が発生した場所を特定できたら、各箇所の担当者と協力して障害を解決してください。たとえば、ネットワーキングに関する障害が発生した場合は、ネットワーク管理者と協力して解決してください。
アプリケーション障害の原因を検出するには、次の手順に従います。
ULOG) 内で、Oracle Tuxedo システムの警告メッセージとエラー メッセージを調べます。ULOG 内でアプリケーションの警告メッセージとエラー メッセージを調べます。stdout および stderr)。stdout ファイルおよび stderr ファイルは APPDIR 変数で定義されたディレクトリにあります。stdout ファイルおよび stderr ファイルの名前は、変更されている場合があります。stdout ファイルと stderr ファイルの名前を変更するには、コンフィグレーション ファイル内で、該当するクライアントとサーバの定義にそれぞれ -e または -o を指定します。詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「servopts(5)」を参照してください。APPDIR 変数で定義されたディレクトリにコア ダンプがないかどうかを調べます。dbx などのデバッガを使用してスタック トレースを実行します。コア ダンプが見つかった場合は、アプリケーション開発者に通知します。sar(1) などのコマンドを実行してシステム アクティビティ レポートを表示し、システムが正しく機能しない原因を調べます。以下の原因が考えられます。
イベント ブローカのイベント サマリ (システム全体に渡るサマリ) 生成機能とメカニズム (イベントにより通知を発行) により、トラブルシューティングの機能が拡張されます。イベント ブローカは、Oracle Tuxedo のシステム イベント (サーバの停止やネットワークの障害など) やアプリケーション イベント (ATM 機のメモリ不足など) の詳細を報告します。あるイベントに関する非請求通知を受信した Oracle Tuxedo クライアントは、呼び出すサービス ルーチンを指定したり、以降のデータの格納先とするアプリケーション キューを指定することができます。また、非請求通知を受信した Oracle Tuxedo サーバは、サービス要求を指定したり、データの格納先とするアプリケーション キューを指定できます。
メッセージは、80 文字以内で記述します。システムは STRING バッファ型でメッセージを送信します。つまり、クライアントの非請求メッセージ処理関数 (tpsetunsol(0) で指定) では、この型のメッセージを処理できなければなりません。この場合、tptypes() 関数を使用すると便利です。
ファイル システムを保守するため、次のタスクを定期的に行う必要があります。
| 注意 : | このファイル形式は、TUXCONFIG、TLOG、および /Q で使用されます。 |
デバイス リスト内のデバイスを再初期化するには、次の手順に従います。
devindx のインデックスを持つデバイス リストを破棄するには、次の手順に従います。
Oracle Tuxedo システムの機能性を最適にするには、環境がある程度安定している必要があります。Oracle Tuxedo の管理サブシステムには、ネットワーク、マシン、およびアプリケーション プロセスの障害から回復するための優れた機能が用意されていますが、これらも完璧ではありません。Oracle Tuxedo システムが以下のように機能することを理解しておいてください。
SYSTEM_ACCESS の FASTPATH モデル (デフォルト) を使用するアプリケーション クライアントおよびアプリケーション サーバは、Oracle Tuxedo 共有データ構造へのダイレクト メモリ アクセスが可能です。FASTPATH モデルを使用すると、Oracle Tuxedo システムの性能を最大限に引き出すことができます。Oracle Tuxedo システムでは、オペレーティング システムが提供する IPC (InterProcess Communication) 機能とファイル システム機能を使用します。
アプリケーションで、これらの機能を誤って使用して Oracle Tuxedo 共有メモリまたは Oracle Tuxedo ファイル記述子に書き込みを行った場合や、誤ってほかの Oracle Tuxedo システム リソースを使用した場合は、データが破壊されたり、Oracle Tuxedo の機能が損なわれたり、アプリケーションが停止したりするおそれがあります。
アプリケーション クライアント、アプリケーション サーバ、および Oracle Tuxedo 管理プロセスは、重要な部分 (つまり、共有メモリ内の共有情報の更新) で実行されている可能性があるため、ユーザや管理者がこれらのプロセスを直接終了するのは適切ではありません。メモリの更新中に重要な部分への割り込みを行うと、内部データ構造に矛盾が生じるおそれがあります。これは、Oracle Tuxedo システム固有の問題ではなく、共有データを使用するすべてのシステムに共通の問題です。Oracle Tuxedo ユーザ ログ内のエラー メッセージがロックやセマフォを参照している場合、このようなデータの破壊が発生したことを示している可能性があります。
アプリケーションの可用性を最大にするには、Oracle Tuxedo システムの冗長性管理機能 (複数サーバ、マルチ マシン、マルチ ドメインなどの機能) を活用します。アプリケーションの機能を分散しておくと、1 つの領域で障害が発生した場合でもオペレーションを継続できます。
この節では、ネットワーク分断の原因を見つけ、回復するためのトラブルシューティングについて説明します。1 つまたは複数のマシンから MASTER マシンにアクセスできない場合は、ネットワークが分断されています。アプリケーションの管理者は、ネットワークの分断を見つけ、回復する責任があります。
分断されたネットワークの回復手順は、分断された原因によって異なります。
分断されたネットワークは、次のいずれかの方法で検出できます。
ネットワークで問題が発生すると、Oracle Tuxedo システムの管理サーバは ULOG へメッセージを送り始めます。ULOG がリモート ファイル システム上で設定されている場合、すべてのメッセージは同じログに書き込まれます。したがって、1 つのファイルで tail(1) コマンドを実行し、画面に表示される障害メッセージを調べることができます。
ただし、リモート ファイル システムが、障害のあるネットワークを使用している場合、リモート ファイル システムが使用できない場合があります。
151804.gumby!DBBL.28446: ... : ERROR: BBL が分断されています。machine=SITE2
次のリストは、分断されたネットワークおよびそのネットワーク上のサーバとサービスに関する情報を収集する tmadmin セッションの例です。次の 3 つの tmadmin コマンドが実行されます。
pnw (printnetwork コマンド)psr (printserver コマンド)psc (printservice コマンド)$ tmadmin
> pnw SITE2
SITE2 からの状態を検索できません。
> psr -m SITE1
a.out 名 キュー名 グループ名 ID 要求終了 ロード終了 現サービス
BBL 30002.00000 SITE1 0 - - ( - )
DBBL 123456 SITE1 0 121 6050 MASTERBB
simpserv 00001.00001 GROUP1 1 - - ( - )
BRIDGE 16900672 SITE1 0 - - ( DEAD )
>psc -m SITE1
サービス名 ルーチン名 a.out グループ名 ID マシン 終了数 状態
------------ ------------ -------- -------- -- ------- ------------
ADJUNCTADMIN ADJUNCTADMIN BBL SITE1 0 SITE1 - PART
ADJUNCTBB ADJUNCTBB BBL SITE1 0 SITE1 - PART
TOUPPER TOUPPER simpserv GROUP1 1 SITE1 - PART
BRIDGESVCNM BRIDGESVCNM BRIDGE SITE1 1 SITE1 - PART
この節では、一時的なネットワーク障害および重大なネットワーク障害からの回復方法を説明します。
一時的なネットワーク障害は、BRIDGE によって自動的に回復され、再接続が行われるため、通常ユーザ側ではこの障害の発生はわかりません。ただし、一時的なネットワーク障害を手動で回復する必要がある場合は次の手順に従います。
MASTER マシンで tmadmin(1) セッションを開始します。reconnect コマンド (rco) を実行し、分断されていないマシンと分断されたマシンの名前を指定します。rconon-partioned_node1 partioned_node2
障害が発生したマシンを復元する手順は、マシンが MASTER マシンであるかどうかによって異なります。
障害が発生した MASTER マシンを復元するには、次の手順に従います。
ACTING MASTER (SITE2) で tmadmin セッションを開始します。tmadmin
MASTER (SITE1) で BBL を起動します。boot -B SITE1
SITE1 で pclean を実行していない場合、BBL は起動できません。
tmadmin セッションで、以下のように入力して、MASTER サイト (SITE1) で再度 DBBL を実行します。MASTER
障害が発生した非マスタ マシンを復元するには、次の手順に従います。
次のリストでは、非マスタ マシン SITE2 を復元する例を示します。
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved
> pclean SITE2
DBBL のクリーニングをしています。
システムが安定するまで 10 秒間お待ちください。
掲示板から 3 個の SITE2 サーバを削除しました。
> boot -B SITE2
TUXEDO 管理プロセスを起動します。
Exec BBL -A :
on SITE2 -> プロセス ID=22923 を起動しました。
1 個のプロセスを起動しました。
> q
Oracle Tuxedo システムのコンポーネントを置換するには、次の手順に従います。
アプリケーションのコンポーネントを置換するには、次の手順に従います。
デフォルトでは、Oracle Tuxedo システムはデッド プロセスに関連付けられた資源 (キューなど) をクリーンアップし、BBL スキャン中に定期間隔で掲示板 (BB) から再起動可能な停止したサーバを再起動します。ただし、ほかの時点でもクリーンアップを要求できます。
デッド プロセスに関連付けられた資源を直ちにクリーンアップするには、次の手順に従います。
bbclean コマンドには、オプションの引数として、クリーンアップされるマシンの名前を指定できます。
| 注意 : | machine には値を指定する必要があります。これは必須引数です。 |
このコマンドは、不意に分断が生じた後でシステムを正常に復元する場合に便利です。
Oracle Tuxedo CORBA アプリケーションの起動に失敗した場合、テキスト エディタでアプリケーションの UBBCONFIG ファイルを開き、SERVERS セクションでサーバが正しい順序で起動されているかどうかを確認します。Oracle Tuxedo CORBA 環境での正しいサーバの起動順序は以下のとおりです。この規則に違反した場合、Oracle Tuxedo CORBA アプリケーションは起動しません。
詳細については、『Oracle Tuxedo アプリケーションの設定』の「CORBA C++ サーバの起動順序」を参照してください。
プログラマが Bootstrap オブジェクト コンストラクタまたは TOBJADDR で指定したネットワーク アドレスは、サーバ アプリケーションの UBBCONFIG ファイルにあるネットワーク アドレスと完全に一致していなければなりません。アドレスの形式や、大文字/小文字も識別されます。アドレスが一致しない場合、Bootstrap オブジェクト コンストラクタの呼び出しが失敗し、一見無関係と思われる以下のエラー メッセージが表示されます。
ERROR: クライアントからの非公式の接続 (アドレス
<tcp/ip address>/<port-number>) です。
たとえば、ネットワーク アドレスが、サーバ アプリケーションの UBBCONFIG ファイルにある ISL コマンドラインのオプション文字列で //TRIXIE:3500 に指定されている場合、Bootstrap オブジェクト コンストラクタや TOBJADDR で //192.12.4.6:3500 または //trixie:3500 のいずれかを指定すると、接続が失敗します。
UNIX システムでは、ホスト システムで uname -n コマンドを使用して大文字/小文字を指定します。Windows システムでは、ホスト システムで [コントロール パネル] の [ネットワーク] を使用して大文字/小文字を指定します。
Oracle Tuxedo CORBA アプリケーションを実行する Windows サーバで、一部のインターネット ORB 間プロトコル (IIOP) クライアントを起動した後、//host:port が正しく指定されているにもかかわらず、一部のクライアントで Bootstrap オブジェクトを作成できず、InvalidDomain メッセージが返される場合は、以下の手順を実行できます。関連情報については、「Oracle Tuxedo CORBA サーバのホスト名形式と大文字/小文字の確認」を参照してください。
regedt32 (レジストリ エディタ) を起動します。HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥Afd¥Parameters
DynamicBacklogGrowthDelta: REG_DWORD : 0xa
EnableDynamicBacklog: REG_DWORD: 0x1
MaximumDynamicBacklog: REG_DWORD: 0x3e8
MinimumDynamicBacklog: REG_DWORD: 0x14
これらの値を追加することにより、5 つの保留接続が保持される静的接続キュー (バックログ) が、動的接続バックログに置き換えられます。この動的接続バックログには、最小 20 エントリ (最小 0x14)、最大 1000 エントリ (最大 0x3e8) を格納でき、最小値から最大値の間で 10 ずつ増加できます (0xa 間隔)。
これらの設定は、システムが受信した接続にのみ適用されますが、IIOP リスナでは受け付けられません。マイクロソフトでは、最小値 20、間隔 10 という値を推奨しています。最大値はマシンによって異なりますが、マイクロソフトでは Windows サーバの場合 5000 を超えない値を推奨しています。
この節では、トランザクションのアボートとコミットの方法について説明します。
aborttrans (abort) [-yes] [-ggroupname]tranindex
tranindex の値を決定するために、printtrans コマンド (tmadmin コマンド) を実行します。groupname が指定されると、メッセージがそのグループの TMS に送信され、そのグループのトランザクションに「アボート済み」のマークが付けられます。グループが指定されないと、メッセージはトランザクション コーディネータの TMS に送信され、トランザクションのアボートを要求します。アボート処理を制御するには、トランザクション内のすべてのグループにアボート メッセージを送信する必要があります。
このコマンドは、トランザクション コーディネータのサイトが分断されているか、またはクライアントがコミットまたはアボートを呼び出す前に終了してしまった場合に便利です。タイムアウト値が大きいと、トランザクションは、アボートされるまでトランザクション テーブルに残ります。
トランザクションをコミットするには、次のコマンドを入力します。
committrans (commit) [-yes] [-ggroupname]tranindex
| 注意 : | groupname および tranindex は必須引数です。 |
トランザクションがプリコミットされていないか、またはアボート済みのマークが付いている場合、操作は失敗します。トランザクションを完全にコミットするため、このメッセージはすべてのグループに送信しなければなりません。
committrans コマンドの使用には注意が必要です。このコマンドは、次の 2 つの条件に合致する場合にのみ実行できます。
また、クライアントが tpcommit() でブロックされることもありますが、これはタイムアウトになります。管理コミットを実行する場合には、そのことをクライアントに必ず知らせてください。
管理対象のアプリケーションにデータベース トランザクションが含まれる場合は、ディスク破損の障害後に回復したデータベースにアフター イメージ ジャーナル (AIJ) を適用する必要があります。または、この回復アクティビティのタイミングをサイトのデータベース管理者 (DBA) と調整することが必要になる可能性もあります。通常はエラーが発生すると、データベース管理ソフトウェアが自動的にトランザクションのロールバックを行います。ただしデータベース ファイルを格納するディスクが永久的に破損した場合は、システム管理者または DBA が介入してロールフォワード オペレーションを行うことが必要になることもあります。
データベースの一部を含むディスクが、水曜日の午後 3 時に破損したと想定します。この例では、シャドウ ボリューム (ディスク ミラーリング) が存在しないとします。
データベースのロールフォワード プロセスの具体的な説明については、リソース マネージャ (データベース製品) のマニュアルを参照してください。
IPC 資源とは、メッセージ キュー、共有メモリ、セマフォなどのオペレーティング システムの資源のことです。tmshutdown コマンドを使って Oracle Tuxedo アプリケーションが正常に停止すると、IPC 資源はすべてシステムから削除されます。ただし、アプリケーションが正常に停止せず、システムに IPC 資源が残る場合もあります。このような場合は、アプリケーションを再起動できなくなります。
この問題の解決策として、IPCS コマンドを実行するスクリプトを使用して IPC リソースを削除し、特定のユーザが保有するすべての IPC リソースを解放する方法があります。しかし、この方法では IPC 資源の識別が困難です。たとえば、Oracle Tuxedo アプリケーションの資源か、特定の Oracle Tuxedo アプリケーションに属する資源か、または Oracle Tuxedo システムとは無関係の資源かを識別することができません。誤って IPC 資源を削除するとアプリケーションが破損する可能性があるため、資源の種類を識別できることは重要です。
Oracle Tuxedo の IPC ツール (tmipcrm コマンド) を使用すると、実行中のアプリケーションで Oracle Tuxedo システムによって割り当てられている IPC リソース (コア システムと Workstation コンポーネントのみ) を削除できます。
IPC リソースを削除するコマンドは、TUXDIR/bin に格納されている tmipcrm です。このコマンドは、バイナリ形式のコンフィグレーション ファイル (TUXCONFIG) を読み込み、このファイルの情報を使用して掲示板に書き込みます。tmipcrm を使用できるのは、ローカル サーバ マシンに対してのみです。Oracle Tuxedo のコンフィグレーションのリモート マシンにある IPC リソースは削除できません。
このコマンドを実行するには、次のコマンドラインを入力します。
tmipcrm [-y] [-n] [TUXCONFIG_file]
IPC ツールを使用すると、Oracle Tuxedo システムで使用されるすべての IPC 資源を一覧表示したり、IPC 資源を削除することができます。
| 注意 : | このコマンドは、TUXCONFIG 環境変数を正確に設定するか、またはコマンドラインで適切な TUXCONFIG ファイルを指定しないと利用できません。 |
シングルスレッドのアプリケーションと比較すると、マルチスレッド化されたアプリケーションのデバッグは困難です。そのため、管理者側で、マルチスレッド化されたアプリケーションの作成基準となる方針を決めておくと便利です。
実行中のアプリケーションが保護モードの場合、そのアプリケーションは ATMI 呼び出しが実行されたときのみ共有メモリにアタッチされます。保護モードにしておくと、Oracle Tuxedo の共有メモリが不正なアプリケーション ポインタによって誤って上書きされるのを防ぐことができます。
保護モードで実行中のマルチスレッド アプリケーションには、アプリケーション コードを実行するスレッドと、Oracle Tuxedo の関数呼び出しにより掲示板の共有メモリにアタッチされるスレッドが混在している場合があります。したがって、ATMI 呼び出しで掲示板にアタッチされたスレッドが少なくとも 1 つあると、保護モードを実行しても、アプリケーション コードを実行するスレッドを不正なアプリケーション ポインタから保護できず、Oracle Tuxedo の共有メモリが上書きされる場合があります。つまり、マルチスレッド化されたアプリケーションでは、保護モードの効果が制限されています。
この制限を解除する方法はありません。マルチスレッド化されたアプリケーションを実行するときは、シングルスレッドのアプリケーションのときほど、保護モードを信頼できない点に注意してください。
  
|