Oracle® Fusion Middleware

SOA SuiteおよびBusiness Process Managementのアップグレード

12c (12.1.3)

E57555-04(原本部品番号:E29543-05)

2015年4月

このガイドでは、Oracle SOA Suite 11gアプリケーションをOracle SOA Suite 12cにアップグレードし、再デプロイする手順について説明します。

Oracle Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード、12c (12.1.3)

E57555-04

Copyright © 2014, 2015, Oracle and/or its affiliates.All rights reserved.

原本主著者: Lisa Jamen

原本協力著者:  Sreetama Ghosh

原本協力者: Jay Kasi、Robert Donat、Vamsee Goruganthu、Subramanian Hariharan、Suresh Krishnaswamy、William Norcott、Renga Rengarajan、Michael Rubino、Sitaraman Swaminathan

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- Fusion Middleware 12cの新機能と変更機能

1 Oracle SOA SuiteおよびBusiness Process Managementのアップグレードの概要

- 1.1 インプレース・アップグレードとアウトオブプレース・アップグレードの理解

- 1.2 SOA 12c (12.1.3)アップグレードの開始点の理解

- 1.3 アップグレード前の相互運用性および互換性の制約の理解

- 1.4 標準アップグレード・トポロジの理解

- 1.5 ドメイン・アップグレードの制限の理解

- 1.5.1 リリース11g (11.1.1.6)以前に本番へのテストで作成されたドメインのアップグレード(未サポート)

- 1.5.2 SOAおよびBAM管理対象サーバーがある非クラスタ環境のアップグレード(未サポート)

- 1.6 SOAコンポジットのアップグレードの理解

- 1.7 スキーマ・アップグレードの制約の理解

- 1.7.1 パーティション化されたスキーマ表のアップグレード(未サポート)

- 1.8 SOA SuiteおよびBPMのアップグレード・プロセス・フローの理解

2 SOA SuiteおよびBPMのアップグレード前に必要なタスクの実行

- 2.1 一般的なアップグレード前タスクの実行

- 2.1.1 本番環境の開発コピーの作成、アップグレードおよびテスト

- 2.1.2 既存のOracle Fusion Middleware 11g環境のバックアップ

- 2.1.3 データベースのバックアップ

- 2.1.4 未使用データのパージ

- 2.1.5 十分な空き領域の確保

- 2.1.6 強化された暗号化(AES 256)の使用

- 2.1.7 カスタムのsetDomainEnv設定の保持

- 2.1.8 32ビットから64ビット・オペレーティング・システムへのアップグレード

- 2.1.9 Fusion Middleware Databaseのアップグレードと準備

- 2.1.10 SOAINFRAおよびIAS_TEMP表領域へのデータファイルの追加

- 2.1.11 ユーザー・メッセージング・サービス(UMS)のアップグレード

- 2.1.12 Oracle Service Bus (OSB)を含むSOAドメインのアップグレード

- 2.1.13 スタンドアロンOracle HTTP Serverのアップグレード

- 2.1.14 アップグレード前のファイルベースのポリシー・ストアの再関連付け

- 2.1.15 Oracle Internet Directoryベースのセキュリティ・ストアの使用

- 2.1.16 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

- 2.1.17 サーバーとプロセスの停止

- 2.2 セキュリティの12.1.3へのアップグレード

- 2.3 アップグレード前の12c (12.1.3)インフラストラクチャ・ディストリビューションのインストール

- 2.3.1 WebLogic ServerおよびJRF Infrastructureのインストール

- 2.3.2 Oracle HTTP Serverのインストール

- 2.4 SOA統合ディストリビューションのインストール

- 2.5 スキーマのアップグレードの準備

- 2.5.1 スキーマ・バージョン・レジストリを使用した既存の11gスキーマの識別

- 2.5.2 アップグレード前の必要なスキーマの作成

3 SOA SuiteおよびBusiness Process Management 12c (12.1.3)のアップグレード

- 3.1 Oracle SOA SuiteおよびBusiness Process Managementのインストール

- 3.2 Oracle SOA SuiteおよびBPMに必要な12c (12.1.3)スキーマの作成

- 3.3 スキーマのアップグレード中のログ・ファイルの生成(推奨)

- 3.4 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

- 3.5 再構成ウィザードを使用したドメインの再構成

- 3.6 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- 3.7 JDeveloperプロジェクトの一括アップグレード

- 3.8 BPM Webフォームのアップグレード

- 3.9 アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

4 クラスタ化されたSOA環境のアップグレード

- 4.1 SOAクラスタ・アップグレード・トポロジの理解

- 4.2 クラスタ化トポロジでの保護されたタスク・フォームの使用

- 4.3 クラスタ化トポロジのアップグレード

- 4.4 SOAHOST2でのドメイン構成の伝播

- 4.5 クラスタのアップグレード後のタスクの実行

- 4.5.1 WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

- 4.5.2 SOAおよびOSBクラスタからのOWSMターゲットの削除

- 4.5.3 OWSMクロス・コンポーネント・ワイヤリングの更新

- 4.5.4 SOAおよびOSBクラスタからのMDS-OWSMデータ・ソースの削除

- 4.5.5 クラスタ・アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

- 4.5.6 JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

5 Oracle Business Activity Monitoring (Oracle BAM)を含むSOAのアップグレード

- 5.1 12cにおけるBusiness Activity Monitoringのアップグレードの理解

- 5.2 Oracle BAMのアップグレード前タスクの実行

- 5.2.1 アップグレード前の新しいOracle BAM 11gドメインの作成

- 5.2.2 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

- 5.2.3 Oracle BAM 11gアーティファクトの新しいOracle BAM 11gドメインへのインポート

- 5.2.4 Oracle BAM 11gドメインの完全なバックアップの作成

- 5.3 Oracle BAMドメインを含むSOAの12cへのアップグレード

- 5.4 アップグレード後の構成タスク

- 5.5Oracle BAM 12cを含むSOAドメインの拡張

- 5.5.1 11g Monitor Expressのプロセス・スター・スキーマへの移行

- 5.5.2 12cでの11g互換プロセス・スター・スキーマのデータ・ビューの生成(オプション)

6 Oracle SOAを含まないOracle Service Busのアップグレード

- 6.1 Oracle Service Busの12cへのアップグレードの理解

- 6.2 単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)

- 6.3 Oracle Service Bus (OSB)のアップグレード前タスクの実行

- 6.3.1 Oracle Service Busのスキーマの作成

- 6.3.2 11g環境へのOracle Web Services Managerポリシー・マネージャのデプロイ

- 6.3.3 Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート

- 6.3.4 すべてのサービス、プロジェクトおよびリソースの削除

- 6.4 以前のリリースからのリソースの移行

- 6.5 Oracle Service Busのインストール

- 6.6 OSBドメインのアップグレード(SOAを含まない場合)

- 6.7 OSBドメインの再構成

- 6.8 WebLogicコンポーネント構成のアップグレード

- 6.9 Oracle Service Busのアップグレード後タスクの実行

- 6.9.1 WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

- 6.9.2 ドメイン構成データのインポート

- 6.9.3 セキュリティ構成のインポート

- 6.9.4 XQueryリソースのアップグレード

- 6.9.5 Enterprise ManagerでのOracle Service Busコンソール・ユーザーの管理

- 6.9.6 12cの分割-結合の理解

7 AIAFP 11gからSOAコア拡張機能12cを含むSOAへのアップグレード

- 7.1 SOA拡張機能12c (12.1.3)へのアップグレード

- 7.2 SOAコア拡張機能のアップグレード後タスクの実行

- 7.2.1 不要なAIAユーザーおよびグループのSOAコア拡張機能からの削除(オプション)

8 アップグレード後のタスクの実行

- 8.1 アップグレード後のタスクの実行

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

- 8.1.2 setDomainEnvへのカスタマイズの再適用

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

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

- 8.1.5 アプリケーションのロールとポリシーに対するパーティション固有のロールの再作成

- 8.1.6 Javaキーストア(JKS)のOPSS KeyStore Services (KSS)への移行

- 8.1.7 サーバーの起動と停止

- 8.1.8 Enterprise Managerでのコンポジット・インスタンスの表示

- 8.1.9 Business Process Management (BPM)メタデータのアップグレード

- 8.1.10 Oracle Fusion Middleware 12c監査データ・ストアの構成

- 8.1.11 リモート・クライアントによるServerSocketのアップグレード

- 8.1.12 SOA 12cのスレッドの再構成

- 8.2 アップグレードしたコンポーネントが期待どおりに動作していることの確認

- 8.2.1 ドメイン・コンポーネント構成のアップグレードの確認

- 8.2.2 データベース・スキーマのアップグレード成功の確認

- 8.2.3 フロー・トレースの12cでの変更内容の理解

9 SOAインスタンスのアップグレードの管理と監視

- 9.1 インスタンス・アップグレードのプロセスの理解

- 9.2 インスタンス・アップグレードのバックグラウンド・ジョブの理解

- 9.3 アップグレード前のパージ・スクリプトの使用

- 9.4 アップグレード管理スクリプトの使用

- 9.4.1 アップグレード・スクリプト・メニューへのアクセス

- 9.4.2 管理スクリプトの実行

- 9.5 管理スクリプトの構成

- 9.5.1 バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)

- 9.5.2 バックグラウンド制御ジョブの有効化と無効化(オプション6)

- 9.5.3 制御ジョブ・パラメータの設定(オプション7)

- 9.5.4 エラーが発生した11gインスタンスのリセット(オプション9)

- 9.6 アップグレードのセッションとジョブの停止

- 9.7 不完全なアップグレードの再開

- 9.8 SQL問合せによるアップグレード・ステータスの監視

- 9.9 Fusion Middleware Controlによるアップグレード・ステータスの監視

- 9.9.1 データ移行の完了の確認

- 9.9.2 不完全な(停止された)アップグレードの管理

- 9.9.3 アップグレード時に失敗したインスタンスの表示

- 9.9.4 コンポジットの再デプロイ前に作成されたインスタンスの表示

- 9.10 インスタンス・アップグレードのエラーの解決

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

- A.1 リリース・ノートの確認

- A.2 サーバー起動エラーの解決

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

- A.4 失敗したBAMアップグレードからのリカバリ

- A.4.1 エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行

- A.4.2 UNIXオペレーティング・システムのエラー処理

- A.4.3 Windowsオペレーティング・システムのエラー処理

- A.5 OWSMクラスタのアップグレード後のコンポーネントの再ワイヤリング

- A.6 アップグレード時の暗号化の問題

- A.7 Oracle Service Busのトラブルシューティング

- A.7.1 クラスタのフロントエンド・ホストとしてOHSを使用するOSBのアップグレード後のHTTP 404エラー

- A.7.2 OSBコンソールへのアクセス時のHTTP 404エラー

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

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

- A.10 Coherenceキャッシュ例外の解決

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

- A.12 リモート・クライアントを介したServerSocketへの接続

はじめに

このガイドでは、Oracle SOA Suite 11gアプリケーションをOracle SOA SuiteおよびBusiness Process Management 12cにアップグレードし、再デプロイする手順について説明します。

対象読者

このドキュメントは、Oracle Fusion Middlewareのインストール、アップグレードおよび管理タスクの知識がある管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

次のドキュメントには、アップグレード前の重要な情報が記載されているため、このガイドの情報と合せて使用してください。

- Oracle Fusion Middlewareのアップグレードのプランニング

- Oracle Fusion Middlewareの理解

- 『Upgrade Assistantによるアップグレード』

- Oracle WebLogic Serverのアップグレード

- Oracle Fusion Middleware Infrastructureへのアップグレード

- スタンドアロンOracle HTTP Serverのアップグレード

- 『Oracle User Messaging Serviceの管理』

- Oracle Fusion Middleware Oracle Enterprise Repositoryアップグレード・ガイド

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次のトピックでは、Oracle Fusion Middlewareのアップグレード・ツールおよびプロセスの新機能と変更された機能を紹介しています。

また、ここではこのマニュアルについての情報と、追加情報へのポインタも提供しています。

Fusion Middleware 12cの新機能と変更された機能

SOA 12cへのアップグレードを開始する前に、Oracle Fusion Middleware 12cで利用可能な新機能と変更内容を確認してください。特に、Oracle Fusion Middlewareの理解の次の項を参照してください。

- 12c (12.1.3)の新機能と変更された機能

- 12c (12.1.3)の新しい用語と非推奨用語

- WebLogic Management Frameworkとは

- Oracle Fusion Middleware 12c (12.1.3.0.0)のSOA SuiteおよびBusiness Process Managementは、最初のSOAおよびBPM 12cリリースであり、Oracle Fusion Middleware Infrastructure 12c (12.1.3)ディストリビューションに依存しています。
注意: Oracle SOA SuiteおよびBPM 12c (12.1.3)は、Oracle Fusion Middleware Infrastructure 12c (12.1.3)に依存しています。Oracle Fusion Middleware 12c (12.1.3.0.0)のSOA SuiteおよびBusiness Process Managementにアップグレードするには、まず、Oracle Fusion Middleware Infrastructure 12c (12.1.3)をインストールする必要があります。

詳細は『Oracle Fusion Middleware Infrastructureのインストールと構成』を参照してください。

- 12cでは、Oracle Fusion Middlewareは既存の11gドメインから12cへのアップグレードに新しい再構成ウィザードを使用します。
詳細は、『Oracle WebLogic Serverのアップグレード』のドメインの再構成に関する項を参照してください。

1 Oracle SOA SuiteおよびBusiness Process Managementのアップグレードの概要

このガイドの手順は、既存の本番バージョンのSOA Suite 11gドメインと、そのドメイン内のOracle Fusion Middlewareコンポーネントの構成を、SOA SuiteおよびBusiness Process Management 12c (12.1.3)にアップグレードする方法について説明します。

注意:
Oracle SOA SuiteおよびBusiness Process Management 12c (12.1.3)にアップグレードするには、Fusion Middleware Infrastructure 12c (12.1.3)をインストールする必要があります。
SOAのアップグレードを開始する前に、Oracle Fusion Middleware Infrastructureのインストールおよび構成および『Oracle Fusion Middleware Infrastructureへのアップグレード』を参照してください。

この章の内容は次のとおりです。

- インプレース・アップグレードとアウトオブプレース・アップグレードの理解

- SOA 12c (12.1.3)アップグレードの開始点の理解

- アップグレード前の相互運用性および互換性の制約の理解

- 標準アップグレード・トポロジの理解

- ドメイン・アップグレードの制限の理解

- SOAコンポジットのアップグレードの理解

- スキーマ・アップグレードの制約の理解

- SOA SuiteおよびBPMのアップグレード・プロセス・フローの理解

注意:
使用しているSOAドメインの11gコンポーネントの一部は、Fusion Middleware 12c (12.1.3)へのアップグレードでサポートされていない可能性があります。アップグレードを開始する前に、相互運用性および互換性の理解ガイドを確認することが重要です。
詳細は、第1.3項「アップグレード前の相互運用性および互換性の制約事項の理解」を参照してください。

1.1 インプレース・アップグレードとアウトオブプレース・アップグレードの理解

SOA Suite 11g環境をSOA SuiteおよびBusiness Process Management 12c (12.1.3)にアップグレードする場合、アップグレードがアップグレード前の環境にどのような影響を与えるかを理解する必要があります。たとえば、アップグレード時に既存の11gファイルを更新するスキーマおよびドメイン・ディレクトリのアップグレードは、「インプレース」で実行されます。12c (12.1.3)のOracleホーム・バイナリは新しいディレクトリにインストールされるため、「アウトオブプレース」でアップグレードされます。

12c (12.1.3)へのアップグレードには、中間層およびスキーマが含まれます。中間層のみ、またスキーマのみのアップグレードはできません。

次のリストで、InfrastructureおよびSOA Suiteコンポーネントに、どのようにアップグレードが実行されるかについて説明します。

- Oracle WebLogic Server、JRFおよびSOA Oracleホーム・バイナリ - アウトオブプレース・アップグレード
Oracle Infrastructure 12c (12.1.3) (WebLogic ServerとJRFを含む)と、SOA SuiteおよびBusiness Process Management 12c (12.1.3)のディストリビューション・バイナリを、新しいOracleホームにインストールします。11gバイナリは上書きされないため、バイナリのアップグレードは「アウトオブプレース」と考えられます。

- スキーマ - インプレースでアップグレード
11gスキーマは12c「インプレース」でアップグレードされるため、Upgrade Assistantはアップグレード処理時にスキーマを更新および上書きします。この処理の間は、サーバーを停止する必要があります。

- インスタンス - スキーマのアップグレード中に移行
アクティブ・インスタンスおよびクローズされたインスタンスの11gから12cへのアップグレードは、スキーマのアップグレードの一環として自動的に実行されます。管理スクリプトを使用してアップグレードを管理できます。

- ドメイン・ディレクトリ再構成 - インプレースでアップグレード
既存のSOAドメインは「インプレース」でアップグレードされます。アップグレード時に、11g SOAドメインの場所を指定し、11gドメインは新しいSOA 12c (12.1.3)のホーム・ディレクトリを指すように再構成されます。

- ドメイン・コンポーネント構成 - インプレースでアップグレード
11g SOAドメインを再構成した後、アップグレード・アシスタントを再度使用して、新しいSOA 12c (12.1.3)ホーム・ディレクトリ内で、アップグレードが必要な残りのドメイン・コンポーネント構成をアップグレードします。

注意:
ドメインのアップグレードはインプレースで実行することをお薦めします。ただし、アウトオブプレース・ドメイン・アップグレードが必要な場合は、「アウトオブプレース・ドメイン・ディレクトリ・アップグレードの実行」を参照してください。

1.2 SOA 12c (12.1.3)アップグレードの開始点の理解

Oracle SOA SuiteおよびBusiness Process Management 12c (12.1.3.0.0)リリースは、12cにおけるSOAおよびBPMの最初のリリースです。次に示す製品版11gの開始点から、SOA 12c (12.1.3)にアップグレードできます。

- SOA 11g (11.1.1.7)

- SOA 11g (11.1.1.6)

- SOA 11g (11.1.1.5)以前 - サポート対象外
SOA 11g (11.1.1.5)以前を実行している場合は、まず、SOA 11g (11.1.1.6または11.1.1.7)にアップグレードしておかないと、アップグレードできません。詳細は、Oracle Fusion Middleware 11g (11.1.1.7)アップグレード・ドキュメント・ライブラリのOracle Fusion Middleware Oracle SOA Suite、WebCenter PortalおよびADFのアップグレード・ガイドを参照してください。

- Oracle Application Integration Architecture Foundation Pack 11g
現時点でOracle Application Integration Architecture Foundation Pack (AIAFP) 11gリリース1 (11.1.1.7)を実行している場合は、アップグレードを行う前に、パッチRUP 2 (17553612)および個別パッチ(18464591)以降を適用する必要があります。

Oracle Application Integration Architecture Foundation Pack 11g (11.1.1.6)を実行している場合は、RUP5 (17423167)を適用する必要があります。

1.3 アップグレード前の相互運用性および互換性の制約事項の理解

SOA SuiteおよびBPM 11gから12cへのアップグレード・プロセスを開始する前に、アップグレードが11gドメインのすべてのコンポーネントにどのような影響を与えるかを理解する必要があります。相互運用性および互換性の理解には、同時にアップグレードできるコンポーネントと、アップグレードできないコンポーネントについての詳細なマトリックスが掲載されています。通常、Oracle Fusion Middleware 12c (12.1.3)ではまだ使用できないコンポーネントを含むドメインはアップグレードできません。12c (12.1.3)にアップグレードできるコンポーネントには、別の制約もあります。これについての情報は、アップグレードを実行する前に慎重に確認する必要があります。

SOA Suiteを12c (12.1.3)にアップグレードするときの制約の一部を次に示します。これは完全なリストではありません。

- 11gドメインにWebCenterが含まれている場合:
ヒューマン・ワークフロー・タスクをポートレットとして公開するためにSOAが使用されている場合、SOAはOracle WebCenterライブラリに依存し、ドメインはアップグレードできません。Oracle WebCenter Portalは、12c (12.1.3)にアップグレードできません。今後のFusion Middlewareリリースで可能になる予定です。

- 11gドメインにOracle Service Registry (OSR)またはOracle Enterprise Repository (OER)が含まれている場合:
OSRまたはOERが含まれているドメインは12c (12.1.3)にアップグレードできません。

注意:
アップグレードを開始する前に、相互運用性および互換性の理解に記載されているアップグレードの制約事項をすべて慎重に確認してください。

1.4 標準アップグレード・トポロジの理解

このアップグレード・ドキュメントでは、2つの一般的なSOA Suite構成をアップグレードするための詳細な手順が説明されています。これらのトポロジを、Oracle Fusion Middleware 12cの標準アップグレード・トポロジと呼びます。具体的には、標準的なインストール・トポロジは、このガイドの目的に合わせて、1つの管理サーバーと1つのクラスタ(2つの管理対象サーバーが含まれている)を含む1つのWebLogic Serverドメイン、または1つのスタンドアロン・ドメインで構成されています。

スタンドアロン・ドメインは、Oracle HTTP Serverなどのシステム・コンポーネントのコンテナです。Oracle WebLogic Serverドメインに似たディレクトリ構造を持っていますが、管理サーバーや管理対象サーバーは含んでいません。スタンドアロン・ドメインには、同一タイプのシステム・コンポーネント(Oracle HTTP Serverなど)、またはタイプの混在したシステム・コンポーネントの1つ以上のインスタンスが含まれます。標準トポロジの詳細は、Oracle Fusion Middlewareの理解のスタンドアロン・ドメインに関する項を参照してください。

実際のトポロジは異なる場合がありますが、このガイドで説明するトポロジは、同様のSOA Suiteコンポーネント・トポロジをアップグレードする際の参考として使用できるサンプルを示しています。標準トポロジとエンタープライズ・デプロイメントの構築の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。

12c SOA Suiteトポロジの設定の詳細は、次を参照してください。

- Oracle SOA Suite FoundationおよびBusiness Process Managementのインストールおよび構成

- Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

1.5 ドメイン・アップグレードの制限の理解

既知の制限および以前のFusion Middlewareリリースからの構造の変更により、12c (12.1.3)にアップグレードできないドメインもあります。次の項目を確認し、ドメインがこれらの制約の影響を受けないことを確認します。これらの制約の影響を受けるドメインはアップグレードできません。

- 第1.5.1項「リリース11g (11.1.1.6)以前に本番へのテストで作成されたドメインのアップグレード(未サポート)」

- 第1.5.2項「SOAおよびBAM管理対象サーバーがある非クラスタ環境のアップグレード(未サポート)」

1.5.1 リリース11g (11.1.1.6)以前に本番へのテストで作成されたドメインのアップグレード(未サポート)

リリース11g (11.1.1.6)以前に本番へのテスト・スクリプトを使用してドメインを作成した場合、このドメインを12c (12.1.3)にアップグレードすることはできません。ドメインのスキーマをアップグレードするためにUpgrade Assistantを実行すると、Upgrade Assistantはドメインがアップグレード可能かどうかのチェックを実行します。リリース11.1.1.6以前に本番へのテスト手順で作成されたドメインは、アップグレードできません。

11.1.1.6.0以前に本番へのテストで作成したドメインがあり、そのドメインを12c (12.1.3)にアップグレードする必要がある場合、アップグレードの実行方法について、Oracleサポートに連絡してください。Upgrade Assistantを使用してこのドメイン内のスキーマをアップグレードしないでください。アップグレードが失敗するため、バックアップからリストアする必要があります。

1.5.2 SOAおよびBAM管理対象サーバーがある非クラスタ環境のアップグレード(未サポート)

この項では、12c (12.1.3)でのUMS構成に関する重要な変更点について説明します。

Oracle Fusion Middleware 11gでは、UMS構成はサーバーごとに構成されました。サーバーがクラスタ化されているどうかに関係なく、UMSサーバーは個別に機能しました。これは、すべてのサーバーを個別に構成する必要があり、構成を他のUMSサーバーと共有しないことを意味しました。ただし、高可用性システムでは2台のUMSサーバーを同じように構成できました。高可用性用のサーバーの構成の詳細は、高可用性ガイドを参照してください。

一方、12.1.3では、UMS構成はドメインまたはクラスタ全体です。構成はサーバーごとではありません。たとえば、クラスタ内のすべてのUMSサーバーは同じ構成を共有します。クラスタが使用されていない場合は、ドメイン内のすべてのUMSが同じ構成を共有します。

クラスタAに1つ(または複数)のSOAサーバーおよびクラスタBに1つ(または複数)のBAMサーバーを持つ11gクラスタ・システムをアップグレードできます。ただし、クラスタSOAサーバーおよび非クラスタBAMサーバーのアップグレードはお薦めしません。非クラスタUMSサーバーとクラスタUMSサーバーを同じドメインに混在させない必要があります。

BAMのあるドメインのアップグレードの詳細は、第5章「Oracle Business Activity Monitoring (Oracle BAM)を含むSOAのアップグレード」を参照してください。

ユーザー・メッセージング・サービスのアップグレードの詳細は、『Oracle User Messaging Serviceの管理』のユーザー・メッセージング・サービスの11gから12cへのアップグレードに関する項を参照してください。

クラスタ作成の詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。

1.6 SOAコンポジットのアップグレードの理解

Oracle 12c (12.1.3)へのSOAコンポジットのアップグレードを実行すると、アップグレード後の環境のアーティファクトに次のような変更が見られます。これはアップグレード後の変更についての完全なリストではありませんが、重要な変更点のいくつかを識別しています。

注意:
SOA 11gのコンポジットは、12c (12.1.3)へのアップグレード後に引続き機能します。アップグレード後に変更を加える必要はありません。この項では、アップグレード後の環境での変更点について説明します。

- アプリケーション・レベルでの変更

- 新しいアプリケーション・レベルのpom.xmlファイルが作成されます。このファイルは、Mavenの統合に使用できます。

- <application>.jwsファイルが新しいバージョンに更新されます。
次に例を示します。

<value n="oracle.ide.model.Project" v="11.1.1.1.0;12.1.3.0.0"/>

- プロジェクト・レベルでの変更

- 新しい12cアーティファクトのための新しい(空の)フォルダ構造が作成されます。11gコンポジットのアーティファクトは、アップグレード後に引続き11gフォルダ構造に存在し、新しいアーティファクトは、11g(または12c)の同じ構造内に作成されます。
たとえば、アップグレード後に新しいアーティファクトを追加した場合は、新しい12cディレクトリ構造にファイルが作成されます。

/SOA
WSDLs
Schema
Transformations
Events

- 新しいプロジェクト・レベルのpom.xmlファイルが作成されます。このファイルは、Mavenの統合に使用できます。

- <project>.jwsファイルが新しいバージョンに更新されます。
次に例を示します。

<value n="oracle.ide.model.Project" v="11.1.1.1.0;12.1.3.0.0"/>

- <project>.jprは、新しい適用可能なテクノロジに更新されます。
次に例を示します。

<hash n="oracle.ide.model.TechnologyScopeConfiguration">
<list n="technologyScope">
<string v="Maven"/>
<string v="SOA"/>
<string v="WSDL"/>
<string v="WSPolicy"/>
<string v="XML"/>
<string v="XML_SCHEMA"/>
</list>
</hash>

