| Oracle® Exalogic Elastic Cloudリリース・ノート B71908-07 |
|
 前 |
 次 |
ここでは、Oracle Virtual Assembly Builderがイントロスペクトできるコンポーネントの固有の問題について説明します。各コンポーネントの問題のリストは、最初に最も深刻または頻繁に発生する問題を示し、続いてより優先度の低い問題を示しています。
この項の内容は、次のとおりです。
ここでは、Oracle VMの問題について説明します。次の項目が含まれます。
Oracle VM使用時の断続的なエラーが報告されています。oracle.ovs.bizを含むエラーを受け取った場合、Oracle VMログを確認し、問題の根本原因を確実に理解してください。場合によっては、タスクを再試行するだけで問題が解決することもありますが、ログを確認することが最良のアプローチです。
Oracle Virtual Machineでは仮想マシン名は100文字以下に制限されています。名前が長すぎると、次のエラーを受け取ります。oracle.ovs.biz.exception.invalidNameException: OVM-4008
Oracle Virtual Assembly Builderデプロイヤは次の形式に基づいて仮想マシン名を判別します。
deploymentId_subassemblyName_applianceName_instanceName0
定義された100文字制限内に仮想マシン名を納めるために、結合されるアセンブリ名(およびすべてのサブアセンブリ名)とアプライアンス名を、結合後に100文字未満になるように十分に短くする必要があります。
Oracle Virtual Machineでは仮想マシンのパスワードが50文字以下に制限されています。お使いの仮想マシンのパスワードを50文字未満にする必要があります。パスワードが長すぎると次のエラーを受け取ります。Oracle.ovs.biz.exception.OVSException: OVM-5101 The template{0} cannot be found
Oracle VMは最大26台の仮想ディスクを備えたアプライアンスの処理をサポートしています。より多くの仮想ディスクを作成する操作の実行を試みると、失敗し「OVFで宣言されたディスク・イメージがOVAに存在しない」ことを示すエラー・メッセージが表示されます。
ここでは、Oracle WebLogic Serverの問題について説明します。次の項目が含まれます。
フォワード・スラッシュ('/')を含む名前のWebLogic Serverサービス(JMSサーバー定義またはデータ・ソース定義)を作成できます。名前にフォワード・スラッシュを含むサービスは、WebLogic Serverデプロイメントの失敗を引き起こします。これを回避するには、WebLogic Serverサービスの名前に'/'文字が含まれていないことを確認します。
アプリケーション・スコープで構成されたJDBCデータ・ソース・マッピングを使用したアプリケーションが起動しないというエラーが報告されています。この障害は、Oracle WebLogic Server AdminServer上のデプロイメントで、AdminServer自体をデプロイした直後にのみ発生します。
この問題を修正するには、手動でAdminServerを起動します。
Oracle WebLogic Server参照システムでもホストされているWebサービスにアクセスしているアプリケーションは、デプロイメント時に新しいWebサービスの場所をポイントするように更新されません。新しいOracle VMホスト上のWebサービスWSDLにアクセスするようにアプリケーションを更新し、その後、管理コンソールやwlstなどのOracle WebLogic Server管理ツールを介してアプリケーションをOracle VM Oracle WebLogic Server環境に再デプロイする必要があります。
Oracle Virtual Assembly Builderは、Oracle WebLogic Serverドメインの移動時にpack/unpackユーティリティを使用します。ユーティリティの問題により、ユーティリティを使用して、元々10.3.1ドメインだったが10.3.2のインストール時に10.3.2にアップグレードされたドメインを移動すると解凍操作が失敗します。
この問題は、Oracle Virtual Assembly Builderが、Oracle WebLogic Server管理対象サーバーを含む必要なインスタンスをアセンブリにデプロイし起動したが、後から管理対象サーバー(ゲストOSではない)がクラッシュするか、外部ツールを介して明示的にシャットダウンされるという、一般的でないシナリオに当てはまります。
ゲストOSのコンテキストから手動起動を実行する場合は、StartManagedServer.shスクリプトを手動で変更して、正しい管理サーバーURL (管理サーバー・ホスト名)を提供する必要があります。これは、デフォルト管理URLが間違った値だったために必要となります(管理サーバーのマシン名はテンプレートの作成時点では不明です)。
引き続き管理コンソールのノード・マネージャを介してサーバーを起動または停止できます。
Oracle WebLogic Serverプラグインはファイル・セットの所有権の変更をサポートしていません。デフォルトの'oracle'ユーザーを使用する必要があります。そうでないと、デプロイメントが失敗する可能性を含め、予期せぬ結果となることがあります。
ノード・マネージャを介してOracle WebLogic Serverクラスタ内のサーバーを起動できないというエラーが見られます。このエラーは、ノード・マネージャのホームを再配置した場合に発生します。このような再配置はサポートされていません。特に、nodemanager.propertiesファイルが<weblogic_home>/common/nodemanagerディレクトリに存在する場合に、イントロスぺクション時にのみノード・マネージャ構成が発生します。
ここでは、Oracle Web Cacheの問題について説明します。次の項目が含まれます。
Oracle WebCacheがEnterprise Managerに登録されており、イントロスペクトされると、プロトコルの不一致が原因で、最終的なEnterprise Manager登録出力をOracle WebLogic Server管理サーバーの入力に接続できません。
回避策は、Oracle Web Cacheのappliance.xmlファイルを手動で編集することです。$AB_INSTANCE/catalog/metadata下に、Oracle Web Cacheコンポーネントのappliance.xmlファイルがあります。それを編集して'EMRegistration'出力を検索します。プロトコルを'HTTP'から'http'に変更します。これで、出力をOracle WebLogic Server管理サーバーの入力に接続できます。
Oracle Virtual Assembly Builderは、その管理ポートとして特権ポート(1024未満のポート番号)を持つOracle Web Cacheアプライアンスのデプロイメントをサポートしていません。
Oracle Virtual Assembly Builderは、スケーリングの実行後、各インスタンスのwebcache.xmlファイルを自動的に更新しません。スケーリング操作がエラーなしで完了した場合でも、インスタンスがクラスタ内のすべてのメンバーを認識できるように、各インスタンスのwebcache.xmlファイルを更新する必要があります。
ここでは、Oracle Databaseの問題について説明します。次の項目が含まれます。
Database Vaultが参照システムのデータベース・ホームに構成されている場合、いくつかのOracle Virtual Assembly Builderの操作中に障害が生じることがあります。
これら問題を回避するには、次の手順を実行します。
イントロスぺクションの前に、システムで次のコマンドを実行してデータベース・ホーム内のDatabase Vaultを一時的に無効にします。
$ make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk dv_off ioracle
参照システムでデータベースを再起動し、その後、シャットダウンします。
ファイル・セットの取得後、参照システムで次のコマンドを実行して、データベース・ホーム内のDatabase Vaultを再度有効にします。
$ make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk dv_on ioracle
参照システムでデータベースを再起動します。
デプロイメント後、新しい仮想マシンで次のコマンドを実行して、データベース・ホーム内のDatabase Vaultを有効にします。
$ make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk dv_on ioracle
新しい仮想マシンでデータベースを再起動します。
Oracle Virtual Assembly Builder操作の間、新たに作成された仮想マシン上のリスナーはデフォルト名LISTENERの使用を開始します。参照システム上のリスナー用に異なる名前を使用していた場合は、エラーを受け取ります。このエラーを回避するには、必ずデフォルト名(LISTENER)を使用します。
異なるリスナー名を使用する必要がある場合は、正しい名前を使用してリスナーを手動で起動します。
$ORACLE_HOME/bin/lsnrctl start <listener name>
注意:
正しいリスナー名を表示するには、$ORACLE_HOME/network/admin/listener.oraを参照します。
データベース・イントロスペクタは次のようにリスナー(listener.ora構成)が構成されているものと想定します。
(ADDRESS = (PROTOCOL = TCP)(HOST = example.cm)(PORT = 5521))
注意:
プロトコル、ホストおよびポートはすべて必須で、前述の順序で表示されている必要があります。
ここでは、Oracle FormsおよびOracle Reportsの問題について説明します。次の項目が含まれます。
アセンブリのデプロイ後、仮想マシンにデプロイされたOracle HTTP Server、Oracle Forms、Oracle Reportsでは、次のファイルの所有権をrootユーザーに変更します。
$ORACLE_HOME/bin/nmo
$ORACLE_HOME/bin/nmb
$ORACLE_HOME/bin/nmhs
代替として、rootユーザーとして$ORACLE_HOME/bin/root.shを実行し、これらのファイルに適切な所有権を設定することもできます。
これらのファイルの所有権がrootに設定されていても、Oracle EMエージェントのパフォーマンス・メトリックの収集能力には影響しません。
