|
|
トラブルシューティングの最初のステップとして、まずどこで障害が発生したかを判別します。ほとんどのアプリケーションでは、障害の発生源として以下の6か所が考えられます。
障害が発生した場所を特定できたら、各箇所の担当者と協力して障害を解決してください。たとえば、ネットワーキングに関する障害が発生した場合は、ネットワーク管理者と協力して解決してください。
アプリケーション障害の原因を検出するには、次の手順に従います。
ULOG)内で、Oracle Tuxedoシステムの警告メッセージとエラー・メッセージを調べます。ULOG内でアプリケーションの警告メッセージとエラー・メッセージを調べます。stdoutおよびstderr)。stdoutファイルおよびstderrファイルはAPPDIR変数で定義されたディレクトリにあります。stdoutファイルおよびstderrファイルの名前は、変更されている場合があります。stdoutファイルとstderrファイルの名前を変更するには、構成ファイル内で、該当するクライアントとサーバーの定義にそれぞれ-eまたは-oを指定します。詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「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 partitioned, machine=SITE2
次のリストは、分断されたネットワークおよびそのネットワーク上のサーバーとサービスに関する情報を収集するtmadminセッションの例です。次の3つのtmadminコマンドが実行されます。
pnw (printnetworkコマンド)psr (printserverコマンド)psc (printserviceコマンド)$ tmadmin
> pnw SITE2
Could not retrieve status from SITE2
> psr -m SITE1
a.out Name Queue Name Grp Name ID Rq Done Load Done Current Service
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
Service Name Routine Name a.out Grp Name ID Machine # Done Status
------------ ------------ -------- -------- -- ------- ------------
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
Cleaning the DBBL.
Pausing 10 seconds waiting for system to stabilize.
3 SITE2 servers removed from bulletin board
> boot -B SITE2
Booting admin processes ...
Exec BBL -A :
on SITE2 -> process id=22923 ... Started.
1 process started.
> 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オブジェクト・コンストラクタの呼出しが失敗し、一見無関係と思われる次のエラー・メッセージが表示されます。
エラー: クライアントからの非公式の接続(アドレス<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 on Local Machine」ウィンドウに移動します。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という値を推奨しています。最大値はマシンに依存します。ただし、Microsoftは、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:00 P.M.に破損したと想定します。この例では、シャドウ・ボリューム(ディスク・ミラーリング)が存在しないとします。
データベースのロールフォワード・プロセスの具体的な説明については、リソース・マネージャ(データベース製品)のマニュアルを参照してください。
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の共有メモリーが上書きされる場合があります。つまり、マルチスレッド化されたアプリケーションでは、保護モードの効果が制限されています。
この制限を解除する方法はありません。マルチスレッド化されたアプリケーションを実行するときは、シングル・スレッドのアプリケーションのときほど、保護モードを信頼できない点に注意してください。
  
|