Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.1.3) E57555-04 |
|
![]() 前 |
この付録では、失敗したアップグレード、ドメインの再構成やサーバー起動の問題をトラブルシューティングする場合に、共通するいくつかの手順について説明します。
リリース・ノートは、既知の問題がアップグレードに影響する可能性があるかどうかを判断するために必ず確認してください。リリース・ノートは、Oracle Fusion Middleware 12c (12.1.3)ライブラリ内にあります。
サーバーが起動しない場合やサーバーがAdminModeで起動する場合、最も可能性の高い原因は、以前の環境からのsetDomainEnv.shの変更内容が12cドメインに再適用されていないことです。11gのsetDomainEnvファイルと新しい12cのsetDomainEnvファイルを比較して、カスタムの変更をアップグレード後に追加してください。
詳細は、起動スクリプトへのカスタマイズの再適用に関する説明を参照してください。
失敗したアップグレードからのリカバリ方法は、どの時点でエラーが発生したかによって異なります。次の事項を確認して、リカバリの方法を判断してください。
アップグレード・アシスタントを実行して、_SOAINFRA
スキーマをアップグレードしているときにエラーが発生した場合は、スキーマのエラーを修正してから、バッチ・ジョブを再実行する必要があります。
このリカバリ方法は、アップグレード・アシスタントの初回実行時に、スキーマ・オプションを選択した場合にのみ適用します。
再構成ウィザードの実行中にエラーが発生した場合は、ソース環境からリストアして、アップグレードを最初からやり直す必要があります。
アップグレード・アシスタントを実行して、WebLogicコンポーネント構成オプションをアップグレードしているときにエラーが発生した場合は、エラーを修正してからアップグレード・アシスタントを再実行します。アップグレード・アシスタントの2回目の実行時には、バックアップからリストアして、アップグレード・プロセスを最初からやり直す必要ありません。このプロセスは、再入可能です。
アップグレード・アシスタントを実行してスキーマをアップグレードしているときにエラーが発生した場合、そのエラーがアップグレード・フェーズで発生したときには、バックアップからリストアして、問題を修正した後に最初からアップグレードをやり直す必要があります。ただし、調査フェーズでエラーが発生した場合は、問題を修正してアップグレード・アシスタントを再開できます。アップグレード・フェーズ前に発生したエラーは、再入可能です。
アップグレードのトラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』の一般的なトラブルシューティングのガイドラインに関する項を参照してください。
BAMアップグレードのみ: CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前にOracle BAMテンプレートの名前を変更する。」を参照)、再構成ウィザードを再度起動します。このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項の手順を実行する必要があります。その後で、再構成プロセスを再度実行してみてください。 |
この項は、BAMサーバーがドメイン内に存在する場合にのみ当てはまります。BAMアップグレードの一環として、BAMアーカイブを11gからエクスポートして、それをBAM 12cにインポートできます。このプロセス中にエラーが返された場合は、この項を使用して問題の解決にあたってください。
一般的なエラーは、データの変更内容をロール・バックして、オプションを変更したスクリプトを再実行することで解決できることがあります。
すべてのデータ変更内容のロールバック:
SOAデータベースでSQLセッションを開きます。
SOAINFRAスキーマ・ユーザーとしてログインし、次のスクリプトを実行して、すべてのデータ変更内容をロールバックします。
"<exportDir>/rollBackBPMProcessCubesMigration.sql"
使用しているオペレーティング・システムの推奨事項を確認してください。
移行時に予期しないエラーが発生した場合は、問題を修正するために次の手順を実行してみてください。
インポート・フェーズで発生したエラーの場合:
BAM 12cにアーカイブをインポートしているときにエラーが発生した場合は、「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」で説明するように、スクリプトmigrateBPMProcessCubes.shを再実行します。ただし、-importOnlyオプションを追加してください。エクスポートの手順を省略することで、時間を節約できます。
次に例を示します。
cd $ORACLE_HOME/bam/bin ./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]
エクスポート・フェーズで発生したエラーの場合:
BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。
(<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。
<exportDir>の内容を削除します。
シェル・スクリプトmigrateBPMProcessCubes.shを「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」で説明しているとおりに再実行します。ただし、-importOnlyオプションは削除してください。.
次に例を示します。
cd $ORACLE_HOME/bam/bin ./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL]
追加情報:
問題の解決を支援するために、次の作業も実行してみてください。
BAM 12cに各アーカイブをインポートした後で、$ORACLE_HOME/bam/binディレクトリにあるbamcommond.log.*ファイルを調べて、エラーが発生していないことを確認します。
<exportDir>/MigrationLogs.*にある移行のログを調べます。
前述したように、すべてのデータ変更内容をロールバックして、次を実行してみてください。
インポート・フェーズで発生したエラーの場合:
次の各項で説明しているとおりに、アーカイブを再インポートします。
エクスポート・フェーズで発生したエラーの場合:
BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。
(<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。
<exportDir>の内容を削除します。
シェル・スクリプトmigrateBPMProcessCubes.shを「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」で説明しているとおりに再実行します。ただし、-importOnlyオプションは削除してください。.
次に例を示します。
java -cp %ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar; %ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar; %ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar; %ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\bam\lib\bam-schema.jar; %ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.dataobject.jar; %ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.hwfanalytics.dataobject.jar oracle.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]
「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」の残りの移行手順を繰り返します。
OWSMに対するwsm-pmのターゲット設定を変更して、wsm-pmがアップグレード後のOWSMクラスタのみに向けてターゲット設定されたら、Oracle WebLogic Serverで、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシー・マネージャの自動検出にクロス・コンポーネント・ワイヤリング使用する方法に関する項の説明に従って、コンポーネントの再ワイヤリングが必要になります。
再構成時に次のエラー・メッセージが返された場合は、JDKに追加のポリシー・ファイルを適用して、バックアップからアップグレードを再開する必要がある可能性があります。
JPS-06513: Failed to save keystore. Reason oracle.security.jps.service.keystore.KeyStoreServiceException: Failed to perform cryptographic operation
このエラーの再発を防止するには、その後のアップグレードを実行する前に、第2.1.6項「強化された暗号化(AES 256)の使用」の情報を使用してポリシー・ファイルを適用します。
Oracle Service Busでアップグレード後の問題が発生した場合は、次の内容を確認して、関連する解決方法を適用してください。
クラスタ・ドメインのフロントエンド・ホストとしてOracle HTTP Server (OHS)を構成する場合は、OHS構成ファイル(ohs.confg)に次のコードを追加する必要があります。
<Location /sbconsole> SetHandler weblogic-handler WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT] </Location> <Location /servicebus> SetHandler weblogic-handler WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT] </Location>
ADMIN.SERVER:PORT
は、OHSに使用するマシン名、サーバー名およびポート番号です。
次のサンプル・コード内のmymachine.us.mycompany.com:7001がその例です。
<Location /sbconsole> SetHandler weblogic-handler WebLogicCluster mymachine.us.mycompany.com:7001 </Location> <Location /servicebus> SetHandler weblogic-handler WebLogicCluster mymachine.us.mycompany.com:7001 </Location>
12cより前のOSBコンソールには、URL: http://[HOST]:[PORT]/sbconsole
を使用してアクセスしていました。
12cでは、OSBコンソールのURLがhttp://[HOST]:[PORT]/servicebus
に変更されています。
アップグレード後に、http://[HOST]:[PORT]/sbconsole
と入力すると、http://[HOST]:[PORT]/servicebus
にリダイレクトされます。
リダイレクトに失敗して、HTTP 404エラーが返された場合は、12cのURL http://[HOST]:[PORT]/servicebus
を直接入力してみてください。
アップグレード・アシスタントから、指定されたドメインをアップグレードできないというエラーが返されたときには、詳細についてOracleサポートに問い合せてください。サポート対象のドメイン構成は、「ドメイン・アップグレードの制限の理解」で説明しています。
サポート対象外のドメインのスキーマやドメイン構成は、アップグレードしないでください。
デシジョン・サービス・コンポーネントのアップグレードした11gインスタンスについての監査証跡は、アップグレード後に使用できなくなります。新しい12cインスタンスの監査証跡は、これまでどおりに表示されます。
次に示す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
に変更するか、実際のマシン名を指定します。
EJBにカスタム例外が含まれているときに、EJBビジネス・サービスからWeb Service Description Language (WSDL)ファイルをエクスポートすると、生成されたWSDLファイルにはカスタム例外のプロパティが含まれなくなります。アップグレード後に、WSDLファイルを手動で編集して、該当するカスタム例外のプロパティを含める必要があります。
これは、ファイルのWSDL生成部分に限定された問題です。実行時に、EJBからスローされたカスタム例外は、SOAPフォルトのそれぞれの要素にマップされます。レスポンス・ペイロードには、カスタム例外のプロパティに対応する要素が移入されます。
Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketの作成動作が変更されます。このため、host name
がlocalhostとして構成されていると、リモート・クライアントがServerSocketに接続できない可能性があります。解決策として、localhost
をhost nameに変更してください。
詳細は、テクノロジ・アダプタの理解のOracleソケット・アダプタに関する項を参照してください。