- <project>.jprは、新しいマイグレータ・バージョンに更新されます。
次に例を示します。

<value n="oracle.jbo.dt.jdevx.deployment.JbdProjectMigrator" v="11.1.1.1.0;11.1.2.0.0"/>

- コンポジット・レベルでの変更

- Composite.xmlは、元のバージョンおよびバージョン属性で更新されます。
次に例を示します。

<property name="originalProductVersion" type="xs:string" many="false">11.1.1.9.0</property>

<property name="productVersion" type="xs:string" many="false">12.1.3.0.0</property>

- componentTypeファイルは、12cでは使用されません。Composite.xmlファイルに、対応するエントリが作成されます

1.7 スキーマ・アップグレードの制約の理解

スキーマ表の構成の中には、このガイドで説明する標準のアップグレード手順を使用してアップグレードできないものがあります。スキーマをアップグレードする前に、次の制約を確認してください。

1.7.1 パーティション化されたスキーマ表のアップグレード(未サポート)

SOAスキーマ表がパーティション化されている場合に、12c (12.1.3)へアップグレードするときは、Oracleサポートに手順について問い合せてください。

パーティション化されたスキーマ表は、このガイドで説明する標準のアップグレード手順ではアップグレードできません。

1.8 SOA SuiteおよびBPMのアップグレード・プロセス・フローの理解

この項では、Oracle Fusion Middleware SOA Suiteをアップグレードする手順の概要について説明します。

表1-1 Oracle SOA Suiteのアップグレード・タスクの説明

手順

説明

詳細

1

アップグレードを開始する前に、Oracle Fusion Middleware 12cコンセプト・ガイドとアップグレードのプランニング・ガイドを確認します。

これらのガイドには、Fusion Middleware12cへのアップグレードに関する重要な情報が記載されています。12cで新しく変更された用語と、新しい要件を理解する必要があります。

Oracle Fusion Middlewareの理解を参照

『Oracle Fusion Middlewareのアップグレードのプランニング』を参照

相互運用性および互換性の理解を参照

2

既存のSOA 11g環境をバックアップします。なんからの理由でアップグレードに失敗した場合は、環境をバックアップからリストアする必要があります。

「既存のOracle Fusion Middleware 11g環境のバックアップ」を参照

3

必須の標準アップグレード前タスクすべてと、アップグレードするコンポーネントに対するコンポーネント固有のアップグレード前タスクを実行します。

「SOA SuiteおよびBPMに必要なアップグレード前タスクの実行」を参照

注意: 一般的なアップグレード前タスクに加え、各製品には、コンポーネント固有のアップグレード・タスクが存在することがあります。これについては、コンポーネント固有の章で説明しています。

4

11gのポリシー・ストアがファイルベースの場合は、アップグレードの前に、データベース・ベースのポリシー・ストアに再関連付けする必要があります。

ポリシー・ストアがすでにデータベース・ベースの場合は、次の手順に進んでください。

「アップグレード前のファイルベースのポリシー・ストアの再関連付け」を参照

Oracle Internet Directoryベースのストアを使用する場合は、「Oracle Internet Directoryベースのセキュリティ・ストアの使用」を参照

注意: ポリシー・ストアの再関連付けが完了したら、アップグレードを続行する前に、別のバックアップを実行することをお薦めします。

5

Fusion Middleware Infrastructure 12c (12.1.3)を、11g本番デプロイメントと同じホストの新しいOracleホームにインストールします。

12cでは、11g Middlewareホームを表現するために、Oracleホームを使用します。12cには、Middlewareホームはありません。

『Oracle Fusion Middleware Infrastructureのインストールと構成』を参照

注意: 構成ウィザードをインストールしますが、ドメインの構成には使用しないでください。アップグレード時には、再構成ウィザードを使用します。

6

SOA SuiteおよびBusiness Process Management 12c (12.1.3)と、統合されたSOA統合ディストリビューション(Oracle HTTP Server、Oracle Service Busなど)をインストールします。

「Oracle SOA SuiteおよびBusiness Process Managementのインストール」を参照

注意: Fusion Middleware 12c (12.1.3)ディストリビューションは、アップグレードするSOA統合製品ごとにインストールする必要があります。たとえば、Oracle Service Busを含むSOA 11g環境をアップグレードする場合は、Oracle SOA SuiteおよびBPM 12c (12.1.3)ディストリビューションのほかに、Oracle Service Bus 12c (12.1.3)ディストリビューションも入手する必要があります。ディストリビューションの完全なリストは、『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。

7

11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

「サーバーとプロセスの停止」を参照

8

12c (12.1.3)リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cスキーマを新しく作成します。

「アップグレード前の必要なスキーマの作成」を参照

9

アップグレード・アシスタントを実行して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを12c (12.1.3)にアップグレードします。

「アップグレード・アシスタントを使用したSOAスキーマのアップグレード」を参照

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12.1.3環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

詳細は、「SOAインスタンスのアップグレードの管理と監視」を参照してください。

10

進行中のクローズ済インスタンスのアップグレードは、管理SQLスクリプトまたはOracle Fusion Middleware Enterprise Manager Controlを使用して管理できます。

「SOAインスタンスのアップグレードの管理と監視」を参照

11

アップグレードする11g SOAドメインにBAMが含まれている場合は、再構成ウィザードを実行する前に、アップグレード前タスクをすべて完了しておく必要があります。これらの手順を再構成ウィザードの実行前に完了していないと、アップグレードに失敗します。

「Oracle Business Activity Monitoring (Oracle BAM)を含むSOAのアップグレード」を参照

注意: 12cのBusiness Activity Monitoring (BAM)は完全に再設計されており、ドメインの再構成前とアップグレードの後に追加の手順が必要になります。

10

再構成ウィザードを実行して、ドメインとノード・マネージャを再構成します。

「再構成ウィザードを使用したドメインの再構成」を参照

11

アップグレード・アシスタントを(再度)実行して、ドメイン構成をアップグレードします。

「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」を参照

12

必要なアップグレード後のタスクを実行します。

「アップグレード後タスクの実行」を参照

13

管理サーバーと管理対象サーバーおよびノード・マネージャを起動します(必要な場合)。

「サーバーの起動と停止」を参照

14

アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

「ドメイン・コンポーネント構成のアップグレードの確認」を参照

2 SOA SuiteおよびBPMに必要なアップグレード前タスクの実行

この章では、ほとんどのアップグレードで必要になるアップグレード前タスクについて説明します。製品固有のアップグレード前タスクについては、このドキュメントの他の章で説明します。

- 第2.1項「一般的なアップグレード前タスクの実行」

- 第2.2項「セキュリティの12.1.3へのアップグレード」

- 第2.3項「アップグレード前の12c (12.1.3) Infrastructureディストリビューションのインストール」

- 第2.4項「SOA統合ディストリビューションのインストール」

- 第2.5項「スキーマのアップグレードの準備」

注意:
アップグレードするOracle SOA 11g製品によっては、追加のアップグレード前タスクを実行する必要がある場合があります。
この章で説明するタスクは、SOA SuiteおよびBPM 12c (12.1.3)にアップグレードするときに必要となる、一般的なアップグレード前タスクです。アップグレードする製品ごとに、製品固有のアップグレードに関する章を確認して、アップグレードに追加のタスクが必要かどうかを判断してください。

- 第5章「Oracle Business Activity Monitoring (Oracle BAM)を含むSOAのアップグレード」

- 第6章「Oracle SOAを含まないOracle Service Busのアップグレード」

- 第7章「AIAFP 11gからSOAコア拡張機能12cを含むSOAへのアップグレード」

2.1 一般的なアップグレード前タスクの実行

この項では、12c (12.1.3)にアップグレードするSOA、Business Process Managementまたは統合製品に適用するアップグレード前のタスクについて説明しています。各自の環境に当てはまるタスクのみを実行してください。

注意:
アップグレードの準備を適切に行わないことが、リカバリ不能なエラーやアップグレードの失敗につながります。アップグレードの開始前に、該当するすべてのアップグレード前タスクが完了していることを確認してください。

一般的なアップグレード前タスクは、次のとおりです。

アップグレード前タスク

詳細

注意: 実際の本番環境をアップグレードする前に、本番環境のクローン・コピーでアップグレードを実行することを強くお薦めします。

第2.1.1項「本番環境の開発コピーの作成、アップグレードおよびテスト」

アップグレード前の手順を開始する前に、既存の環境の完全なバックアップを作成します。

第2.1.2項「既存のOracle Fusion Middleware 11g環境のバックアップ」

アップグレードする前に、スキーマ・リポジトリをホストしているデータベースをバックアップします。

第2.1.3項「データベースのバックアップ」

アップグレードを開始する前に11gのパージ・スクリプトを実行して、アップグレード中の停止時間を減らします。

第2.1.4項「未使用データのパージ」

十分なディスク領域があることを確認します

第2.1.5項「十分な空き領域の確保」

強化された暗号化を使用するための計画を立てます。

第2.1.6項「強化された暗号化(AES 256)の使用」

setDomainEnvファイルをバックアップします。

第2.1.7項「カスタムのsetDomainEnv設定の保持」

64ビット・オペレーティング・システムにアップグレードします。

第2.1.8項「32ビットから64ビット・オペレーティング・システムへのアップグレード」

Oracle Databaseがサポートされている(バージョン11.2.0.3以降)かどうか確認します。

第2.1.9項「Fusion Middleware Databaseのアップグレードと準備」

表領域のサイズが適切に設定されていることを確認します(不十分なサイズに設定すると、アップグレードは失敗します)。

第2.1.10項「SOAINFRAおよびIAS_TEMP表領域へのデータファイルの追加」

SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。

第2.1.11項「ユーザー・メッセージング・サービス(UMS)のアップグレード」

SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行します。

第2.1.12項「Oracle Service Bus (OSB)を含むSOAドメインのアップグレード」

スタンドアロンOracle HTTP Serverをアップグレードします(必要な場合)。

第2.1.13項「スタンドアロンOracle HTTP Serverのアップグレード」

ファイルベースのポリシー・ストアをデータベース・ベースのポリシー・ストアに再関連付けします。

第2.1.14項「アップグレード前のファイルベースのポリシー・ストアの再関連付け」

Oracle Internet Directoryベースのセキュリティ・ストアを使用するときのスキーマの要件を理解します。

第2.1.15項「Oracle Internet Directoryベースのセキュリティ・ストアの使用」

カスタム・アプリケーションをアップグレードする場合は、Oracle SOA SuiteまたはOracle Business Process ManagementのQuick Start for Developersをインストールします。

第2.1.16項「Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード」

アップグレード・アシスタントを起動する前に、11g FMWサーバーとプロセスをすべて停止します。

第2.1.17項「サーバーとプロセスの停止」
注意: アップグレード・アシスタントを起動する前に、soa_server1などの中間層サーバーをすべて停止する必要があります。

2.1.1 本番環境の開発コピーの作成、アップグレードおよびテスト

実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

アップグレードの導入に使用するためのテスト環境の作成の詳細は、『Oracle Fusion Middlewareの管理』のテスト環境から本番環境への移動に関する項を参照してください。

アップグレードは元に戻せません。ほとんどの場合、エラーが発生したときには、アップグレードを中止してバックアップから環境全体をリストアし、アップグレード・プロセスを最初からやり直す必要があります。潜在的なアップグレードの問題を開発環境で特定しておくと、無駄な停止時間を排除できます。

アップグレード前にクローン環境でテストを実施することにより、本番のアップグレード計画全体に適用できる重要なデータが得られます。『Oracle Fusion Middlewareのアップグレードのプランニング』には、完全なアップグレード前計画の立案と実行についての詳細な情報が記載されています。

本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。

- アップグレードに関する問題を明らかにし、修正します。

- エンドツーエンドのアップグレードを完了させる練習をします。

- アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。

- アップグレードの完了までに必要な時間を理解します。

- データベース・リソースの使用(一時表領域、PGAなど)について理解します。

2.1.2 既存のOracle Fusion Middleware 11g環境のバックアップ

SOA 11gからSOA 12.1.3へのアップグレードを実行する前に、既存の11g環境をバックアップする必要があります。

アップグレードに失敗すると、アップグレード前のバックアップから環境をリストアすることが必要になる場合があります。バックアップ戦略を計画する際には、SOAのバックアップに次のものが含まれていることを確認してください。

- スキーマ・バージョン・レジストリ表

- 製品固有のスキーマのすべて

- ドメインおよびアプリケーション・ディレクトリ

- インストーラで作成されたインベントリ・ディレクトリ

バックアップの考慮事項と手順の完全なリストは、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ戦略に関する項を参照してください。アップグレードを開始する前に、必ずこの情報を確認し、完全なバックアップを実行してください。

2.1.3 データベースのバックアップ

データベース・リポジトリをアップグレードする場合、標準の手順では、新しいデータベース・バージョンへのアップグレードを行う前にデータベースをバックアップすることを規定しています。

新しいデータベース・バージョンへのアップグレードが成功した後で、データベースを再度バックアップすることも検討してください。この方法により、新しくアップグレードされた状態のデータベースがバックアップに反映されます。

データベースのバックアップの詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のデータベース・アップグレードのバックアップ計画に関する項を参照してください。

2.1.4 未使用データのパージ

アップグレード前に未使用のデータをパージすることで、新しい12cデプロイメントにアップグレードするインスタンス、フォルト・アラートまたはアダプタ・レポートの数を減らして、アップグレード・プロセスを最適化できます。クローズされたインスタンスをパージすると、アップグレードの期間を大幅に短縮できます。ただし、パージしたクローズ済インスタンスは、Enterprise Manager 12cを使用して表示や報告ができなくなります。

注意:
パージ・スクリプトの実行中は、アップグレード・アシスタントを起動しないでください。パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗します。パージ・スクリプトとアップグレード・アシスタントの併用の詳細は、第9.3項「アップグレード前のパージ・スクリプトの使用」を参照してください。

自動パージまたはパージ・スクリプトの使用方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベース成長の管理に関する項を参照してください。

注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。
詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のパージおよびパーティション化の方法の開発に関する項およびデータベース成長管理戦略の開発に関する項を参照してください。

2.1.5 十分な空き領域の確保

アップグレードを開始する前に、アップグレードを完了するための十分な空き領域を確保することをお薦めします。

一般的なアップグレードでは、次のことが推奨されます。

- 表領域の空きが25%以上である

- 一時領域の空き容量が800MB以上である

2.1.6 強化された暗号化(AES 256)の使用

Javaプラットフォームでは、主要なセキュリティ領域(暗号化、公開鍵インフラストラクチャ、認証、セキュアな通信、アクセス制御など)に広がるAPIのセットを定義しています。これらのAPIを使用すると、開発者は自分のアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。

Fusion Middleware 12.1.3で使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、これらのポリシー・ファイルをJDKに適用することをお薦めします。詳細は、次を参照してください。

Java暗号化アーキテクチャのOracleプロバイダ・ドキュメント

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

2.1.7 カスタムのsetDomainEnv設定の保持

アップグレード前にsetDomainEnvスクリプト(または他の起動スクリプト)に加えられた変更は、ドメインの再構成プロセスで再生成されるスクリプトにより上書きされます。アップグレード前に、カスタムのsetDomainEnv設定の保持(オプション)に関する項の説明に従って、別個のファイルを作成してドメインのカスタマイズを保存しておくことを検討してください。

注意:
アップグレード前に、setUserOverridesスクリプトを作成できない場合は、「setDomainEnvへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

2.1.8 32ビットから64ビット・オペレーティング・システムへのアップグレード

32ビットのオペレーティング・システムを実行している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境にアップグレードする必要があります。Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。

32ビット・システムから64ビット・システムにアップグレードする方法の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』の32ビットから64ビットへのオペレーティング・システムのアップグレードに関する項を参照してください。

2.1.9 Fusion Middleware Databaseのアップグレードと準備

Oracle SOA SuiteおよびBPM 12.1.3にアップグレードする場合のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認することが重要です。Fusion Middleware 12c (12.1.3)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。最新の情報については、常に最新のデータベースの動作保証マトリックスを参照してください。

次に示す、12c (12.1.3)の重要な変更点に注意してください。

- 12c (12.1.3)の時点では、サポートされているデータベースはOracleのみです。Oracle XEはサポートしていません。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』の12c (12.1.3)のためのOracle Databaseのアップグレードと準備に関する項を参照してください。

- このリリースのOracle Fusion Middlewareでは、バイトモードのデータベースのスキーマのみをサポートしています。スキーマがあるデータベース上のNLS_LENGTH_SEMANTICS初期化パラメータのCHARへの設定はサポートされていないため、BYTEに設定する必要があります。
NLS_LENGTH_SEMANTICSをCHARに設定すると、アップグレード・アシスタントにより、次の例外が報告されます。

JDBC SQLException - ErrorCode: 1450SQLState:72000 Message: ORA-01450: maximum key length (6398) exceeded

SQL*Plusを使用してこのパラメータの値を確認するには、次のようにshow parametersコマンドを使用します。

prompt> sqlplus "sys/<password> as sysdba"SQL> show parameters nls_length_semantics

<password>の部分は、実際のSYSユーザーのパスワードに置き換えてください。

別の方法として、次のようにV$PARAMETERビューを問い合せて値を確認することもできます。

prompt> sqlplus "sys/password as sysdba"SQL> select name,value from v$parameter;

詳細は、使用するデータベースの管理ドキュメントを参照してください。

注意:
11gでは、SOAスキーマは必須ではなかったため、データベースなしでOracle Service Busを実行することもできました。ただし、12cでは、OSB 12c (12.1.3)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。詳細は、第2.5項「スキーマのアップグレードの準備」を参照してください。

2.1.10 SOAINFRAおよびIAS_TEMP表領域へのデータファイルの追加

すべての表領域にとって重要なことですが、11g SOAINFRA表領域とIAS_TEMP表領域のサイズをアップグレードが成功するように設定することが特に重要です。アップグレードの失敗を防止するために、既存のSOAデータベース表領域に、データ・ファイルをさらに追加することをお薦めします。

2つのサンプル・コマンドを次に示します。自分のユース・ケース・シナリオに合せて、ファイルのサイズを設定してください。

SOAINFRA表領域にデータファイルを追加するには:

sysdbaとしてデータベースに接続して、次のコマンドを実行します。

alter tablespace <PREFIX>_SOAINFRA add datafile '<DB_HOME>/oradata/orcl/<New_SoaInfra_DBF_FileName>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

IAS_TEMP表領域に一時ファイルを追加するには:

sysdbaとしてデータベースに接続して、次のコマンドを実行します。

alter tablespace PREFIX_IAS_TEMP add tempfile '<DB_HOME>/oradata/orcl/<New_iastemp_dbf_filename>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

アップグレード前の表領域のサイズ設定の詳細は、『Oracle Database管理者ガイド』の データファイルの作成および表領域への追加に関する項を参照してください。

注意:
サイズ設定のエラーが原因でデータベース・スキーマのアップグレードに失敗すると、ディスク領域を追加するだけではアップグレードを再試行できません。スキーマが不整合な状態になり、「INVALID」としてマークされた可能性があります。元の、アップグレード前の環境をバックアップからリストアしないと、このエラーからはリカバリできません。

2.1.11 ユーザー・メッセージング・サービス(UMS)のアップグレード

ユーザー・メッセージング・サービスを11gから12cにアップグレードする場合は、追加のアップグレード前タスク(構成ファイルを手動で管理対象サーバーから管理サーバーにコピーするなど)を実行する必要がある場合があります。

詳細は、『Oracle User Messaging Serviceの管理』のユーザー・メッセージング・サービスのアップグレードに関する項を参照してください。

2.1.12 Oracle Service Bus (OSB)を含むSOAドメインのアップグレード

Oracle Service Busを含むSOAドメインをアップグレードする場合は、必須のアップグレード前タスクをいくつか実行する必要があります。第6.3項「Oracle Service Bus (OSB)のアップグレード前タスクの実行」を参照してください。

2.1.13 スタンドアロンOracle HTTP Serverのアップグレード

このガイドでは、Oracle WebLogic Serverドメインに「関連付けられる」ように構成されていたOracle HTTP Server 11gインスタンスをアップグレードする方法について説明します。このアップグレードは、Oracle HTTP Serverが関連付けられているドメインのアップグレード時に実行されます。

スタンドアロンOracle HTTP Serverインスタンス(11gドメインに関連付けられていないもの)をアップグレードするには、『スタンドアロンOracle HTTP Serverのアップグレード』を参照してください。

2.1.14 アップグレード前のファイルベースのポリシー・ストアの再関連付け

既存の11g環境でファイルベースのポリシー・ストアを使用している場合は、アップグレード・プロセスの開始前に、データベース・ベースのポリシー・ストアへの再関連付けが必要になります。

詳細は、次のタスクを参照してください。

- タスク1「11g OPSSおよびIAUスキーマの作成」

- タスク2「11gポリシー・ストアとデータベース・ベースのポリシー・ストアおよびOPSSスキーマとの再関連付け」

タスク1   11g OPSSおよびIAUスキーマの作成

11g Repository Creation Utilityを使用して、サポートされているDatabaseで新しい11g Oracle Platform Security Services (OPSS)および監査スキーマ(IAU)のスキーマを作成します。

11gスキーマ作成の詳細は、11gリリース1 (11.1.1.7.0)の『Oracle Fusion Middlewareリポジトリ作成ユーティリティ・ユーザーズ・ガイド』のリポジトリ作成ユーティリティの入手と実行に関する項を参照してください。

タスク2   11gポリシー・ストアとデータベース・ベースのポリシー・ストアおよびOPSSスキーマとの再関連付け

11g環境でファイル・ベースのポリシー・ストアを使用している場合、ファイル・ベースのストアをデータベース・ベースのリポジトリおよびOPSSスキーマに再関連付けします。

ファイルベース・ポリシー・ストアの再関連付けの詳細は、11gリリース1 (11.1.1.7.0)ドキュメント・ライブラリのOracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのOPSSセキュリティ・ストアの再関連付けに関する項を参照してください。

2.1.15 Oracle Internet Directoryベースのセキュリティ・ストアの使用

11gでOracle Internet Directory (Oracle Internet Directory)ベースのセキュリティ・ストアを使用している場合は、12cのリポジトリ作成ユーティリティを使用して、新しい12c OPSSスキーマを作成します。アップグレード・アシスタントで、OPSSスキーマを選択します(アップグレード・アシスタントによってOracle Internet Directoryベースのセキュリティ・ストアがアップグレードされます)。アップグレード前に、Oracle Internet Directoryベースのセキュリティ・ストアの再関連付けは必要ではありません。

注意:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためのみです。ドメインでは、アップグレード後も引続きOracle Internet Directoryベースのセキュリティ・ストアが使用されます。

2.1.16 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

カスタム・アプリケーションをSOA 11gドメインにデプロイしていた場合、アップグレード手順の実行後、アプリケーションのデプロイメントはOracle Fusion Middleware 11gでの場合と同様に機能します。

ただし、新しいOracle Application Development Framework (Oracle ADF) 12c (12.1.3)の機能を活用する場合は、Oracle SOA SuiteまたはOracle Business Process ManagementのQuick Start for Developersをダウンロードしてインストールしてください。

Quick Start for Developersディストリビューションには、Oracle JDeveloper 12c (12.1.3)と、Oracle SOA SuiteおよびOracle Business Process Managementのアプリケーションを開発するために必要な拡張機能が含まれています。

詳細は、『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』のOracle SOA SuiteのQuick Start for Developersのインストールに関する項を参照してください。

2.1.17 サーバーとプロセスの停止

アップグレード・アシスタントを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止する必要があります。これを行わないと、結果としてアップグレードが不完全になったり、障害が発生する場合があります。アップグレードは完全にオフラインで実行されます。

ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。

Oracle Fusion Middleware環境を停止する手順は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware環境の停止に関する項に記載されています。

2.2 セキュリティの12.1.3へのアップグレード

OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成してください。セキュリティ・ストアのバックアップの詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。

アップグレード手順は、アップグレードされるセキュリティ・ストアのタイプに応じて異なります。ファイル・ベース、Oracle Internet DirectoryベースまたはDBベースのセキュリティ・ストアをアップグレードできます。手順は、元の監査データ・ストアのタイプ(ファイルベースまたはDBベース)に応じて異なります。

- DBベースのセキュリティ・ストアのアップグレード

- Oracle Internet Directoryベースのセキュリティ・ストアのアップグレード

- 共有セキュリティ・ストアのアップグレード

- ファイルベースのセキュリティ・ストアのアップグレード

2.3 アップグレード前の12c (12.1.3) Infrastructureディストリビューションのインストール

Oracle SOA SuiteおよびBusiness Process Managementと、統合SOAコンポーネントには、Fusion Middleware InfrastructureおよびOracle HTTP Server (該当する場合)が必要になります。これらのディストリビューションは、Oracle SOA SuiteとBPM 12c (12.1.3)をインストールして構成する前にインストールしておく必要があります。

2.3.1 WebLogic ServerおよびJRF Infrastructureのインストール

既存のSOA 11gコンポーネントをアップグレードする前に、まず、12c (12.1.3) Infrastructureディストリビューションを使用して、Oracle WebLogic ServerとJRFをインストールする必要があります。

詳細な手順は、『Oracle Fusion Middleware Infrastructureのインストールと構成』を参照してください。

注意:
Infrastructureディストリビューションをインストールするときには、ドメインの構成に構成ウィザードを使用しないでください。11gドメインは、新しい再構成ウィザードを使用して、アップグレード・プロセスで構成します。

注意:
12c (12.1.3) Infrastructureディストリビューションのインストールを完了してから、SOA 12c (12.1.3)にアップグレードする必要があります。Oracle Fusion Middleware 12c (12.1.3)でサポートしているアプリケーション・サーバーは、Oracle WebLogic Serverのみです。
以前に12c (12.1.2)リリースを使用してInfrastructureコンポーネントをインストールおよび構成した場合は、まず、Infrastructure 12c (12.1.3)にアップグレードする必要があります。

詳細は、『Oracle Fusion Middleware Infrastructureへのアップグレード』の以前のInfrastructure 12cリリースからのアップグレードに関する項を参照してください。

2.3.2 Oracle HTTP Serverのインストール

11gのドメインに、そのドメインに関連付けられたOracle HTTP Serverインスタンスが含まれる場合は、次のマシンにOracle HTTP Server 12.1.3をインストールする必要があります。

- 11g Oracle HTTP Serverインスタンスが実行されているマシン

- 管理サーバーが実行されているマシン

Oracle HTTP Server 12.1.3のインストールの詳細は、『Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成』のOracle HTTP Serverソフトウェアのインストールに関する項を参照してください。

2.4 SOA統合ディストリビューションのインストール

12c (12.1.3)製品のディストリビューションは、アップグレードするSOA 11g統合コンポーネントごとにインストールする必要があります。

詳細は、製品固有のインストレーション・ガイドを参照してください。

- Oracle SOA Suite FoundationおよびBusiness Process Managementのインストールおよび構成

- Oracle Service Busのインストールおよび構成

- Oracle User Messaging Serviceの管理

- Managed File Transferのインストールと構成

- Oracle Event Processingのインストールと構成

- B2BおよびHealthcareのインストールおよび構成

