プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureへのアップグレード
12c (12.2.1.1)
E77368-01
目次へ移動
目次

前
前へ
次
次へ

2 Fusion Middleware Infrastructureのアップグレードの準備

アップグレードはサーバーが停止している間に実行されます。アップグレード前には時間がかかることがよくあります。これらのアップグレード前タスクを完了することによってご使用の環境をアップグレードに向けて計画および準備し、正常なアップグレードと限られた停止時間が実現されるようにすることをお薦めします。

次のチェックリストを使用して、アップグレード前タスクの完了を確認してください。

2.1 Oracle Fusion Middlewareアップグレード前のチェックリスト

Oracle Fusion Middlewareアップグレード前のチェックリストは、正常なアップグレードと限られた停止時間を保証するために、アップグレードを開始する前に実行するタスクを示しています。

アップグレードはサーバーが停止している間に実行されます。このチェックリストは、停止時間を制限するためにアップグレードの前に実行できる、重要な(時間がかかることも多い)アップグレード前タスクを示すためのものです。アップグレード・プロセスを開始する前に可能な準備が多いほど、オフラインで消費する時間が少なくなります。

注意:

実行するアップグレード前手順は、既存のシステムの構成、アップグレードするコンポーネントおよびアップグレードと構成プロセスの最後に作成する環境によって異なります。各自の構成またはユース・ケースに当てはまるタスクのみを完了してください。

表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク

タスク 説明 ドキュメント

既存の環境の完全なバックアップを作成します。

必須

アップグレードを開始する前に、アップグレードしようとしているスキーマを含めてシステムに重要なファイルとデータベースをすべてバックアップします。

アップグレードに失敗した場合は、アップグレード前の環境をリストアして、アップグレードを再試行できます。

完全なバックアップの作成

既存のドメイン内のいずれかの起動スクリプトを変更した場合は、アップグレード中にそのスクリプトを一時ディレクトリ場所(既存のドメイン外)にコピーしてアップグレード後に再デプロイする必要があります。

カスタム・ドメイン環境設定のメンテナンス

使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。

オプション

システム・ファイルの完全なバックアップを作成することに加えて、本番環境をクローンすることをお薦めします。この環境は、アップグレードをテストするために使用されます。

本番環境のテスト用クローニング

サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。

サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。

必須

ハードウェアとソフトウェア(オペレーティング・システムも含む)の構成が、最新の動作保証および要件のドキュメントでサポートされていることを確認します。

動作保証要件は頻繁に更新されるため、アップグレードを開始する直前にこの情報を確認することをお薦めします。

アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。

12c製品のディストリビューションをインストールする前に、サポートされているJDKバージョンを使用することも必要です。

動作保証およびシステム要件の確認

現在32ビット・オペレーティング・システムを使用している場合は、アップグレードする前に64ビット・オペレーティング・システムに移行する必要があります。

32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合にのみ必要)

強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。

オプション

強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、最新の必須ポリシー・ファイルをJDKに適用することをお薦めします。

強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新

アップグレードする前に期限切れまたは未使用のデータをパージします。

オプション

パフォーマンスの最適化のために、アップグレードされた環境で使用しないデータおよびオブジェクトをパージすることを検討してください。

インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。

未使用データのパージ

Oracle Databaseユーザーの場合のみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12c (12.2.1.1)のデータベース・サーバーにエディションを作成する必要があります。 EBRデータベースを使用する場合に必要

エディションベースの再定義(EBR)データベースを使用している場合、アップグレードを開始する前にエディションを作成する必要があります。
エディション・ベースの再定義のためのサーバー上でのエディションの作成
Upgrade Assistantを実行するために非SYSDBAユーザーを作成します。 オプション

Upgrade Assistantを実行するには、FMWユーザーを作成することをお薦めします。ユーザーFMWはシステム管理権限なしでUpgrade Assistantを実行できます。

Upgrade Assistantを実行するための非SYSDBAユーザーの作成

2.2 完全なバックアップの作成

新しい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$表を含む必要があります。

2.2.1 スキーマ・バージョン・レジストリ表のバックアップ

システム・バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表を含む必要があります。

