| Oracle® Fusion Middleware Oracle Data Integratorのアップグレード 12c (12.2.1.1) E77371-02 |
|
 前 |
 次 |
Oracle Data Integrator 12c (12.2.1.1)へのアップグレードを開始する前に、既存のドメインをバックアップし、リポジトリをクローニングし、システムが認定された要件を満たすことを確認する必要があります。
この項のタスクは、ユーザーが「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)データベースを使用している場合は、アップグレードを開始する前に、エディションを作成する必要があります。 | エディション・ベースの再定義のためのサーバー上でのエディションの作成 |
| アップグレード・アシスタントを実行する非SYSDBAユーザーを作成します。 | オプション アップグレード・アシスタントを実行するFMWユーザーを作成することをお薦めします。ユーザーFMWはシステム管理権限なしでアップグレード・アシスタントを実行できます。 |
アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成 |
アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。
スキーマ・アップグレードを実行する前に完全なデータベース・バックアップを実行することは、アップグレード・アシスタントを実行するための前提条件です。バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。
実際のアップグレードに進む前に、バックアップが実行されていることを確認する必要があります。詳細は、データベースのドキュメントを参照してください。
Oracle Fusion Middlewareの管理のOracle Fusion Middleware環境のバックアップ
Oracle Fusion Middlewareのアップグレードのプランニングの12cのためのOracleデータベースのアップグレードおよび準備
システムの完全なバックアップの作成に加え、次の項で説明する、スキーマ・レジストリのバックアップおよびアップグレードされた環境で使用するカスタム設定も作成する必要があります。
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スクリプトを作成できない場合は、Oracle WebLogic Serverのアップグレードの起動スクリプトへのカスタマイズの再適用の説明に従って、設定を再適用する必要があります。
Oracle Data Integrator (ODI)本番環境のクローニングは、クローニングおよびクローニングした環境でのアップグレードのテストという2つのプロセスで構成されます。
タスク1: 既存の本番環境のクローニング(またはコピー)。下の例ではAと呼びます。
タスク2: クローニングした環境でのフル・アップグレードの実行。下の例ではBと呼びます。
タスク2: クローニングした環境をアップグレードして、アップグレードをテスト(B)
Oracle Fusion Middlewareアップグレード前のチェックリストをレビューして、アップグレード前のすべての要件が満たされていることを確認します。
Oracle Data Integrator 12c (12.2.1.1)およびその他の製品ディストリビューションを、テスト・マシン上の新しいOracleホームにインストールします。『Oracle Data Integratorのインストールと構成』を参照してください。
アップグレード・アシスタントでアップグレード前の準備状況チェックを実行します。「アップグレード前の準備状況チェックの実行」を参照してください。
環境用の標準的なアップグレード手順に従います。環境に適したアップグレード手順を選択する必要があります。「Oracle Data Integratorの標準アップグレード・トポロジの理解」を参照してください。
すべてのアップグレード後構成タスクを実行して、アップグレードしたコンポーネントが予想どおりに動作することを確認します。
ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。
注意:
動作保証、システム要件および相互運用性情報を確認する場合、特に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ドメイン・ホーム
$ORACLE_HOME/wlserver/common/にある11g /nodemanagerディレクトリ
『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に適用せずに強化された暗号化を使用しようとすると、アップグレードに失敗することがあり、その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。アップグレード前に未使用データをパージし、パージ方法をメンテナンスすることで、アップグレード・プロセスを最適化できます。
注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の次の情報を参照してください。パージおよびパーティション化の方法の開発
データベース増分管理戦略の策定
一部のコンポーネントには自動化されたパージ・スクリプトがあります。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。
次の手順で作業リポジトリのエクスポート/インポートの一部として過剰なデータがエクスポートおよびインポートされないように、実行ログをパージします。「ログのパージ」を参照してください
エディション・ベースの再定義(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;
アップグレード・アシスタントを実行するには、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にアクセスしてパッチをダウンロードします。
このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。
DB2データベースを使用する場合、ODIアップグレード時にデータベース・トランザクション・ログがいっぱいになることがあります。
db2 'update database config for database_alias using LOGFILSIZ 10000' db2 'update database config for database_alias using LOGPRIMARY 50'
Oracle Data Integratorのマスター・リポジトリおよび作業リポジトリそれぞれのバックアップを作成することをお薦めします。
バックアップにより、必要時にアップグレード前の状態にリストアできます。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのバックアップ計画に関する項を参照してください。
アップグレードに失敗した場合、schema_version_registry表の内容をアップグレード前の状態にリストアする必要があります。そのため、SYSTEM.SCHEMA_VERSION_REGISTRY$表をバックアップの一部に含める必要があります。
アップグレード・アシスタントの前提条件の画面ではODIリポジトリのバックアップが完了したかどうかを確認されます。ただし、アップグレード・アシスタントではバックアップが完了したことが検証されない点に注意してください。
注意:
これは、特にリポジトリをクローニングしていない場合には、アップグレード・プロセスの重要な手順です。アップグレードの結果に問題がある場合、リポジトリはロックされ、使用できません。
ODIリポジトリのバックアップ・コピーを作成することで、重要なデータを失うことがなくなるだけでなく、アップグレード失敗後にリストアする唯一の手段となります。失敗した状態からアップグレードを再開することはできません。
バックアップの作成の詳細は、データベースのバックアップおよびリカバリのドキュメントを参照してください。
Oracle Data Integratorリポジトリをクローニングすると、クローニングされたマスター・リポジトリには、元のソース・リポジトリの作業リポジトリ接続詳細が埋め込まれます。クローニングする際は、必ずクローニングされるリポジトリのマスター・リポジトリに接続してください。各作業リポジトリを開いて、スキーマ名とパスワード、およびJDBC URL(あるいはその両方)を変更します。
この手順を行わないと、意図せずに元のスキーマがアップグレードされる可能性があります。
例1: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマを、すべて同じデータベース・インスタンスにリストアします。
作業リポジトリのJDBC URLを更新するには、次の手順を実行します。
次のコマンドでスキーマCUST1およびCUST2をエクスポートすることにより、Oracle Datapumpを使用して単純なクローンを実行します。
Expdb System/Password Directory=Dumpdir Schemas=cust1,cust2 Dumpfile=Filename.dmp
CUST1およびCUST2をクローニングして、新しいスキーマ(NEWCUST1、NEWCUST2)を作成します。
Impdp System/Password Directory=Dumpdir Schemas=cust1,cust2 Remap_schemas=cust1:newcust1, cust2:newcust2 Dumpfile=Filename.dmp
NEWCUST1のみのマスター・リポジトリに接続します。
ODI Studioを使用して作業リポジトリの接続を確認し、クローニング/バックアップ・スキーマに従ってリポジトリの接続(URL)を更新します。詳細は、『Oracle Data Integratorの管理』のリポジトリの管理のための高度なアクションに関する項を参照してください。
ODI Studioを使用して作業リポジトリの接続を確認し、クローニングまたはバックアップ・スキーマに従ってリポジトリの接続(URL)を更新します。詳細は、リポジトリの管理のための高度なアクションに関する項を参照してください。
workrep1を開いて、schema_nameをCUST1からNEWCUST1に更新します。
workrep2を開いて、schema_nameをCUST2からNEWCUST2に更新します。
例2: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマがあります。この例では、スキーマの名前変更を行いません。すべてのスキーマを別々のデータベース・インスタンスにリストアします。
スキーマを新しいデータベース・インスタンスにリストアするには、次の手順を実行します。
スキーマを新しいデータベース・インスタンスにリストアし、同時にスキーマ名も変更する場合は、schema_namesとJDBC_URLの両方を更新します。
リポジトリをクローニングした後で、リポジトリ接続を確認し、クローニングされたマスター・リポジトリがクローニングされた正しい作業リポジトリ・スキーマを指していることを確認する必要があります。アップグレード・プロセスでは、作業リポジトリ情報がそのマスター・リポジトリから取得されます。作業リポジトリを正常にアップグレードするために、アップグレードの前に、リポジトリが正しいスキーマおよびホストにアタッチされていることを確認する必要があります。
これを確認する手順は、次のとおりです。
注意:
この項のドキュメント・リンクは、11g リリース1 (11.1.1.7)のドキュメントを参照しています。
アップグレード・アシスタントを起動する前に、外部認証モードを内部認証に切り替えます。
注意:
これは、外部認証を使用している場合にのみ適用されます。外部認証を使用していない場合は、この手順をスキップします。『Oracle Data Integratorの管理』の次の各項を参照してください。
外部認証の構成
既存のマスター・リポジトリから外部認証モードへの切替え
