アップグレードのトラブルシューティング

A アップグレードのトラブルシューティング

この付録では、失敗したアップグレード、ドメインの再構成やサーバー起動の問題をトラブルシューティングする場合に、共通するいくつかの手順について説明します。

タスク・フォームURLの更新

セキュア・モードを使用してSOAアップグレードした後、URLがHTTPSポートではなくSOA HTTPポートを使用している場合、Worklistappのタスク・フォームは開きません。

アップグレード後に次のエラーが発生した場合は、以下に説明するようにタスク・フォームのURLを変更する必要があります。

taskform failed to open
     Unable to connect
     Firefox can’t establish a connection to the server at
    <hostname_server_location>:<soa_http_port_number>

Enterprise Managerにログインし、SOA HTTPSポートを使用するようにワークリストを変更します。

図A-1 タスク・フォーム・ワークリスト・アプリケーションのURL

「図A-1 タスク・フォーム・ワークリスト・アプリケーションのURL」の説明

リリース・ノートの確認

リリース・ノートは、既知の問題がアップグレードに影響する可能性があるかどうかを判断するために必ず確認してください。リリース・ノートは、Oracle Fusion Middleware 14c (14.1.2.0.0)ライブラリ内にあります。

サーバー起動エラーの解決

アップグレード後に管理サーバーまたは管理対象サーバーが起動しない場合は、起動スクリプト、ファイルおよびクラスに追加したカスタマイズを再適用する必要がある可能性があります。

サーバーが起動しない場合やAdminModeで起動される場合、その最も可能性の高い原因は、以前の環境からの起動スクリプトまたはドメイン変数の変更内容が、新しく構成されたドメインに再適用されていないことです。アップグレード・プロセスの間に、起動スクリプトは、最新バージョンに置き換えられます。これらのファイルに変更を加えた場合、新しい起動スクリプトを同じ情報で編集する必要があります。

これが原因かどうかを判断するには、アップグレード前の起動スクリプトまたはファイルのバックアップを新しいスクリプトおよびファイルと比較します。相違点がある場合は、次の手順で示すように、ファイルを更新します。

setDomainEnv.shへのカスタマイズの再適用

サーバーが起動しない場合やAdminModeで起動される場合、その最も可能性の高い原因は、以前の環境からのsetDomainEnv.shの変更内容が、新しく構成したドメインに再適用されていないことです。アップグレード・プロセスの間に、起動スクリプトは、最新バージョンに置き換えられます。これらのファイルに変更を加えた場合、新しい起動スクリプトを同じ情報で編集する必要があります。

これが原因かどうかを判断するには、アップグレード前のsetDomainEnvファイルのバックアップを新しいsetDomainEnvファイルと比較します。相違点がある場合は、新しいsetDomainEnvファイルに同様の変更を加えます。

JVMの開始スクリプトのプロパティの再適用

開始スクリプトを使用して、必要な起動プロパティを指定したり、既存の環境で起動時に必要になるその他の操作を実行した場合は、アップグレード後にそれらのプロパティを再適用する必要があります。

具体的には、JRockit JVMの引数を構成した場合は、アップグレード後にこれらの構成を再適用する必要があります。JVMの起動パラメータを構成する場合は、startup-plan.xmlまたはstartscript.xmlを使用することをお薦めします。

注意:

開始スクリプトの引数を更新していないと、アップグレード後にSOAサーバーとOSBサーバーが起動できなくなることがあります。

スクリプトを有効にするには:

nodemanager.propertiesファイルで、StartScriptEnabledプロパティをtrueに設定します。(デフォルトはfalseです。)起動スクリプトの名前がstartWebLogic.shまたはstartWebLogic.cmdの場合は、ノード・マネージャはそれらのスクリプトのいずれかをデフォルトとして使用します。
カスタム起動スクリプトを指定する場合は、nodemanager.propertiesファイルで、StartScriptNameプロパティを、使用するスクリプトの名前に設定します。

ノード・マネージャは、JAVA_VENDOR、JAVA_HOME、JAVA_OPTIONS、SECURITY_POLICY、CLASSPATH、およびADMIN_URLを設定します。管理コンソールを使用してサーバーを起動するか、または管理サーバーに接続されたWLSTを使用するとき、ノード・マネージャはこれらの値をServerMBean、ServerStartMBean、およびSSLMBeanから取得します。ノード・マネージャに直接接続されたWLSTを使用する場合は、値を指定できますが、使用しない場合は空白にします。

