| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.1) E77369-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.1) E77369-01 |
|
|
前 |
次 |
アップグレードを開始する前に、必要なアップグレード前タスクを完了しておく必要があります。必要なタスクを完了しないと、アップグレードが失敗したり、システムの停止時間が長引いたりする可能性があります。各自のデプロイメントに該当するタスクのみを完了してください。
注意:
アップグレードするOracle SOA製品によっては、追加のアップグレード前タスクを実行する必要がある場合があります。Oracle Service Busやユーザー・メッセージング・サービスなどの製品には、アップグレード前およびアップグレード後の追加構成タスクが必要になることがあります。
Oracle Fusion Middlewareアップグレード前のチェックリストでは、限られた停止時間でアップグレードを正常に行うために、アップグレードの開始前に実行できるタスクを示しています。
アップグレードはサーバーが停止している間に実行されます。このチェックリストでは、停止時間を抑えるためにアップグレード前に実行できる、重要であるが時間がかかることが多いアップグレード前タスクを示します。アップグレード・プロセスの開始前に行える準備が多いほど、オフラインでかかる時間が少なくなります。
注意:
実行するアップグレード前手順は、既存のシステムの構成、アップグレードするコンポーネント、およびアップグレードと構成プロセスの最後に作成する環境によって異なります。各自の構成やユースケースに該当するタスクのみを完了してください。表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク
| タスク | 説明 | ドキュメント |
|---|---|---|
既存の環境の完全なバックアップを作成します。 |
必須 アップグレードを開始する前に、アップグレードしようとしているスキーマを含めてシステムに重要なファイルとデータベースをすべてバックアップします。 アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再開できます。 |
既存のドメイン内の起動スクリプトのいずれかを変更した場合、アップグレード中にそれらを(既存ドメインの外部にある)一時ディレクトリの場所にコピーし、アップグレード後に再デプロイする必要があります。 |
使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。 |
オプション システム・ファイルの完全なバックアップを作成するだけでなく、本番環境をクローニングしておくことも強くお薦めします。この環境は、アップグレードをテストするために使用されます。 |
|
サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。 サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。 |
必須 (オペレーティング・システムを含む)ハードウェアとソフトウェアの構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。 動作保証の要件は頻繁に更新されるため、アップグレードの開始直前にこの情報を確認することをお薦めします。 アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。 また、12c製品ディストリビューションをインストールする前に、サポートされているJDKバージョンを使用していることを確認してください。 |
32ビットのオペレーティング・システムを現在実行している場合は、アップグレード前に64ビット・オペレーティング・システムに移行する必要があります。 |
強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。 Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。 |
オプション 強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。 |
|
アップグレードする前に、期限切れまたは未使用のデータをパージします。 |
オプション パフォーマンスの最適化のために、アップグレードされた環境で使用しないデータおよびオブジェクトをパージすることを検討してください。 インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。 |
|
| Oracle Databaseユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12c (12.2.1.1)のデータベース・サーバーにエディションを作成する必要があります。 | EBRデータベースを使用している場合のみ必須 エディション・ベースの再定義(EBR)データベースを使用している場合、アップグレードの開始前にエディションを作成する必要があります。 | エディション・ベースの再定義のためのサーバー上でのエディションの作成 |
| Upgrade Assistantを実行するために非SYSDBAユーザーを作成します。 | オプション Upgrade Assistantを実行するには、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理権限なしでUpgrade Assistantを実行できます。 |
Upgrade Assistantを実行するための非SYSDBAユーザーの作成 |
新しい12c (12.2.1.1)ディストリビューションをインストールして、既存のOracle Fusion Middlewareデプロイメントのアップグレードを開始する前に、必ず、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含む、システムに重要なすべてのファイルをバックアップしておきます。
スキーマ・アップグレードを実行する前に完全データベース・バックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。
詳細は、「Oracle Fusion Middleware環境のバックアップ」および「12cのためのOracle Databaseのアップグレードおよび準備」を参照してください。
注意:
システム・バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。SYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。setDomainEnvなど)が含まれます。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。システム・バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。
SYSTEM.SCHEMA_VERSION_REGISTRY$表に、各Fusion Middlewareスキーマに対応する行があります。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。必ず、既存のデータベース・スキーマをバックアップしてから、Upgrade Assistantを実行してください。
注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。すべてのドメインには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。
カスタム・ドメイン・レベルの環境設定を維持するには、アップグレードの前に、カスタム・ドメイン情報を格納するファイルを別途作成してください。
たとえば、ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、たとえば、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のJavaコマンド行オプションを指定する、または追加の環境変数を指定する、などの構成が可能です。このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存され、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スクリプトを作成できない場合は、「起動スクリプトへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。
実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。
注意:
このドキュメントでは、すべてのコンポーネントおよびオペレーティング・システムのクローニング手順を記載していません。クローニング手順は、コンポーネントおよびオペレーティング・システムに固有です。大まかに言えば、コンポーネント・ドメインのアップグレード前バージョンをテスト・マシンにインストールし、リポジトリ作成ユーティリティ(RCU)を使用して必要なスキーマを作成して、アップグレードを実行します。アップグレードに関する問題を明らかにし、修正します。
エンドツーエンドのアップグレードを完了させる練習をします。
アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。
アップグレードの完了までに必要な時間を理解します。
データベース・リソースの使用(一時表領域、PGAなど)について理解します。
注意:
クローニングした本番環境でアップグレード前の準備状況チェックを実行すれば、データで発生しうるアップグレード時の問題は特定できますが、正常なアップグレードの万全を期すためには、クローニングした環境で完全なテスト・アップグレードを実行する必要があります。ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントを併せて使用する必要があります。
注意:
動作保証、システム要件および相互運用性情報を確認する場合、特に32ビットまたは64ビットのシステム要件を確認するようにしてください。32ビットまたは64ビットの環境専用として設計されているソフトウェアを明示的にダウンロードすることが重要です。警告:
アップグレードを開始する前に、現在の環境に最新のパッチが適用されていることを確認してください。動作保証は、特に指定がないかぎり、完全にパッチが適用された環境に基づいています。Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。
新しい動作保証情報が発表された場合は、適切な動作保証ドキュメントにすぐに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。
ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。
Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証要件を満たしていることを確認してください。たとえば、この動作保証に関するドキュメントに、ご使用の製品を64ビットOracle Linux 7上にインストールすることが動作保証されていると示されている場合、このドキュメントを使用して、Oracle Linux 7システムが最低限必要な仕様(ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチおよびその他のオペレーティング・システム固有のアイテムなど)を満たしていることを確認します。このドキュメントは必要に応じて更新され、ドキュメント・ライブラリの外部に置かれています。最新バージョンは、Oracle Technology Networkから入手できます。
Oracle Fusion Middleware 12cのインストールおよび12cへのアップグレードの詳細は、「システム要件と仕様のレビュー」を参照してください。
注意:
アップグレード準備としてOracle Fusion Middlewareリリース12cソフトウェアをインストールする際は、既存のアップグレード前のOracle Fusion Middlewareソフトウェアのインストールおよび構成に使用したものと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これによって、正しい所有者とグループが新しいOracle Fusion Middleware 12cのファイルおよびディレクトリに確実に適用されます。この手順は、32ビット環境を実行している場合にのみ必要です。32ビットのOSを使用している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。
Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。
次のタスクでは、ホストは、32ビット・ソース・マシンを指し、ターゲットは、新しい64ビット・ターゲット・マシンを指します。
注意:
これらの手順は、データベースが別のホスト上にあり、移動されないことを前提としています。注意:
これらの手順は、オペレーティング・システム・アップグレード・プロセスの例として説明されているため、特定のオペレーティング・システムを更新する場合に実行する必要がある手順がすべて含まれている場合と含まれていない場合があります。詳細は、使用しているオペレーティング・システムのアップグレード・ドキュメントを参照してください。アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。
アップグレード前に、管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。
たとえば、管理サーバーを停止するには、次のコマンドを入力します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]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ホームでインストールする必要があります。
12cディストリビューションの入手方法の詳細な説明は、「製品ディストリビューションの理解と入手」を参照してください。インストール・ユーザーを指定するには、「インストール・ユーザーの選択」を参照してください。インストールおよび構成用のディレクトリ構造について理解するには、「インストールおよび構成のためのディレクトリの理解」を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。
ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。
詳細なアップグレード手順は、アップグレードするコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。
注意:
ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。「32ビット・ホスト・マシンからすべてのファイルをバックアップする」の一部として32ビット・ソース・マシンからバックアップした11gノード・マネージャ・ファイルを使用します。Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。
アップグレード時のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認しているものとします。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。
汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。
このマニュアルの発行時点で動作保証されているJDKは、1.8.0_77です。
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に適用せずに強化された暗号化を使用しようとすると、アップグレードに失敗することがあり、その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。
アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。
注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。「パージおよびパーティショニング方法の開発」と「データベース増分管理戦略の策定」を参照してください一部のコンポーネントには自動化されたパージ・スクリプトがあります。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。
SOA Suiteコンポーネントの場合:
クローズされた11gインスタンス・データを移行する場合は、アップグレードの実行前にインスタンス・パージ・スクリプトを実行します。「インスタンス・データ・パージ・スクリプトの使用」を参照してください。
エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。
エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。すべての変更が実行およびテストされている場合のみ、アプリケーションの新バージョンをユーザーが使用できるようにしてください。
注意:
このタスクは、DBA権限を持つOracle Databaseユーザーのみが実行する必要があります。エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11gまたは12cエディションの子である必要があります。
データベース・サーバーにエディションを作成するには、SYSユーザー(またはDBA権限のある別のOracleユーザー)としてログインし、次のコマンドを入力します。
create edition Oracle_FMW_12_2_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;
Upgrade Assistantを実行するには、FMWという名前の非SYSDBAを作成することをお薦めします。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;
注意:
Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。
このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。
アップグレード前の環境によっては、Oracle Fusion Middlewareアップグレード前の要件に加えて、SOA固有の追加アップグレード・タスクを完了しておく必要がある場合もあります。
この項では、12c (12.2.1.1)にアップグレードするSOA、Business Process Managementまたは統合製品に適用するアップグレード前のタスクについて説明しています。各自の環境に当てはまるタスクのみを実行してください。
注意:
アップグレードの準備を適切に行わないことが、リカバリ不能なエラーやアップグレードの失敗につながります。アップグレードの開始前に、該当するすべてのアップグレード前タスクが完了していることを確認してください。
| アップグレード前タスク | 詳細 |
|---|---|
必須 環境がOracle SOA SuiteおよびBPM 12c (12.2.1.1)へのアップグレードのOracle Database要件を満たしていることを確認します |
|
必須 表領域のサイズが適切に設定されていることを確認します(不十分なサイズに設定すると、アップグレードは失敗します)。 |
|
| SOA Composerユーザーのみ: コミットされていない変更はアップグレード後には使用できないことに注意してください。 | アップグレード前のSOA Composerの変更のコミット |
| 以前の12cリリースからアップグレードする場合にのみ必要です。 アップグレード前に、ドメインから既存のcloudsdkデプロイメントを削除します。 |
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.1)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。
Oracle SOA SuiteおよびBPM 12c (12.2.1.1)にアップグレードする場合のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認することが重要です。Fusion Middleware 12c (12.2.1.1)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。最新の情報については、常に最新のデータベースの動作保証マトリックスを参照してください。
『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.1)バージョンは自動的にサーバーにデプロイされ、ネーミング規則の変更によって、以前にデプロイされたアプリケーションと競合する可能性があります。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を個別にアップグレードする必要はありません。