Fusion MiddlewareスキーマはそれぞれSYSTEM.SCHEMA_VERSION_REGISTRY$表に行を持っています。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。必ず、既存のデータベース・スキーマをバックアップしてから、Upgrade Assistantを実行してください。

注意:

スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。

2.2.2 カスタム・ドメイン環境設定のメンテナンス

すべてのドメインには、動的に生成されたドメインおよび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スクリプトを作成できない場合は、「起動スクリプトへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

2.3 本番環境のテスト用クローニング

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

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

注意:

すべてのコンポーネントおよびオペレーティング・システムのクローニング手順の説明はこのドキュメントの範囲を超えています。クローニング手順はコンポーネントおよびオペレーティング・システム固有です。高いレベルでは、アップグレード前のバージョンのコンポーネント・ドメインをテスト・マシンにインストールし、必須のリポジトリ作成ユーティリティ(RCU)を作成してアップグレードを実行します。
本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。
  • アップグレードに関する問題を明らかにし、修正します。

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

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

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

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

注意:

クローニングした本番環境でアップグレード前の準備状況チェックを実行すれば、データで発生しうるアップグレード時の問題は特定できますが、正常なアップグレードの万全を期すためには、クローニングした環境で完全なテスト・アップグレードを実行する必要があります。

2.4 動作保証およびシステム要件の確認

ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントを併せて使用する必要があります。

注意:

動作保証、システム要件および相互運用性情報を確認する場合、特に32ビットまたは64ビットのシステム要件を確認するようにしてください。32ビットまたは64ビットの環境専用として設計されているソフトウェアを明示的にダウンロードすることが重要です。

警告:

アップグレードを開始する前に、現在の環境に最新のパッチが適用されていることを確認してください。動作保証は、特に指定がないかぎり、完全にパッチが適用された環境に基づいています。

2.4.1 環境が動作保証要件を満たしていることの確認

Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。

新しい動作保証情報が発表された場合は、適切な動作保証ドキュメントにすぐに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。

2.4.2 システム要件と仕様の確認

ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

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のファイルおよびディレクトリに確実に適用されます。

2.4.2.1 32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合にのみ必要)

この手順は、32ビット環境を実行している場合にのみ必要です。32ビットOSを持っている場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。

次のタスクでは、ホストは、32ビット・ソース・マシンを指し、ターゲットは、新しい64ビット・ターゲット・マシンを指します。

注意:

これらの手順は、データベースが別のホスト上にあり、移動されないことを前提としています。
オペレーティング・システムのアップグレードには、通常、次の内容が含まれます。

注意:

これらの手順は、オペレーティング・システム・アップグレード・プロセスの例として説明されているため、特定のオペレーティング・システムを更新する場合に実行する必要がある手順がすべて含まれている場合と含まれていない場合があります。詳細は、使用しているオペレーティング・システムのアップグレード・ドキュメントを参照してください。
2.4.2.1.1 アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する

アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。

2.4.2.1.2 すべてのプロセスを停止する

アップグレードの前に、管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。

たとえば、管理サーバーを停止するには、次のコマンドを入力します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
2.4.2.1.3 32ビット・ホスト・マシンからすべてのファイルをバックアップする

11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。

注意:

同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあります。

11gのファイルのバックアップの詳細は、『Oracle® Fusion Middleware管理者ガイド』環境のバックアップに関する項を参照してください。

アップグレード時に、次のコンテンツにアクセスする必要があります。

  • 11gドメイン・ホーム

  • $ORACLE_HOME/wlserver/common/にある11g /nodemanagerディレクトリ

『Oracle® Fusion Middleware管理者ガイド』環境のバックアップに関する項で説明されている一部のバックアップおよびリカバリ手順は、製品に固有です。完全バックアップを作成するまでアップグレードを続行しないでください。

2.4.2.1.4 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する

ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。

IPアドレスおよびホスト名を変更するプロセスは、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムの管理ドキュメントを参照してください。

2.4.2.1.5 11gのバックアップを32ビット・ホストから64ビット・ホストにリストアする

11gで使用したのと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

