| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
|
前 |
次 |
アップグレードを開始する前に、必要なアップグレード前タスクを完了しておく必要があります。必要なタスクを完了しないと、アップグレードが失敗したり、システムの停止時間が長引いたりする可能性があります。各自のデプロイメントに該当するタスクのみを完了してください。
注意:
アップグレードするOracle SOA製品によっては、追加のアップグレード前タスクを実行する必要がある場合があります。Oracle Service Busやユーザー・メッセージング・サービスなどの製品には、アップグレード前およびアップグレード後の追加構成タスクが必要になることがあります。
FMWという名前の非SYSDBAユーザーを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限はありますが、完全な管理者権限はありません。 アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に、このチェックリスト内の作業を実行します。
アップグレードはサーバーが停止している間に実行されます。このチェックリストでは、停止時間を抑えるためにアップグレード前に実行できる、重要だが時間がかかることが多いアップグレード前作業を示します。アップグレード・プロセスの開始前に行える準備が多いほど、オフラインでかかる時間が少なくなります。
注意:
実行するアップグレード前手順は、既存のシステムの構成、アップグレードするコンポーネント、およびアップグレードと構成プロセスの最後に作成する環境によって異なります。各自の構成やユースケースに該当するタスクのみを完了してください。表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク
| タスク | 説明 |
|---|---|
必須 既存の環境の完全なバックアップを作成します。 |
アップグレードしようとしているスキーマを含めて、システムに重要なファイルとデータベースをすべてバックアップします。アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再度開始する必要があります。 「完全なバックアップの作成」を参照してください。
|
オプション 使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。 |
システム・ファイルの完全なバックアップを作成するだけでなく、本番環境をクローニングしておくことも強くお薦めします。この環境は、アップグレードをテストするために使用されます。 「本番環境のテスト用クローニング」を参照してください。 |
必須 サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。 警告: サポートされている最新のオペレーティング・システムを使用できない場合は、アップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。 |
(オペレーティング・システムを含む)ハードウェアとソフトウェアの構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。また、12c製品のディストリビューションをインストールする前に、サポート対象バージョンのJDKを使用していることを確認してください。 動作保証の要件は頻繁に更新されるため、アップグレードの開始直前にこの情報を確認することをお薦めします。 アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。 動作保証とシステム要件の確認に関する項を参照してください。 |
32ビット・オペレーティング・システムのみで必要 アップグレードの前に、64ビット・オペレーティング・システムに移行します。 |
これは、現在サポート対象外の32ビット・オペレーティング・システムを実行している場合にのみ必要になります。 「32ビットから64ビット・オペレーティング・システムへの移行」を参照してください。 |
オプション 強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。 |
Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。 強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。 「強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新」を参照してください。 |
オプション アップグレードする前に、期限切れまたは未使用のデータをパージします。 |
パフォーマンスを最適化するために、アップグレード後の環境で使用されない、データおよびオブジェクトをパージすることをお薦めします。 「未使用データのパージ」を参照してください。 |
| Oracle Databaseユーザーのみ必要 エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12c (12.2.1.2)のデータベース・サーバー上でエディションを作成する必要があります。 | エディション・ベースの再定義(EBR)データベースを使用している場合、アップグレードの開始前にエディションを作成する必要があります。 「エディション・ベースの再定義のためのサーバー上でのエディションの作成」を参照してください。 |
オプション Upgrade Assistantを実行するために非SYSDBAユーザーを作成します。 |
Upgrade Assistantを実行するには、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理権限なしでUpgrade Assistantを実行できます。 |
オプション 開始する前に、現在ドメイン内にあるスキーマを識別します。 |
アップグレードの開始前に、アップグレード前のドメインに存在するスキーマを把握することが重要です。スキーマの所有者名とパスワード、および各スキーマのバージョンを知る必要があります。 「アップグレードに対応可能な既存のスキーマの特定」を参照してください。 |
アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。
アップグレードが失敗した場合にコンテンツをそのアップグレード前の状態にリストアできるよう、バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。
実際のアップグレードに進む前に、Upgrade Assistantの「前提条件」画面に、バックアップを実行してあることの確認を求めるメッセージが表示されます。ただし、Upgrade Assistantではバックアップが作成されていることは確認しないため注意してください。
Oracle Fusion Middlewareの管理の環境のバックアップ
Oracle Fusion Middlewareのアップグレードのプランニングの12cのためのOracleデータベースのアップグレードおよび準備
システムの完全なバックアップの作成に加え、スキーマ・バージョン・レジストリのバックアップ、およびアップグレード後の環境で使用するカスタム設定も作成する必要があります。次の資料も参照してください。
SYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。システム・バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。
SYSTEM.SCHEMA_VERSION_REGISTRY$表に、各Fusion Middlewareスキーマに対応する行があります。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。Upgrade Assistantを実行する前に、必ず既存のデータベース・スキーマおよびスキーマ・バージョン・レジストリをバックアップしてください。
注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。アップグレード中に、バックアップを実行してあることの確認を求められます。アップグレード前の環境で、生成されたドメイン、またはサーバー起動スクリプトを変更した場合は、これらの変更がインストール、ドメイン・アップグレードおよび再構成操作の間に上書きされることに注意することが重要です。
すべてのドメイン・インストールには、動的に生成されたドメイン、およびsetDomainEnvなどのサーバー起動スクリプトが含まれています。これらのファイルは、インストールおよびアップグレード・プロセスの間に新しいバージョンに置き換えられます。カスタムのドメインレベルの環境設定を保持するには、スクリプトを直接変更するのではなく、アップグレードする前に別のファイルを作成してカスタムのドメイン情報を格納することをお薦めします。
たとえば、ドメイン内のすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のコマンドライン・オプションを指定する、または追加の環境変数を指定するなどの構成が可能です。このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。
setUserOverridesファイル内の起動のカスタマイズを示します。# add custom libraries to the WebLogic Server system claspath
if [ "${POST_CLASSPATH}" != "" ] ; then
POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
else
POST_CLASSPATH="${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
fi
# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcustom.property.key=custom.value"
サーバーの起動中にsetUserOverridesファイルが存在する場合、このファイルが起動シーケンスに含まれ、このファイルにオーバーライドがあれば、有効になります。setUserOverridesファイルは、domain_home/binディレクトリに格納する必要があります。
注意:
アップグレード前に、setUserOverridesスクリプトを作成できない場合は、Oracle WebLogic Serverのアップグレードの起動スクリプトへのカスタマイズの再適用の説明に従って、設定を再適用する必要があります。
実際の本番環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードします。
テスト用に本番環境をクローニングすることをお薦めしますが、必須ではありません。
注意:
このドキュメントでは、すべてのコンポーネントおよびオペレーティング・システムのクローニング手順を記載していません。クローニング手順は、コンポーネントおよびオペレーティング・システムに固有です。大まかに言えば、コンポーネント・ドメインのアップグレード前バージョンをテスト・マシンにインストールし、リポジトリ作成ユーティリティ(RCU)を使用して必要なスキーマを作成して、アップグレードを実行します。アップグレードに関する問題を明らかにし、修正します。
エンドツーエンドのアップグレードを完了させる練習をします。
アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。
アップグレードの完了までに必要な時間を理解します。
データベース・リソースの使用(一時表領域、PGAなど)について理解します。
注意:
クローニングした本番環境でアップグレード前の準備状況チェックを実行すれば、データで発生しうるアップグレード時の問題は特定できますが、正常なアップグレードの万全を期すためには、クローニングした環境で完全なテスト・アップグレードを実行する必要があります。ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。
注意:
動作保証、システム要件および相互運用性情報を確認する場合、特に32ビットまたは64ビットのシステム要件を確認するようにしてください。32ビットまたは64ビットの環境専用として設計されているソフトウェアを明示的にダウンロードすることが重要です。警告:
アップグレードを開始する前に、現在の環境に最新のパッチが適用されていることを確認してください。動作保証は、特に指定がないかぎり、完全にパッチが適用された環境に基づいています。Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。
新しい動作保証要件が確認されると、それらはすぐに動作保証に関する適切なドキュメントに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。詳細は、12c (12.2.1.2)の動作保証マトリックスに関する説明を参照してください。
ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。
Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証の要件が満たされていることを確認してください。たとえば、12c (12.2.1.2)の動作保証マトリックスに、ご使用の製品を64ビットOracle Linux 7上にインストールすることが動作保証されていると示されている場合、「システム要件と仕様」ドキュメントを使用して、Oracle Linux 7システムが最低限必要な仕様(ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチ、およびその他のオペレーティング・システム固有のアイテムなど)を満たしていることを確認します。このドキュメントはOracle Technology Network (OTN)のドキュメント・ライブラリとは別の場所にあり、必要に応じて更新されます。
注意:
アップグレード準備としてOracle Fusion Middlewareリリース12cソフトウェアをインストールする際は、既存のアップグレード前のOracle Fusion Middlewareソフトウェアのインストールおよび構成に使用したものと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これによって、正しい所有者とグループが新しいOracle Fusion Middleware 12cのファイルおよびディレクトリに確実に適用されます。32ビット環境を実行している場合は、さらに一連の手順を実行する必要があります。
32ビットのオペレーティング・システムを使用している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。
Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。
次のタスクでは、ホストは、32ビット・ソース・マシンを指し、ターゲットは、新しい64ビット・ターゲット・マシンを指します。
注意:
これらの手順は、データベースが別のホスト上にあり、移動されないことを前提としています。注意:
これらの手順は、オペレーティング・システム・アップグレード・プロセスの例として説明されているため、特定のオペレーティング・システムを更新する場合に実行する必要がある手順がすべて含まれている場合と含まれていない場合があります。詳細は、使用しているオペレーティング・システムのアップグレード・ドキュメントを参照してください。アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。
アップグレードの前に、すべてのプロセスを停止する必要があります。ホスト上で管理対象サーバー、管理サーバーおよびノード・マネージャが起動されている場合は、これらも含めて停止する必要があります。
管理対象サーバーを停止します
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
SOAサーバーおよびプロセスは、次の順番で停止してください。
Business Activity Monitoring (BAM)管理対象サーバー
Oracle Service Bus (OSB)管理対象サーバー
サービス指向アーキテクチャ(SOA)管理対象サーバー
Oracle Web Services Manager (OWSM)管理対象サーバー
管理サーバーを停止します
管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。
管理サーバーを停止するには、stopWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
ノード・マネージャを停止します
ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。
またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。
11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。
注意:
同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあります。11gのファイルのバックアップの詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。
アップグレード時に、次のコンテンツにアクセスする必要があります。
11gドメイン・ホーム
11g /nodemanager directory located in $ORACLE_HOME/wlserver/common/
『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項で説明されているバックアップおよびリカバリ手順の一部は、製品固有のものです。完全バックアップを作成するまでアップグレードを続行しないでください。
ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。
IPアドレスおよびホスト名を変更するプロセスは、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムの管理ドキュメントを参照してください。
11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。
64ビットのターゲット・マシンに11gのファイルをリストアする方法の詳細は、『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。
アップグレードには、ホーム外のアプローチをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。
インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。
ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。
詳細なアップグレード手順は、アップグレードするコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。
注意:
ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。「32ビット・ホスト・マシンからすべてのファイルをバックアップする」の一部として32ビット・ソース・マシンからバックアップした11gノード・マネージャ・ファイルを使用します。Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。
注意:
ご使用のデータベース・バージョンがサポート対象外だった場合は、アップグレードを開始する前に、サポート対象のバージョンにアップグレードする必要があります。Oracle Fusion Middlewareのアップグレードのプランニングの12cのためのOracleデータベースのアップグレードと準備を参照してください。Oracle Technology Network (OTN)で、Oracle Fusion Middlewareのサポート対象システム構成に関する情報を参照して、現在使用しているJDKがサポートされていることを確認します。
このマニュアルの発行時点で、12c (12.2.1.2)の動作保証済JDKは、1.8.0_101です。
http://www.oracle.com/technetwork/java/javase/downloads/index.htmlJDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。このため、JDKは/home/oracle/products/jdkディレクトリにインストールすることをお薦めします。
汎用インストーラとプラットフォーム固有のインストーラの相違点の詳細は、Oracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルの汎用とプラットフォーム固有のディストリビューションとの相違点の理解に関する項を参照してください。
アップグレード後の環境で、強化された暗号化(Advanced Encryption Standard (AES) 256など)を使用する予定がある場合に行います。アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。
Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。これらのAPIによって、開発者はアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。
Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。詳細は、Java暗号化アーキテクチャOracleプロバイダのドキュメントを参照してください。
注意:
アップグレードの開始前に、これらのポリシー・ファイルをJDKに適用せずに強化された暗号化を使用しようとすると、アップグレードに失敗することがあり、その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。
注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の次の情報を参照してください。パージおよびパーティション化の方法の開発
データベース増分管理戦略の策定
一部のコンポーネントには自動化されたパージ・スクリプトがあります。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。
クローズされた11gインスタンス・データを移行する場合は、アップグレードの実行前にインスタンス・パージ・スクリプトを実行します。「インスタンス・データ・パージ・スクリプトの使用」を参照してください。
エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。
エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。すべての変更が実行およびテストされている場合のみ、アプリケーションの新バージョンをユーザーが使用できるようにしてください。
注意:
このタスクは、DBA権限を持つOracle Databaseユーザーのみが実行する必要があります。エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11gまたは12cエディションの子である必要があります。
データベース・サーバーにエディションを作成するには、SYSユーザー(またはDBA権限のある別のOracleユーザー)としてログインし、次のコマンドを入力します。
create edition Oracle_FMW_12_2_1_1 as child of Oracle_FMW_11_1_1_7_0;
ここで、Oracle_FMW_11_1_1_7_0は、11.1.1.7スキーマを作成したときにRCU 11.1.1.7で指定したエディション名の例です。エディションを作成する際は、実際に使用する名前を入力してください。
次のメッセージは、エディションが正常に作成されたことを示します。
エディションが作成されました。
アップグレードの間、再構成ウィザードを実行して既存のドメインを再構成するよう要求されます。再構成ウィザードの実行前に、データベースのデフォルト・エディションを指定する必要があります。次のSQLを使用して、データベースのデフォルト・エディション名を手動で設定します。次に例を示します。
ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1_1;
Upgrade Assistantを実行するために、FMWという名前の非SYSDBAを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限はありますが、完全な管理者権限はありません。
注意
前のリリースで非SYSDBAユーザーFMWを作成した場合は、アップグレードを開始する前に、このユーザーを削除して再作成する必要があります。古いFMWユーザーでUpgrade Assistantを実行すると、新しい権限が追加されているためにアップグレードが失敗する可能性があります。既存のFMWユーザーを変更するのではなく、ユーザーを削除して再作成することをお薦めします。v$xatrans$表は存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。また、v$xatrans$表に対する選択権限付与は、Oracle Identity Managerでのみ必要となります。構成にOracle Identity Managerが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。 grant select on v$xatrans$ to FMW with grant option;
welcome1がパスワードです。権限を付与する際に、実際のパスワードを指定していることを確認します。create user FMW identified by welcome1; grant dba to FMW; grant execute on DBMS_LOB to FMW with grant option; grant execute on DBMS_OUTPUT to FMW with grant option; grant execute on DBMS_STATS to FMW with grant option; grant execute on sys.dbms_aqadm to FMW with grant option; grant execute on sys.dbms_aqin to FMW with grant option; grant execute on sys.dbms_aqjms to FMW with grant option; grant execute on sys.dbms_aq to FMW with grant option; grant execute on utl_file to FMW with grant option; grant execute on dbms_lock to FMW with grant option; grant select on sys.V_$INSTANCE to FMW with grant option; grant select on sys.GV_$INSTANCE to FMW with grant option; grant select on sys.V_$SESSION to FMW with grant option; grant select on sys.GV_$SESSION to FMW with grant option; grant select on dba_scheduler_jobs to FMW with grant option; grant select on dba_scheduler_job_run_details to FMW with grant option; grant select on dba_scheduler_running_jobs to FMW with grant option; grant select on dba_aq_agents to FMW with grant option; grant execute on sys.DBMS_SHARED_POOL to FMW with grant option; grant select on dba_2pc_pending to FMW with grant option; grant select on dba_pending_transactions to FMW with grant option; grant execute on DBMS_FLASHBACK to FMW with grant option; grant execute on dbms_crypto to FMW with grant option; grant execute on DBMS_REPUTIL to FMW with grant option; grant execute on dbms_job to FMW with grant option; grant select on pending_trans$ to FMW with grant option; grant select on dba_scheduler_job_classes to fmw with grant option; grant select on SYS.DBA_DATA_FILES to FMW with grant option; grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option; grant select on v$xatrans$ to FMW with grant option; grant execute on sys.dbms_system to FMW with grant option; grant execute on DBMS_SCHEDULER to FMW with grant option; grant select on dba_data_files to FMW with grant option; grant execute on UTL_RAW to FMW with grant option; grant execute on DBMS_XMLDOM to FMW with grant option; grant execute on DBMS_APPLICATION_INFO to FMW with grant option; grant execute on DBMS_UTILITY to FMW with grant option; grant execute on DBMS_SESSION to FMW with grant option; grant execute on DBMS_METADATA to FMW with grant option; grant execute on DBMS_XMLGEN to FMW with grant option; grant execute on DBMS_DATAPUMP to FMW with grant option; grant execute on DBMS_MVIEW to FMW with grant option; grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option; grant select on dba_queue_subscribers to FMW with grant option; grant execute on SYS.DBMS_ASSERT to FMW with grant option; grant select on dba_subscr_registrations to FMW with grant option; grant manage scheduler to FMW;
注意:
Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。
このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。
Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることや、個々のスキーマを選択してアップグレードすることができます。決定に役立つよう、次の手順に従って、アップグレード可能なすべてのスキーマのリストを表示します。
Oracleデータベースを使用している場合は、Oracle DBA権限があるアカウントを使用することでデータベースに接続し、SQL*Plusから次を実行します。
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列内の値が11.1.1.7.0以上で、STATUS列の値がVALIDの場合、スキーマは、アップグレードのサポート対象となります。
あるスキーマでアップグレードの必要がない場合、schema_version_registry表には、アップグレード前のバージョンでそのスキーマが保持されます。
既存スキーマに使用されていたスキーマ接頭辞名をメモします。新しい12cスキーマを作成するときに、これと同じ接頭辞を使用することになります。
注意
既存のスキーマがサポート対象バージョンでない場合は、12c (12.2.1.2)のアップグレード手順を使用する前に、それらをサポート対象バージョンにアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。
Oracle Enterprise Data Quality、Oracle GoldenGate MonitorおよびOracle GoldenGate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。
11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードを実行する前に新しいOPSSスキーマを必ず作成してください。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。
Oracle Fusion Middleware 12c (12.2.1.2)リリースでアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.2)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。
アップグレード前の環境によっては、Oracle Fusion Middlewareアップグレード前の要件に加えて、SOA固有の追加アップグレード・タスクを完了しておく必要がある場合もあります。
この項では、12c (12.2.1.1)にアップグレードするSOA、Business Process Managementまたは統合製品に適用するアップグレード前のタスクについて説明しています。各自の環境に当てはまるタスクのみを実行してください。
注意:
アップグレードの準備を適切に行わないことが、リカバリ不能なエラーやアップグレードの失敗につながります。アップグレードの開始前に、該当するすべてのアップグレード前タスクが完了していることを確認してください。
| アップグレード前タスク | 詳細 |
|---|---|
必須 環境がOracle SOA SuiteおよびBPM 12c (12.2.1.2)へのアップグレードのOracle Database要件を満たしていることを確認します |
|
必須 表領域のサイズが適切に設定されていることを確認します(不十分なサイズに設定すると、アップグレードは失敗します)。 |
|
| SOA Composerユーザーのみ: コミットされていない変更はアップグレード後には使用できないことに注意してください。 | アップグレード前のSOA Composerの変更のコミット |
| 以前の12cリリースからアップグレードする場合にのみ必要です。 アップグレード前に、ドメインから既存のcloudsdkデプロイメントを削除します。 |
以前の12cリリースからのアップグレード時のcloudsdkアプリケーションの削除 |
ユーザー・メッセージング・サービス(UMS)をアップグレードする場合にのみ必要です SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。 |
|
Oracle Service Bus (OSB)をアップグレードする場合にのみ必要です SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行します。 |
|
オプション スタンドアロンOracle HTTP Serverをアップグレードします。これは、アップグレードの前でも後でも実行できます。 |
Fusion Middleware 12c (12.2.1.2)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。
Oracle SOA SuiteおよびBPM 12c (12.2.1.2)にアップグレードする場合のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認することが重要です。Fusion Middleware 12c (12.2.1.2)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。最新の情報については、常に最新のデータベースの動作保証マトリックスを参照してください。
『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のデータベース・プロファイルのカスタム変数に関する項
Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理のSOAコンポジット・アプリケーションの概要に関する項
『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベースのプロファイルまたはサイズの確認に関する項
アップグレードの失敗を防止するために、既存のSOAデータベース表領域に、データ・ファイルをさらに追加することをお薦めします。
すべての表領域にとって重要なことですが、11g SOAINFRA表領域とIAS_TEMP表領域のサイズをアップグレードが成功するように設定することが特に重要です。
注意:
サイズ設定のエラーが原因でデータベース・スキーマのアップグレードに失敗すると、ディスク領域を追加するだけではアップグレードを再試行できません。スキーマが不整合な状態になり、「INVALID」としてマークされた可能性があります。元の、アップグレード前の環境をバックアップからリストアしないと、このエラーからはリカバリできません。
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;
アップグレード前の表領域のサイズ設定の詳細は、データ・ファイルの作成および表領域への追加に関する項を参照してください。
アップグレードする前にSOA Composerサンドボックスへの変更をコミットまたはロールバックしない場合、変更が新しい環境に伝播されないことがあります。
アップグレードを開始する前に、アップグレードされた環境に伝播するすべての変更をコミットし、伝播したくない変更をロールバックしていることを確認します。
カスタム・アプリケーションをSOA 11gドメインにデプロイしていた場合、アップグレード手順の実行後、アプリケーションのデプロイメントはOracle Fusion Middleware 11gでの場合と同様に機能します。
新しいOracle 12c機能を利用するには、Oracle SOA SuiteまたはOracle Business Process ManagementのQuick Start for Developersをダウンロードしてインストールします。
Quick Start for Developersディストリビューションには、Oracle JDeveloper 12cユーザーに、Oracle SOA SuiteおよびOracle Business Process Managementのアプリケーションを開発するために必要な拡張機能を提供します。
詳細は、「Oracle SOA Suite Quick Start for Developersのインストール」を参照してください。
注意:
新しいOracle SOA 12c機能を使用するには、Oracle QuickStartが必要です。アップグレード前の環境にcloudsdkをインストールした場合は、アップグレードの開始前にそれを削除する必要があります。
この手順は、以前の12cリリースでcloudsdkがデプロイされた場合にのみ必要です。
cloudsdkの12c (12.2.1.2)バージョンは自動的にサーバーにデプロイされ、ネーミング規則の変更によって、以前にデプロイされたアプリケーションと競合する可能性があります。SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。
ユーザー・メッセージング・サービスを11gから12cにアップグレードする場合は、追加のアップグレード前タスク(構成ファイルを手動で管理対象サーバーから管理サーバーにコピーするなど)を実行する必要がある場合があります。以前の12cリリースからUMSをアップグレードする場合、このタスクをもう一度実行する必要はありません。
詳細は、「ユーザー・メッセージング・サービスのアップグレード」を参照してください。
SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行する必要があります。
Oracle Service Busを含むSOAドメインをアップグレードする場合は、必須のアップグレード前タスクをいくつか実行する必要があります。「Oracle Service Bus (OSB)のアップグレード前タスクの実行」を参照してください。
スタンドアロンのOracle HTTP Serverをアップグレードする場合は、「Oracle HTTP Serverのアップグレード」の説明に従ってください。
このオプションの手順は、アップグレードの前でも後でも実行できます。
注意:
既存のドメインに関連付けられた管理対象Oracle HTTP Serverは、Infrastructureのアップグレード・プロセス中に自動的にアップグレードされます。管理対象HTTP Serverを個別にアップグレードする必要はありません。