注意:
SOA 12c (12.1.3)ディストリビューションをインストールするときには、ドメインの構成に構成ウィザードを使用しないでください。11gドメインは、新しい再構成ウィザードを使用して、アップグレード・プロセスで構成します。

2.5 スキーマのアップグレードの準備

アップグレードする前に、アップグレードする11gスキーマと、作成しておく必要があるスキーマを特定する必要があります。この項では、アップグレード用にスキーマを準備する方法について説明します。

- 第2.5.1項「スキーマ・バージョン・レジストリを使用した既存の11gスキーマの識別」

- 第2.5.2項「アップグレード前の必要なスキーマの作成」

注意:
スキーマのアップグレードの一部として、アクティブ・インスタンスおよびクローズされているインスタンスはすべて自動的にアップグレードされます。アクティブまたは進行中の11gワーク・フローのインスタンスが、アップグレード中に失われることはありません。
インスタンスをアップグレードしない場合は、アップグレード・アシスタントを起動する前に、インスタンスのアップグレードを回避する必要があります。

詳細は、第9章「SOAインスタンスのアップグレードの管理と監視」を参照してください。

2.5.1 スキーマ・バージョン・レジストリを使用した既存の11gスキーマの識別

11gのスキーマの作成にリポジトリ作成ユーティリティ(RCU)を使用した場合は、SYSTEMとして、またはDBA権限のあるその他のデータベース・ユーザーとしてデータベースに接続してから、次のSQLコマンドを使用して、すでにデータベースにインストールされているOracle Fusion Middleware 11gのスキーマのリストを確認します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

12.1.3にアップグレードできるスキーマは、バージョン11.1.1.7.xまたは11.1.1.6.xです。このリストを使用すると、ドメインのスキーマを確認でき、作成するスキーマやアップグレードする必要があるスキーマの特定に役立ちます。

Oracle Fusion Middleware 12c (12.1.3)へのアップグレードに使用できるスキーマの完全なリストは、『Upgrade Assistantによるアップグレード』のアップグレード・アシスタントでアップグレード可能なスキーマの識別に関する項を参照してください。

2.5.2 アップグレード前の必要なスキーマの作成

12.1.3.0.0コンポーネントをインストールした後、このリリースのOracle Fusion Middlewareでの使用が動作保証されている、サポートされたデータベースに新しい12cに必要なスキーマを作成する必要があります。表2-1 に、アップグレードに基づいて作成されるスキーマを示します。

表2-1 SOAおよびSOA統合製品に必要なスキーマ

アップグレードする内容

アップグレード前に作成する12cのスキーマ

SOA Suite (SOA)

Service Table (STB)

Audit Services (IAU)

注意: _STBスキーマの12.1.2バージョンを作成した場合は、そのスキーマを12.1.3にアップグレードする必要があります。

Business Process Monitoring (BPM)

SOA Suiteに必要なスキーマ

Business Activity Monitoring (BAM)

SOA Suiteに必要なスキーマ

および

WebLogic Services (_WLS)

Oracle Service Bus(OSB)

SOAインフラストラクチャ(_SOAINFRA)

Service Table (STB)

ユーザー・メッセージング(_UMS)

注意: Oracle SOAを実行せずにOracle Service Busをインストールすることは可能ですが、_SOAINFRA、_UMSおよび_STBスキーマを作成する必要があります。

詳細は、「OSBドメインのアップグレード(SOAを含まない場合)」を参照してください。

Application Integration Architecture Foundation Pack (AIAFP)

SOA Suiteに必要なスキーマ

ユーザー・メッセージング・サービス(UMS)

SOA Suiteに必要なスキーマ

『Oracle User Messaging Serviceの管理』を参照してください。

詳細は、『Oracle Fusion Middleware Infrastructureへのアップグレード』の次に関する項を参照してください。

- 作成するスキーマの決定

- リポジトリ作成ユーティリティを使用した必要なスキーマの作成

3 SOA SuiteおよびBusiness Process Management 12c (12.1.3)のアップグレード

この章では、単一ノードの本番SOA SuiteおよびBusiness Process Management 11gリリース1 (11.1.1.6または11.1.1.7)インストールを、SOA SuiteおよびBusiness Process Management 12c (12.1.3)にアップグレードする詳しい手順について説明します。

- Oracle SOA SuiteおよびBusiness Process Managementのインストール

- Oracle SOA SuiteおよびBPMに必要な12c (12.1.3)スキーマの作成

- スキーマのアップグレード中のログ・ファイルの生成(推奨)

- アップグレード・アシスタントを使用したSOAスキーマのアップグレード

- 再構成ウィザードを使用したドメインの再構成

- アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- JDeveloperプロジェクトの一括アップグレード

- BPM Webフォームのアップグレード

- アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

注意:
実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。
潜在的なアップグレードの問題をクローン環境で特定しておくと、本番環境で無駄な停止時間を排除できます。

詳細は、第2.1.1項「本番環境の開発コピーの作成、アップグレードおよびテスト」を参照してください。

3.1 Oracle SOA SuiteおよびBusiness Process Managementのインストール

既存のSOAおよびBusiness Process Management (BPM) 11gのコンポーネントをアップグレードする前に、まず、SOA SuiteおよびBusiness Process Management 12c (12.1.3)ディストリビューションをインストールする必要があります。Oracle SOA Suite FoundationおよびBusiness Process Managementのインストールおよび構成で説明されている手順に従ってください。

注意:
使用するSOAドメインに別のSOA統合コンポーネントがある場合は、それらのディストリビューションもインストールする必要があります。インストレーション・ガイドの完全なリストは、Oracle Fusion Middlewareドキュメント・ライブラリを参照してください。このドキュメントの、コンポーネント固有の章を確認して、追加のインストールに対する追加のアップグレード前の手順があるかどうかを判断してください。
インストール・プロセス中に、新しくインストールしたドメインを構成するように指示されます。ただし、アップグレードの際、SOA 12.1.3ドメインの構成に構成ウィザードは使用しないでください。構成ウィザードは新しいドメインのインストールを構成するために使用します。既存のドメインは、アップグレード中にこのガイドで後述する再構成ウィザードを使用してアップグレードします。

3.2 Oracle SOA SuiteおよびBPMに必要な12c (12.1.3)スキーマの作成

第2.5.2項「アップグレード前の必要なスキーマの作成」で説明しているように、SOA 11gからアップグレードする場合は、必要な12cスキーマを作成してからアップグレードを開始する必要があります。

具体的には、12c (12.1.3)リポジトリ作成ユーティリティ(RCU)を実行して、次のスキーマを作成します。

- Audit Servicesの_IAU (IAU_APPENDおよびIAU_VIEWER)

- Service Tableの_STB (12cで新規)

- Webの_WLF (Business Activity Monitoring (BAM) 11.1.1.6および11.1.1.7のアップグレードに必要)

注意:
Oracle Fusion Middlewareでは、バイトモードのデータベースのスキーマのみをサポートしています。スキーマがあるデータベース上のnls_length_semantics初期化パラメータのCHARへの設定はサポートされていないため、BYTEに設定する必要があります。
SQL*Plusを使用してこのパラメータの値を確認するには、次のようにshow parametersコマンドを使用します。

prompt> sqlplus "sys/<password> as sysdba"SQL> show parameters nls_length_semantics

<password>の部分は、実際のSYSユーザーのパスワードに置き換えてください。

別の方法として、次のようにV$PARAMETERビューを問い合せて値を確認することもできます。

prompt> sqlplus "sys/password as sysdba"SQL> select name,value from v$parameter;

詳細は、使用するデータベースの管理ドキュメントを参照してください。

3.3 スキーマのアップグレード中のログ・ファイルの生成(推奨)

アップグレードのトラブルシューティングを容易にするために、_SOAINFRAスキーマのアップグレード時にログ・ファイルを生成することをお薦めします。デフォルトでは、ロギングは無効になっています。

ロギングを有効化するには:

1. soainfraユーザー・ディレクトリをUPGRADE_DIRという名前で作成します。

2. set_LogLevel(1)またはALTER PROCEDURE log_debug COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE';関数を呼び出して、デバッグ・ログを有効化します。

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level>] [-logDir <log_directory>]

ログ・ファイルの生成および使用の詳細は、『Upgrade Assistantによるアップグレード』のオプションの引数を使用したアップグレード・アシスタントの起動に関する項を参照してください。

3.4 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

アップグレード・アシスタントを使用してSOAおよびBPMのスキーマとインスタンスをアップグレードするには、この項の手順に従います。

注意:
パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。
パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。

- タスク1「アップグレード・アシスタントの起動」

- タスク2「スキーマのアップグレード」

- タスク3「スキーマのアップグレードの検証」

- タスク5「無効なデータベース・オブジェクトの確認」

タスク1 アップグレード・アシスタントの起動

次の手順を実行して、アップグレード・アシスタントを起動します。

1. ディレクトリをORACLE_HOME/oracle_common/upgrade/bin (UNIXオペレーティング・システムの場合)またはORACLE_HOME\oracle_common\upgrade\bin (Windowsオペレーティング・システムの場合)に変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。
(UNIX) ./ua

(Windows) ua.bat

アップグレード・アシスタントは、次の例に示すようにロギングを有効にして実行することをお薦めします。

./ua [-logLevel <log_level>] [-logDir <log_directory>]

タスク2 スキーマのアップグレード

スキーマのアップグレード時、アップグレード・アシスタントでは表3-1に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。「Oracle SOA」を選択すると、アップグレードには_IAU、_MDS、_OPSS、_SOAINFRAおよび_UMSスキーマが含まれます。

表3-1 Upgrade Assistant画面: スキーマのアップグレード

画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

「スキーマ」を選択します。

使用可能なコンポーネント

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。たとえば、「Oracle SOA」を選択すると、アップグレードには_IAU、_MDS、_OPSS、_SOAINFRAおよび_UMSスキーマが含まれます。

注意: デフォルトでは、Oracle Platform Security Services (OPSS)とAudit Servicesのスキーマが選択されています。ほとんどのコンポーネントのアップグレードでは、これらのスキーマが必要です。これらのスキーマがアップグレードに一切不要な場合以外は、これらのオプションを選択解除しないでください。

AIAFPをアップグレードする場合は、第7章「SOAコア拡張機能12c (12.1.3)へのアップグレード」を参照してください。

ドメイン・ディレクトリ

この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。

既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてアップグレードする11gドメイン・ディレクトリに移動して選択します。

前提条件

スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。

注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。

スキーマ資格証明

この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。

1. 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

2. データベース接続の詳細を入力して、「接続」をクリックします。

3. 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。
場合によっては(_ORASDPMなど)、スキーマ・ユーザー名とパスワードを手動で入力する必要があります。

注意: UCSUMSスキーマは自動的には移入されません。ユーザーとして、接頭辞_ORASDPMを入力します。アップグレード環境ではスキーマ名に_ORASDPMが使用されますが、12c環境ではこれは_UMSスキーマと見なされます。

4. 「次へ」をクリックします。

注意:

- _OPSS、_IAU、_MDSおよび_ODIのスキーマには、昇格したログイン資格証明(AS SYSDBA)が必要です。

- スキーマ資格証明画面のタイトルは、アップグレードするスキーマに応じて変化します。たとえば、_SOAINFRAスキーマをアップグレードする場合、画面のタイトルはSOAINFRAスキーマと表示されます。

- データベースへの接続に必要なフィールドの詳細は、「ヘルプ」をクリックするか、『Upgrade Assistantによるアップグレード』のスキーマ資格証明に関する項を参照してください。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

現在のアップグレード・プロセスのステータスを確認します。

注意: この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

タスク3 スキーマのアップグレードの検証

次のSQLコマンドを使用して、schema_version_registryのスキーマ・バージョンが正しく更新されていることを検証します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。『Upgrade Assistantによるアップグレード』の表1-1「アップグレードが必要なスキーマ」を参照して、スキーマの更新されたバージョン番号が正しいことを確認します。

問合せ結果のSTATUSフィールドは、スキーマへのパッチ適用処理中は「UPGRADING」または「UPGRADED」に、処理が終了すると「VALID」になります。

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

タスク4   インスタンスのアップグレードの確認(該当する場合)

スキーマのアップグレードの一部としてインスタンスをアップグレードした場合は、インスタンスにエラーがないことを確認します。

- アップグレード・アシスタントのレポートに、アップグレード対象のインスタンスが存在しなくなったと示された場合は、アップグレード・アシスタントのUIを閉じて、残りのアップグレード手順(再構成ウィザードを起動するなど)を続行します。

- アップグレード・アシスタントのレポートに、インスタンスのアップグレード中にエラーが発生したと示されている場合は、エラーを修正してからデータベース・ジョブを再発行して、アップグレードを完了します。Report Upgrade Summary管理スクリプト(オプション1)を使用して、レポートのUPGRADE ERROR COUNTセクションを確認することもできます。詳細は、第9.10項「インスタンス・アップグレードのエラーの解決」を参照してください。

- アップグレード対象のクローズされたインスタンスが残っている場合は、アップグレード・アシスタントの終了後に、クローズされたインスタンスのアップグレードがバックグラウンドで続行されることが通知されます。アップグレード・アシスタントが完了を報告し、次のメッセージが表示されるまでは、アップグレード・アシスタントを閉じないでください。

Oracle SOA
1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.

タスク5   無効なデータベース・オブジェクトの確認

Oracle Databaseを使用している場合は、アップグレード・アシスタントを実行した後、SYSとしてデータベースに接続し、SQL*Plusから次の方法を実行することで、データベース・オブジェクトを再コンパイルしてください。

SQL>@?/rdbms/admin/utlrp.sql

これによって、アップグレード・アシスタントによってアップグレードされたデータベース・オブジェクトがコンパイルされます。

その後、次の問合せを発行して、無効なデータベース・オブジェクトがなくなったことを確認します。

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

この時点で、アップグレードしたスキーマに無効なデータベース・オブジェクトがあってはなりません。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が続く場合は、サービス・リクエストを提出します。

3.5 再構成ウィザードを使用したドメインの再構成

再構成ウィザードを使用して既存の11gドメインを再構成するには、この項の手順に従います。ドメインの再構成についての一般情報は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

- タスク1「再構成ウィザードの起動」

- タスク2「ドメインの再構成」

タスク1   再構成ウィザードの起動

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

1. ドメインが存在するシステムにログインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。

ALTER DATABASE DEFAULT EDITION = edition_name;

ここで、edition_nameは、子エディションの名前です。

4. 次のディレクトリに移動します。
(UNIX) ORACLE_HOME/oracle_common/common/bin

(Windows) ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEはOracleホーム・ディレクトリです。

5. 次のコマンドを実行します。

(UNIX) ./reconfig.sh -log=<log_file> -log_priority=ALL
(Windows) reconfig.cmd -log=<log_file> -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスに置き換えます。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLは、ログを詳細モードで出力します。

注意:
reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルト・キャッシュ・ディレクトリが無効であることを示す次のようなエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

タスク2   ドメインの再構成

再構成ウィザードでは表3-2に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

表3-2 再構成ウィザードの画面

再構成ウィザードの画面

説明および必要なアクション

ドメインの選択

既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードとJDK

ドメイン・モードは変更できません。

ドメイン内の使用するJDKを選択するか、「参照」をクリックして、使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utilityはサービス表を自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースに定義されているJDBCデータ・ソースを構成します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

警告: データ・ソースのテストに失敗した場合、その問題を修正してから次の手順に進んでください。すべてのデータ・ソースのテストがPASSのステータスを示す必要があります。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。

JDBCコンポーネント・スキーマ

各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。

注意:

- 第3.4項でアップグレードしたスキーマについて、11gスキーマの詳細を指定する必要があります。それ以外については、12.1.3スキーマの詳細を指定します。

- このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として得られる構成は、「ノード・マネージャ・タイプ」と「ノード・マネージャ構成」に選択したオプションの組合せによって異なります。

ドメインごとおよびホストごとのノード・マネージャの構成の詳細は、Oracle WebLogic Serverのノード・マネージャの管理のノード・マネージャのデフォルトの構成に関する項を参照してください。

拡張構成

この画面に表示されるカテゴリは、ドメインの構成中にドメインに選択したテンプレートで定義されているリソースによって異なります。

たとえば、SOA SuiteおよびBPMテンプレートをドメインに適用するときに、次の事項が1つ以上当てはまる場合は、「管理対象サーバー、クラスタおよびCoherence」を選択します。

- 単一のドメイン(たとえば、soa_server1やbam_server1)に複数の管理対象サーバーがある

- クラスタまたはCoherenceのデータを変更する必要がある

「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、『Oracle WebLogic Serverのアップグレード』の拡張構成に関する項を参照してください。

管理対象サーバー

ドメイン内の各管理対象サーバーのためのリスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名をhost name.company.comとして指定する必要があります

サーバーのマシンへの割当

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーはクラスタに割り当てることができないため表示されません。

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

3.6 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントを使用して追加ドメイン・コンポーネント構成をアップグレードするには、この項の手順に従います。

- タスク1「アップグレード・アシスタントの起動」

- タスク2「コンポーネント構成のアップグレード」

注意:
アップグレード・アシスタントを起動する前に、管理サーバーを起動しないでください。

タスク1   アップグレード・アシスタントの起動

次の手順を実行して、管理サーバーが実行されているホストでアップグレード・アシスタントを起動します。

1. ディレクトリをORACLE_HOME/oracle_common/upgrade/bin (UNIXオペレーティング・システムの場合)またはORACLE_HOME\oracle_common\upgrade\bin (Windowsオペレーティング・システムの場合)に変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。
UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

タスク2   コンポーネント構成のアップグレード

WebLogicコンポーネント構成のアップグレード時には、アップグレード・アシスタントでは表3-3に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。

注意: 表示される再構成ウィザードの画面は、使用している環境に基づいています。次に示す画面は、すべてが表示されない場合もあります。

表3-3 アップグレード・アシスタント画面: WebLogicコンポーネント構成のアップグレード

画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

「次へ」をクリックして続行します。

WebLogicコンポーネント

「WebLogicコンポーネント構成」を選択します。

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。アップグレードするドメインのドメイン・ディレクトリを入力してください。

「次へ」をクリックします。

OWSMポリシー・マネージャ

この画面は、11g環境に複数のWebLogic Serverドメインがある場合に、OWSMポリシー・マネージャが1つのWLSドメインのみにあり、他のドメインにはOWSMエージェントがあるときに表示されます。

Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を指定します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Upgrade Assistantによるアップグレード』のOWSMポリシー・マネージャに関する項を参照してください。

コンポーネント・リスト

この画面では、ドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。

前提条件

コンポーネント構成アップグレードの前提条件が満たされているかどうかを確認します。

UMS構成

この画面は、UMS 11g構成ファイルをホストする、リモートの管理対象サーバーがある場合に表示されます。アップグレード・アシスタントで構成ファイルにアクセスするには、これらのサーバーに資格証明を指定する必要があります。

注意: アップグレード・アシスタントでUMS構成ファイルを見つけられない場合は、それらのファイルを手動でコピーする必要があります。『Oracle Fusion Middleware Infrastructureへのアップグレード』のアップグレード・アシスタント: UMS構成ファイルのコピーに関する項を参照してください。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

アップグレード処理のステータスを確認します。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

注意:
追加の構成タスクが必要になる場合があります。
アップグレード・アシスタントによるスキーマとコンポーネント構成のアップグレードが正常に完了したら、第8章「アップグレード後のタスクの実行」のアップグレード後のタスクを実行して、コンポーネントが引き続き期待通りに機能していることを確認する必要がある場合があります。

3.7 JDeveloperプロジェクトの一括アップグレード

多数のJDeveloperプロジェクトを、JDeveloperで1つずつ開くことなく一括でアップグレードする場合は、12c OracleホームにインストールされたJDeveloper移行ツールojmigrateを使用できます。ワークスペース・ファイル名とアップグレードするワークスペースを持つファイルを指定する必要があります。

次に例を示します。

ojmigrate [option]... file...|@file

Where: file is the name of the Workspace to upgrade and @file is the file with workspaces to upgrade (one filename per line)

また、次のオプションを指定できます。

- -ade
現在のADEビューへの接続

- -dry
マイグレータの呼出しをスキップ

- -failFast
最初の失敗後に移行を停止

- -generateDefaults
アップグレード・オプションのデフォルト値を含むファイルをアップグレード・ツールに生成させる。通常、これらの生成ファイルは、migration.propertiesファイルと.jws fileです。

3.8 BPM Webフォームのアップグレード

BPM 11g (11.1.1.7.0)で開発されたほとんどのBPM Webフォームは、12cと互換性があります。少数ですが要素間に手動で空白を指定している場合があり、そのようなフォームは、12cで正しく動作しない可能性があります。これらのフォームは手動でアップグレードする必要があります。手動の操作がない場合、これらのフォームは一時停止モードになります。これらの手動によるレイアウトを使用しないフォームは、移行なしで正しく動作します。

BPM Webフォームをアップグレードするには、管理権限のあるユーザーが次のURLに移動し、プロンプトが表示されたら管理者資格証明を入力します。

http://host name:port/workflow/DefaultToDoTaskFlow/migratewebforms

このページをロードすることでアップグレードが開始され、アップグレードされたフォームが表示されます。エラーが発生した場合は、ログ・ファイルを確認し、エラーがリカバリできる場合はページのロードを再試行します。エラーがリカバリできない場合は、エラーが発生したフォームが含まれるBPMコンポジットのデプロイを試行します。

注意:
このURLは何度でも起動できますが、Webフォームを使用しているアクティブ・ユーザーがいるときにはアップグレードは実行できません。

3.9 アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

表3-4に、SOA 12.1.3へのアップグレード後に実行することが多い一般的な管理タスクを示します。また、コンポーネント固有の管理ガイドでは、アップグレード後に実行する追加の構成タスクについても説明している場合があります。

表3-4 基本的な管理タスク

タスク

説明

詳細

コンポーネントの追加のアップグレード後構成手順の実行

第8章「アップグレード後のタスクの実行」で説明しているアップグレード後のタスクに加えて、追加の構成タスクを実行して、新しくアップグレードしたコンポーネントが期待通りに機能するかどうかを確認する必要もあります。

- Oracle Fusion Middlewareの管理

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

- Oracle Service Busの管理

- Oracle User Messaging Serviceの管理

Fusion Middleware管理ツールについての学習

環境の管理に使用できる様々なツールについて学習します。

『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware管理ツールの概要に関する項を参照してください。

Secure Sockets Layer (SSL)の構成

SSLを使用してOracle Fusion Middlewareコンポーネント間にセキュアな通信を設定する方法を説明します。

『Oracle Fusion Middlewareの管理』のOracle Fusion MiddlewareにおけるSSLの構成に関する項

Oracle Fusion Middlewareの監視

Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。

『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareのモニタリングに関する項

4 クラスタ化されたSOA環境のアップグレード

この章では、クラスタ化されたSOA環境へのアップグレード・プロセスと、アップグレード後の構成タスクを実行するプロセスについて説明します。

- 第4.1項「SOAクラスタのアップグレード・トポロジの理解」

- 第4.2項「クラスタ化トポロジでの保護されたタスク・フォームの使用」

- 第4.3項「クラスタ化トポロジのアップグレード」

- 第4.4項「SOAHOST2へのドメイン構成の伝播」

- 第4.5項「クラスタのアップグレード後のタスクの実行」

4.1 SOAクラスタ・アップグレード・トポロジの理解

図4-1は、クラスタ化されたOracle SOA Suiteデプロイメントのサンプル・トポロジを示しています。このトポロジでは、SOA、Oracle Web Services Manager (OWSM)、Oracle Service Bus (OSB)およびOracle Business Activity Monitoring (Oracle BAM)が、2つのアプリケーション・ホスト(SOAHOST1とSOAHOST2)に渡る個別のクラスタに含まれています。Oracle HTTP Server、管理サーバー、Oracle Enterprise Manager Fusion Middleware Controlおよびデータベースは、両方のホストで共有されています。

この章では、特に、複数のホスト・コンピュータにスケール・アウトされた複数のWebLogic Serverクラスタが含まれているWebLogicドメインのアップグレードに必要な手順を説明します。この章の概念と手順は、ユーザー独自のOracle SOA Suite環境に適用できます。

このサンプル・トポロジのアップグレードに必要な手順は、次の項の表4-1で説明しています。

注意:
SOAを含むOracle BAMをアップグレードする場合は、第5.3項「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照してください。

図4-1 クラスタ化されたSOAのトポロジ

4.2 クラスタ化トポロジでの保護されたタスク・フォームの使用

SOAコンポジットにヒューマン・タスク・フォームが含まれている場合や、タスク・フォームが非SOAサーバーにデプロイされている場合は、アップグレード後にタスク・フォームを保護する必要があります。

タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloper Designerで作成します。『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

4.3 クラスタ化トポロジのアップグレード

表4-1は、クラスタ化された複数ホストのOracle SOA Suiteサンプル・トポロジ(図4-1)をアップグレードするために必要な手順を示しています。

表4-1 Oracle SOA SuiteおよびBPMクラスタのアップグレード・ロードマップ

タスク番号

タスク

参照先

1

アップグレード・トポロジを確認して、設定でSOAHOST1およびSOAHOST2を特定します。

「SOAクラスタ・アップグレード・トポロジの理解」を参照

2

SOAHOST1またはSOAHOST2で実行中の管理サーバー、すべての管理対象サーバーおよびノード・マネージャを停止します。

「サーバーとプロセスの停止」を参照

3

既存の環境をバックアップします。

「既存のOracle Fusion Middleware 11g環境のバックアップ」を参照

4

SOAHOST1の新しいOracleホーム・ディレクトリに、12.1.3 Infrastructure (WebLogic Server、OWSMおよびJRF)、SOA、OSBおよびBAMをインストールします。

「アップグレード前の12c (12.1.3) Infrastructureディストリビューションのインストール」および「SOA統合ディストリビューションのインストール」を参照

5

SOAHOST1で、11gデプロイメントの完全アップグレードを実行します。環境に適用するアップグレード後の構成を実行します。

「SOA SuiteおよびBusiness Process Management 12c (12.1.3)のアップグレード」を参照

関連項目:

BAMがドメインの一部に含まれる場合は、「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照

OSBがドメインの一部に含まれる場合は、「Oracle SOAを含まないOracle Service Busのアップグレード」を参照

6

SOAHOST1のドメイン構成をSOAHOST2に伝播します。

これを行うには、 SOAHOST1でドメインをパックして、それをSOAHOST2で解凍する必要があります。

「SOAHOST2へのドメイン構成の伝播」を参照

7

SOAHOST1とSOAHOST2で、管理サーバーと管理対象サーバーを起動します。

「サーバーの起動と停止」を参照

8

アップグレード後に必要なタスクを実行します。

「アップグレード後のタスクの実行」を参照してください。

4.4 SOAHOST2へのドメイン構成の伝播

SOAHOST1で単一ノードのアップグレードを完了したら、ここに示す手順を実行して、もう一方のノード(SOAHOST2)に新しくアップグレードしたファイルを伝播します。

- タスク1「管理サーバーと管理対象サーバーの1つがインストールされているサーバーでpackコマンドを実行する。」

- タスク2「前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーする。」

- タスク3「SOAHOST2の12c Oracleホームからunpackコマンドを実行する。」

タスク1   管理サーバーと管理対象サーバーの1つがインストールされているサーバーでpackコマンドを実行する。

