1. SOA SuiteおよびBusiness Process Managementのアップグレード
  2. アップグレードのトラブルシューティング

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

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

リリース・ノートの確認

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

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

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

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

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

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

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

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

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

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

親トピック: サーバー起動エラーの解決

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

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

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

注意:

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

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

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

  2. カスタム起動スクリプトを指定する場合は、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クラスを新しい12c Oracleホームにコピーする必要があります。

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

/11g_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

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

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

親トピック: サーバー起動エラーの解決

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

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

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

    このリカバリ方法は、アップグレード・アシスタントの初回実行時に、スキーマ・オプションを選択した場合にのみ適用します。

  • 再構成ウィザードの実行中にエラーが発生した場合は、ソース環境からリストアして、アップグレードを最初からやり直す必要があります。

  • アップグレード・アシスタントを実行して、WebLogicコンポーネント構成オプションをアップグレードしているときにエラーが発生した場合は、エラーを修正してからアップグレード・アシスタントを再実行します。アップグレード・アシスタントの2回目の実行時には、バックアップからリストアして、アップグレード・プロセスを最初からやり直す必要ありません。このプロセスは、再入可能です。

  • アップグレード・アシスタントを実行してスキーマをアップグレードしているときにエラーが発生した場合、そのエラーがアップグレード・フェーズで発生したときには、バックアップからリストアして、問題を修正した後に最初からアップグレードをやり直す必要があります。ただし、調査フェーズでエラーが発生した場合は、問題を修正してアップグレード・アシスタントを再開できます。アップグレード・フェーズ前に発生したエラーは、再入可能です。

アップグレードのトラブルシューティングの詳細は、「一般的なトラブルシューティングのガイドライン」を参照してください。

ノート:

CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。

このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項のステップを実行する必要があります。その後で、再構成プロセスを再度実行してみてください。

BAM固有の問題点の解決に関する詳細は、「失敗したOracle BAMアップグレードからのリカバリ」を参照してください。

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

ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラー

アップグレード・アシスタントでUMS構成ファイルの自動コピーに失敗した場合は、UMSをアップグレードする前に、アップグレードを停止して構成ファイルを手動でコピーする必要があります。この手順は、アップグレード・アシスタントで構成ファイルの自動コピーが失敗した場合、または構成ファイルを手動でコピーした場合のみ必要です。

この項では、UMSを11gから12cにアップグレードする際にリモートの管理対象サーバー・ノードから管理サーバーにコピーされる、UMS構成ファイルの場所について説明します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、リモート構成ファイルは、アップグレード・アシスタントにより自動的にコピーされます。Upgrade Assistantを使用した構成ファイルのコピーの詳細は、Upgrade AssistantによるアップグレードのUpgrade Assistantによりアップグレード可能な構成の識別に関する項を参照してください。

ただし、Upgrade Assistantでファイルの場所を特定できない場合は、リモートの管理対象サーバーからアップグレードを実行している管理サーバー上の同じ場所に、構成ファイルをコピーする必要があります。コピーする必要がある構成ファイルには、UMSサーバー構成ファイル(appconfig.xml)、ドライバの構成ファイル(driverconfig.xml)およびユーザー・プリファレンス・ファイル(businessterms.xml)などがあります。表A-1に示すように、これらのファイルは各管理対象サーバーの/applicationsフォルダにあります。

管理対象サーバーから管理サーバーに構成ファイルを手動でコピーした後に、アップグレード・アシスタントを再度実行する必要があります。

表A-1 構成ファイルの場所

構成ファイル 場所

UMSサーバー(appconfig.xml)

 DOMAIN_HOME/config/fmwconfig/servers/MANAGED_SERVER_NAME/applications/usermessagingserver/configuration/appconfig.xml

ドライバの構成(driverconfig.xml)

 DOMAIN_HOME/config/fmwconfig/servers/MANAGED_SERVER_NAME/applications/usermessagingdriver-DRIVER_NAME/configuration/driverconfig.xml

ユーザー・プリファレンス(businessterms.xml)

DOMAIN_HOME/config/fmwconfig/servers/MANAGED_SERVER_NAME/applications/usermessagingserver/configuration/businessterms.xml

ノート:

ドメイン内に複数のドライバがデプロイされている場合は、すべてのドライバの構成ファイルをコピーしていることを確認してください。DRIVER_NAMEを、ドメインにデプロイされているすべてのドライバ名で置き換えて確認できます。

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

12c (12.1.3または12.2.1.0)から12c (12.2.1.3.0)へのアップグレード中のOWSMデータ・ソース接続の失敗

Upgrade Assistant実行時に「ドメインによって使用されるすべての構成」を選択すると、アップグレードは調査フェーズで失敗する可能性があります(WSMERROR-00015エラー)。このエラーは、アップグレード前のドメインがマルチ・データソース接続で作成されている場合に発生します。

エラー・メッセージ

[2015-09-22T10:46:54.552-07:00] [WSM] [INCIDENT_ERROR] [upgrade.WSM.WSMPLUGIN]oracle.ias.update.exception.UpgradeException: WSMERROR-00015: Failed to read the Oracle WSM datasource connection details.at oracle.wsm.lifecycle.upgrade.impl.WSMUpgradePlugin.initializePluginData(WSMUpgradePlugin.java:396)

12c (12.2.1.3.0)にアップグレードする場合、Upgrade Assistantは汎用データソース接続を必要とします。調査フェーズの間にこのエラーが検出された場合は、前に戻って問題を修正し、バックアップからリストアすることなく、アップグレードを続行できます。

