| Oracle® Fusion Middleware Forms Servicesデプロイメント・ガイド 11gリリース1 (11.1.1) B61388-05 |
|
 前 |
 次 |
この章には、次の項が含まれています。
この章では、Oracle Formsを使用してWeb上でアプリケーションを実行する際に発生する可能性のある問題の解決に役立つ情報を提供します。この中では、エラーの一般的な原因について概説し、インストール内容を確認する方法と、問題を診断するためのツールとテクニックを紹介します。
この章は、http://www.oracle.com/technology/products/forms/にあるホワイトペーパー『Oracle Forms診断テクニック』のサブセットでもあります。
インストールになんらかの問題があると、構成が不正になり、Oracle Formsが正しく動作しなくなります。Fusion Middleware Controlを正常にインストールしたという通知がOracle Universal Installerから得られた後で、Oracle Forms Servicesが正しく構成されているかどうかを確認できます。このために次のツールが用意されています。
Web Form Testerは、Oracle Fusion Middlewareをインストールすると使用できるようになります。OracleのインストールおよびForms Servicesの構成が正しいかどうかを確認するには、中間層でWeb Form Testerを実行します。Windowsコンピュータでは、この操作を次のように実行します。
WebLogic Serverドメインの管理サーバーが起動していない場合は、「スタート」、「プログラム・ファイル」、「Oracle WebLogic Server」、「User Projects」、「Domain」、「Start Admin Server for WLS Domain」の順に選択して起動します。
管理対象サーバーが起動していない場合は、次の手順を実行します。
ノード・マネージャが起動していない場合は、「スタート」、「プログラム・ファイル」、「Oracle WebLogic」、「WebLogic Server 11gR1」、「Tools」、「Node Manager」の順に選択して起動します。
WebLogic管理コンソールからForms Servicesを起動します。
URLに<ORACLE_HOME>/tools/web/html/runform.htmと入力して[Enter]キーを押し、ブラウザのインスタンスを開きます。ORACLE_HOMEは、実際のOracle Fusion MiddlewareのOracleホームに置換します。
また、Oracle Fusion MiddlewareのWindows「スタート」メニューから「スタート」、「プログラム・ファイル」、<Oracle_Home>、「Forms Services」、「Run a Form on the Web」の順に選択して、Web Form Testerを起動することもできます。
Webポートを入力して、「フォームの実行」ボタンを押します。Webポートの確認方法は、第A.1.2項「ポート情報の確認」を参照してください。
Oracle Fusion Middlewareのインストールに問題がなければ、Webブラウザに成功メッセージが表示されます。Oracle Fusion MiddlewareでのFormsの基本設定がインストーラによって中間層で正しくインストールされているかどうかを、クライアント・コンピュータからテストすることもできます。クライアント・コンピュータからテスト・フォームを実行するには、ブラウザでURLhttp://example.com:NNNN/forms/frmservlet?form=test.fmxを指定してそのテスト・フォームを実行します。
インストール後に問題が疑われる場合や、Formsの実行に使用するポート番号がわからない場合は、<ORACLE_HOME>/install/portlist.iniファイルでポート情報を確認できます。インストールには適切なポート番号を使用してください。
FRM-XXXXXエラーの診断と解決には、次のツールを使用します。
問題の基本的な原因の特定に、簡潔なFRMエラーのメッセージが役立ちます。多くの場合、Formsアプレットからレポートされるエラーには、FRMエラーの原因の特定が可能なすべての情報が含まれています。FRMエラーが発生すると、エラー・ダイアログに「詳細」ボタンが表示されます。「詳細」ボタンを押すと、現在のJavaスタックが表示されます。このスタックには、根本的な原因とOracle Formsのバージョンが関連付けられています。これは、リリースが異なると、アプレット・クラス・ファイルに使用されるパッケージ構造も異なるためです。
この項は、次の小項目に分かれています。
Forms Webランタイムが予期せず終了した場合は、$ORACLE_INSTANCE/FormsComponent/forms/traceディレクトリにスタック・トレースが書き込まれます。ファイル名の形式は<forms_runtime_process>_dump_<process id>です。ダンプ・ファイルには、実行中のプロセスのスタック・トレースが記録され、Formsで最後に成功した操作が示されます。ダンプが発生したマシン上で実行しているGNU Debuggerやdbxなどのデバッグ・ツールでこのコア・ファイルを使用して、シンボル名でスタック・トレースをアセンブルできます。
スタック・トレースは、次の2つの理由で役立ちます。
スタック内の情報から既知の問題であると同定できます。100%信頼できるわけではありませんが、スタック・トレースが同一の場合、問題が同一であると考えることができます。同一ではなくても、既存のバグに対する迂回策やパッチがあれば、それを試すことができます。
問題が既知のバグでない場合、スタックから、正確な原因と開発を支援する有益な情報を得ることができる場合があります。
この項は、次の小項目に分かれています。
UNIXまたはWindowsでスタック・トレースをテストするには、環境変数FORMS_DELIBERATECRASHを設定します。名前が示すように、この変数を設定するとFormsランタイム・プロセスがクラッシュします。Oracle Formsでは現在1と2の設定が認識されます。FORMS_DELIBERATECRASHを1に設定すると、実行時にBELLビルトインが実行されたときにFormsがクラッシュします。2に設定すると、実行時にwhen-button-pressedトリガーが起動されたときにFormsがクラッシュします。この環境変数は、環境ファイル(default.envなど)で設定できます。
UNIXのスタック・トレースでは、上位2つの関数siehjmpterm()およびsigacthandler()が、シグナル処理コードとしてスタック・トレースに頻繁に出現します。エラーが発生したときにプログラムが実行していた関数を確認するには、さらに下方のスタックを参照する必要があります。
FORMS_CATCHTERM=0を設定すると、この2つの関数はダンプ・ファイルに記述されなくなります。スタック・トレースにはクラッシュ処理シンボルが示されません。
UNIXとWindowsではスタック・トレースの動作が異なります。UNIXでは、シンボル情報が実行可能ファイルおよび共有ライブラリに格納されます。Windowsでは、バイナリ形式の.symファイルとしてこの情報がリンク時に取り出されています。すべてのOracle Forms実行可能ファイルまたはDLLに、.symファイルが1つずつ存在します。.symファイルはデフォルトでインストールされます。Windowsでは、このファイルはORACLE_HOME\binディレクトリにあります。Windowsプラットフォームのメカニズムとして、クラッシュが発生すると、メモリーにロードされているForms実行可能ファイルに対応するすべての.symファイルが、Formsランタイム・プロセスによって読み取られます。その後に、.symファイル内の情報を使用してシンボル名が参照されます。
この項は、次の小項目に分かれています。
Formsアプレットが予期せず表示されなくなり致命的エラーを通知するダイアログが表示される場合は、Formsアプレットはクラッシュしています。Windowsでは、クラッシュが発生すると無効な操作を通知するダイアログが表示されるか、タスク・マネージャで「応答なし」のフラグが設定されます。クラッシュを検証するには、クライアントのスタック・トレース・ファイルをチェックします。クライアントがクラッシュした場合は、実行可能ファイルと同じディレクトリに.rpt拡張子の付いたファイルが作成されます。ファイル名のルートは、実行可能ファイルの名前です。
アプレットがクラッシュしたように見えても、対応する.rptファイルが見つからないことがあります。この場合は、Oracle Formsとクライアントの接続が予期せず突然切断された可能性があります。アプレットはそのまま稼働されますが、すべてのFormsウィンドウがシャットダウンされたために、クライアントがクラッシュしたように見えます。
クライアントがハングしたように見える場合は、サーバー・プロセスがまだ稼働しているかを確認することが重要です。サーバー・プロセスがクラッシュしていないのにクライアントがユーザーの操作に応じなくなったように見える場合は、アプリケーションがハングしていると考えられます。
このような場合は、スレッド・ダンプにデッドロックが示されている可能性があります。Javaコンソールでtを押すとスレッド・ダンプが得られます。ここには、クライアントのJVMで動作しているすべてのスレッドのリストが表示されます。
ダンプ・ファイル内の情報は、オラクル社の開発に非常に役立ちます。問題を報告する場合は、提出するバグにこの情報を含めるようにしてください。
原因の1つに、Javaクラス・ファイルとOracle Formsのバージョンの不一致があげられます。アプレットとFormsランタイム・プロセス間の通信は、メッセージIDに基づいて行われます。これらのメッセージIDが同期していないと、アプレットとサーバーは互いの指示を理解できません。JARファイルを使用している場合は、<ARCHIVE>タグを削除してみてください。問題が解消されない場合は、インストールまたはパッチのCDから手動で正しいクラス・ファイルを取得してください。
もう1つの原因として、Formsランタイム・プロセスの終了が考えられます。サーバー上でFormsランタイム・プロセスが稼働しているかどうか確認します。FORMS_TIMEOUTパラメータが設定されていることを確認します。これは、Oracle Formsクライアントに送信したpingに対する応答をサーバーが待機する時間を定義するもので、ここで指定した時間が経過してもFormsクライアントから何の反応もない場合、ランタイム・プロセスはクリーンアップされます。デフォルトでは、クライアントから2分ごとにHEARTBEATが送信されています。FORMS_TIMEOUTを2分以上に設定すると、サーバーはクライアントからHEARTBEATが得られるまで待機します。HEARTBEATの間隔を短く設定すると、FORMS_TIMEOUTで指定した時間が経過した時点でサーバーはシャットダウンします。この間隔を設定するには、formsweb.cfgでHEARTBEATアプレット・パラメータを設定します。詳細は、第8.6.3項「非同期型通信の構成」を参照してください。この機能の主な目的は、サーバー・プロセスの孤立を防止することですが、サーバー・プロセスが早い段階で不必要にクリーンアップされないようにする効果もあります。
Forms TraceおよびServlet Loggingの2つのツールは、Oracle Formsの環境をトラブルシューティングする際に使用します。Forms Traceの構成および使用の詳細は、第12章「Forms Traceについて」および第12章「Oracle Diagnostics Loggingのツールの利用」を参照してください。
この項は、次の小項目に分かれています。
すべてのソフトウェア・プログラムと同様に、Javaアプレットもメモリーを使用します。Javaの言語仕様ではガベージ・コレクタを必要とします。これはJava仮想マシン(JVM)の内部メモリーを管理するものです。メモリーが必要になるとJavaプログラムはJVMにこのメモリーを要求します。メモリーが残っていない場合は、JVMがガベージ・コレクタを使用してある程度のメモリーを解放しようとします。ガベージ・コレクタは、プログラムで不要となったメモリーを解放してJVMに戻そうとします。それでも必要なタスクの実行にメモリーが足りない場合は、JVMがオペレーティング・システムからさらにメモリーを取得しようとします。このメモリーの割当てが失敗すると、Javaプログラムは処理を続行できません。
Fusion Middleware Controlで、アプリケーションの初期Javaヒープ(JVMが使用するメモリー)を指定できます。クライアントに対しては、オラクル社のJava Plug-inをインストールした後にJavaコントロール・パネルで設定を変更できます。
|
注意: JVMは、使用を許可されているメモリーのみを使用します。オペレーティング・システムに使用可能なメモリーがあっても、使用しないように指定することでJVMではそれを使用しなくなります。 |
メモリー・リークは、プログラムの動的な格納割当てロジックにおけるエラーであり、破棄されたメモリーを再利用できなくなるため、メモリーが枯渇して最終的な崩壊に至ります。
たとえば、プログラムの実行において特定のタスクの実行にメモリーの割当てが必要な場合があります。プログラムがメモリーを使用して作業を終了し、不要になったメモリーをコンピュータ上の他のプログラムに解放できなかった場合は、メモリーはリークしたと判断されます。
メモリー・リークを発見するための一般的な方法は、一連のステップを繰り返し実行してアプリケーションによるメモリーの使用状況を監視します。実行を繰り返すたびにメモリー使用量が増えていく場合は、プログラムでメモリー・リークが発生していると考えられます。
ただし、後から再利用できるように、前に割り当てられたメモリーを保持する複雑なアプリケーションもあります。メモリーの割当ては大きな負荷がかかるため、後でさらにメモリーが必要であると予測されるとき、使用されていないメモリーを再利用できるように保持しておく方が効率的な場合があります。
Java言語仕様では、JVMにガベージ・コレクタを実装することを必要としています。Javaでは、プログラマが新しいオブジェクトを作成することでメモリーを割り当てます。そのメモリーの割当てを解除する方法はありません。ガベージ・コレクタは、プログラムに割り当てられたメモリーを定期的にすべて検索し、安全に破棄できるオブジェクトを特定してメモリーを解放します。安全に破棄できるオブジェクトを特定するために、ガベージ・コレクタはmark and sweepアルゴリズムを使用します。ガベージ・コレクタは、オブジェクトに動的に割り当てられたメモリーをスキャンし、アクティブな参照を持つオブジェクトをマークします。
オブジェクトへのパスがすべて調査された後に、不要と認定されたマークのないオブジェクトがガベージとして収集されます。一般に、Javaプログラミングでは、ガベージ・コレクタがあればメモリー・リークが発生しないと言われています。ガベージ・コレクタは、単純に、アクティブな参照を持つオブジェクトをマークし、そうでないものは破棄します。不要になったオブジェクトへのアクティブな参照を持つ可能性があります。これがJavaにおけるメモリー・リークです。リークを解決するには、不要となったオブジェクトへの参照を破棄して、ガベージ・コレクタがそのオブジェクトを安全に破棄できる対象と判断できるようにします。Javaプログラムにメモリー・リークが存在する場合は、ガベージ・コレクタを頻繁にコールしても意味がありません。
問題をさらに複雑にしているのが、JVMが使用されていないメモリーをオペレーティング・システムにあえて戻さない場合がある点です。しかしほとんどのプログラムは追加のメモリーが必要なときにJVM内の空きメモリーを再使用するため、実際にはこれはほとんど問題となりません。ただし、JVMに割り当てられたすべてのメモリーが、JVMで稼働中のプログラムによって使用されるわけではないことに注意してください。
通常、ある一連の操作を実行するたびにメモリー使用量が増えていく場合は、メモリー・リークが発生しています。適切な判別方法は次のとおりです。
フォームを初期の基本状態にして、メモリー使用量を記録します。
一連の手順を実行して問題を再現します。
初期の基本状態に戻り、メモリー使用量を記録します。
ステップ2と3を繰り返すことで、継続的にメモリー・リークが発生しているかどうかを判断できます。何度繰り返しても使用量があまり伸びない場合は、リークではなく、JVMが使用されていないメモリーを保持しているか、あるいはガベージ・コレクタが予定の頻度で動作していない可能性があります。
Javaプログラムの実行時に、Java仮想マシンはクラス・ファイルをロードする必要があります。インターネット上で実行する場合は、プログラムが実行されるたびにクラス・ファイルをダウンロードすると時間がかかってパフォーマンスに支障をきたすことがあります。このダウンロードの問題を解決するために、JDKではJavaアーカイブ(JAR)ファイルがサポートされています。JARファイルは簡単に言えば、一連のクラス・ファイルを1つの圧縮ファイルにまとめたものです。一般に、JARファイルのサイズは、その中に含まれているクラス・ファイルのサイズの合計よりもはるかに小さくなります。
JVMは、最初にクラスを参照する際に、ローカル・コンピュータにキャッシュされているJARファイルにそのクラスが存在するかどうかを確認します。事前にキャッシュされたJARファイルのいずれかにそのクラスが存在する場合、JVMはキャッシュ内のJARファイルより新しいバージョンがアプリケーション・サーバーに存在するかどうかを確認します。新しいJARファイルが存在する場合は、JARファイルの新しいコピーがクライアント・キャッシュにダウンロードされます。キャッシュされているJARファイルが最新のものである場合は、ネットワークからではなくキャッシュされているJARファイルからクラス・ファイルがロードされます。
キャッシングは重要な機能です。アプリケーションの1回目の実行で必要なすべてのJARファイルがクライアントにキャッシュされます。アプリケーションのJARファイルに変更がなければ、それ以降のアプリケーションの起動では、常にローカルにキャッシュされたコピーからクラスがロードされるようになります。これによって、アプリケーションの起動時間のパフォーマンスが大幅に向上します。アプリケーションの特定の部分の実行に新しいクラスが必要な場合は、必要に応じてそれらがダウンロードされます。
以降のトラブルシューティング一覧は、複雑な問題の対処に役立つ場合がありますが、問題を解決するための決定的なガイドではなく、またOracle Forms環境に対する解決策として保証されているわけでもありません。
順序立てて対処する
原因と思われる箇所に直感や推測ですぐに着手するのではなく、まず他の可能性を排除します。人は証拠から判断可能なことに集中せずに、自らの仮説を裏付ける証拠を探すために長い時間を費やしてしまいがちです。ささいな事項や明白な事項を見落とさないでください。
問題を分割する
問題を管理しやすいように分割することで、全体を調査する必要がなくなります。ある部分を調査して問題がないことがわかれば、次の部分に進むことができます。問題を重要な部分別に分けるアプローチは、問題の診断において有用です。オラクル社カスタマ・サポート・センターと問題を協議して解決策を得る必要がある場合は、このアプローチは重要です。
具体的な現象、および発生のタイミングと頻度を明確にします。これと同様に、発生しなかった現象や発生しなかったタイミングなどを把握することも重要です。たとえば、同じ建物内のユーザー・グループ全体に問題が発生し、その発生が常に午前9時から午前10時の間である場合は、別の建物でその問題が再現しないか、あるいは午後10時以降は再現しないかを把握することも重要です。ユーザーが特定のフォームを午前9時から午前10時の間にのみ使用しているか、あるいはこの時間帯にシステムの負荷が最も高くなっていることが考えられます。
エラー・メッセージを確認する
当たり前のようですが、解決策がエラー・テキストに記述されていることが少なくありません。このドキュメントは、エラー・メッセージを理解して対策を特定する際に役立ちます。
可能であれば問題を再現する
問題を自ら再現できれば、エンド・ユーザーが発見できなかった動作に気付くことができます。その問題が常に発生していたために、エンド・ユーザーがそれを意図された動作であると考えている可能性があります。問題を再現できれば、その解決に一歩踏み出したことになります。
使用するツールを確実に理解する
診断ツールを使用する場合は、その使用方法、およびそのデータの分析方法を把握しておいてください。問題が発生する前にツールの使用方法を理解しておくことは時間の無駄ではありません。ツールを習得するための時間も確保してください。
http://support.oracle.comにあるMy Oracle Support(以前のOracleMetaLink)でより多くの解決策を参照できます。問題の解決策が見つからない場合は、サービス・リクエストを作成してください。
|
関連項目:
|