このサンプル・トポロジの場合は、SOAHOST1で次を実行します。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.1.3ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

- デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

ORACLE_COMMON_HOME/common/bin/

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

タスク2   前の手順で作成したテンプレート・ファイルをSOAHOST2にコピーする。

次のコマンドを使用して、domainupgradetemplate.jarファイルをSOAHOST2にコピーします。

scp soadomaintemplate.jar company@SOAHOST2:12c_ORACLE_HOME/oracle_common/common/bin

タスク3   SOAHOST2の12c Oracleホームからunpackコマンドを実行する。

管理サーバーと管理対象サーバーが停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用する完全ドメインまたはドメインのサブセットを作成します。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。

サンプルのunpackコマンドのコード・スニペットを次に示します。これは例としてのみ使用します。unpackには、"-overwrite_domain=true"フラグを指定する必要がある点に注意してください。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=11g_DOMAIN_HOME -overwrite_domain=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.1.3ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

unpackの実行後、次を完了します。

1. 11gドメインからのsetDomainEnv.shスクリプトのWL_HOME、SOA_ORACLE_HOME、UMS_ORACLE_HOMEが、12cを指していることを確認します。
「setDomainEnvへのカスタマイズの再適用」を参照してください。

2. SOAHOST1とSOAHOST2のノード・マネージャ、WebLogic管理サーバーおよび管理対象サーバーを次の順序で起動します。

1. SOAHOST1とSOAHOST2で、ノード・マネージャを起動します。

2. SOAHOST1で、WebLogic管理サーバーを起動します。

3. SOAHOST1とSOAHOST2で、管理対象サーバーを起動します。

詳細は、「サーバーの起動と停止」を参照してください。管理対象サーバーを起動する順序を十分に確認してください。

サーバーを起動できない場合や、その他の技術的問題が発生した場合は、付録A「アップグレードのトラブルシューティング」を参照してください。

注意:
アップグレード時に、ノード・マネージャ構成ファイル(nodermanager.propertiesなど)が、11g_DOMAIN_HOME/wlserver_10.3/の場所から、11g_ORACLE_HOME/ domains/DOMAIN_HOME/nodemanagerの場所に移動されます。そのため、12cのノード・マネージャは、11g_DOMAIN_HOMEドメイン・ディレクトリから起動する必要があります。

4.5 クラスタのアップグレード後のタスクの実行

クラスタのアップグレードが正常に完了した後で、追加のアップグレード後構成タスクを実行する必要があります。目的のクラスタ化環境に当てはまるタスクのみを実行してください。

- WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

- SOAおよびOSBクラスタからのOWSMターゲットの削除

- OWSMクロス・コンポーネント・ワイヤリングの更新

- SOAおよびOSBクラスタからのMDS-OWSMデータ・ソースの削除

- クラスタ・アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

- JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

4.5.1 WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle Service Bus用のOracle HTTP Serverの構成に関する項を参照してください。

4.5.2 SOAおよびOSBクラスタからのOWSMターゲットの削除

12cドメインの専用クラスタにOracle Web Services Manager (OWSM)が含まれていて、そのドメインをSOAクラスタとOSBクラスタで拡張している場合は、アップグレード後に、SOAクラスタとOSBクラスタからwsm-pmのターゲット設定を手動で解除する必要があります。

SOAクラスタとOSBクラスタからowsm-pmターゲットを削除するには:

1. WebLogic Server管理コンソール12cにログインします。
ブラウザに次のURLを入力します。

http://host name:port_number/console

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

ログイン・ページが表示されます。

2. 「ドメイン構造」で「デプロイメント」を選択します。

3. 「デプロイメント」からwsm-pmを選択します。

4. 「wsm-pmの設定」で、「ターゲット」を選択します。

5. タイプが「エンタープライズ・アプリケーション」のwsm-pmコンポーネントを選択して、「ターゲットの変更」を選択します。

6. SOAクラスタとOSBクラスタの選択を解除します。

7. プロンプトが表示されたら、「はい」をクリックして変更内容を適用します。

8. 必須: wsm-pmのターゲットをOWSMクラスタのみに設定した後、「OWSMクロス・コンポーネント・ワイヤリング」の説明に従ってコンポーネントを再接続する必要があります。

4.5.3 OWSMクロス・コンポーネント・ワイヤリングの更新

「SOAおよびOSBクラスタからのOWSMターゲットの削除」で説明しているように、SOAおよびOSBクラスタからOWSMターゲットを削除した後、次に説明するようにOWSMポリシー・マネージャを再接続する必要があります。

1. 管理(admin)サーバーと1つのOWSMサーバーを起動します。
詳細は、「サーバーの起動と停止」を参照してください。

2. Oracle Enterprise Manager Fusion Middleware Control 12cコンソールにログインし、「クロス・コンポーネント・ワイヤリング」→「コンポーネント」オプションに移動します。

3. 使用可能なコンポーネントの一覧からOWSM Policy Managerを選択します。

4. 「サービス・エンド・ポイント」表から、OWSM Policy Manager t3接続エントリを選択し、「公開」をクリックします。ステータスが「同期外れ」から「公開」に変更されます。

5. 「コンポーネント・タイプ」リストからOWSM Agentを選択します。t3接続エントリを選択し、「バインド」をクリックします。

6. サービス・エンドポイントの「サービス・タイプ」がOWSM Policy Managerであることを確認します。

7. ステップ5と6を繰り返して残りのコンポーネント・タイプをバインドします。この例では、com.oracle.essとFusion Middleware Controlを選択します。

4.5.4 SOAおよびOSBクラスタからのMDS-OWSMデータ・ソースの削除

アップグレード前は、mds-owsmデータ・ソースはOWSMクラスタと管理サーバーのみに向けてターゲット設定されています。ただし、アップグレード後は、mds-owsmデータ・ソースはすべてのクラスタ(SOA、OSBおよびOWSMを含む)に向けてターゲット設定されます。

1. WebLogic Server管理コンソール12cにログインします。
ブラウザに次のURLを入力します。

http://host name:port_number/console

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

ログイン・ページが表示されます。

2. 「ロックして編集」をクリックして、ターゲットを編集します。

3. 「サービス」を選択して、「ドメイン構造」から「データ・ソース」を選択します。

4. 「mds-owsm」データ・ソースを選択して、「ターゲット」を選択します。

5. SOAクラスタとOSBクラスタの選択を解除して、データ・ソースを削除します。

6. プロンプトが表示されたら、「はい」をクリックして変更内容を適用します。

4.5.5 クラスタ・アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

SOAクラスタ・ドメインを12.1.3にアップグレードすると、アップグレードしたSOA JMSモジュールにEDNTopicがない場合があります。JMSモジュールにEDNTopicがない場合は、管理コンソールまたはWLSTを使用して、このトピックにトピックまたはUDDを手動で追加する必要があります。

EDNTopicの再適用の詳細は、管理コンソールのオンライン・ヘルプを参照してください。

4.5.6 JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

12cクラスタ・ドメインのjmsServerは、移行可能なターゲットに向けてターゲット設定されています。これは、jmsServerが個別のサーバーに向けてターゲット設定されていた、11gのデフォルト動作とは異なります。

JMSトランスポートに基づいて12cプロキシ・サービスを構成するときには、トピック分散モードをOne-Copy-Per-ApplicationまたはOne-Copy-Per-Serverに設定します。重複メッセージを防止するために、クラスタ化環境では互換性モードを使用しないでください。

5 Oracle Business Activity Monitoring (Oracle BAM)を含むSOAのアップグレード

この章では、Business Activity Monitoring (Oracle BAM)が含まれているサポート対象のOracle SOA Suite 11g環境から、新たに再設計されたOracle BAM 12cが含まれるSOA 12c (12.1.3)環境にアップグレードするプロセスについて説明します。

この章で説明するプロシージャは、次のとおりです。

- 第5.1項「12cにおけるBusiness Activity Monitoringのアップグレードの理解」

- 第5.2項「Oracle BAMのアップグレード前タスクの実行」

- 第5.3項「Oracle BAMドメインを含むSOAの12cへのアップグレード」

- 第5.4項「アップグレード後の構成タスク」

- 第5.5項「Oracle BAM 12cを含むSOAドメインの拡張」

5.1 12cにおけるBusiness Activity Monitoringのアップグレードの理解

Oracle Business Activity Monitoring (BAM) 12cは、Oracle SOA Suite 12cと併用するように完全に再設計されているため、ダイレクト・アップグレード・パスはありません。Oracle BAM 12cで使用するスキーマ、バイナリおよびディレクトリ構造は、Oracle BAM 11gで使用するものとは異なります。そのため、Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。

BAM 12cドメインで使用できるOracle BAM 11gオブジェクトのみが、データ・オブジェクト(DO)であり、エンタープライズ・メッセージ・ソース(EMS)であることを理解することも重要です。これらのオブジェクトは、手動でXMLファイルにエクスポートしてから、BAM 12cドメインにインポートする必要があります。その他のOracle BAM 11gアーティファクト(ダッシュボードなど)は、Oracle BAM 12cドメインに手動で再作成する必要があります。

Oracle BAM 11gドメインは、アップグレード後も続けて使用することをお薦めします。これにより、必要になるすべてのアーティファクトを作成およびテストする機会が得られます。そのため、Oracle BAMを含むSOAのアップグレード・プロセスを開始する前に、Oracle BAM 11gドメインを別個の場所にインストールしておくことで、ドメインの再構成中にソース・ファイルが改変されないようにすることを強くお薦めします。アップグレード後に、この新しい11gドメインを指すようにSOA 12cを構成します。これは、既存の11g Oracle BAMドメインは変更され、SOA 12cでは機能しなくなるためです。

注意:
Oracle BAMのみのドメイン(SOAのないドメイン)のアップグレードはサポートされていません。BAM専用ドメインがあり、Oracle BAM 12cへのアップグレードが必要になる場合は、新しいOracle BAM 12cドメインを作成し、データ・オブジェクトをインポートしてから、すべてのダッシュボードとアラートを再作成する必要があります。

次のフローチャートは、Oracle BAMを含むSOA 11gドメインからOracle BAM 12cを含むSOA 12cドメインへのアップグレード・プロセスの概要を示しています。

5.2 Oracle BAMのアップグレード前タスクの実行

この項のタスクは、Oracle BAM 11gを含むSOAドメインを12c (12.1.3)にアップグレードするときに実行してください。

注意:
既存の11g環境でファイルベースのポリシー・ストアを使用している場合は、アップグレード・プロセスの開始前に、データベース・ベースのポリシー・ストアへの再関連付けが必要になります。これは、標準のアップグレード前の要件であり、BAMのアップグレード前に実行する必要があります。「アップグレード前のファイルベースのポリシー・ストアの再関連付け」を参照してください。

- 第5.2.1項「アップグレード前の新しいOracle BAM 11gドメインの作成」

- 第5.2.2項「既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート」

- 第5.2.3項「新しいOracle BAM 11gドメインへのOracle BAM 11gアーティファクトのインポート」

- 第5.2.4項「Oracle BAM 11gドメインの完全なバックアップの作成」

該当するアップグレード前タスク(「SOA SuiteおよびBPMに必要なアップグレード前タスクの実行」を参照)が、すべて完了していることを確認してください。

5.2.1 アップグレード前の新しいOracle BAM 11gドメインの作成

既存のOracle BAM 11gドメインはアップグレード後も継続使用することになるため、アップグレード前にBAM 11gを新しいドメイン・ホームにインストールする必要があります。新しい(別個の) BAM 11gドメインを作成しないと、アップグレード後に機能するBAMドメインがなくなり、アーティファクトや構成の多くが失われてしまいます。

注意:
Oracle BAM 11gに別個のドメインを作成しないと、BAMアーティファクトとBAM関連の構成のみが失われます(SOAアーティファクトには影響しません)。
さらに、BAMアーティファクトを参照するコンポジット(アダプタなど)や新しいインスタンスは、実行時に失敗するようになります。

『Oracle Fusion Middleware Oracle SOA Suite and Oracle Business Process Management Suiteインストレーション・ガイド』のバージョン11.1.1.7.0のインストール手順を使用してください。

既存の11g BAM環境を保持するには、11g ICommandを使用して、Oracle BAM 11gアーティファクトのすべて(DOとEMSにかぎらず)をエクスポートして、それを新しいOracle BAM 11gドメインにインポートします。これにより、アップグレード後にも完全に機能するOracle BAM 11gドメインを用意できます。

- 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

- 新しいOracle BAM 11gドメインへのOracle BAM 11gアーティファクトのインポート

Oracle BAM 11gドメインは、アップグレードの後も継続使用できます。別の方法として、Oracle BAM 12cを含む12c SOAドメインを拡張し、11gドメインからDOとEMSアーティファクトをエクスポートして、それらを拡張したOracle BAM 12cドメインにインポートすることもできます。詳細は、「Oracle BAM 12cを含むSOAドメインの拡張」を参照してください。

5.2.2 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

新しいOracle BAM 11gドメインを新しい場所にインストールして構成したら、アップグレード前に、11g Oracle BAM ICommandユーティリティを使用して既存の(旧) Oracle BAM 11gドメインからデータをエクスポートし、そのデータを新しいOracle BAM 11gドメインにインポートする必要があります。

11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のエクスポートに関する項を参照してください。

5.2.3 新しいOracle BAM 11gドメインへのOracle BAM 11gアーティファクトのインポート

Oracle BAM 11gアーティファクト(DOとEMSにかぎらず)の完全なエクスポートXMLを作成した後で、そのXMLファイルを新しく作成したOracle BAM 11gドメインにインポートする必要があります。これにより、アップグレードとドメイン再構成の後も、完全に機能するOracle BAMドメインを維持できるようになります。

11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のインポートに関する項を参照してください。

5.2.4 Oracle BAM 11gドメインの完全なバックアップの作成

アップグレードが失敗した場合は、バックアップ・バージョンを使用して、アップグレード前の環境全体をリストアする必要があります。アップグレード・プロセスを続行する前に、Oracle BAM 11g環境全体のバックアップ・バージョンを必ず作成してください。バックアップのドメインは、第5.2.1項で作成した新しいOracle BAM 11gドメインとは異なります。

詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。

5.3 Oracle BAMドメインを含むSOAの12cへのアップグレード

この項では、Oracle BAMが含まれているSOA 11gドメインを、Oracle BAMが含まれるSOA 12c (12.1.3)ドメインにアップグレードするプロセスについて説明します。これらのタスクは、Oracle BAM 11gドメインの完全なバックアップを作成するまで実行しないでください。

- タスク1「Fusion Middleware Infrastructure 12c (12.1.3)を新しいOracleホーム・ディレクトリにインストールする。」

- タスク2「Oracle SOA SuiteおよびBusiness Process Management 12c (12.1.3)を12.1.3 Oracleホームにインストールする。」

- タスク3「サーバーおよびプロセスを停止する。」

- タスク4「12c (12.1.3)リポジトリ作成ユーティリティ(RCU)を使用してスキーマを作成する。」

- タスク5「11gスキーマのアップグレード前にOracle BAMテンプレートの名前を変更する。」

- タスク6「アップグレード・アシスタントを実行して11gスキーマをアップグレードする。」

- タスク7「再構成ウィザードを使用して11gドメインを再構成する。」

- タスク8「アップグレード・アシスタントを実行してコンポーネント構成をアップグレードする。」

タスク1   Fusion Middleware Infrastructure 12c (12.1.3)を新しいOracleホーム・ディレクトリにインストールする。

Infrastructure 12c (12.1.3)の新しいOracleホームを作成します(「WebLogic ServerおよびJRF Infrastructureのインストール」を参照)。

タスク2   Oracle SOA SuiteおよびBusiness Process Management 12c (12.1.3)を12.1.3のOracleホームにインストールする。

12c (12.1.3)のOracleホームに最新のSOAコンポーネントのバイナリを追加します(「Oracle SOA SuiteおよびBusiness Process Managementのインストール」を参照)。

タスク3   サーバーおよびプロセスを停止する。

アップグレードを開始する前に、現在実行中の11gサーバーとプロセスをすべて停止します。サーバーの停止方法の詳細は、「サーバーとプロセスの停止」を参照してください。

タスク4   12c (12.1.3)リポジトリ作成ユーティリティ(RCU)を使用してスキーマを作成する。

SOAおよびOracle BAM 12c (12.1.3)の新しいスキーマを作成することが必要になる場合があります。Oracle BAMが含まれているSOAのアップグレードでは、次に示すスキーマを作成する必要があります(事前に作成していない場合)。

- サービス表(_STB)

- 監査サービス(_IAU)

- WebLogic Services (_WLS): Oracle BAMにはOracle WebLogic Servicesスキーマが必要です(ただし、11gではOracle BAMに専用の個別のスキーマはありません)。

アップグレード用のスキーマを作成して準備する方法の詳細は、「アップグレード前の必要なスキーマの作成」を参照してください。

タスク5   11gスキーマのアップグレード前にOracle BAMテンプレートの名前を変更する。

アップグレード・アシスタントで11gスキーマをアップグレードする前に、次のOracle BAM再構成テンプレートの名前を変更する必要があります。そうしないと、アップグレードは失敗します。

この手順を完了する前に、11g Oracle BAMデータがエクスポート済になっていることを確認してください。不明な場合は、第5.2.2項を参照してください。

テンプレートは、12cのディレクトリ$ORACLE_HOME/soa/common/templates/wlsにあります。

テンプレート名

変更後の名前

oracle.bam.reconfig_template_12.1.3.jar

oracle.bam.reconfig_template_12.1.3.jar.old

oracle.bam.reconfig.template_12.1.3.jar.rename

oracle.bam.reconfig_template_12.1.3.jar

タスク6   アップグレード・アシスタントを実行して11gスキーマをアップグレードする。

アップグレード・アシスタントを使用したスキーマのアップグレードの、標準の手順に従います。詳細は、第3.4項「アップグレード・アシスタントを使用したSOAスキーマのアップグレード」を参照してください。

Oracle BAM 11gスキーマを使用するSOA SuiteおよびBPMをアップグレードする場合は、「使用可能なコンポーネント」画面(それぞれのスキーマ名がリストされる)で次のオプションを選択します。

- Oracle Platform Security Services (_OPSS)

- Oracle SOA (_SOAINFRA)

Oracle Platform Security ServicesとOracle SOAを選択した場合は、次の依存関係も選択します。

- Oracle Audit Services(_IAU)

- Oracle Metadata Services (_MDS)

- ユーザー・メッセージング・サービス(_ORASDPM)
注意: 11g _ORASDPMスキーマは、12cでは名前が_UMSに変更されています。ただし、アップグレード・アシスタントで要求された場合は、11gのスキーマ名、接頭辞_ORASDPMを入力する必要があります。スキーマ名はアップグレード・アシスタントでは変更できないため、アップグレードしたドメインのスキーマは、<接頭辞>_ORASDPMのままになります。

タスク7   再構成ウィザードを使用して11gドメインを再構成する。

Oracle BAM再構成テンプレートの名前を変更したら、再構成ウィザードを起動して、第3.5項「再構成ウィザードを使用したドメインの再構成」の手順に従います。

再構成ウィザードにより、Oracle BAM 11gアプリケーション、ライブラリ、BAMDataSource、BAMJMSSserverおよびBAMJmsSystemResourceがドメインから削除されます。

注意: アップグレード後に、Oracle BAMサーバーとクラスタを手動で削除する必要があります(「ドメインからOracle BAMサーバーおよびクラスタを削除する。」を参照)。

タスク8   アップグレード・アシスタントを実行してコンポーネント構成をアップグレードする。

ドメインの再構成が終了したら、アップグレード・アシスタントを再実行して、残りのコンポーネントの構成をアップグレードします。

詳細は、第3.6項「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」を参照してください。

5.4 アップグレード後の構成タスク

アップグレードが正常に完了したら、次のタスクを実行して、最終的にOracle BAM 12cが含まれるSOA 12cドメインを実行します。

- タスク1「管理サーバーを起動する。」

- タスク2「WebLogic Server管理コンソール12cにログインする。」

- タスク3「Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースを削除する。」

- タスク4「Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除する。」

- タスク5「ドメインからOracle BAMサーバーおよびクラスタを削除する。」

- タスク6「アップグレードされたドメインから不要なOracle BAM 11gファイルを削除する。」

- タスク7「クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーを停止する。」

- タスク8「クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの1つがインストールされたサーバーでpackコマンドを実行する。」

- タスク9「クラスタのアップグレードのみ: unpackコマンドを実行してSOAHOST1のドメイン構成をSOAHOST2にレプリケートする。」

- タスク10「SOA 12cドメインで動作するように11g Oracle BAMアダプタを構成する。」

- タスク11「管理対象サーバーを起動する。」

- タスク12「SOAドメインから既存のUMS電子メール・ドライバを削除する。」

注意:
Oracle BAM 11gを含む12c SOA環境を最初に実行することをお薦めします。環境が期待どおりに機能することを確認したら、Oracle BAM 12cを含むドメインを拡張します(第5.5項「Oracle BAM 12cを含むSOAドメインの拡張」を参照)。

タスク1   管理サーバーを起動する。

Oracle WebLogic管理サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

タスク2   WebLogic Server管理コンソール12cにログインする。

管理コンソールを表示する手順は次のとおりです。

1. ブラウザに次のURLを入力します。

http://host name:port_number/console

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

ログイン・ページが表示されます。

2. インストール時に指定したユーザー名とパスワード、作成した別の管理ユーザーのユーザー名とパスワードを使用してログインします。
Oracle WebLogic Server管理コンソールは、次の図のように表示されます。

また、Fusion Middleware Controlで、管理サーバーや管理対象サーバーなどのターゲットのホーム・ページから、管理コンソールにアクセスすることもできます。

タスク3   Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースを削除する。

ここに示す手順は、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加の手順が必要になります。

1. Oracle BAMサーバーまたはOracle BAMクラスタに向けてターゲット設定されているJMSサーバー名を特定します。複数のJMSサーバーがある場合は、Oracle BAMサーバーまたはクラスタに向けてターゲット設定されているサーバーをメモしてから、作業を進めることが重要になります。所有するUMS JMSサーバーが1つのみの場合、デフォルト名はUMSJMSServer_auto_1になります。選択したUMS JMSサーバーのターゲットが、Oracle BAMサーバーまたはOracle BAMクラスタであることを必ず確認してください。
「JMSサーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「メッセージング」→「JMSサーバー」を選択します。Oracle BAMサーバーに向けてターゲット設定されているUMSJMSServerを見つけます。

次の例では、UMSJMSServer_auto_3はOracle BAMサーバーにターゲット設定されたサーバーです。

2. Oracle BAMに向けてターゲット設定されたUMS JMSサーバー(この例では、UMSJMSServer_auto_3)のローカル・キューを削除します。
「JMSモジュールのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「JMSモジュール」を選択します。UMSJMSSystemResourceを見つけてクリックすることで、「UMSJMSSystemResourceの設定」画面にローカル(および分散)キューを表示します。この結果にフィルタを適用すると、UMS JMSサーバーにターゲット設定したキューのみを表示できます。

3. Oracle BAMクラスタのみ: Oracle BAMサーバーまたはクラスタ(この例では、UMSJMSServer_auto_3)のみをターゲットに設定した共通分散キューをすべて選択します。(タイプ「共通分散キュー」でフィルタ処理できます)。「削除」をクリックします。
注意: Oracle BAM以外のサーバー・ターゲットを含む分散キューは、削除しないでください。その他のターゲット対象サーバーがある場合は、まず、分散キューからOracle BAMサーバーを削除(ターゲット設定解除)しておく必要があります(手順4を参照)。

4. 分散キューからOracle BAMサーバーのターゲット設定を解除します(必要な場合)。
分散キューからOracle BAMサーバーのターゲット設定を解除するには、「UMSJMSSystemResourceの設定」画面で「ターゲット」タブをクリックします。Oracle BAMサーバーの横のチェックマークを削除して、「保存」をクリックします。これで、手順3の説明に従って、分散キューを安全に削除できます。

5. UMS JMSサーバーに向けてターゲット設定されているローカル・キューを削除します。
「UMSJMSSystemResourceの設定」画面で、Oracle BAMに向けてターゲット設定されているUMS JMSサーバー(UMSJMSServer_auto_3)にターゲット設定されたローカル・キューをすべて選択します(次を参照)。

6. 「削除」をクリックします。

タスク4   Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除する。

1. UMS JMSサーバーから、サブデプロイメントのリソースを削除します。
「UMSJMSSystemResourceの設定」画面(上図参照)で、「サブデプロイメント」タブをクリックします。

2. Oracle BAMに向けてターゲット設定されたUMS JMSサーバーを選択します(次の例では、UMSJMSServer_auto_3)。

3. 「削除」をクリックします。

タスク5   ドメインからOracle BAMサーバーおよびクラスタを削除する。

管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。

注意:
Fusion Middleware Controlコンソールでの移動の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle SOA SuiteおよびOracle BPM Suiteの管理のスタート・ガイドに関する項を参照してください。

1. 「JMSサーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「メッセージング」→「JMSサーバー」を選択します。

2. リストから、UMSJMSServer_auto_xを選択します。「現在のターゲット」が、Oracle BAMサーバーであることを確認します。

3. 「削除」をクリックします。

4. 永続ストアのサマリー画面に移動します(次の図を参照)。

5. リストから、UMSJMSFileStore_auto_xを選択します。(「ターゲット」が、Oracle BAMサーバーであることを確認します。)

6. 「削除」をクリックします。

7. 「クラスタのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「環境」を開き、「クラスタ」を選択します。

8. クラスタのリストで、bam_clusterを選択します。

9. 「削除」をクリックします。

10. 「サーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「環境」を開き、「サーバー」を選択します。

11. リストから、Oracle BAMサーバーを選択します。

12. 「削除」をクリックします。

タスク6   アップグレードされたドメインから不要なOracle BAM 11gファイルを削除する。

domainupdaterスクリプトを使用して、不要な11gのファイルをアップグレードしたドメインから削除します。

1. 12c管理サーバーを停止します。

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

2. SOA 12cホームからdomainupdaterスクリプトを実行して、アップグレードしたドメインから不要なレガシー11gファイルを削除します。

(UNIX) cd ORACLE_HOME/soa/bam/bin
./domainupdater.sh
Enter the 11g domain path: (ex:)/soa11g/user_projects/domains/soa_domain

(Windows) cd ORACLE_HOME\soa\bam\bin
domainupdater.cmd
Enter the 11g domain path: (ex:)\soa11g\user_projects\domains\soa_domain

3. 12c管理サーバーを再起動します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

タスク7   クラスタのアップグレードのみ: 管理および管理対象サーバーを停止する。

クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、次の手順で説明するように、packコマンドとunpackコマンドを実行する必要があります。

WebLogic Serverを停止するには:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

SOAサーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
soa_server_name admin_url

正しい順序でサーバーを停止する方法の詳細は、「サーバーの起動と停止」を参照してください。

タスク8   クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの1つがインストールされたサーバーでpackコマンドを実行する。

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

クラスタ内の別のノードにNodeManagerを含む再構成済ドメインを取り込むには、管理サーバー・マシンから管理対象packを実行して、これをリモート・ノードで解凍する必要があります。

packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