64ビットターゲット・マシンに11gファイルをリストアする方法の詳細は、『Oracle® Fusion Middleware管理者ガイド』環境のリカバリに関する項を参照してください。

2.4.2.1.6 12c製品ディストリビューションをターゲット・マシンにインストールする

アップグレードには、ホーム外のアプローチをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。

12cディストリビューションの入手の詳細は、製品ディストリビューションの理解と入手を参照してください。インストール・ユーザーを識別するには、インストール・ユーザーの選択を参照してください。インストールおよび構成用のディレクトリ構造を理解するには、インストールおよび構成のためのディレクトリの理解を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

2.4.2.1.7 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする

ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後タスクを完了する必要があります。

詳細なアップグレード手順は、アップグレードするコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。

注意:

ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。32ビット・ホスト・マシンからすべてのファイルをバックアップする手順の一部として、32ビット・ソース・マシンからバックアップした11gノード・マネージャ・ファイルを使用します。

2.4.3 Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認

Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。

アップグレード時のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認しているものとします。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。

2.4.4 Oracle Fusion Middlewareのこのリリースに対してJDKが動作保証されているかどうかの確認

汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

このドキュメントが発行された時点で、動作保証されたJDKは1.8.0_77でした。

必要なJDKをダウンロードするには、ブラウザで次のURLにアクセスしてJava SE JDKをダウンロードします。
http://www.oracle.com/technetwork/java/javase/downloads/index.html

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。このため、次のディレクトリ/home/oracle/products/jdkにJDKをインストールすることをお薦めします。

汎用インストーラとプラットフォーム固有のインストーラの相違点の詳細は、Oracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルの「汎用とプラットフォーム固有のディストリビューションとの相違点の理解」を参照してください。

2.5 強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新

Advanced Encryption Standard (AES) 256などの強化された暗号化をアップグレード済環境で使用する予定の場合に実行するオプションの手順です。アップグレードする前に必要な最新のポリシー・ファイルをJDKに適用することをお薦めします。

Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。これらのAPIによって、開発者はアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。詳細は、Java暗号化アーキテクチャOracleプロバイダのドキュメントを参照してください。

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

2.6 未使用データのパージ

アップグレード前に未使用データをパージしてパージ方法を維持すると、アップグレード・プロセスを最適化できます。

注意:

大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。「パージおよびパーティショニング方法の開発」と「データベース増分管理戦略の策定」を参照してください

コンポーネントの一部ではパージ・スクリプトが自動化されています。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。

Oracle Data Integrator (ODI)コンポーネントの場合:

次の手順で作業リポジトリのエクスポート/インポートの一部として過剰なデータがエクスポートおよびインポートされないように、実行ログをパージします。「ログのパージ」を参照してください

SOA Suiteコンポーネントの場合:

クローズされた11gインスタンス・データを移行している場合は、アップグレードを実行する前にインスタンス・パージ・スクリプトを実行する必要があります。インスタンス・データ・パージ・スクリプトの使用を参照してください。

2.7 エディション・ベースの再定義のためのサーバー上でのエディションの作成

エディション・ベースの再定義(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;

2.8 Upgrade Assistantを実行するための非SYSDBAユーザーの作成

Upgrade Assistantを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。FMWユーザーはスキーマを変更するために必要な権限を持っていますが、完全な管理者権限は持っていません。

SYSDBAはデータベースの作成、起動、停止、バックアップまたはリカバリなどの高度な管理操作を実行するために必要な管理権限です。SYSDBAシステム権限は、完全な権限を持つデータベース管理者が使用します。SYSDBA権限で接続すると、通常はユーザー名に関連付けられているスキーマではなく、デフォルトのスキーマで接続が確立されます。SYSDBAの場合、このスキーマはSYSです。デフォルト・スキーマへのアクセスは非常に強力な権限となる場合があります。たとえば、ユーザーSYSとして接続する場合、データ・ディクショナリの表における権限は無制限となります。したがって、スキーマをアップグレードするには、非SYSDBAユーザーを作成することをお薦めします。アップグレード・アシスタントを起動する前に、このトピックにリストされている権限を付与する必要があります。

注意:

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にアクセスしてパッチをダウンロードします。

このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。