ノード・マネージャは、ServerStartMBean Arguments属性で指定されるすべてのコマンド行起動オプション(-Dフラグ)とSSLArgumentsを組み合わせ、JAVA_OPTIONSという1つの環境変数にします。SSLArgumentsは、SSLMBeanの値から取得されます。SSLMBeanは、ignoreHostnameVerification、HostnameVerifier、およびReverseDNSAllowedの各値があるか検査し、それらの値は-Dフラグに付加されます。すべてのフラグは、SSLArgumentsパラメータから構成されます。ServerStartMBean内のSSLArgumentsおよびArgumentsのすべての値は、起動スクリプトに定義されるJAVA_OPTIONS環境変数から構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。

XEngine構成ファイルへのカスタマイズの再適用

アップグレード前に、XEngineの構成ファイル(SeverityConfig.xmlなど)に加えた変更は、ドメインの再構成プロセスで再生成される新しい構成ファイルにより上書きされます。そのため、アップグレード前の構成ファイルで使用していたカスタマイズしたすべての設定を、アップグレード後に再適用する必要があります。

たとえば、アップグレード前のXEngine構成ファイルSeverityConfig.xmlに、SNIPについてのセクションを追加している場合は、それと同じセクションをアップグレード後の新しいSeverityConfig.xmlファイルに追加する必要があります。

カスタムのXPathクラスのコピー

アップグレード前の環境でデフォルトのXPathクラスを変更した場合は、アップグレード後に、次の例で示すように、カスタマイズしたXPathクラスを新しいOracleホームにコピーする必要があります:

アップグレード前のバックアップからカスタムXPathクラスをコピーします。クラスは、次のディレクトリにあります。

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_xxx/classes

コピー先は次の14cディレクトリです:

/14c_ORACLE_HOME/soa/modules/oracle.soa.ext_xxx/classes

失敗したアップグレードからのリカバリ

失敗したアップグレードからのリカバリ方法は、どの時点でエラーが発生したかによって異なります。次の事項を確認して、リカバリの方法を判断してください。

アップグレード・アシスタントを実行して、_SOAINFRAスキーマをアップグレードしているときにエラーが発生した場合は、スキーマのエラーを修正してから、バッチ・ジョブを再実行する必要があります。

このリカバリ方法は、アップグレード・アシスタントの初回実行時に、スキーマ・オプションを選択した場合にのみ適用します。
再構成ウィザードの実行中にエラーが発生した場合は、ソース環境からリストアして、アップグレードを最初からやり直す必要があります。
アップグレード・アシスタントを実行して、WebLogicコンポーネント構成オプションをアップグレードしているときにエラーが発生した場合は、エラーを修正してからアップグレード・アシスタントを再実行します。アップグレード・アシスタントの2回目の実行時には、バックアップからリストアして、アップグレード・プロセスを最初からやり直す必要ありません。このプロセスは、再入可能です。
アップグレード・アシスタントを実行してスキーマをアップグレードしているときにエラーが発生した場合、そのエラーがアップグレード・フェーズで発生したときには、バックアップからリストアして、問題を修正した後に最初からアップグレードをやり直す必要があります。ただし、調査フェーズでエラーが発生した場合は、問題を修正してアップグレード・アシスタントを再開できます。アップグレード・フェーズ前に発生したエラーは、再入可能です。

アップグレードのトラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』の一般的なトラブルシューティングのガイドラインに関する項を参照してください。

アップグレード後のSOA JMSモジュールへのEDNTopicの再適用

14c (14.1.2.0.0)にアップグレードした後、アップグレードしたSOA JMSモジュールにEDNTopicがない場合があります。JMSモジュールにEDNTopicがない場合は、WebLogicリモート・コンソールまたはWLSTを使用して、このトピックにトピックまたはUDDを手動で追加する必要があります。

これは既知の問題であり、クラスタ環境でも非クラスタ環境でも発生します。

リモート・コンソールのオンライン・ヘルプでEDNTopicの再適用の詳細を参照するか、Oracleサポートに問い合せてください。

Oracle Service Busのトラブルシューティング

Oracle Service Busでアップグレード後の問題が発生した場合は、「Oracle Service Busアップグレードのトラブルシューティング」で説明されているトラブルシューティング手順を確認してください。

Oracle Managed File Transfer (MFT)アップグレードの問題点のトラブルシューティング

Oracle Managed File Transferのアップグレード時にアップグレード・エラーが発生する場合、次のトラブルシューティング・タスクを参照して問題を修正します。

いくつかの一般的なManaged File Transferのアップグレード・エラー・メッセージを次に示します。

SQLException: ORA-04020: オブジェクトをロックしようとしてデッドロックを検出しました。