注意: packおよびunpackコマンド・ユーティリティは、アップグレード済の11gドメインを指す12cインストール・ディレクトリから実行する必要があります。

packコマンドは、管理サーバーといずれかの管理対象サーバーがインストールされているサーバーで実行します。

この例では、SOAHOST1で次を実行します。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.1.3ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

- デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

ORACLE_COMMON_HOME/common/bin/

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

タスク9   クラスタのアップグレードのみ: unpackコマンドを実行してSOAHOST1のドメイン構成をSOAHOST2にレプリケートする。

管理サーバーと管理対象サーバーがまだ停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシン上の管理対象サーバー・ドメイン・ディレクトリに使用する、完全なドメインまたはドメインのサブセットを作成します。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。

サンプルのunpackコマンドのコード・スニペットを次に示します。これは例としてのみ使用します。unpackには、"-overwrite_domain=true"フラグを指定する必要がある点に注意してください。

packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=11g_DOMAIN_HOME -overwrite_domain=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.1.3ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

タスク10   SOA 12cドメインで動作するように11g Oracle BAMアダプタを構成する。

SOA 12cドメインのアップグレードが完了したら、このSOA 12cドメインを構成して、Oracle BAM 11gドメイン(第5.2.1項「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成したドメイン)を使用するようにします。

この設定の構成方法の詳細は、11gバージョンの『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle BAMアダプタの構成に関する項を参照してください。

タスク11 管理対象サーバーを起動する。

SOAサーバーを起動するには:

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
soa_server_name admin_url

正しい順序でサーバーを停止する方法の詳細は、「サーバーの起動と停止」を参照してください。

タスク12 SOAドメインから既存のUMS電子メール・ドライバを削除する。

メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。新しいドライバは、SOA 12cドメインをOracle BAM 12cテンプレートで拡張した後に作成します。

1. 管理サーバーと、すべての管理対象サーバーがSOAドメインで実行しているときに、「ユーザー・メッセージング・サービス」に移動し、soa_serverに向けてターゲット設定されたusermessagingdriver-mailサービスを選択します。
「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで、「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

2. 「ターゲット・ナビゲーション」ペインで、「ユーザー・メッセージング・サービス」の電子メール・ドライバ名を選択します。

3. 「削除」をクリックします。

4. ドメイン内にある別のクラスタにも、このプロセスを繰り返します。

5.5 Oracle BAM 12cを含むSOAドメインの拡張

アップグレードしたSOA 12c環境でOracle BAM 12cを使用する準備が整ったら、次に示すタスクを完了する必要があります。一部のタスクはオプションです。

- タスク1「管理サーバーおよびSOA管理対象サーバーを停止する。」

- タスク2「Oracle BAM 12cドメイン・テンプレートでSOAドメインを拡張する。」

- タスク3「Oracle BAMサーバーの新しいUMS電子メール・ドライバを作成する。」

- タスク4「Oracle BAM 11gデータ・オブジェクトとEMSデータをBAM 12cサーバーにインポートする。」

- タスク5「BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトを手動で再作成する。」

- タスク6「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」

- タスク7「11g Monitor ExpressデータをBAM 12cプロセス・スター・スキーマに移行する。(オプション)」
追加のタスク(オプション):

- 第5.5.1項「11g Monitor Expressのプロセス・スター・スキーマへの移行」

- 第5.5.2項「12cでの11g互換プロセス・スター・スキーマのデータ・ビューの生成(オプション)」

タスク1   管理サーバーおよびSOA管理対象サーバーを停止する。

ドメインを拡張する前に、現在実行中の12cサーバーとプロセスをすべて停止します。

WebLogic Serverを停止するには:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

SOAサーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
soa_server_name admin_url

正しい順序でサーバーを停止する方法の詳細は、「サーバーの起動と停止」を参照してください。

タスク2   Oracle BAM 12cドメイン・テンプレートでSOAドメインを拡張する。

構成ウィザードを使用して、Oracle BAM 12cで既存のSOAドメインを拡張します。

1. 構成ウィザードを起動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin
./config.sh

(Windows) ORACLE_HOME\oracle_common\common\bin
config.cmd

2. 要求されたら、「既存のドメインの拡張」を選択します。

3. 「テンプレート」画面で、次のテンプレートを選択します。

- Oracle WSM Policy Manager - 12.1.3

- Oracle Business Activity Monitoring - 12.1.3

4. 『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のOracle SOA SuiteおよびBusiness Activity Monitoring (BAM)トポロジの構成に関する項の説明に従って、構成ウィザードの残りの画面を完了します。

注意:
SOA、OSB、BAMなど特定のFusion Middlewareコンポーネントは、12cではUMSに依存しています。単一の12.1.3ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります。第4章「クラスタ化されたSOA環境のアップグレード」の図4-1「クラスタ化されたSOAのトポロジ」を参照してください。
構成ウィザードの「拡張構成」画面に進んだら、「管理対象サーバー、クラスタおよびCoherence」を選択して、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項の説明に従い、BAMクラスタを作成します。

タスク3   Oracle BAMサーバーの新しいUMS電子メール・ドライバを作成する。

Oracle BAMサーバーがクラスタで実行されているときに、Fusion Middleware Controlコンソールを使用して、次のタスクを完了します。

1. 「電子メール・ドライバ・プロパティ」 画面に移動します。
「ターゲット・ナビゲーション」ペインで「ユーザー・メッセージング・サービス」を選択し、「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

2. 「作成」をクリックして、新しいUMS電子メール・ドライバを追加します。

3. 次に示すように、「名前」フィールドで新しい電子メール・ドライバの一意の名前を指定します。UMSは、12cドメイン内の各クラスタに対して構成する必要があります。そのため、イメージに示すように「クラスタ」として「構成レベル」のデフォルト選択を維持します。

4. デフォルトの送信者アドレスの使用を選択して、EMAIL:emailid@company.comと入力します。このフィールドには、EMAIL:という接頭辞が必須になります。

5. 「OK」をクリックして、指定したプロパティで新しいドライバを作成します。

タスク4   Oracle BAM 11gデータ・オブジェクトとEMSデータをBAM 12cサーバーにインポートする。

BAM 12cが含まれるようにドメインを拡張した後で、SOA 12cで使用しているBAM 11g環境から、データ・オブジェクトとEMSデータをエクスポートする必要があります。その後で、BAM 12cを含むSOA環境に、このデータをインポートします。

1. 11g ICommandコマンドライン・ユーティリティを使用して、データ・オブジェクトとEMSデータを11g BAMドメインからエクスポートします。(EMS定義は標準アップグレード・プロセスの一部としてアップグレードされているため、インポートする必要はありません。)
次の例では、Oracle BAMサーバーの1つ以上のオブジェクトに関する情報をXMLファイルにエクスポートする、ICommand 11gの使用方法を示しています。

$11g_ORACLE_HOME/soa/bam/bin/icommand -cmd export -name "/Samples/Call Center" -type dataobject -file C:\CallCenter.xml

注意: スクリプトを実行する前に、ICommand構成ファイルに変更を加えることが必要になる場合があります。具体的には、正しいユーザー名とパスワードが入力されていることを確認してください。BAMICommandConfig.xmlファイルは、WLS_HOME/user_projects/domains/base_domain/config/fmwconfig/servers/bam_server1/applications/oracle-bam_11.1.1/config/にあります。

構成ファイルの例を、次に示します。

<host>www.example.com</host>
<port>7001</port>
<username>weblogic</username>
<password>welcome1</password>
<dbusername>SOAINFRA</dbusername>
<dbpassword>welcome1</dbpassword>
<dburl>jdbc:oracle:thin:@localhost:1521:orcl</dburl>

11g BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のエクスポートに関する項を参照してください。

2. 12cのBAMCommandコマンドライン・ユーティリティを使用して、前述の手順で作成したXMLファイルをインポートします。
次の例は、12cのBAMCommandを使用して情報をインポートする方法を示しています。

$12c_ORACLE_HOME/soa/bam/bin/bamcommand -cmd import -file BPELOrderBookingDataObject.xml -upgrade 1 -username weblogic -port 7001 -host server.yourcompany.com

BAMCommandコマンドライン・ユーティリティを使用したデータ・ファイルのインポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のインポートに関する項を参照してください。

注意:
importコマンドを-upgradeパラメータとともに使用して、Oracle BAM 11gアーティファクトをOracle BAM 12cに移行すると、一部の情報が変更されます。
詳細は、Oracle BAMによるビジネス・アクティビティの監視のアップグレードの考慮事項に関する項を参照してください。

タスク5   BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトを手動で再作成する。

BAM 11gドメインで使用したダッシュボード、アラート、ビューなどは、BAM 12cドメインで再作成する必要があります。

BAMユーザー・ガイド、Oracle BAMによるビジネス・アクティビティの監視の、次に関する項を参照してください。

- ダッシュボードの作成

- アラートの作成

- パラメータの作成

- ビジネス・ビューの作成と使用

タスク6   11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)

アップグレード済のBPM 12cドメインをBAM 12cで拡張した後には、プロセス・キューブの移行を実行することを強くお薦めします。この移行により、BPMエンティティに必要なすべての12cデータ・オブジェクトが作成されるようになります。さらに、BPMプロセス分析データも11gプロセス・キューブから移行されるようになります(キューブ表に実行時データが移入される場合にのみ該当します)。

各アーカイブをエクスポートおよびインポートするときに、SOAINFRAスキーマのユーザー名とパスワードに加えて、サーバー管理者(admin)のユーザー名とパスワードを指定する必要があります。

注意:
プロセス・キューブの移行は、Monitor Expressの移行(タスク7を参照)を開始する前の必須の前提条件です。
この手順は、BPM 11gでOracle BAM 11g Monitor Expressを使用していなかった場合でも必要になります。

1. プロセス・メトリックを無効にします。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle SOA 12cサーバーがインストールされているドメインを選択します。
たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下のoracle.as.soainfra.configノードを開きます。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。
analytics属性がリストされます。

10. trueに設定されていない場合は、DisableProcessMetrics属性の値をtrueに変更します。

11. 「適用」をクリックします。

2. 移行に使用するexportTypeを決定します。exportTypeは、移行前に決定しておく必要があります。アクティブ・インスタンスの移行が完了して、プロセス分析が有効化されると、後戻りして完了インスタンス・データを移行できなくなってしまいます。
有効なexportTypeの値は、次のとおりです。

- INFLIGHT_WITH_DIMENSION_AND_DEFINITION (デフォルト): アクティブ・インスタンスのファクト・データ・アーカイブのみを移行します

- ALL: すべてのアクティブ・インスタンスと完了インスタンスのファクト・データ・アーカイブを移行します

3. (UNIXのみ) 12c SOAホームから、migrateBPMProcessCubesスクリプトを実行します。
migrateBPMProcessCubesシェル・スクリプトは、エクスポートとインポートの2フェーズで移行を実行します。最初のフェーズでは、次のアーカイブをBPMプロセス・キューブからエクスポートします。2番目のフェーズでは、エクスポートしたアーカイブをBAM 12cにインポートします。

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (-exportType = ALLオプションを使用して実行している場合)

UNIXオペレーティング・システムの場合:

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]

説明:

serverUrl      (mandatory) : BAM 12c Server URL
serverPort     (mandatory) : BAM 12c Server Port
serverUserName (mandatory) : BAM 12c Server  admin user
dbUrl          (mandatory) : SOA DB jdbc URL
dbUserName     (mandatory) : SOAINFRA schema username
exportDir      (mandatory) : A writable Directory where exported archives will be written
exportType     (optional ) : Export Type.  Valid values are
a)INFLIGHT_WITH_DIMENSION_AND_DEFINITION (default):  Migrates only Active instance fact data archives
b)ALL                                             :  Migrates all Active and Completed instance fact data archives
importOnly     (optional ) : If specified, data object definition and data archive export phase is skipped and only import is performed. It is assumed that archives are already present under "exportDir"

注意:
移行中にエラーが発生した場合は、手動で問題を修正して、スクリプトを再度開始する必要があります。詳細は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

4. (Windowsのみ) 11g BPMプロセス・キューブから、データ・オブジェクトの定義とデータをエクスポートして、それらを12cにインポートします。
データ・オブジェクト定義の移行は、2つの手順で実行されます。手順1では11gプロセス・キューブからデータをエクスポートし、手順2ではデータを12cにインポートします。

最初のフェーズでは、次のアーカイブをBPMプロセス・キューブからエクスポートし、2番目のフェーズでは、それらをBAM 12cにエクスポートします。後述するエクスポート・コマンドにより、次のアーカイブ・ファイルが<exportDir>ディレクトリに生成されます。

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (-exportType = ALLオプションを使用して実行している場合)

手順1: データ・オブジェクトと定義を、次のコード例を使用してエクスポートします(必ず実際のディレクトリ名を指定してください)。

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]

手順2: データ・オブジェクト定義(DefinitionExport.zip)をBAMサーバーにインポートします。

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DefinitionExport.zip> -mode update

注意: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