アップグレードを完了するには、次のステップを実行します。

  1. Upgrade Assistantでデータソース画面に戻ります。

  2. "mds-owsm"データ・ソースを汎用データ・ソースに変更します。

  3. Upgrade Assistantを再起動し、要求されたら「ドメインによって使用されるすべての構成」を選択します。

  4. アップグレードに成功したら、"mds-owsm"データ・ソースをマルチDSに戻すことができます。

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

失敗したBAMアップグレードのトラブルシューティング

Oracle Business Activity Monitoring (BAM)を含むドメインをアップグレードする場合、追加のBAM固有のトラブルシューティング手順があります。

詳細は、「失敗したOracle BAMアップグレードからのリカバリ」を参照してください。

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

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

12c (12.2.1.3.0)にアップグレードした後、アップグレードしたSOA JMSモジュールにEDNTopicがない場合があります。JMSモジュールにEDNTopicがない場合は、管理コンソールまたは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スキーマは含まれません。

soa_mft.pngの説明が続きます
図soa_mft.pngの説明

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

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

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

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

12cへのアップグレード後のOWSM起動エラー

アップグレード前にEnterprise Manager 11gに構成されたカスタムのトラスト・キーストアがあった場合、OWSMの起動で問題が発生する場合があります。

具体的には、OWSMを実行している11gドメインを12cにアップグレードした後に、OWSMサーバー・ログ(2回目の起動後)に次のエラーが発生した場合、この問題を手動で修正する必要があります。

<Error> <HTTP> <srvgdysoap01.nov.com> <wls_wsm1> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <26c804bb-15a7-46de-a81e-82565fcd2f28-00000004> <1418929621034> <BEA-101216> <Servlet: "PolicyManagerValidator" failed to preload on startup in Web application: "/wsm-pm".

wsm-pmアプリケーションが起動しない場合、次のステップを実行する必要があります。

  1. バックアップ・ファイルをリストアすることで、11gへのアップグレードをロールバックします。

  2. Upgrade Assistantを使用してアップグレード・ステップをもう一度実行します。

  3. OWSMサーバーを起動します

    ノート:

    OWSMサーバーは、一度のみ起動し、そのまま実行させておくことが非常に重要です。それを停止して再起動すると、NPEが現れ、再びロールバックする必要が生じます

  4. <domain_home>/oracle_common/common/bin場所から実行中のOWSMサーバーに対して、次のWLSTコマンドを実行します。

    exportMetadata('wsm-pm','<wsm server>','location to write the zip')
 
where <wsm_server> is the name of the WLS server running OWSM ('wsm_server1' for example)

  5. MDSアーカイブを抽出し、/configuration/WLS/に移動して、そこでファイルを開きます。ファイル名はドメインの名前です。

  6. 文字列「keystore.inst.0」を含んでいるプロパティ・エントリを検索します。おそらく、次のようなものがいくつか続けて見つかります

    <orares:property ........</orares:property>

  7. これらのプロパティをファイルから削除します。

  8. アーカイブを再構築して、次のコマンドを使用して、実行中のサーバーにそれをインポートして戻します。

    importMetadata('wsm-pm','<wsm server>','location of zip')

  9. サーバーを再起動します。

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

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

再構成時に次のエラー・メッセージが返された場合は、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 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。「Java暗号化アーキテクチャOracleプロバイダのドキュメント」を参照してください。

ノート:

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

親トピック: アップグレード時の暗号化の問題

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

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

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

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

インスタンスのアップグレード後に表示されなくなるビジネス・ルールの監査証跡

デシジョン・サービス・コンポーネントのアップグレードした11gインスタンスについての監査証跡は、アップグレード後に使用できなくなります。新しい12cインスタンスの監査証跡は、これまでどおりに表示されます。

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

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)

解決方法:

  1. WebLogic Serverコンソールにログインします。

  2. 「サーバー」に移動します。

  3. 管理対象サーバー(SOAやOSBなど)を検索します。

  4. 「リスニング・アドレス」をlocalhostから127.0.0.1に変更するか、実際のマシン名を指定します。

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

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

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

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

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

リモート・クライアントを介したServerSocketへの接続の失敗

Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketを作成する際の動作が変更されます。このため、hostnameがlocalhostとして構成されていると、リモート・クライアントはServerSocketに接続できなくなる可能性があります。回避策として、localhostをhostnameに変更してください。

詳細は、テクノロジ・アダプタの理解のOracleソケット・アダプタに関する項を参照してください。

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

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

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

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

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

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

SOAコンポジットの移行後にワイヤがない

11gからのアップグレード後に、サービスとリファレンスを接続するワイヤがコンポジットからなくなることがあります。この問題を解決するにはパッチを適用する必要があります。

11gからのアップグレード後に、サービスとリファレンスを接続するワイヤがコンポジットからなくなっていることに気づく場合があります。この問題は、SCAプロジェクト・マイグレータの11g JDevバージョンが新しい12cバージョンよりも高いことが原因です。これを解決するには、パッチを適用して11g SCAプロジェクト・マイグレータのバージョンを変更する必要があります。

パッチを適用するには、https://support.oracle.comに移動し、Doc ID 2356254.1を探します。

ノート:

ほとんどの場合、11g SCAプロジェクト・マイグレータは新規にインストールした12cマイグレータよりもバージョン番号が低く、この問題は発生しません。

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