解決方法: Upgrade Assistantの「使用可能なコンポーネント」画面で「Managed File Transfer」を選択していることを確認します。Oracle Managed File Transferを選択しない場合、アップグレードにMFTスキーマは含まれません。

SOAPサービスの下位互換性の作成

JDevを使用して古いバージョンでManaged File Transfer固有プロジェクトを作成してある場合は、既存のSOA/SOAPプロジェクトのWSDL定義を、JDevで開いてコンポジットを再デプロイすることで修正する必要があります。

これは、MFTがSOAコンポジットのターゲットであり、SOAのソースでない場合に必要になります。

アップグレード時の暗号化の問題

再構成時に次のエラー・メッセージが返された場合は、JDKに追加のポリシー・ファイルを適用して、バックアップからアップグレードを再開する必要がある可能性があります。

JPS-06513: Failed to save keystore. Reason oracle.security.jps.service.keystore.KeyStoreServiceException: Failed to perform cryptographic operation

このエラーが再度発生しないようにするには、後続のアップグレードの前に、次で説明されているようにポリシー・ファイルを適用します。

強化された暗号化(AES 256)の使用時のポリシー・ファイルの更新

アップグレードされた環境で、Advanced Encryption Standard (AES 256),など強化された暗号化を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

Javaプラットフォームでは、暗号化、公開キー・インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。これらのAPIによって、開発者はアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。

Fusion Middleware 14c (14.1.2.0.0)で使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。「Java暗号化アーキテクチャOracleプロバイダのドキュメント」を参照してください。

ノート:

アップグレードの開始前に、これらのポリシー・ファイルをJDKに適用せずに強化された暗号化を使用しようとすると、アップグレードに失敗することがあり、その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。

アップグレード・アシスタントによるサポート対象外ドメインのアップグレード

指定されたドメインをアップグレードできないというエラーがUpgrade Assistantから示された場合、このリリースでは、ご使用のドメイン構成がサポートされていません。サポートされている構成およびドメインに関する制限事項の詳細は、SOAドメイン・アップグレードの制限の理解を参照してください。

サポート対象外のドメインのスキーマやドメイン構成は、アップグレードしないでください。

Coherenceキャッシュ例外の解決

次に示すWebLogic Cache Provider Coherence例外が示された場合は、エンタープライズ・デプロイメント・トポロジの推奨事項に従って、特定のListenAddressを指定していない可能性があります。

この例外が示されたときには、次のように管理対象サーバーのListenAddressを設定する必要があります。

例外:

weblogic.cacheprovider.coherence.CoherenceException:
  at weblogic.cacheprovider.coherence.CoherenceClusterManager.ensureWKAAddresses(CoherenceClusterManager.java:510)
  at weblogic.cacheprovider.coherence.CoherenceClusterManager.configureClusterService(CoherenceClusterManager.java:236)
  at weblogic.cacheprovider.CacheProviderServerService.bootCoherenceFromWLSCluster(CacheProviderServerService.java:225)
  at weblogic.cacheprovider.CacheProviderServerService.initCoherence(CacheProviderServerService.java:94)

解決方法:

WebLogic Serverリモート・コンソールにログインします。
「サーバー」に移動します。
管理対象サーバー(SOAやOSBなど)を検索します。
「リスニング・アドレス」をlocalhostから127.0.0.1に変更するか、実際のマシン名を指定します。

WSDLで生じるカスタム例外の欠落要素

EJBにカスタム例外が含まれているときに、EJBビジネス・サービスからWeb Service Description Language (WSDL)ファイルをエクスポートすると、生成されたWSDLファイルにはカスタム例外のプロパティが含まれなくなります。アップグレード後に、WSDLファイルを手動で編集して、該当するカスタム例外のプロパティを含める必要があります。

これは、ファイルのWSDL生成部分に限定された問題です。実行時に、EJBからスローされたカスタム例外は、SOAPフォルトのそれぞれの要素にマップされます。レスポンス・ペイロードには、カスタム例外のプロパティに対応する要素が移入されます。

スキーマ・レジストリ内の無効なオブジェクトのトラブルシューティング

アップグレード後のステータスがINVALIDであるスキーマは、状況によりますが、アップグレードの失敗を示している場合があります。

アップグレード後のステータスが「INVALID」と表示されている場合は、スキーマ更新が失敗したことを示している可能性があります。ログ・ファイルを調べて、失敗した理由を判定する必要があります。次の問合せを実行して、無効なオブジェクトを特定します。

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

例外: IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、スキーマ・バージョン・レジストリ表でINVALIDと表示されますが、失敗を示しているわけではありません。シノニム・オブジェクトは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらのINVALIDオブジェクトは無視してかまいません。