5. (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。(このコマンドには、-datamodeパラメータと-migrateパラメータを使用しています。)

次のコード例を使用して、ディメンション・データをインポートします。

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DimensionExport.zip>  -datamode update -migrate 1

注意: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

6. (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。(このコマンドには、-datamodeパラメータと-migrateパラメータを使用しています。)

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

7. (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。(このコマンドには、-datamodeパラメータと-migrateパラメータを使用しています。)

このコマンドは、BAM 11gプロセス・キューブのデータ・オブジェクト定義を移行したときに、exportTypeにALLを使用した場合にのみ使用します。

cd %ORACLE_HOME%\bam\bin\

run the following command
bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

注意: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

8. 移行が正常に完了したら、Oracle BAMサーバーを再起動します。

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
bam_server_name admin_url

(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
bam_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

9. Oracle BAMサーバーの実行中に、プロセス・メトリックを有効にします。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle BAMサーバーがインストールされているドメインを選択します。
たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下のoracle.as.soainfra.configノードを開きます。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。
analytics属性がリストされます。

10. DisableProcessMetrics属性の値をfalseに変更します。

11. 「適用」をクリックします。

タスク7   11g Monitor ExpressデータをBAM 12cプロセス・スター・スキーマに移行する。(オプション)

BAM 11gの履歴データをBAM 12cのプロセス分析ダッシュボードで分析できるようにするには、11g Monitor ExpressのデータをBAM 12cのプロセス・スター・スキーマに移行する必要があります。この移行手順は、第5.5.1項「11g Monitor Expressのプロセス・スター・スキーマへの移行」で説明しています。

注意:
このオプションのタスクは、BAM 11gの履歴データをBAM 12cのプロセス分析ダッシュボードから分析できるようにする場合にのみ実行します。これを行うには、BAM 11gのMonitor Expressデータ・オブジェクトの11gプロセス分析データを、BAM 12cのプロセス・スター・スキーマのデータ・オブジェクトに移行する必要があります(第5.5.1項を参照)。

5.5.1 11g Monitor Expressのプロセス・スター・スキーマへの移行

この項では、11g Monitor ExpressデータをBAM 12cプロセス・スター・スキーマに移行する場合の前提条件と手順について説明します。このプロセスの一部のタスクは、特定のコンポーネントまたはオペレーティング・システムにのみ適用されます。そのコンポーネントまたはオペレーティング・システムを使用していない場合は、その次のタスクにスキップしてください。

- タスク1「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」

- タスク2「BAM 11g Monitor ExpressスキーマからBPMデータを移行する。」

タスク1   11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)

11g Monitor ExpressのデータをBAM 12cのプロセス・スター・スキーマにアップグレードする前に、11gプロセス・キューブをBAM 12cスター・スキーマに移行して、BPMのエンティティに必要なすべての12cデータ・オブジェクトが作成されるようにする必要があります。さらに、BPMプロセス分析データも11gプロセス・キューブから移行されるようになります(キューブ表に実行時データが移入される場合にのみ該当します)。

次の手順に進む前に、「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」の手順を実行します。

タスク2   BAM 11g Monitor ExpressスキーマからBPMデータを移行する。

このオプションのタスクは、BAM 11gの履歴データをBAM 12cのプロセス分析ダッシュボードから分析できるようにする場合にのみ実行します。これを行うには、この項で説明するように、BAM 11gのMonitor Expressデータ・オブジェクトの11gプロセス分析データを、BAM 12cのプロセス・スター・スキーマのデータ・オブジェクトに移行する必要があります。

1. プロセス・メトリックを無効にします。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle BAMサーバーがインストールされているドメインを選択します。
たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下のoracle.as.soainfra.configノードを開きます。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。
analytics属性がリストされます。

10. DisableProcessMetrics属性の値をtrueに変更します。

11. 「適用」をクリックします。

2. BAM/BPM 11g移行ユーティリティを実行して、Monitor Expressデータを移行します。(データ・オブジェクトとデータ・オブジェクト定義は、「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」で移行済です。)
次のコマンドにより、BPMデータのデータ・エクスポートがzip圧縮されたCSVファイルで作成されます。

java -cp
$DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.interface.jar:
$ORACLE_HOME/oracle_common/modules/oracle.jdbc_12.1.0/ojdbc6.jar:
$ORACLE_HOME/bam/modules/oracle.bam.client/bam-client.jar:
$ORACLE_HOME/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_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.model.jar    oracle.bpm.metrics.dataobject.migration.application.Migrate11gBAMBPMTo12cDO  PropertyFiles

このコマンドにより、<PATH>ディレクトリに、FactDataExport.zipファイルが作成されます。

注意: プロパティ・ファイルで、コンポジット名を指定できます。コンポジット名を指定すると、該当するコンポジットのみのデータが移行されるようになります。プロパティ・ファイルでコンポジット名を定義していないと、すべてのコンポジット・データが移行されます。

#*************************************
#Mandatory Fields
#*************************************
#11g User Name
BAM_11g_USER_NAME= <<11gUserName>>
#12c User Name
BAM_12c_SOURCE_NAME = <<12cUserName>>

#11g URL
BAM_11g_URL=jdbc:oracle:thin:@<<11gBAMSchemaDatabaseIP>>:<<Port>>:<<SID>>
#12c URL
BAM_12c_URL=jdbc:oracle:thin:@<<12cDatabaseIP>>:<<Port>>:<<SID>>

#Path where data to be exported
PATH = <<Path where data need to be exported>>
#*************************************
#Optional Fields
#************************************

COMPOSITE_LIST = <<List of Composite for which data needs to be exported. This is ':' seperated>>
#If above mention configurable is missing then all the composite data will be migrated.
DATAOBJECT_FOLDER_PATH = <<DataObject Path If this field is absent then default path will taken as Samples/Monitor Express/BI_>>
#************************************

3. BPMデータをBAM 12cにインポートします。
この手順により、事前にエクスポートしたBPM Monitor Expressデータが、確実にBAM 12cにインポートされます。

cd $DOMAIN_HOME/bam/bin

./bamcommand -host <<host>> -protocol t3 -dbusername <<DbUserName>>  -dburl jdbc:oracle:thin:@<<DBIP>>:<<Port>><<SID>> -username  <<weblogicUserName>> -cmd import  -file <<Path of BPM FactDataExport zip file >> -mode update -migrate 1

4. 移行が完了したら、BAM 12cへのパブリッシュを有効にするために、DisableProcessMetricsパラメータをfalseに設定します。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle BAMサーバーがインストールされているドメインを選択します。
たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下のoracle.as.soainfra.configノードを開きます。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。
analytics属性がリストされます。

10. DisableProcessMetrics属性の値をfalseに変更します。

11. 「適用」をクリックします。

注意:
アーカイブ・ファイルのインポート中にエラーが発生した場合は、ロールバックSQLファイルを実行することで、BAM 12cプロセス・スター・スキーマのデータ・オブジェクトにインポートしたすべてのデータをロールバックできます。
BAM 12cデータベースのSQLプロンプトから、SOAINFRAスキーマ・ユーザーとしてログインし、<PATH>ディレクトリに移動して、次のコマンドを実行します。

sql> @rollbackMonitorExpressMigration.sql

その他のエラー処理手順の詳細は、第A.4.1項「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

5.5.2 12cでの11g互換プロセス・スター・スキーマ・データ・ビューの生成(オプション)

前提条件: これらのビューを生成する前に、タスク6「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」で説明する手順を完了する必要があります。

11gのプロセス・スター・スキーマ・ビューを基にして構築されたOracle Fusion Middleware 11gアプリケーションがあるときに、そのアプリケーションを12cでも継続して使用する場合は、そのビューをアップグレード後に再作成する必要があります。12cのスター・スキーマ・データベース・ビューは、11gのビューとは異なっていて、自動的にアップグレードできません。

つまり、12cのスター・スキーマ・データベース・ビューには異なる名前が付けられていて、Oracle BAMデータ・オブジェクトを基にしており(プロセス・キューブ表を基にしていない)、コンポジット・レベルで作成されている(11gのようにプロセス・レベルではない)ということです。Oracle 12c環境で使用するビュー(標準およびプロセス固有の両方)の再作成を支援するために、自動化されたユーティリティが用意されています。

注意:
この手順はオプションですが、BAM 12cプロセス・スター・スキーマ・ビューは11gプロセス・スター・スキーマ・ビューよりも多くの情報を提供するため、このビューを使用することをお薦めします。

タスク1   クラスパスを更新してインタフェースJARファイルを含める

CLASSPATHを更新して、SOAホームにあるoracle.bpm.analytics.interface.jarファイルの場所が含まれるようにする必要があります。

次に例を示します。

DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar

タスク2   標準のビューを再作成する

標準ビュー11g移行ユーティリティを使用して、次に示す11g標準ビューの12c互換バージョンを作成します。

BPM_ACTIVITY_DEFINITION_V
BPM_ACTIVITY_INSTANCE_V
BPM_ACTIVITY_PERFORMANCE_V
BPM_PROCESS_DEFINITION_V
BPM_PROCESS_INSTANCE_V
BPM_PROCESS_PERFORMANCE_V
BPM_ROLE_DEFINITION_V
次のコマンドを使用して、ユーティリティを実行します。

java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.util.StandardView11gMigrationUtil <initialContextFactory> <protocol> <host name> <soa-port> <username>[]

説明:

- initialContextFactoryはJNDI初期コンテキスト・ファクトリです(weblogic.jndi.WLInitialContextFactoryなど)。

- protocolは、ターゲット・サーバー用に構成されたRMI/JNDIプロトコルです。t3、IIOP、HTTP、T3s、IIOPSまたはHTTPSを指定します。

- host nameは、ホストのフル・ネームです(soa.mycompany.comなど)

- soa-portは、SOAのリスニング・ポートです(7001など)。

- usernameは、サーバーのログイン名です(weblogicなど)。

タスク3   プロセス固有のビューを再作成する

プロセス固有ビュー11g移行ユーティリティを使用して、次に示す11gプロセス固有ビューの12c互換バージョンを作成します。

BPM_ACTV_INST_<viewIdentifier>_V
BPM_ACTV_PERF_<viewIdentifier>_V
BPM_PRCS_INST_<viewIdentifier>_V
BPM_PRCS_PERF_viewIdentifier>_V
次のコマンドを使用して、ユーティリティを実行します。

java -cp $ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.utill.ProcessSpecificView11gMigrationUtil <initialContextFactory> <protocol> <host name> <soa-port> <username > [<composite-name>]

説明:

- initialContextFactoryはJNDI初期コンテキスト・ファクトリです(weblogic.jndi.WLInitialContextFactoryなど)。

- protocolは、ターゲット・サーバー用に構成されたRMI/JNDIプロトコルです。t3、IIOP、HTTP、T3s、IIOPSまたはHTTPSを指定します。

- host nameは、ホストのフル・ネームです(soa.mycompany.comなど)

- soa-portは、SOAのリスニング・ポートです(7001など)。

- usernameは、サーバーのログイン名です(weblogicなど)。

- composite-name(オプション)は、ビューを作成する単一のコンポジットの名前です。

6 Oracle SOAを含まないOracle Service Busのアップグレード

この章では、Oracle SOA SuiteおよびBusiness Process Managementを含まないOracle Service Busをアップグレードする際の、アップグレード固有のタスクについて説明します。

Oracle Service Bus 11g (11.1.1.6または11.1.1.7)をリリース12c (12.1.3)にアップグレードするときには、この章で説明するアップグレード前タスクとアップグレード後タスクを実行する必要があります。これを実行しないと、アップグレード後環境が機能しなくなる可能性があります。

- 第6.1項「Oracle Service Busの12cへのアップグレードの理解」

- 第6.2項「単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)」

- 第6.3項「Oracle Service Bus (OSB)のアップグレード前タスクの実行」

- 第6.4項「以前のリリースからのリソースの移行」

- 第6.5項「Oracle Service Busのインストール」

- 第6.6項「OSBドメインのアップグレード(SOAを含まない場合)」

- 第6.7項「OSBドメインの再構成」

- 第6.8項「WebLogicコンポーネント構成のアップグレード」

- 第6.9項「Oracle Service Busのアップグレード後タスクの実行」

6.1 Oracle Service Busの12cへのアップグレードの理解

Oracle Service Bus (OSB)は、Oracle SOA SuiteおよびBusiness Process Managementの有無にかかわらず12c (12.1.3)にアップグレードできます。この章のアップグレード手順では、SOAを含まないOracle Service Busのアップグレード方法について説明します。

OSBがSOA 11gドメインの一部に含まれていて、SOA Suiteの12c (12.1.3)へのアップグレードの一環としてOSBをアップグレードする場合は、第3章「SOA SuiteおよびBusiness Process Management 12c (12.1.3)のアップグレード」で説明している標準のアップグレード・プロセスに従ってください。

SOAを含まないOracle Service Busをアップグレードする場合は、この章で説明するアップグレード手順を使用してください。ドメインにSOAが含まれていない場合でも、OSBデータをアップグレードするには、_SOAINFRAスキーマをアップグレードする必要があります。OSBには、個別のスキーマがありません。「Oracle Service Busのスキーマの作成」を参照してください。

注意:
OSBに固有のアップグレード前およびアップグレード後の手順をすべて、必ず確認してください。これらの追加手順は、12c (12.1.3)へのアップグレード時に、すべてのOSBのアップグレード(SOAの有無にかかわらず)で必要になります。

手順

説明

詳細

すべてのアップグレード前タスクを実行します。

標準の12cアップグレード前タスクと、各自のデプロイメントに当てはまるOSBに固有のタスクをすべて実行します。

第2.1項「一般的なアップグレード前タスクの実行」
第6.3項「Oracle Service Bus (OSB)のアップグレード前タスクの実行」

ポリシー・ストアがデータベース・ベースであることを確認します。

この重要なアップグレード前タスクは、Oracle Service Busを12cにアップグレードする前に完了しておく必要があります。

第2.1.14項「アップグレード前のファイルベースのポリシー・ストアの再関連付け」

OSBドメインをホストするWebLogicサーバーとJRFをアップグレードします。

12cインフラストラクチャをインストールして、インフラストラクチャ・ドメインをアップグレードしてから、Oracle Service Busをアップグレードする必要があります。

第2.3項「アップグレード前の12c (12.1.3) Infrastructureディストリビューションのインストール」

Oracle Service Busをインストールします。

OSBディストリビューションを入手して、その内容を新しいOracleホームにインストールします。

第6.5項「Oracle Service Busのインストール」

Oracle Service Busをアップグレードします。

この章の手順に従って、既存のOracle Service Busドメインをアップグレードします。

第6.6項「OSBドメインのアップグレード(SOAを含まない場合)」

アップグレード後タスクをすべて実行します。

標準の12cアップグレード後タスクと、各自のデプロイメントに適用するアップグレード後のOSBに固有のタスクをすべて実行します。

第8.1項「アップグレード後タスクの実行」
第6.9項「Oracle Service Busのアップグレード後タスクの実行」

第A.7項「Oracle Service Busのトラブルシューティング」

6.2 単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)

OSB 11gのトポロジが単一のドメイン内の複数のコンポーネントで構成されている場合は、12c (12.1.3)にアップグレードできません。

特定のFusion Middlewareコンポーネント(Oracle SOA、OSB、Business Activity Monitoring (BAM)など)は、12cでは、ユーザー・メッセージング・サービス(UMS)に対する依存関係があります。単一の12.1.3ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります。

このようなコンポーネントをアップグレードするには、ドメインの再構成時に、各コンポーネントに個別のクラスタを作成する必要があります(構成ウィザードを使用したWebLogicドメインの作成のクラスタに関する項を参照)。

このようなコンポーネントに対してサポートされるアップグレード・トポロジについては、第4.3項「クラスタ化トポロジのアップグレード」を参照してください。

6.3 Oracle Service Bus (OSB)のアップグレード前タスクの実行

Oracle Service Busをアップグレードする場合は、アップグレードを開始する前に、次の各タスクを実行する必要があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

1. Oracle Service Busのスキーマの作成

2. 11g環境へのOracle Web Services Managerポリシー・マネージャのデプロイ

3. Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート

4. すべてのサービス、プロジェクトおよびリソースの削除

6.3.1 Oracle Service Busのスキーマの作成

Oracle Service Busのすべてのデータベース・スキーマのデータはSOAINFRAスキーマに組み込まれているので、Oracle Service Busには独自のスキーマがありません。したがって、Oracle SOAを実行せずにOracle Service Busを実行できますが、アップグレードを開始する前に、_SOAINFRA、_UMSおよび_STBスキーマを作成する必要があります。

詳細は、リポジトリ作成ユーティリティによる必要なスキーマの作成に関する項を参照してください。

6.3.2 11g環境へのOracle Web Services Managerポリシー・マネージャのデプロイ

Oracle Web Services Manager (OWSM)ポリシー・マネージャがOracle Service Bus 11g環境にデプロイされていない場合は、12cにアップグレードする前に、それを手動でデプロイする必要があります。

11gでは、WebLogicのセキュリティ・ポリシーとOWSMのポリシーは、どちらもOracle Service Busでサポートされていました。11g (11.1.1.7)の時点で、WebLogicセキュリティ・ポリシーは非推奨になり、12c (12.1.3)ではサポートされなくなりました。11gではWebLogicセキュリティ・ポリシーが使用可能であったため、OWSMマネージャのデプロイメントとOWSMポリシーの使用はオプションでした。12cではOWSMポリシーのみがサポートされているため、OWSMポリシー・マネージャのデプロイメントが必須になります。

OWSMポリシー・マネージャを手動で11g環境にデプロイする方法の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWebLogic ServerでのOWSMのインストールに関する項を参照してください。

6.3.3 Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート

Oracle Service Bus 12.1.3にアップグレードする前に、サービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい12c環境にインポートします。

リソースとサービスは、サポート対象の旧リリースから手動でエクスポートできます。「以前のリリースからのリソースの移行」を参照してください。

詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

6.3.4 すべてのサービス、プロジェクトおよびリソースの削除

エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。

Oracle Service Busコンソールの使用方法の詳細は、『Oracle Service Busでのサービスの開発』のプロジェクト、フォルダおよびリソースの削除方法に関する項を参照してください。

JDeveloperを使用してリソースを削除する方法の詳細は、『Oracle Service Busでのサービスの開発』のプロジェクトまたはリソースの削除方法に関する項を参照してください。

6.4 以前のリリースからのリソースの移行

リソースとサービスは、次の各リリースから手動でエクスポートして、Oracle Service Bus 12c (12.1.3)で使用できます。

- Oracle Service Bus 11gリリース: 11.1.1.6.0、1.1.1.5.0、11.1.1.4.0、11.1.1.1.3

- Oracle Service Bus 10.3リリース: 10.3.1および10.3.0

- AquaLogic® Service Busリリース3.0以降

詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

6.5 Oracle Service Busのインストール

Oracle Service Busをインスト－するには、『Oracle Service Busのインストールと構成』を参照してください。

Oracle Service Busは、Oracle SOA SuiteおよびBusiness Process Managementなしでインストールおよびアップグレードできますが、Oracle Service Busをアップグレードする前には、Oracle Fusion Middleware Infrastructure 12c (12.1.3)をインストールする必要があります。詳細は『Oracle Fusion Middleware Infrastructureのインストールと構成』を参照してください。

注意:
Oracle Web Services ManagerのポリシーをOracle Service Busで使用する場合は、Oracle WebLogicドメインの構成時に、Oracle Service Busドメイン・テンプレートのいずれかを選択した後で、Oracle Web Services Manager拡張テンプレートを選択する必要があります。

6.6 OSBドメインのアップグレード(SOAを含まない場合)

Oracle Service Busアップグレードするには、表6-1で説明する基本手順に従います。

表6-1 Upgrade Assistant画面: スキーマのアップグレード

画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

「スキーマ」を選択します。

注意: OSBスキーマはありません。Oracle Service Busのすべてのデータベース・スキーマのデータは、SOAINFRAスキーマに組み込まれています。

使用可能なコンポーネント

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

OSBのアップグレード時には、Metadata Services、Audit ServicesおよびOracle Platform Security Servicesを選択します。

ドメイン・ディレクトリ

この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。

既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてアップグレードする11gドメイン・ディレクトリに移動して選択します。

前提条件

スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。

注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。

スキーマ資格証明

この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

現在のアップグレード・プロセスのステータスを確認します。

注意: この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

6.7 OSBドメインの再構成

スキーマのアップグレード後に、Oracle再構成ウィザードを使用して、11g OSBドメインを再構成する必要があります。このプロセスは、「再構成ウィザードを使用したドメインの再構成」で説明しているSOAドメインの再構成手順と同じです。

6.8 WebLogicコンポーネント構成のアップグレード

ドメインの再構成後に、アップグレード・アシスタントをもう一度実行して、11g OSBドメインのコンポーネント構成をアップグレードします。

このプロセスについては、「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」で説明しています。

6.9 Oracle Service Busのアップグレード後タスクの実行

アップグレードが正常に完了したら、次のタスクを1つ以上実行する必要がある場合があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

注意:
クラスタ化OSBトポロジをアップグレードした場合は、第4.5項「クラスタのアップグレード後のタスクの実行」に記載されたアップグレード後のタスクを完了する必要があります。

- WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

- ドメイン構成データのインポート

- セキュリティ構成のインポート

- XQueryリソースのアップグレード

- Enterprise ManagerでのOracle Service Busコンソール・ユーザーの管理

- 12cの分割-結合の理解

注意:
Oracle Service Busでアップグレード後の問題が発生した場合は、第A.7項「Oracle Service Busのトラブルシューティング」で、一般的な解決策の一覧を参照してください。

6.9.1 WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle Service Bus用のOracle HTTP Serverの構成に関する項を参照してください。

6.9.2 ドメイン構成データのインポート

アップグレード後に、「Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート」でエクスポートしたドメイン構成データをインポートする必要があります。

詳細は、『Oracle Service Busでのサービスの開発』のコンソールで構成JARファイルからリソースをインポートする方法に関する項およびOracle Service Busの管理の構成ファイルの実行に関する項を参照してください。

6.9.3 セキュリティ構成のインポート

Oracle WebLogic Server管理コンソールを使用して、アップグレード前にエクスポートしたセキュリティ・データを新しいOracle Service Busドメインにインポートします。

詳細は、Oracle WebLogic Server管理コンソールのオンライン・ヘルプでセキュリティ・プロバイダへのデータのインポートに関する項を参照してください。

注意:
セキュリティ情報は、セキュリティ・プロバイダごとに個別にインポートする必要があります。

6.9.4 XQueryリソースのアップグレード

Oracle Service Busでは、XQuery 1.0をサポートしています。旧XQuery 2004もサポートされます。Service Busで新規作成したXQueryリソースは、デフォルトでXQuery 1.0バージョンを使用します。

12cより前のService Busプロジェクトからアップグレードすると、そのプロジェクト内のすべてのXQueryリソースが、XQuery 2004バージョンを使用するように構成されます。

XQueryリソースのアップグレードの詳細は、『Oracle Service Busでのサービスの開発』のXQuery 1.0を使用するようにXQueryリソースをアップグレードする方法に関する項を参照してください。

6.9.5 Enterprise ManagerでのOracle Service Busコンソール・ユーザーの管理

Oracle Service Bus 11gでは、Oracle Service Busコンソール・ユーザー・ロールは、WebLogicコンソールでのみ管理されていました。12cでは、Oracle Enterprise Managerコンソールで管理する必要があるOracle Service Busコンソール・アプリケーション・ロールがあります。

Enterprise Managerコンソールでロールにユーザーとグループを追加する手順:

1. Enterprise Managerでドメインを右クリックし、「アプリケーション・ロール」を選択します

2. OSBコンソールアプリケーションを選択し、矢印アイコンをクリックしてロール・リストを表示します。

3. 必要に応じてロールにユーザーとグループを追加します。

6.9.6 12cの分割-結合の理解

12cには、パイプライン・サービスまたはプロキシ・サービスから直接分割-結合コンポーネントを呼び出す方法があるため、11gの分割-結合ビジネス・サービスがなくなりました。アップグレード・プロセスでは、次のようにして、静的に構成されたすべての呼び出しの参照を自動的に分割-結合ビジネス・サービスに変更します。

- フロー・ビジネス・サービスは削除されます。つまり、フロー・ビジネス・サービス用に構成されたTimeoutプロパティも削除されます。

- ビジネス・サービスと、それを呼び出すプロキシ・サービスが同じプロジェクトに配置されている場合は、そのプロキシ・サービスに関連付けられたパイプラインにより分割-結合が直接呼び出されます。

- ビジネス・サービスと、それを呼び出すプロキシ・サービスが異なるプロジェクトに配置されている場合は、分割-結合を呼び出すためのローカル プロキシ・サービスが作成されます。このローカル・プロキシ・サービスは、元のプロキシ・サービスから呼び出されます。

7 AIAFP 11gからSOAコア拡張機能12cを含むSOAへのアップグレード

この章では、Application Integration Architecture Foundation Pack (AIAFP) 11gのアップグレード手順について説明します。12cでは、AIAFPはSOAコア拡張機能と呼ばれます。

この章では、次のタスクについて説明します。

- 第7.1項「SOAコア拡張機能12c (12.1.3)へのアップグレード」

- 第7.2項「SOAコア拡張機能のアップグレード後タスクの実行」

注意:
現時点でOracle Application Integration Architecture Foundation Pack (AIAFP) 11gリリース1 (11.1.1.7)を実行している場合は、アップグレードを行う前に、パッチRUP 2 (17553612)および個別パッチ(18464591)以降を適用する必要があります。
Oracle Application Integration Architecture Foundation Pack 11g (11.1.1.6)を実行している場合は、RUP5 (17423167)を適用する必要があります。

サポートされている開始点の詳細は、第1.2項「SOA 12c (12.1.3)アップグレードの開始点の理解」を参照してください。

7.1 SOA拡張機能12c (12.1.3)へのアップグレード

「SOA SuiteおよびBusiness Process Management 12c (12.1.3)のアップグレード」で説明する手順に従って、Oracle Application Integration Architecture Foundation Pack 11gを含むSOAを、SOAコア拡張機能12c (12.1.3)を含むSOAにアップグレードします。

AIAFPのアップグレード時には、次に示す追加のオプションに注意してください。

アップグレード・アシスタントの画面

説明および必要なアクション

使用可能なコンポーネント

タスク2「スキーマをアップグレードする」でスキーマをアップグレードするときは、次に示すように、「使用可能なコンポーネント」画面でSOAコア拡張機能を選択していることを確認します。

11g AIAFPの詳細

第3.6項「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」に記載されたタスクを実行するときは、次に示すように、11g AIAFPの詳細画面で、11g AIAFPディレクトリの場所とインスタンス名を入力する必要があります。

SCEクラスタの構成

SOA 11gクラスタにAIAFP 11gがインストールされている場合は、共有ディレクトリの場所を指定する必要があります。

7.2 SOAコア拡張機能のアップグレード後タスクの実行

SOAコア拡張機能12c (12.1.3)へのアップグレード後には、次に示すアップグレード後タスクを実行する必要があります。

- 不要なAIAユーザーおよびグループのSOAコア拡張機能からの削除(オプション)

7.2.1 不要なAIAユーザーおよびグループのSOAコア拡張機能からの削除(オプション)

AIAFP 11gから商標変更されたSOAコア拡張機能12c (12.1.3)へのアップグレードの一環として、廃止された11g AIAのユーザーとグループの一部が非推奨にされています。このようなユーザーとグループは、削除してもかまいません。

アップグレード・アシスタントを実行して、SOAコア拡張機能12c (12.1.3)への構成のアップグレードを行うと、インストールされるantスクリプトを実行できるようになります。このスクリプトでは、次に示すように、該当する不要なユーザーとグループを削除できます。

タスク1   管理サーバーおよびSOA管理対象サーバーを起動します。

管理サーバーを起動するには、DOMAIN_HOME/binディレクトリに移動します。

UNIXオペレーティング・システムの場合は次を実行します。

./startWebLogic.sh

Windowsオペレーティング・システムの場合は次を実行します。

startWebLogic.cmd

SOA管理対象サーバーを起動するには、Oracle Fusion Middleware Controlにログインして、管理対象サーバーの起動に関する項の手順を実行します。

タスク2   次のコマンドを使用して環境変数を設定します。

次のコマンドを使用して、SOAコア拡張機能環境変数を設定します。

UNIXオペレーティング・システムの場合:

cd <Domain_Home>/soa/aiafp/bin
./aiaenv.sh

Windowsオペレーティング・システムの場合:

cd <Domain_Home>/soa/aiafp/bin
aiaenv.bat

タスク3   次のantスクリプトを実行して、不要なセキュリティ構成を削除します。

antは、FMW 12.1.3.0.0の一部として、MW_HOME/oracle_common/modules/org.apache.ant_1.9.2にインストールされており、前の手順でPATHに追加されています。

UNIXオペレーティング・システムの場合:

ant -f $SOA_HOME/aiafp/Install/config/PostUpgrade.xml

Windowsオペレーティング・システムの場合:

ant -f  %SOA_HOME%/aiafp/Install/config/PostUpgrade.xml

注意:

- ログ・ファイルは$DOMAIN_HOME/soa/aia/logsディレクトリにあります。

- このスクリプトを実行すると、ユーザーAIAIntegrationAdminが削除されます。

- このスクリプトを実行すると、グループAIALifecycleUser、AIALifecycleDeveloperおよびAIALifecycleInstallDeveloperが削除されます。

- 失敗モード: デプロイ・プランの内部でタスクの実行に失敗すると、スクリプトは最初のエラー発生時に失敗の状態で終了し、失敗の内容をログに出力します。

8 アップグレード後のタスクの実行

この章では、SOA 12cへのアップグレード後に実行する必要のある可能性があるタスクについて概要を説明します。

この章の内容は次のとおりです。

- 第8.1項「アップグレード後タスクの実行」

- 第8.2項「アップグレードしたコンポーネントが期待どおりに動作していることの確認」

注意:
次のものについては、コンポーネント固有の追加のアップグレード後タスクがあります。
Business Activity Monitoring (BAM)については、「Oracle Business Activity Monitoring (Oracle BAM)を含むSOAのアップグレード」を参照してください。

SOAコア拡張機能(AIAFP)については、「SOAコア拡張機能のアップグレード後タスクの実行」を参照してください。

Oracle Service Bus (OSB)については、「Oracle Service Busのアップグレード後タスクの実行」を参照してください。

ユーザー・メッセージング・サービス(UMS)については、『Oracle User Messaging Serviceの管理』のユーザー・メッセージング・サービスのアップグレードに関する項を参照してください。

8.1 アップグレード後のタスクの実行

次の各タスクは、アップグレード後に実行する必要があります。

- 第8.1.1項「JVMの開始スクリプトのプロパティの再適用」

- 第8.1.2項「setDomainEnvへのカスタマイズの再適用」

- 第8.1.3項「XEngine構成ファイルへのカスタマイズの再適用」

- 第8.1.4項「カスタムのXPathクラスのコピー」

- 第8.1.5項「アプリケーションのロールとポリシーに対するパーティション固有のロールの再作成」

- 第8.1.6項「Javaキーストア(JKS)のOPSS KeyStore Services (KSS)への移行」

- 第8.1.7項「サーバーの起動と停止」

- 第8.1.8項「Enterprise Managerでのコンポジット・インスタンスの表示」

- 第8.1.9項「Business Process Management (BPM)メタデータのアップグレード」

- 第8.1.10項「Oracle Fusion Middleware 12c監査データ・ストアの構成」

- 第8.1.11項「リモート・クライアントによるServerSocketのアップグレード」

- 第8.1.12項「SOA 12cのスレッドの再構成」

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

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

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

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

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

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

2. カスタムの開始スクリプトを指定する場合は、StartScriptNameプロパティを、nodemanager.propertiesファイル内の各自のスクリプトの名前に設定します。

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

ノード・マネージャは、ServerStartMBeanのArguments属性とSSLArgumentsで指定されたコマンドラインの起動オプション(-Dフラグ)のすべてを、1つの環境変数JAVA_OPTIONSに結合します。SSLArgumentsは、SSLMBeanの値から取得されます。SSLMBeanで、ignorehost nameVerification、host nameVerifierおよびReverseDNSAllowedの値が調べられ、それらの値が-Dフラグに追加されます。これらすべてのフラグにより、SSLArgumentsパラメータが構成されます。SSLArgumentsと、ServerStartMBeanのArgumentsのすべての値により、開始スクリプト用に定義されるJAVA_OPTIONS環境変数が構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。

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

SOA SuiteおよびBPM環境の12.1.3へのアップグレードを完了するには、開始スクリプト(setDomainEnvなど)のカスタマイズの再適用が必要になることがあります。

サーバーが起動しない場合やAdminModeで起動する場合、最も可能性の高い原因は、setDomainEnv.shの11gからの変更内容が12cドメインに再適用されていないことです。11gと12cのsetDomainEnvを比較して、カスタムの変更をアップグレード後に追加してください。

詳細は、起動スクリプトへのカスタマイズの再適用に関する説明を参照してください。

注意:
今後のアップグレードでカスタマイズの内容が失われないようにするには、第2.1.7項「カスタムのsetDomainEnv設定の保持」を参照してください。

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

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

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

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

アップグレード後には、次の例で示すように、カスタマイズしたXPathクラスを新しい12c Oracleホームの/classesディレクトリにコピーする必要があります。

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

<11g Oracle Home>/soa/modules/oracle.soa.ext_11.1.1/classes

コピー先:

<12c Oracle Home>/soa/modules/oracle. soa. ext_11. 1. 1/classes folder

8.1.5 アプリケーションのロールとポリシーに対するパーティション固有のロールの再作成

アップグレード後に、パーティション固有のロールはすべてのパーティションについて自動的には再作成されません。ロールは、デフォルト・パーティションに対してのみ作成されます。他のすべてのパーティションについては、下のWLSTコマンドを使用してこれらのロールを作成する必要があります。

sca_createDefaultPartitionAppRoles partition

この12c (12.1.3)の新機能の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のパーティションへのアクセスのセキュリティ保護に関する項を参照してください。

8.1.6 Javaキーストア(JKS)のOPSS KeyStore Services (KSS)への移行

Oracle Web Services Manager (OWSM) 11gでは、メッセージ保護のために複数のタイプのキーストアをサポートしていましたが、Javaキー・ストア(JKS)がデフォルトのキーストアでした。しかし、OWSMリリース12c (12.1.2)の時点で、OWSMはデフォルト・キーストアをKSS (OPSS KeyStore Service)に切り替えています。

11gでJKSを使用していた場合に、12cでKSSを使用するには、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のメッセージ保護のキーストアの構成に関する項を参照してください

8.1.7 サーバーの起動と停止

統合コンポーネントを含むSOA SuiteおよびBPMのアップグレード後には、環境のすべての管理サーバーと管理対象サーバーを起動して、それらが期待どおりに機能していることを確認する必要があります。

ドメインのアップグレードが適切に実行されているときには、引き続きアップグレードされた11gのドメイン・ホームからサーバーを起動します。

サーバーを起動する順序と停止する順序が重要であり、正しい順序で起動または停止していないと、デプロイメントで問題が発生することがあります。

注意:
管理サーバー、管理対象サーバーおよびコンポーネントを含めたOracle Fusion Middlewareの開始および停止の手順については、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの開始と停止に関する項を参照してください。

サーバーの起動順序:

1. Web層(Oracle HTTP Serverを含む)

2. ノード・マネージャ

3. 管理サーバー

4. Oracle Web Services Manager (OWSM)管理対象サーバー

5. サービス指向アーキテクチャ(SOA)管理対象サーバー

6. Oracle Service Bus (OSB)管理対象サーバー

7. Business Activity Monitoring (BAM)管理対象サーバー

サーバーの停止順序:

1. Business Activity Monitoring (BAM)管理対象サーバー

2. Oracle Service Bus (OSB)管理対象サーバー

3. サービス指向アーキテクチャ(SOA)管理対象サーバー

4. Oracle Web Services Manager (OWSM)管理対象サーバー

5. 管理サーバー

6. ノード・マネージャ

7. Web層(Oracle HTTP Serverを含む)

8.1.8 Enterprise Managerでのコンポジット・インスタンスの表示

アップグレードに多数のインスタンス(クローズおよびオープン)の移行が含まれる場合は、Enterprise Managerフロー・トレースのロード時にパフォーマンスの問題が発生することがあります。パフォーマンスの低下を防ぐには、次の手順で説明するように索引を作成します。

1. 第8.1.7項の説明に従って、管理サーバーおよび実行中の管理対象サーバーを停止します。

2. SQLPLUSからSOAINFRAスキーマに接続し、次のコマンドを実行します。

CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);

3. 第8.1.7項の説明に従って、管理サーバーおよび管理対象サーバーを再起動します。

注意:
インスタンスのアップグレードの管理の詳細は、第9章「SOAインスタンスのアップグレードの管理とモニタリング」を参照してください。

8.1.9 Business Process Management (BPM)メタデータのアップグレード

BPMメタデータのアップグレードは、Business Process Composer 12c (12.1.3)に最初にログインすると(アップグレード完了後)開始されます。

Business Process Composerの詳細は、『Oracle Business Process Management Business Process Composerユーザーズ・ガイド』を参照してください。

8.1.10 Oracle Fusion Middleware 12c監査データ・ストアの構成

包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。監査データ・ストアの使用の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の監査データ・ストアの管理に関する項を参照してください。

8.1.11 リモート・クライアントによるServerSocketのアップグレード

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

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

8.1.12 SOA 12cのスレッドの再構成

Oracle SOA Suite 12c (12.1.3)から、ワーク・マネージャはほとんどのSOA関連ワーク・スレッドを処理するようになりました。SOA 11gに指定したスレッドの構成は、アップグレードしたSOA 12c環境には適用されません。SOA 12cへのアップグレード後に、スレッドを再構成する必要があります。

新しいスレッド・モデルの使用方法の詳細は、パフォーマンス・チューニングのSOAインフラストラクチャのチューニングに関する項を参照してください。

8.2 アップグレードしたコンポーネントが期待どおりに動作していることの確認

アップグレードが正常に終了したら、次のタスクを実行して、コンポーネントが引き続き期待どおりに機能していることと、新しいデプロイメントに問題がないことを確認する必要があります。

- ドメイン・コンポーネント構成のアップグレードの確認

- データベース・スキーマのアップグレード成功の確認

- フロー・トレースの12cでの変更内容の理解

8.2.1 ドメイン・コンポーネント構成のアップグレードの確認

ドメイン・コンポーネント構成のアップグレードが成功したことを確認するには、次のURLを使用して管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントでアップグレードされたバージョン番号を確認します。

管理コンソールのURL: http://administration_server_host:administration_server_port/console

Fusion Middleware ControlのURL: http://administration_server_host:administration_server_port/em

注意:
アップグレード後には、11g Oracleホームではなく、新しい12.1.3 Oracleホームからすべての管理ツールを実行する必要があります。

8.2.2 データベース・スキーマのアップグレード成功の確認

データベース・スキーマのアップグレードとインスタンスのアップグレードが成功したかどうかは、アップグレード・アシスタントの各アップグレード・ステータス画面に加え、SQLコマンドを使用して手動で確認することもできます。

詳細は、「SQL問合せによるアップグレード・ステータスの監視」を参照してください。

8.2.3 フロー・トレースの12cでの変更内容の理解

12c SOAでは、インスタンスがECIDではなくflowIDを使用して制御されます。アップグレード・アシスタントでインスタンスを11g SOAから12c SOAにアップグレードすると、アップグレードした11gのフロー・インスタンスと新しく作成した12cインスタンスには、いくつかの相違点があります。このような相違点がフロー・トレースの機能性に影響を与えることはありませんが、その相違点に注意することは重要です。

後述するフロー・トレースXMLの例には、次のような相違点が示されています。

- ActionType属性とActionName属性は、新しく12cに導入されたもので、アップグレードした11gインスタンスでは使用できません。

- アップグレードした11gインスタンスの場合、DateとlastUpdatedDateは同じです。

- アップグレードした11gインスタンスの場合、Entry Instance IdのElapsedTimeは0になります。

注意:
次のメッセージは、フォルトのステータスを正しく識別するための十分な情報がなく、一時的なフォールト・ステータスが割り当てられた場合に表示されます:
エラー・メッセージがありません。インスタンス・アップグレード中に生成されました。

これらのエラー・メッセージは無視できます。

11gから12cにアップグレードしたインスタンスのフロー・トレースXML:

================================
<audit_trail
ecid="9dd01e5816e19dbc:-33f3b618:140c1ee8b0f:-8000-000000000000317e"
flowId="96102"  flowCorrelationId="null"  activeInstances="0"
date="2013-09-02 00:09:52.133 PDT"  lastUpdatedDate="2013-09-02 00:09:52.156
PDT"  elapsedTime="23">
<entry instanceId="10093" parentInstanceId="-110092" date="2013-09-02
00:09:52.156 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT"
elapsedTime="0" timestamp="1378105792156" state="18" subType="bpel"
type="component">
...
</entry>
</audit_trail>

新しく作成した12cインスタンスのフロー・トレースXML:

====================================
<audit_trail ecid="dfcc3828-d7de-4af8-b94e-474ff830c961-0000069a"  flowId="6"
flowCorrelationId="0000K7z3tBPFCCGpIwt1if1IRXgh00000M"  activeInstances="0"
date="2013-10-28 05:35:12.738 PDT"  lastUpdatedDate="2013-10-28 05:35:12.825
PDT"  elapsedTime="87">
<entry instanceId="13" parentInstanceId="12" date="2013-10-28
05:35:12.749 PDT" lastUpdatedDate="2013-10-28 05:35:12.786 PDT"
elapsedTime="37" timestamp="1382963712749" state="18" actionType="operation"
actionName="process" subType="bpel" type="component">
...
</entry>
</audit_trail>

さらに、BPELで捕捉されたフォルトについて、12cで作成した新しいインスタンスのリカバリ・ステータスは、図8-1に示すようにrecoveredと表示されます。

図8-1 新しい12cインスタンスのフロー・トレース

BPELで捕捉されたフォルトについて、アップグレードした11gインスタンスのリカバリ・ステータスは、図8-2に示すようにNonrecoverableと表示されます。

図8-2 アップグレードした11gインスタンスのフロー・トレース

9 SOAインスタンスのアップグレードの管理と監視

この章では、オープンおよびクローズされたSOAインスタンスを12c (12.1.3)にアップグレードする方法と、アップグレード・プロセスの管理と監視のためのオプションについて説明します。

SOA SuiteおよびBPM 12cの標準アップグレード・プロセスでは、オープンおよびクローズされたSOAインスタンスの自動アップグレード・ソリューションを提供します。閉じているインスタンスのアップグレードは、この章の次の各項で説明する管理スクリプトで監視および管理できます。

- 第9.1項「インスタンス・アップグレードのプロセスの理解」

- 第9.2項「インスタンス・アップグレードのバックグラウンド・ジョブの理解」

- 第9.3項「アップグレード前のパージ・スクリプトの使用」

- 第9.4項「アップグレード管理スクリプトの使用」

- 第9.5項「管理スクリプトの構成」

- 第9.6項「アップグレードのセッションとジョブの停止」

- 第9.7項「不完全なアップグレードの再開」

- 第9.8項「SQL問合せによるアップグレード・ステータスの監視」

- 第9.9項「Fusion Middleware Controlによるアップグレード・ステータスの監視」

- 第9.10項「インスタンス・アップグレードのエラーの解決」

9.1 インスタンス・アップグレードのプロセスの理解

アップグレード・アシスタントのフレームワークでは、スキーマのアップグレードは各コンポーネントのインストール(MDS、ORASDPM、OPSS、SOAなど)に委託します。12c SOAのアップグレード時に、アップグレード・アシスタントでインスタンスをアップグレードすることもできます。

アップグレードされる内容

SOAのインストールでは、アップグレード・プロセスの一環として各種コンポーネント(_MDSスキーマや_SOAINFRAスキーマなどを含む)もアップグレードされます。_SOAINFRAスキーマには、次のスキーマ・コンポーネントが格納されています。

- スキーマの定義: 表や索引など

- メタデータ: SOAサーバーとSOAコンポジットの実行に必要になるデータ

注意:
BPMメタデータのアップグレードは、Business Process Composer 12c (12.1.3)に最初にログインすると(アップグレード完了後)開始されます。
Business Process Composerの詳細は、『Oracle Business Process Management Business Process Composerユーザーズ・ガイド』を参照してください。

- インスタンス・データ: 各種コンポーネントで作成されたデータ。インスタンスは、オープンまたはクローズのどちらかになります。

これらのコンポーネントのアップグレード方法

12cスキーマのアップグレード・プロセス時に、これらのコンポーネントがどのような順序でUAによってアップグレードされるかについて理解することが重要です。

アップグレードは、次に示す4つの異なる段階で行われます。

1. アップグレード・アシスタントにより、11gスキーマの定義がアップグレードされます。

2. その後、アップグレード・アシスタントにより、11gメタデータがアップグレードされ、オープン・インスタンスをアップグレードするためのバックグラウンド制御ジョブが作成されます。
注意: このプロセスには時間がかかることがあります。これは、最後のデータベース・ジョブがオープン・インスタンスのアップグレードを完了するまで、各ジョブがUAで実行され続けるためです。最後のジョブが完了するまで、アップグレード・アシスタントを終了しないことが重要になります。

たとえば、インスタンスのアップグレードに必要な時間は、次の項目に応じて異なります。

- 接頭辞_SOAINFRAスキーマのサイズ(オープンおよびクローズされたインスタンス数)

- システム構成(CPIの数(コア数)、メモリーの使用状況、ディスクI/O構成)。

- システムの速度とドライバ表のサイズ

3. すべてのオープン・インスタンスのアップグレードが完了すると、クローズされたインスタンスをアップグレードするバックグラウンド・ジョブが開始されます。クローズされたインスタンスのアップグレードは、アップグレード・アシスタントのクローズ後も、バックグラウンドで継続される点に注意してください。ただし、バックグラウンド・ジョブが停止されたときに、アップグレード対象のクローズされたインスタンスが残っている場合は、管理スクリプトを使用してこれらを再開する必要があります。

4. 最終的に、最後のジョブがオープン・インスタンスのアップグレードを完了すると、アップグレード・アシスタントによりアップグレード・ステータスが示され、アップグレード・プロセスの後続の手順がリストされます。
アップグレード・アシスタントの「アップグレード成功」画面に示された情報を基にして、次に実行する手順を判断してください。注意: -response (サイレント)モードで実行すると、この情報はUAのstdoutファイルにリストされます。

- アップグレード・アシスタントのレポートに、アップグレード対象のインスタンスが存在しなくなったと示された場合は、アップグレード・アシスタントのUIを閉じて、残りのアップグレード手順(再構成ウィザードを起動するなど)を続行します。

- アップグレード・アシスタントのレポートに、インスタンスのアップグレード中にエラーが発生したと示されている場合は、エラーを修正してからデータベース・ジョブを再発行して、アップグレードを完了します。Report Upgrade Summary管理スクリプト(オプション1)を使用して、レポートのUPGRADE ERROR COUNTセクションを確認することもできます。

- アップグレード・アシスタントの終了後には、クローズしたインスタンスのアップグレードがバックグラウンドで続行されることが通知されます。アップグレード・アシスタントが完了を報告し、次のメッセージが表示されるまでは、アップグレード・アシスタントを閉じないでください。

Oracle SOA
1. The Upgrade Assistant has successfully upgraded all open instances. You can now close the Upgrade Assistant.
2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.

注意:
クローズされたインスタンスのアップグレードは、すべてのインスタンスのアップグレードが完了するか、中間層(SOA管理対象サーバーなど)が開始されるまで継続されます。
すべてのクローズされたインスタンスのアップグレードが完了する前に中間層が開始されると、アップグレード・ジョブは停止します。管理スクリプトを使用して、手動でアップグレードを再開する必要があります。

9.2 インスタンス・アップグレードのバックグラウンド・ジョブの理解

バックグラウンド・ジョブは、_SOAINFRAスキーマのアップグレード時に、アップグレード・アシスタントによって作成されます。このようなジョブは、バックグラウンドで実行され、オープンおよびクローズされたインスタンス・データを自動的にアップグレードします。このようなジョブがアップグレード・プロセスで動作する方法と、そのジョブを管理する方法について理解することが重要になります。次のリストでは、このようなジョブに関する重要な情報について説明します。

- ジョブの作成はアップグレード・アシスタント(UA)で行いますが、ジョブの管理は管理スクリプトで行います。管理スクリプトを使用することで、たとえば、このようなジョブを実行する方法や時期を構成できます。

- ジョブは、スキーマのアップグレード・プロセス後に、自動的に開始されます。

- UAから開始されたジョブは、次のいずれかの状況が発生すると自動的に停止します。

- ジョブが完了して、クローズされたすべてのインスタンスが12cに移行された

- 中間層アプリケーションが開始された(管理対象サーバーなど)

- ジョブ停止スクリプト(オプション8)が開始された

- クローズされたインスタンスのアップグレードが完了していない場合は、アップグレード・アシスタントの終了後も、バックグラウンド・ジョブがバックグラウンドで続行されます。

- ジョブが停止されたときに、アップグレード対象のインスタンスが残っている場合は、管理スクリプトを使用することで、別のときにジョブを実行することも、ジョブを実行するようにスケジュールすることもできます。
バックグラウンド・ジョブの構成の詳細は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」、「アップグレードのセッションとジョブの停止」および「不完全なアップグレードの再開」を参照してください。

9.3 アップグレード前のパージ・スクリプトの使用

インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。12cパージ・スクリプトには、移行対象外のクローズされたインスタンスが含まれています。つまり、アップグレード後、12cパージ・スクリプトの実行をスケジュールすると、移行対象外のクローズされたインスタンスがスクリプトでパージされます。パージ・スクリプトを使用してクローズされたインスタンスを削除すると、アップグレードの全体的なパフォーマンスを向上できます。

注意:
オープン・インスタンスのみをアップグレードすると、中断されたステータス・フローが表示されることがあります。子フローが11gで中断されていると、フローは中断状態になります。
このECIDに関連付けられたすべてのコンポジット・インスタンスは、終了状態を維持します。

自動パージまたはパージ・スクリプトの使用方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベース成長の管理に関する項を参照してください。

注意:
アップグレード・アシスタントのバックグラウンド・ジョブの実行中に、パージ・ジョブを実行するようにスケジュールしないでください。アップグレード・アシスタントの実行中にスクリプトを実行すると、パージまたはアップグレードが失敗することがあります。
UAの実行中にパージ・スクリプトを実行するように構成すると、ORA-20099: ERROR 11gから12cへのアップグレードが進行中ですというメッセージが表示されます。

パージ・スクリプトの実行中にUAを実行すると、SQLException: ORA-00054: リソース・ビジー。NOWAITが指定されているか、タイムアウトしましたというメッセージが表示されます。

9.4 アップグレード管理スクリプトの使用

アップグレード管理スクリプトは、SOA Suite 12c (12.1.3)のインストールに付属するアップグレード・アシスタント・プラグインの一部として含まれています。このようなPL/SQLスクリプトは、インスタンスのアップグレード全体に追加的な管理制御を提供します。アップグレードが完了すると、Oracle Enterprise Manager Consoleでインスタンスを表示できるようになります。さらに詳しいアップグレード・プロセスの情報が必要な場合は、追加のレポートおよび構成オプションに対応した管理スクリプトを使用してください。

- アップグレード・スクリプト・メニューへのアクセス

- 管理スクリプトの実行

- アップグレードのセッションとジョブの停止

注意:
管理アップグレード・スクリプトにより、アップグレードに関する詳細情報が示されます。このようなスクリプトにより、インスタンス・アップグレードに対する追加の構成、管理および監視機能が得られます。このようなスクリプトは、独自の要件に基づいて実行するように(または実行しないように)構成できます。
Fusion Middleware Control Consoleを使用してアップグレード・プロセスを管理および監視することもできますが、管理スクリプトを使用するほうが管理オプションが多くなります。

クローズされたインスタンスのアップグレードを監視するためにアップグレード・アシスタントを使用した後には、Report Upgrade Summary(オプション1)スクリプトを実行することをお薦めします。

アップグレードの進行状況の監視にFusion Middleware Control Consoleを使用する方法の詳細は、「Fusion Middleware Controlによるアップグレード・ステータスの監視」を参照してください。

9.4.1 アップグレード・スクリプト・メニューへのアクセス

インスタンス・アップグレードを構成、管理および監視するために使用できるスクリプトは複数あります。これらのスクリプトへのアクセスには、soa_upgrade_menu PL/SQLスクリプトを使用できます。

アップグレード・スクリプト・メニューにアクセスするには:

タスク1   12.1.3 SOAホームの/adminディレクトリに移動する。

次に例を示します。

cd  <ORACLE_HOME>/soa/common/sql/soainfra/sql/oracle/121300/upgrade/admin

タスク2   SQL* Plusを使用して、スキーマ所有者の名前とパスワードで_SOAINFRAスキーマにアクセスする。

次に例を示します。

sqlplus dev_soainfra/<welcome1>

devは、SOAINFRAスキーマの作成時に使用したスキーマ所有者の接頭辞、welcome1は、スキーマのパスワードになります。

注意:
<接頭辞>_SOAINFRA以外のユーザーを使用して、管理スクリプトにアクセスしようとすると、次のエラー メッセージが表示されます。

ERROR at line 24:
ORA-06550: line 24, column 3:
PLS-00201: identifier 'CONTROL_MIGRATION.UPGRADE_STATUS_INFO' must be declared

タスク3   soa_upgrade_menu.sqlスクリプトを実行して、アップグレードの管理オプション・メニューを表示する。

SQL> @soa_upgrade_menu.sql
==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

表9-1では、各スクリプトの機能について説明しています。

9.4.2 管理スクリプトの実行

管理スクリプトのメイン・メニューには、バックグラウンド制御ジョブとその他の管理タスク(トラブルシューティングなど)の監視と管理に必要になるすべてのオプションが表示されます。

注意:
拡張オプションは、アップグレードのトラブルシューティングを行う場合や、特定のアップグレード要件に基づいてアップグレード・プロセスに変更を加える場合にのみ使用します。多くの場合、このようなスクリプトは、指名されたシステム管理者またはOracleサポートのみが実行します。

管理スクリプトのいずれかを実行するには、プロンプトが表示されているときにオプション番号を入力します。表9-1では、各スクリプトの機能について説明しています。

表9-1 アップグレード管理スクリプトのメニュー・オプション

オプション番号

スクリプト名

このオプションの用途

説明

1

Report Upgrade Summary

アップグレードの全体的なステータスを表示します。

このレポートは、サブセクションに分割されていて、アップグレード全体の概要と現在の実行が示されます。

Report Upgrade Summaryには、METADATA、OPEN ECIDS (オープン・インスタンス)およびALL ECIDS (クローズされたインスタンス)のアップグレード・サマリーが示されます。アップグレード・ステータスはCOMPLETEまたはOUTSTANDING (実行中)のどちらかになります。

さらに、次の事項についての説明されています。

- クローズされた11gインスタンスの最終アップグレード日
Maximum Upgrade Date for Closed 11g Instancesセクションには、最後にアップグレードされたフローのクローズ日が表示されます。アップグレードは、最も最近クローズされたインスタンスから開始され、最も以前に完了したインスタンスがアップグレードされるまで継続します。2014年1月1日にクローズしたインスタンス・フローは、2013年12月1日にクローズしたフローより先にアップグレードされます。Maximum Upgrade Dateが2013年6月1日の場合は、2013年6月1日までにクローズされたすべてのインスタンスのアップグレードが完了していて、2013年6月1日よりも前にクローズされていたインスタンスはまだアップグレード処理中であることを示しています。

- アップグレードのエラー数
UPGRADE ERROR COUNTには、アップグレード中に発生したエラーの数が表示されます。upgrade_error_logファイルを使用すると、エラーの原因がわかります。

アップグレード・エラーの処理方法の詳細は、第9.10項「インスタンス・アップグレードのエラーの解決」を参照してください。

- アップグレード開始以降のインスタンス数
Overview Since Start of Upgradeには、アップグレードの開始日時、アップグレード対象インスタンスの合計数および残りのインスタンス数が示されます。

- 現在の実行統計
現在のアップグレードの実行からのアップグレード・データです。各実行には、番号が付けられます。後述するサンプル・レポートの場合、データは最初の実行(run:1)から得られたものになります。(run:2)の指定では、アップグレードは2番目に実行されたものであることが示され、2番目の実行についての統計が表示されます。

- START COUNT: 実行の開始時点で未処理のインスタンス数が表示されます。後続のアップグレード実行(run2、run3など)については、START COUNTの合計に、前回の実行が完了した時点で残されているものの詳細が示されます。

- REMAINING COUNT: アップグレードの実行中に、未処理の現行インスタンス数の合計が5分ごとに収集されます。未処理の現行インスタンス数を、START COUNTから差し引くと、REMAINING COUNTとなります。つまり、REMAINING COUNT= START COUNT - 未処理の現行インスタンス数になります。

- PROCESSED COUNT:
PROCESSED COUNT= START COUNT - REMAINING COUNT

レポート・データは、次のように示されます。

=============================================
Report Upgrade Summary
(Please wait for report to generate)
=============================================
.
. METADATA : COMPLETE
. OPEN FLOWS : COMPLETE
. ALL FLOWS : COMPLETE
.
. ------------------------------------------
. Date of last upgraded and closed 11g Flows
. ------------------------------------------
. DATE : NOT AVAILABLE OR ALL DATA UPGRADED
.
. NOTE: Closed 11g flows prior to this date
. may not be visible on the EM console
. until they are upgraded.
.
. ---------------------
. UPGRADE ERROR COUNT
. ---------------------
. COUNT : 0

PL/SQL procedure successfully completed.

Enter to continue..
.
---------------------------------------------
Upgrade Start Date and Initial Instance Count
---------------------------------------------
. Upgrade Start Date : 06/MAY/2014:04/50
. Initial Instance Count : 1881
. Outstanding Instances Count : 0
.
------------------------------------
CURRENT RUN STATISTICS (run#: 1)
------------------------------------
. Note: 1/ Statistics maybe from previous run
. until new statistics are generated.
. 2/ Statistics can take 10mins to refresh.
.
. STARTED: 06/MAY/2014:04/50
. ENDED: 06/MAY/2014:04/52
. START COUNT: 1881
. PROCESSED COUNT: 1881
. REMAINING COUNT: 0
.
========= End of Report =====================
Upgrade Counter (Oracle Internal Use): < 300

2

Report upgrade database sessions (実行中のセッション)

現在実行中のジョブを特定します。

この情報は、手動でジョブを停止するために使用しないでください。

このオプションにより、実行中のセッションのデータがModule、Inst、SidおよびSerialの各列に返されます。

次に例を示します。

======================================================
Report Upgrade Database Sessions (Running)
======================================================
.
Module                        Inst  Sid   Serial
---                        --  --   ----
SOAUPGRADECONTROLMAIN         1     122   16535
SOAUPGRADEDATA_0              1     228   14557
SOAUPGRADEDATA_1              1     64    46683
SOAUPGRADEDATA_2              1     180   621
SOAUPGRADEDATA_3              1     130   61577
SOAUPGRADESUBMITJOBS          1     172   66

ジョブの完了は、データベース・スケジューラのジョブ・ログで監視します。

注意: この情報はセッションを停止するために使用しないでください。「アップグレードのセッションとジョブの停止」の説明に従って、管理スクリプトを使用してください。

3

Report upgrade database background jobs (完了済ジョブ)。

アップグレードが完了したジョブを特定します。

インスタンス・アップグレードを実行するデータベース・セッションは、データベース・ジョブとして実行されます。ジョブが完了すると、このオプションでステータスを確認できます。ユーザーが各ジョブの実行内容を理解することを期待しているのではなく、エラーなく成功していることがステータスに示されていることを確認できるようにするものです。

このレポ－トには、制御ジョブのパラメータ値、発行されたアップグレード・ジョブ、ジョブの現行ステータス(発行済、待機中、実行中)およびジョブのスレッド番号(該当する場合)が表示されます。

次に例を示します。

======================================================
Report Upgrade Database Background Jobs (Completed)
======================================================
.
.  State of last 15 completed Jobs in descending order
.
Log_date                 Job_name                   Status      ERROR
----                 ----                   ---      ----
21-FEB-2014 03:07:36  UPGRADE_SOA_METADATA_JOB      SUCCEEDED   0

4

Report background control job parameters

現行のバックグラウンド制御ジョブのパラメータを表示します。

このオプションにより、インスタンスのアップグレードを調整する制御ジョブに渡されたパラメータがレポートされます。

======================================================
Report Backgrond Control Job Parameters
------------------------------------------------------
BATCH_SIZE            : 10000
MAX_COUNT             : 100000
JOB_MAX_RUNTIME       : 240
DOP                   : 4
METADATA_JOB_COMPLETE : TRUE
OPEN_ECIDS_COMPLETE   : FALSE
DATA_JOB_COMPLETE     : FALSE
CTL_MAX_RUNTIME       : 1
FIRST_TIME            : FALSE
FIRST_CTL_MAX_RUNTIME : 0
FIRST_JOB_MAX_RUNTIME : 0
SQL_TRACE             : FALSE
METRICS               : TRUE
ASYNC                 : TRUE
-----------------------
ENABLE                : FALSE
REPEAT INTERVAL       : freq=daily; byhour=3; byminute=0; bysecond=0

5

Change background control job execution schedule

バックグラウンド制御ジョブの繰り返し間隔と継続時間を変更します。

デフォルトでは、バックグラウンド制御ジョブの間隔は、クローズされたすべてのインスタンスのアップグレードが完了するまで、毎日午前3時(ローカル時間)に開始され4時間(240分)実行されます(具体的な設定は、freq=daily; byhour=3; byminute=0; bysecond=0です)。このジョブを別の時間に実行するには、このオプションを使用して繰り返し間隔を変更します。

Change Background Control Job Execution Schedule - Repeat Interval
==================================================================
The repeat interval determines when the control procedure is
executed by the database scheduler.
Examples of repeat intervals can be found in the Oracle Database
Administors Guide.
Enter REPEAT INTERVAL:

詳細は、「バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)」を参照してください。

注意: 実行の継続時間(デフォルトは240分)を変更するには、Change Background Control Job Parameters (オプション7)を使用して、JOB_MAX_RUNTIMEに変更を加えます。

6

Enable/Disable background control job

バックグラウンド・ジョブを有効または無効にします。

デフォルトでは、Enable/Disable background control jobは無効にされています(ENABLE: FALSE)。現在の設定を変更するには、Y (Yes)を入力します。制御ジョブを無効化すると、指定した繰り返し間隔でバックグラウンド制御ジョブが実行できなくなる点に注意してください。

この設定は、サマリー・レポートではENABLE: TRUEまたはFALSEとして表示されます。

現在の設定を維持するには、N (No)を入力します。

ENABLE/DISABLE CONTROL JOB SCHEDULE
===================================
Disabling the Control Schedule will stop the Control job
from executing at the specified Repeat Interval.
Change ENABLE Y/N:

詳細は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」を参照してください。

拡張オプション

7

Change background control job parameters

BATCH_SIZE、MAX_COUNT、JOB_MAX _RUNTIMEまたはDOP (並列度)を変更します(オプション1-4)。

拡張オプション(オプション5-14)は、アップグレードのトラブルシューティングのために、Oracleサポートによる指示があった場合を除いて変更しないでください。

ほとんどのアップグレードに対して、バックグラウンド制御ジョブのパラメータはデフォルトの値で十分です。それでも変更が必要な場合は、「制御ジョブ・パラメータの設定(オプション7)」のパラメータの説明を確認してください。

1:  Set BATCH_SIZE
2:  Set MAX_COUNT
3:  Set JOB_MAX_RUNTIME
4:  Set DOP
.
Advanced Options:
.  (Options below for Oracle Internal Use)
.  (Please contact Oracle Support)
.
5:  Set METADATA_JOB_COMPLETE
6:  Set DATA_JOB_COMPLETE
7:  Set OPEN_ECIDS_COMPLETE
8:  Set CTL_MAX_RUNTIME
9:  Set FIRST_TIME
10: Set FIRST_CTL_MAX_RUNTIME
11: Set FIRST_JOB_MAX_RUNTIME
12: Set SQL_TRACE
13: Set METRICS
14: Set ASYNC
.
15: MAIN MENU
.
Enter option :

8

Stop upgrade database background sessions and jobs

現行のデータベースのセッションまたはジョブを停止します。

このオプションを使用して、「アップグレードのセッションとジョブの停止」の説明に従い、現行のバックグラウンド・ジョブまたはセッションを正常に停止します。

Stop Upgrade Database Background Sessions/Jobs
==============================================
All upgrade sessions and jobs should stop but this may require 5 minutes to take affect.

There will be a one minute wait before this procedure returns.
Are you sure Y/N: Y
Enter for MENU

9

Reset errored 11g instances

アップグレードの実行後、upgrade_error_logを確認して、報告されたエラーを修正します。その後で、このオプションを使用して、次回のアップグレード・ジョブで再度処理されるように該当するインスタンスを再発行します。

このオプションにより、エラーの発生したインスタンスを次回のアップグレード・ジョブで再処理できるようになります。このオプションを使用する前に、upgrade_error_logで報告されたエラーを必ず修正しておいてください。

Reset errored 11g instances
=======================
The 11g instances which have encountered an error will have their
flow_id set to -1. This reset updates the flow_id back to null
so they can be processed in the next exection of the background job.
.
The rows in the upgrade_error_log table will have their type column
set to zero. The rows in this table are not removed so that history
is not lost.
.
NOTE: Ensure to schedule and enable the background job.

Are you sure Y/N:

10

Report Current job run log (Oracleの内部使用)

現行の実行で使用されているパラメータを示す、Oracleサポート向けのレポートを生成します。

このレポートの出力は、アップグレードのトラブルシューティング時にOracleサポートに送信できます。

また、このレポートは、制御ジョブのパラメータに加えた変更が正しいことを確認するためにも使用できます。

Example:
======================================================
Report Current RUN log (Oracle Internal Use)
======================================================
.
Module    Type Comment
---    --- -----
CONTROL  PARM batch_size            => 10000
CONTROL  PARM max_count             => 100000
CONTROL  PARM use_ctl_max_runtime   => 0
CONTROL  PARM use_job_max_runtime   => 0
CONTROL  PARM DOP                   => 4
CONTROL  PARM metadata_job_complete => FALSE
CONTROL  PARM data_job_complete     => FALSE
CONTROL  PARM open_ecids_complete   => FALSE
CONTROL  PARM first_time            => TRUE
CONTROL  PARM sql_trace             => FALSE
CONTROL  PARM metrics               => TRUE
CONTROL  PARM async                 => TRUE
CONTROL  PARM ctl_stoptime_d        => NULL
CONTROL  PARM job_stoptime_d        => NULL
CONTROL  INFO UPGRADE jobs submitted ASYNCRONOUS
METADATA INFO UPGRADE submitting: UPGRADE_SOA_METADATA_JOB
CONTROL  INFO CONTROL procedure waiting for (metadata and/or open ecids)
METADATA INFO UPGRADE UPGRADE_SOA_JOB will wait for UPGRADE_SOA_METADATA_J
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB0
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB1
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB2
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB3
DATA     INFO UPGRADE will wait if UPGRADE_SOA_JOB running

11

Exit

スクリプト管理メニューを閉じます。

このオプションで、メニューが閉じられます。

9.5 管理スクリプトの構成

この項では、アップグレード管理スクリプトの構成に必要な手順について説明します。

- バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)

- バックグラウンド制御ジョブの有効化と無効化(オプション6)

- 制御ジョブ・パラメータの設定(オプション7)

9.5.1 バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)

バックグラウンド制御ジョブの実行スケジュールを変更するには、オプション5を使用します。

次に示す例では、ジョブの開始時間が午前3時から午前4時(ローカル時間)に変更されています。

Change Background Control Job Execution Schedule - Repeat Interval
==================================================================
The repeat interval determines when the control procedure is executed by the database scheduler.

Examples of repeat intervals can be found in the Oracle Database Administors Guide.

Enter REPEAT INTERVAL: freq=daily; byhour=4;

BEFORE Change  :  freq=daily; byhour=3;byminute=0; bysecond=0
AFTER Change   :  freq=daily; byhour=4

9.5.2 バックグラウンド制御ジョブの有効化と無効化(オプション6)

Enable/Disable Background Control Jobスクリプト(オプション6)を使用すると、バックグラウンド制御ジョブの開始を有効にしたり、スケジュールされた制御ジョブの開始を禁止したりできます。T

注意:
バックグラウンド制御ジョブは、デフォルトで無効にされています(ENABLE: FALSE)。このジョブを手動で有効にする(ENABLE: TRUE)場合は、ジョブの無効化も手動で行う必要があります。

ENABLE/DISABLE CONTROL JOB SCHEDULE
===================================
Disabling the Control Schedule will stop the Control job
from executing at the specified Repeat Interval.
Change ENABLE Y/N:

9.5.3 制御ジョブ・パラメータの設定(オプション7)

Set Control Job Parametersスクリプト(option 7)を使用すると、表9-2で説明するパラメータを構成できます。

表9-2 バックグラウンド制御ジョブのパラメータ

パラメータ

デフォルト値

説明

BATCH_SIZE

10000

実行のため、一度にデータベースに送信する更新(挿入、更新および削除)の数を決定します。

MAX_COUNT

100000

別のMAX_COUNT相当のインスタンス数がフェッチされる前に、アップグレードのためにフェッチされるインスタンス数(ECID)を決定します。

JOB_MAX_RUNTIME

240分(4時間)

バックグラウンド制御ジョブが実行される最大の分数です。

DOP

4

1つの操作に関連付けられるパラレル実行サーバーの数は、並列度 (DOP)と呼ばれます。パラレル実行は複数のCPUを効率よく使用するためのものです。

注意: 並列度の変更は拡張オプションになります。各自のデプロイメントに適した並列度の設定の詳細は、データベース管理ドキュメントを参照してください。

拡張オプション(Oracle内部専用。Oracleサポートにご連絡ください)

SQL_TRACE

FALSE

注意: をTRUEに設定したSQL_TRACEは、デバッグやトラブルシューティングに使用できますが、DBAは次に示すようにsoainfraユーザーにalter sessionを付与することが必要になる場合があります。

$ sqlplus / as sysdba
SQL> grant alter session to <soainfra>;

ジョブ制御パラメータを変更するには:

タスク1   第9.4.1項の手順を使用してSOAアップグレード・メニューを起動する。Enter optionフィールドに7を入力して、Change Background Control Job Parametersスクリプトを実行します。

SOAアップグレード・メニューが次のように示されます。

==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

タスク2   変更するパラメータの番号をEnter Optionフィールドに入力する。たとえば、BATCH_SIZEを変更する場合は1を入力します。

制御ジョブ・パラメータの完全なリストが、次のように示されます。

1:  Set BATCH_SIZE
2:  Set MAX_COUNT
3:  Set JOB_MAX_RUNTIME
4:  Set DOP
.
Advanced Options:
.  (Options below for Oracle Internal Use)
.  (Please contact Oracle Support)
.
5:  Set METADATA_JOB_COMPLETE
6:  Set DATA_JOB_COMPLETE
7:  Set OPEN_ECIDS_COMPLETE
8:  Set CTL_MAX_RUNTIME
9:  Set FIRST_TIME
10: Set FIRST_CTL_MAX_RUNTIME
11: Set FIRST_JOB_MAX_RUNTIME
12: Set SQL_TRACE
13: Set METRICS
14: Set ASYNC
.
15: MAIN MENU
.
Enter option :

タスク3   新しい値を入力して、パラメータの値を変更する。[Enter]キーを押して、変更をコミットします。変更するパラメータごとに、この手順を繰り返します。

Before ChangeフィールドとAfter Changeフィールドの値を調べることで、変更が受け入れられたことを確認できます。

タスク4   Enter Optionフィールドに15を入力してメイン・メニューに戻る。

メインの管理スクリプト・メニューに戻ります。

==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

タスク5   Report Background Control Job Parametersスクリプト(オプション4)を使用して、変更内容を確認する。

======================================================
Report Backgrond Control Job Parameters
------------------------------------------------------
BATCH_SIZE            : 10000
MAX_COUNT             : 100000
JOB_MAX_RUNTIME       : 240
DOP                   : 4
METADATA_JOB_COMPLETE : TRUE
OPEN_ECIDS_COMPLETE   : FALSE
DATA_JOB_COMPLETE     : FALSE
CTL_MAX_RUNTIME       : 1
FIRST_TIME            : FALSE
FIRST_CTL_MAX_RUNTIME : 0
FIRST_JOB_MAX_RUNTIME : 0
SQL_TRACE             : FALSE
METRICS               : TRUE
ASYNC                 : TRUE
-----------------------
ENABLE                : FALSE
REPEAT INTERVAL       : freq=daily; byhour=3; byminute=0; bysecond=0

9.5.4 エラーが発生した11gインスタンスのリセット(オプション9)

実行中にアップグレードのエラーが発生した場合は、問題を解決してから、エラーのflow_idを(-1)からNullにリセットすることでエラーが発生したインスタンスを再発行します。このインスタンスは、次回にスケジュールされたバックグラウンド制御ジョブの実行で処理されます。

詳細は、第9.10項「インスタンス・アップグレードのエラーの解決」を参照してください。

Reset errored 11g instances
=======================
The 11g instances which have encountered an error will have their
flow_id set to -1. This reset updates the flow_id back to null
so they can be processed in the next exection of the background job.
.
The rows in the upgrade_error_log table will have their type column
set to zero. The rows in this table are not removed so that history
is not lost.
.
NOTE: Ensure to schedule and enable the background job.
Are you sure Y/N:

9.6 アップグレードのセッションとジョブの停止

管理スクリプトを使用すると、実行中のセッションまたはジョブを停止できます。

注意:
実行中のアップグレードジョブを完了前に停止すると、Enterprise Managerコンソールを使用して残りのデータの問合せや表示ができなくなります。
バックグラウンド・ジョブでは、最新のインスタンスを最初にアップグレードするため、Upgrade Summary Report (Option 1)のMaximum Upgrade Date for Closed 11g instancesセクションで、最後にアップグレードされたインスタンスのタイムスタンプを調べることで、アップグレードの進行状況を確認できます。

次に示すように、読取り専用インスタンスのアップグレードを停止する方法は2通りあります。

- バックグラウンドのデータベース制御ジョブが開始されていたら、Stop Upgrade Database Background Sessions and Jobスクリプト(オプション8)を使用して、現在実行中のアップグレード・セッションとジョブをすべて停止します。すべてのジョブが停止するまでに、数分かかることがあります。

Stop Upgrade Database Background Sessions/Jobs
==============================================
All upgrade sessions and jobs should stop but this may require 5 minutes to take affect.

There will be a one minute wait before this procedure returns.
Are you sure Y/N: Y
Enter for MENU

Report Upgrade Database Sessions (オプション2)を使用して、実行中のジョブがないことを確認します。アップグレード・ジョブは、ユーザーが定義した時間にジョブを実行するようにスケジュールすることで、必要に応じて再開できます。この方法をお薦めします。

- 中間層アプリケーション(SOA管理対象サーバーなど)を起動します。
中間層アプリケーション(管理対象サーバーなど)が起動されると、クローズされたインスタンスのアップグレードが自動的に停止されます。管理スクリプトを使用すると、アップグレード・ジョブを別のときに実行するようにスケジュールできます。

9.7 不完全なアップグレードの再開

インスタンスのアップグレードが停止されている場合は、次に説明するように管理スクリプトを使用して、手動で再開する必要があります。

1. 管理スクリプト・オプション6のEnable/Disable background control jobを使用して、バックグラウンド制御ジョブを有効にします。
第9.5.2項「バックグラウンド制御ジョブの有効化と無効化(オプション6)」を参照してください。

2. 管理スクリプト・オプション5のChange background control job execution scheduleを使用して、指定した時間間隔でバックグラウンド制御ジョブが実行されるようにスケジュールします。
第9.5.1項「バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)」を参照してください。

3. 手順2で指定した時間間隔に達すると、バックグラウンド制御ジョブが開始されます。管理スクリプトのオプション1のReport Upgrade Summaryを使用して、アップグレード・ステータスを監視します。
表9-1「アップグレード管理スクリプトのメニュー・オプション」の「オプション1」を参照してください。

4. アップグレードが完了したら、Oracle Enterprise Manager Fusion Middleware Controlにログインし、「SOA」を開いて「soa-infra」(soa_server1)をクリックし、「SOAランタイム・ヘルス」セクションに「データ移行の完了」リンクが表示されていることを確認します。
第9.9.1項「データ移行の完了の確認」を参照してください。

9.8 SQL問合せによるアップグレード・ステータスの監視

この項では、管理スクリプトとともに、アップグレードの監視と検証に使用できるSQL問合せについて説明します。

検証内容

使用する問合せ

詳細

アップグレード中にフロー・インスタンスにエラーが発生した(flowIdが-1または-2に設定されている)。

Select count (*) from composite_instance where flow_id=-1;

select count(*) from composite_instance where flow_id = -1;

select count(*) from cube_instance where flow_id = -2

select count(*) from dlv_message where flow_id = -2;

select count(*) from mediator_instance where flow_id = -2;

アップグレード・アシスタントによるオープン・インスタンスのアップグレードが完了したら、SOAINFRAスキーマのUPGRADE_ERROR_LOG表に含まれる行を確認することをお薦めします。この表には、エラーが発生して12cにアップグレードされていないデータが格納されています。列typeでは、発生したエラーのタイプを特定します。UPGRDAE_ERROR_LOG表では、次に示す各タイプのエラーが報告されます。

- 0: このエラーは、前回のアップグレード実行で報告されています。Typeは、アップグレード管理スクリプトのResetting Errored 11g instances(オプション9)を実行したときに、0に設定されます。

- 1: インスタンスのアップグレード中にエラーが発生しました。

- 2: EDNエラー・イベント・ストアまたはアダプタ拒否メッセージのアップグレード中にエラーが発生しました。

- 9: メタデータのアップグレード中にエラーが発生しました。

- 12: データのアップグレード・プロセス中に一般エラーが発生しました。

これらの表にエラーが発生したレコードが存在していないことを確認することが重要です。

詳細は、第9.5.4項「エラーが発生した11gインスタンスのリセット(オプション9)」を参照してください。

すべてのオープン・インスタンスがアップグレードされた。

select count (*) from cube_instance where state < 5 and flow_id = -1;

select count (*) from dlv_message where  state in (0,1,4) and  flow_id = -1

select count (*) from mediator_instance where component_state between 4 and 15 and flow_id is null;

これらの問合せは、アップグレード後に実行して検証を行います。すべてのオープン・インスタンスが移行されている場合は、0行が返されます。

すべてのインスタンスが期待どおりにアップブレードされている(アップグレード後)。

select count (*) from composite_instance  where flow_id is null;

select count (*) from cube_instance where flow_id = -1;

select count (*) from dlv_message where flow_id = -1;

select count (*) from mediator_instance where flow_id is null;

SELECT count (*) from REJECTED_MESSAGE WHERE FLOW_ID IS NULL;

SELECT count (*) from EDN_EVENT_ERROR_STORE WHERE FLOW_ID IS NULL;

これらの問合せをアップグレード後に実行して、すべての問合せが0レコードを返すことを確認します。
これらの問合せによりレコードが生成された場合、該当するインスタンスはアップグレード・アシスタントでアップグレードされていません。詳細は、Oracleサポートに連絡してください。

9.9 Fusion Middleware Controlによるアップグレード・ステータスの監視

管理スクリプトに加えて、アップグレードの一般的なステータスを表示するには、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用することもできます。管理スクリプトでは、アップグレード・ジョブを詳細に管理制御できますが、次に示す事項はFusion Middleware Controlコンソールで監視できます。

- データ移行の完了の確認

- 不完全な(停止された)アップグレードの管理

- アップグレード時に失敗したインスタンスの表示

- コンポジットの再デプロイ前に作成されたインスタンスの表示

注意:
アップグレードの際に高度な管理タスク(アップグレードのスケジュールや時間間隔の変更など)を実行する必要がある場合は、「アップグレード管理スクリプトの使用」に記載されている管理スクリプトを使用する必要があります。

9.9.1 データ移行の完了の確認

Oracle Enterprise Manager Fusion Middleware Controlの「ターゲット・ナビゲーション」ペインで、「SOA」を開いて「soa-infra (soa_server1)」をクリックし、次に示すように、「SOAランタイム・ヘルス」セクションに「データ移行の完了」リンクが表示されていることを確認します。

図9-1 SOAランタイム・ヘルス: データ移行の完了

「データ移行の完了」をクリックして、次のメッセージが表示されることを確認します。

図9-2 移行完了

「OK」をクリックして、「移行完了」ダイアログ・ボックスを閉じます。「SOAランタイム・ヘルス」の移行ステータス・メッセージが表示されます(図9-3)。

図9-3 SOAランタイム・ヘルス: 移行ステータス・メッセージ

「このメッセージを閉じる」をクリックします。次の確認ダイアログが表示されます。

図9-4 データ非表示の確認

「はい」をクリックして、データ移行完了アラートを非表示にします。「SOAランタイム・ヘルス」セクションから、「このメッセージを閉じる」ボタンの表示がなくなります。

「いいえ」をクリックすると、「SOAランタイム・ヘルス」セクションにアラートが表示されたままになります。

9.9.2 不完全な(停止された)アップグレードの管理

Fusion Middleware Controlを使用して、不完全なアップグレードを管理できます。不完全なアップグレードは次の状況で発生します。

- オープンまたはクローズされたインスタンスが一切アップグレードされていない。

- 一部のオープン・インスタンスがアップグレードされている。たとえば、オープン・インスタンスのアップグレード中に、管理スクリプトのオプション8(Stop upgrade database background sessions and jobs)を使用して、手動でバックグラウンド制御ジョブを停止した場合です。

- オープン・インスタンスのみがアップグレードされている。

- クローズされたインスタンスの一部がアップグレードされているか、まったくアップグレードされていない。

注意:
インスタンスのアップグレードが完了する前にSOA管理対象サーバーを起動すると、Fusion Middleware Controlに「データの移行が完了していません」というアップグレード・ステータスが表示され、「不完全なアップグレードの再開」の説明に従ってアップグレードを手動で再開する必要があります。

アップグレードが未完了の場合、Fusion Middleware Controlでは、アップグレードが未完了のすべての11gインスタンスの最も新しい作成日を表示できます。最も新しい作成日は、12c Enterprise Managerコンソールに一部のインスタンスが表示されない原因を特定する際にも役立つため重要です。たとえば、一部の古い11gのクローズされたインスタンスがFusion Middleware Controlコンソールに表示されないことに気付いたときには、アップグレードされていないすべてのインスタンスの最も新しい作成日を調べると、アップグレードが該当するインスタンスに到達していないためかどうかを判断するのに役立ちます。

Middleware Controlを使用して、不完全な(停止された)アップグレードのステータスを確認するには、次の手順を実行します。

Oracle Enterprise Manager Fusion Middleware Controlの「ターゲット・ナビゲーション」ペインで、「SOA」を開いて「soa-infra (soa_server1)」をクリックします。この画面の「SOAランタイム・ヘルス」セクションに、現在のアップグレード・ステータスが表示されます。不完全なアップグレードの場合、ステータスは「データの移行が完了していません」になります。この画面は、5分ごとにリフレッシュできます。

図9-5 SOAランタイム・ヘルス: データの移行が完了していません

「データの移行が完了していません」をクリックすると、次のメッセージが表示されます。

図9-6 SOAランタイム・ヘルス: 移行が完了していない場合のステータス・メッセージ

データ移行のステータス:

- アクティブ・インスタンス: アップグレードされたオープン・インスタンスのステータスが示されます。前掲の例では、オープン・インスタンスはアップグレードが完了しています(ステータスは、「完了」になります)。

- 非アクティブ・インスタンス: アップグレードされたクローズ済インスタンスのステータスが示されます。前掲の例では、2013年7月9日より古いクローズ済インスタンスは、まだアップグレードされていません。アップグレードは最新のものから古いものへの順で実行されます。アップグレードが済んでいないインスタンスは、Fusion Middleware Controlのレポートやビューに表示されません。レポートは、5分ごとにリフレッシュできます。

注意:
実行中のアップグレードについての詳細なレポートは、Report Upgrade Summaryスクリプト(オプション1)を実行します(第9.4.2項「管理スクリプトの実行」を参照)。

すべてのクローズ済インスタンスがアップグレードされると、リンクは「データ移行の完了」に変化します(図9-2を参照)。

9.9.3 アップグレード時に失敗したインスタンスの表示

アップグレード中に失敗した11gインスタンスは、コンポジット・レベルでのみアップグレード後に表示できます。このようなインスタンスは、パーティション・レベルでは表示されません。

このようなインスタンスを表示するには、デプロイ済コンポジットの「フロー・インスタンス」タブに移動します(図9-7を参照)。

図9-7 アップグレード時に失敗したインスタンスのコンポジット・レベルを使用した表示

注意: 「検索オプション」を使用すると、特定のインスタンス作成時間または作成日の範囲を指定できます。

9.9.4 コンポジットの再デプロイ前に作成されたインスタンスの表示

コンポジットが同一のアップグレード前リビジョンで再デプロイされている場合、該当するインスタンスを表示するには、パーティション・レベル(コンポジット・レベルではありません)に移動する必要があります(図9-8を参照)。

ただし、アップグレード後に作成されたインスタンスは、12cのコンポジット・レベルで表示できます。

図9-8 アップグレード前に作成したインスタンスのパーティション・レベルを使用した表示

9.10 インスタンス・アップグレードのエラーの解決

アップグレードが失敗した場合や、Report Upgrade Summaryレポート(オプション1)のUPGRADE ERROR COUNTセクションに、現在の実行でのエラー発生が示されている場合は、アップグレードに向けてインスタンスを再発行する前に、エラーを解決する必要があります。

upgrade_error_logは、エラーの状況を診断するために使用でき、問題を解決する手がかりを示すこともあります。一般的なアップグレード・エラーの解決方法の詳細は、第A.3項「失敗したアップグレードからのリカバリ」を参照してください。

注意:
次のメッセージは、フォルトのステータスを正しく識別するための十分な情報がない場合に表示されます: エラー・メッセージがありません。インスタンス・アップグレード中に生成されました。
このメッセージはアップグレード中のエラーに一時的なフォルト・ステータスが割り当てられたことを示します。これらのエラー・メッセージは無視できます。

次の表では、各エラーと考えられる解決方法について説明します。

エラー・タイプ

説明

エラー・メッセージ

解決方法

0

これらのエラーは、前回のアップグレード実行で報告されています。
タイプは、エラーが発生したインスタンスをリセットすると0に設定されます(第9.5.4項「エラーが発生した11gインスタンスのリセット(オプション9)」を参照)。

エラー・メッセージには、前回のエラー・タイプに基づいて、発生したエラーに関する詳細が示されます。

前回の実行からのエラーを修正し、管理スクリプトを使用してリセットします。

1

インスタンスのアップグレード中にエラーが発生しました。

エラー・メッセージには、アップグレード・スクリプトからスローされた実際のエラーが含まれています。また、エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースも示されます。

根本原因のデバッグは、トレースとともに実際のエラーを調べて、エラーの場所を見つけることで実行できます。
Info列に移入されたECIDは、失敗したインスタンスのデータを取得する場合に役立ちます。

2

EDNエラー・イベント・ストアまたはアダプタ拒否メッセージのアップグレード中にエラーが発生しました。

エラー・メッセージには、失敗したコンポーネントを特定するための文字列upgrade_rejected_message/upgrade_edn_messageが含まれています。
これには、失敗したメッセージのIDとともに、失敗の理由が含まれています。

デバッグは、エラーの実際の理由を分析することで実行できます。失敗したアダプタ/EDNメッセージの詳細を取得するために、ERROR_MSGの一部としてログ出力されたIDを使用できます。

9

メタデータのアップグレード中にエラーが発生しました。

メタデータのアップグレードに失敗したcomposite_dnの詳細が含まれています。
エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースとともに、アップグレード・スクリプトからスローされた実際のエラーも含まれます。

デバッグは、トレースとともに実際のエラーを調べて、エラーの場所を見つけることで実行できます。Info列では、メタデータのアップグレードに失敗したcomposite_dnの全体が得られます。

12

データのアップグレード・プロセス中に一般エラーが発生しました。これは、単一のインスタンスに関するものではありません。

Infoには、文字列migrate_soaのみが含まれます。
エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースとともに、アップグレード・スクリプトからスローされた実際のエラーも含まれます。

このエラー・タイプは、アップグレードの実行中に、データのアップグレードが全体として失敗したときに、失敗が必ずしも特定のインスタンスに関連しない場合に報告されます。
このタイプのエラーの一例として、TEMP表領域の問題が考えられます。

エラーを解決したら、次の手順を実行してアップグレードを再開します。

1. upgrade_error_logに表示されたエラー条件を修正します。

2. 「エラーが発生した11gインスタンスのリセット(オプション9)」の説明に従って、upgrade_error_logからエラー・フラグを削除します。これにより、エラーが発生したインスタンスを後続の実行で再発行できるようになります。

3. 「バックグラウンド制御ジョブの有効化と無効化(オプション6)」の説明に従って、バックグラウンド制御ジョブを有効にします。別個のアップグレード実行をトリガーする必要があります。

4. バックグラウンド制御ジョブの繰り返し間隔と継続時間を必要に応じて変更します(「バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)」を参照)。

5. Report Summary Upgradeスクリプト(オプション1)を使用して、アップグレード・ステータスを監視します。レポートのUPGRADE ERROR COUNTセクションに、エラーが0個と示される必要があります。エラーが残っている場合は、問題を解決してから、ここに示した手順を繰り返します。

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

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

- 第A.1項「リリース・ノートの確認」

- 第A.2項「サーバー起動エラーの解決」

- 第A.3項「失敗したアップグレードからのリカバリ」

- 第A.4項「失敗したBAMアップグレードからのリカバリ」

- 第A.5項「OWSMクラスタのアップグレード後のコンポーネントの再ワイヤリング」

- 第A.6項「アップグレード時の暗号化の問題」

- 第A.7項「Oracle Service Busのトラブルシューティング」

- 第A.8項「アップグレード・アシスタントによるサポート対象外ドメインのアップグレード」

- 第A.9項「インスタンスのアップグレード後に表示されなくなるビジネス・ルールの監査証跡」

- 第A.10項「Coherenceキャッシュ例外の解決」

- 第A.11項「WSDLで生じるカスタム例外の欠落要素」

- 第A.12項「リモート・クライアントを介したServerSocketへの接続」

A.1 リリース・ノートの確認

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

A.2 サーバー起動エラーの解決

サーバーが起動しない場合やサーバーがAdminModeで起動する場合、最も可能性の高い原因は、以前の環境からのsetDomainEnv.shの変更内容が12cドメインに再適用されていないことです。11gのsetDomainEnvファイルと新しい12cのsetDomainEnvファイルを比較して、カスタムの変更をアップグレード後に追加してください。

詳細は、起動スクリプトへのカスタマイズの再適用に関する説明を参照してください。

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

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

- アップグレード・アシスタントを実行して、_SOAINFRAスキーマをアップグレードしているときにエラーが発生した場合は、スキーマのエラーを修正してから、バッチ・ジョブを再実行する必要があります。
このリカバリ方法は、アップグレード・アシスタントの初回実行時に、スキーマ・オプションを選択した場合にのみ適用します。

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

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

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

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

BAMアップグレードのみ:
CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前にOracle BAMテンプレートの名前を変更する。」を参照)、再構成ウィザードを再度起動します。
このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項の手順を実行する必要があります。その後で、再構成プロセスを再度実行してみてください。

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

この項は、BAMサーバーがドメイン内に存在する場合にのみ当てはまります。BAMアップグレードの一環として、BAMアーカイブを11gからエクスポートして、それをBAM 12cにインポートできます。このプロセス中にエラーが返された場合は、この項を使用して問題の解決にあたってください。

A.4.1 エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行

一般的なエラーは、データの変更内容をロール・バックして、オプションを変更したスクリプトを再実行することで解決できることがあります。

すべてのデータ変更内容のロールバック:

1. SOAデータベースでSQLセッションを開きます。

2. SOAINFRAスキーマ・ユーザーとしてログインし、次のスクリプトを実行して、すべてのデータ変更内容をロールバックします。

"<exportDir>/rollBackBPMProcessCubesMigration.sql"

使用しているオペレーティング・システムの推奨事項を確認してください。

- UNIXオペレーティング・システムのエラー処理

- Windowsオペレーティング・システムのエラー処理

A.4.2 UNIXオペレーティング・システムのエラー処理

移行時に予期しないエラーが発生した場合は、問題を修正するために次の手順を実行してみてください。

インポート・フェーズで発生したエラーの場合:

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プロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。

1. (<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。

2. <exportDir>の内容を削除します。

3. シェル・スクリプト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.*にある移行のログを調べます。

A.4.3 Windowsオペレーティング・システムのエラー処理

前述したように、すべてのデータ変更内容をロールバックして、次を実行してみてください。

インポート・フェーズで発生したエラーの場合:

次の各項で説明しているとおりに、アーカイブを再インポートします。

- (Windowsのみ) ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。(このコマンドでは、-datamodeパラメータと-migrateパラメータを使用します。)

- (Windowsのみ) アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。(このコマンドでは、-datamodeパラメータと-migrateパラメータを使用します。)

- (Windowsのみ: exportType=ALLの場合) 完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。(このコマンドでは、-datamodeパラメータと-migrateパラメータを使用します。)

エクスポート・フェーズで発生したエラーの場合:

BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。

1. (<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。

2. <exportDir>の内容を削除します。

3. シェル・スクリプト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]

4. 「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」の残りの移行手順を繰り返します。

A.5 OWSMクラスタのアップグレード後のコンポーネントの再ワイヤリング

OWSMに対するwsm-pmのターゲット設定を変更して、wsm-pmがアップグレード後のOWSMクラスタのみに向けてターゲット設定されたら、Oracle WebLogic Serverで、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシー・マネージャの自動検出にクロス・コンポーネント・ワイヤリング使用する方法に関する項の説明に従って、コンポーネントの再ワイヤリングが必要になります。

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

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

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

このエラーの再発を防止するには、その後のアップグレードを実行する前に、第2.1.6項「強化された暗号化(AES 256)の使用」の情報を使用してポリシー・ファイルを適用します。

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

Oracle Service Busでアップグレード後の問題が発生した場合は、次の内容を確認して、関連する解決方法を適用してください。

- 第A.7.1項「クラスタのフロントエンド・ホストとしてOHSを使用するOSBのアップグレード後のHTTP 404エラー」

- 第A.7.2項「OSBコンソールへのアクセス時のHTTP 404エラー」

A.7.1 クラスタのフロントエンド・ホストとしてOHSを使用するOSBのアップグレード後のHTTP 404エラー

クラスタ・ドメインのフロントエンド・ホストとして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>

A.7.2 OSBコンソールへのアクセス時のHTTP 404エラー

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を直接入力してみてください。

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

アップグレード・アシスタントから、指定されたドメインをアップグレードできないというエラーが返されたときには、詳細についてOracleサポートに問い合せてください。サポート対象のドメイン構成は、「ドメイン・アップグレードの制限の理解」で説明しています。

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

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

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

A.10 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に変更するか、実際のマシン名を指定します。

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

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

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

A.12 リモート・クライアントを介したServerSocketへの接続

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

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

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。