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

前
次

2 Oracle GoldenGate Studioのアップグレードの準備

アップグレードはサーバーが停止している間に実行されます。アップグレード前は通常、多くの時間を要します。次のアップグレード前タスクを完了することでアップグレードの計画を立てて環境を準備し、アップグレードを正常に終了して停止時間を抑えられるようにすることをお薦めします。

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

2.1 アップグレード前チェックリスト

アップグレード前チェックリストでは、アップグレードが正常に終了して停止時間を抑えられるように、アップロードを開始する前に実行できるタスクを特定します。

アップロードは、サーバーが停止している間に実行されます。このチェックリストは、停止時間を抑えるために、アップグレード前に実行できる重要な(通常、多くの時間を要する)アップグレード前タスクを特定するように作成されています。アップグレード・プロセスを開始する前に実行できる準備が多いほど、オフライン状態に費やす時間が少なくなります。

注意:

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

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

タスク 説明

必須

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

システムの重要なファイルと、アップグレード対象となるスキーマが含まれるデータベースをすべてバックアップします。アップグレードに失敗した場合、アップグレード前の環境をリストアし、アップグレードを再度開始する必要があります。

完全バックアップの作成を参照してください。

  • バックアップがスキーマ・バージョン・レジストリ表が含まれていることを確認します。スキーマ・バージョン・レジストリ表のバックアップを参照してください。

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

任意

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

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

テスト用の本番環境のクローニングを参照してください。

必須

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

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

ハードウェア構成とソフトウェア構成(オペレーティング・システムを含む)が動作保証および要件に関する最新のドキュメントでサポートされていることを確認します。また、12c製品ディストリビューションをインストールする前に、サポートされているJDKバージョンを使用していることも確認します。

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

アップグレードする前に、必ず最新のパッチをコンポーネントに適用しておきます。

動作保証要件とシステム要件の確認を参照してください。

32ビット・オペレーティング・システムの場合のみ必須

アップグレードする前に、64ビット・オペレーティング・システムに移行する必要があります。

これは、サポートされていない32ビットのオペレーティング・システムを現在実行している場合にのみ必要です。

任意

拡張暗号化(AES256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。

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

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

拡張暗号化(AES 256)を使用する際のポリシー・ファイルの更新を参照してください。

任意

アップグレードする前に、古いデータや使用されていないデータをすべてパージします。

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

使用していないデータのパージを参照してください。

Oracle Databaseユーザーの場合のみ必須

エディションベース再定義(EBR)対応のスキーマをアップグレードする前に、データベース・サーバーに接続し、12c (12.2.1.2.6)用のエディションをデータベース・サーバーで作成する必要があります。
エディションベース再定義(EBR)データベースを使用している場合は、アップグレードを開始する前にエディションを作成する必要があります。

サーバーでのエディションベース再定義用のエディションの作成を参照してください。

任意

アップグレード・アシスタントを実行するSYSDBA以外のユーザーを作成します。

アップグレード・アシスタントを実行するために、FMWユーザーを作成することをお薦めします。ユーザーFMWはシステム管理権限なしでアップグレード・アシスタントを実行できます。

アップグレード・アシスタントを実行するSYSDBA以外のユーザーの作成を参照してください。

任意

始める前に、現在どのスキーマがドメインにあるかを識別します。

アップグレードを開始する前に、アップグレード前のドメインにどのスキーマがあるのかを把握することが重要です。スキーマ所有者名とパスワード、および各スキーマのバージョンを把握する必要があります。

アップグレード可能な既存のスキーマの識別を参照してください。

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

アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含む、システムに重要なファイルをすべてバックアップします。

アップグレードが失敗した場合にアップグレード前の状態にコンテンツを戻せるように、バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表を含める必要があります。

実際のアップグレードを続行する前に、バックアップを実行したことを確認するプロンプトが「Upgrade Assistant Prerequisites」画面に表示されます。ただし、アップグレード・アシスタントはバックアップが作成されていることを確認しません。

バックアップの作成の詳細は、次を参照してください。
  • Oracle Fusion Middleware Oracle Fusion Middlewareの管理の環境のバックアップ

  • Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニングの12cへのOracle Databaseのアップグレードおよび準備

システムの完全バックアップの作成に加えて、スキーマ・バージョン・レジストリおよびアップグレードされた環境で使用するカスタム設定のバックアップも作成する必要があります。次の資料を参照してください。

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

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

SYSTEM.SCHEMA_VERSION_REGISTRY$表には、Fusion Middlewareスキーマごとに1行含まれています。アップグレード・アシスタントを実行して既存のスキーマを更新し、失敗した場合、再試行するには元のスキーマをリストアする必要があります。アップグレード・アシスタントを実行する前に、既存のデータベース・スキーマおよびスキーマ・バージョン・レジストリのバックアップを必ず作成してください。

注意:

スキーマのアップグレードを実行する前にこのようなバックアップを実行することは、アップグレード・アシスタントを実行するための前提条件です。アップグレード時には、バックアップが実行されていることを確認する必要があります。

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

実際の本番環境のコピーを作成し、クローン環境をアップグレードしてアップグレード後のコンポーネントが想定どおりに動作するかを検証した後に(初めて)本番環境をアップグレードします。

本番環境をテスト用にクローニングすることをお薦めしますが、必須ではありません。

アップグレードを元に戻すことはできません。ほとんどの場合、エラーが発生すると、アップグレードを中止してバックアップから環境全体をリストアし、初めからアップグレード・プロセスを開始する必要があります。開発環境で発生する可能性のあるアップグレード問題を特定すると、不要な停止時間を省くことができます。

注意:

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

  • アップグレードを始めから終わりまで完了する練習をする。

  • アップグレードのパフォーマンスとパージ・スクリプトがどの程度役立つかを把握する。

  • アップグレードの完了に必要な時間を把握する。

  • データベース・リソースの使用状況(一時表領域、PGAなど)を把握する。

注意:

クローン本番環境でアップグレード前の準備状況チェックを実行し、データに関して発生する可能性があるアップグレード問題を容易に特定できますが、確実にアップグレードに成功するためにはクローン環境で完全テスト・アップグレードを実行する必要があります。

2.4 動作保証要件とシステム要件の確認

動作保証マトリックスとシステム要件のドキュメントを確認して、現在の環境が必要なインストール要件を満たしていることを確認します。

注意:

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

警告:

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

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

オラクル社では、動作保証されたシステムおよび環境すべてで製品のパフォーマンスをテストおよび検証しています。サポートされているハードウェアまたはソフトウェア構成で製品をインストールしていることを確認します。

新しい動作保証情報が発生するたびに、適切な動作保証に関するドキュメントにすぐに追加されます。新しい動作保証情報は常に発生する可能性があるため、動作保証ドキュメントはドキュメント・ライブラリの外部に保持され、Oracle Technology Networkで利用できます。詳細は、12c (12.2.1.2.6)の動作保証マトリックスを参照してください。

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

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

Oracle Fusion Middlewareのシステム要件と仕様のドキュメントを使用して、動作保証要件を満たしていることを確認してください。たとえば、ご使用の製品が64ビットのOracle Linux 7で動作保証されていることが12c (12.2.1.2.6)の動作保証マトリックスに記載されている場合、そのOracle Linux 7システムが、ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチおよびその他のオペレーティング・システム固有の項目などの最小要件を満たしていることを「システム要件と仕様の確認」ドキュメントで確認する必要があります。このドキュメントは必要に応じて更新され、Oracle Technology Network (OTN)のドキュメント・ライブラリ以外の場所にあります。

注意:

アップグレードのための準備で、Oracle Fusion Middlewareリリース12cソフトウェアをインストールする際は、既存のアップグレード前のOracle Fusion Middlewareソフトウェアをインストールして構成するために使用したのと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これにより、適切な所有者およびグループが新しいOracle Fusion Middleware 12cのファイルおよびディレクトリに確実に適用されます。

32ビット環境を実行している場合は、追加の一連の手順を実行する必要があります。

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

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

アップグレードを開始する前にFusion Middlewareのデータベース要件を確認して、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードを実行するのに十分な空き領域があることを確認します。詳細は、12c (12.2.1.2.6)の動作保証マトリックスを参照してください。

注意:

データベース・バージョンがもうサポートされていない場合は、アップグレードを開始する前にサポートされているバージョンにアップグレードする必要があります。Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニングの12cへのOracle Databaseのアップグレードおよび準備を参照してください。

2.4.4 JDKがこのリリースのOracle Fusion Middlewareで動作保証されていることの確認

Oracle Fusion Middleware製品ディストリビューションをインストールするには、サポートされているJDKをダウンロードしてシステムにインストールする必要があります。

Oracle Fusion Middlewareでサポートされるシステム構成の情報をOracle Technology Network (OTN)で参照して、使用中のJDKがサポートされていることを確認します。

このドキュメントの公開時点で、12c (12.2.1.2.6)に対して動作保証されたJDKは1.8.0_101でした。

JDKがサポートされていない場合、またはJDKがインストールされていない場合は、必要なJava SE JDKを次のWebサイトからダウンロードする必要があります。
http://www.oracle.com/technetwork/java/javase/downloads/index.html

JDKは、必ずOracleホーム以外にインストールしてください。Oracle Universal Installerでは、指定されたOracleホーム・ディレクトリが空であることを検証するため、空のディレクトリを指定するまでインストールは先に進みません。Oracleホームの下にJDKをインストールすると、その後の操作で問題が発生することがあります。したがって、JDKは/home/oracle/products/jdkディレクトリにインストールすることをお薦めします。

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

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

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

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

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

注意:

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

2.6 使用していないデータのパージ

アップグレード前に使用していないデータをパージし、パージ手順を整えておくと、アップグレード・プロセスを最適化できます。

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

2.7 サーバーでのエディションベース再定義用のエディションの作成

エディションベース再定義(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で指定したサンプルのエディション名です。必ずエディションの作成時に使用した実際の名前を指定してください。

エディションが正常に作成されると、次のメッセージが表示されます。

Edition created.

アップグレード中、再構成ウィザードを起動して既存のドメインを再構成するように求められます。再構成ウィザードの実行前に、データベースのデフォルト・エディションを指定する必要があります。次のSQLを使用して、データベースのデフォルト・エディション名を手動で設定します。

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1;

2.8 アップグレード・アシスタントを実行するSYSDBA以外のユーザーの作成

アップグレード・アシスタントを実行するために、FMWというSYSDBA以外のユーザーを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限がありますが、管理者権限をすべて持っているわけではありません。

SYSDBAは、データベースの作成、起動、停止、バックアップまたはリカバリなどの高レベルの管理操作を実行するために必要な管理権限です。SYSDBAシステム権限は、全権限を持つデータベース管理者のためのものです。SYSDBA権限で接続する場合、デフォルト・スキーマには接続しますが、一般にユーザー名に関連付けられたスキーマには接続しません。SYSDBAの場合、そのスキーマはSYSです。デフォルト・スキーマへのアクセス権は非常に強力な権限になる可能性があります。たとえば、ユーザーSYSとして接続すると、データ・ディクショナリ表に対して無制限の権限を保有します。したがって、スキーマをアップグレードするためにSYSDBA以外のユーザーを作成することをお薦めします。この項で示した権限は、アップグレード・アシスタントを起動する前にユーザーFMWに付与する必要があります。

注意

SYSDBA以外のユーザーFMWを前のリリースで作成した場合は、アップグレードを開始する前にこのユーザーを削除して再作成する必要があります。新しい権限が追加されている可能性があるため、古いFMWでアップグレード・アシスタントを実行すると、アップグレードに失敗する可能性があります。既存のFMWユーザーを変更するのではなく、ユーザーを削除して再作成することをお薦めします。
デフォルトでは、v$xatrans$表は存在しません。ユーザーの作成前に、XAVIEW.SQLスクリプトを実行してこの表を作成する必要があります。さらに、Oracle Identity Managerのみに必要な選択権限をv$xatrans$表に付与します。構成に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 Patch 13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。

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

2.9 アップグレード可能な既存のスキーマの識別

このオプション・タスクでは、スキーマ・バージョン・レジストリに問い合せることにより、アップグレードする前に、使用可能なスキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が格納されています。

アップグレード・アシスタントでドメイン内のすべてのスキーマをアップグレードすることも、スキーマを個別に選択してアップグレードすることもできます。決定しやすくするために、次の手順に従って、アップグレードできるすべてのスキーマのリストを表示します。

  1. Oracle Databaseを使用している場合は、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 ;
    
  2. 生成されたレポートを調べます。VERSION列の値が11.1.1.7.0以上で、STATUS列の値がVALIDの場合は、スキーマのアップグレードがサポートされています。

    スキーマをアップグレードする必要がない場合は、アップグレード前のバージョンのスキーマがschema_version_registry表に保持されます。

  3. 既存のスキーマに使用したスキーマ接頭辞名をメモします。12cの新規スキーマを作成する際には、同じ接頭辞を使用します。

注意

  • 既存のスキーマが、サポートされているバージョンではない場合、12c (12.2.1.2.6)のアップグレード手順を使用する前に、サポートされているバージョンにそれらをアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。

  • Oracle Enterprise Data Quality、Oracle GoldenGate MonitorおよびOracle GoldenGate Veridataなど、一部のコンポーネントでは、Oracle Fusion Middlewareで標準的にサポートされているバージョン以外のバージョンからのアップグレードがサポートされています。

  • OIDベースのポリシー・ストアを11gで使用した場合は、アップグレードする前に新しいOPSSスキーマを必ず作成してください。アップグレード後は、OPSSスキーマはLDAPベースのストアのままになります。

  • Oracle Fusion Middlewareリリース12c (12.2.1.2.6)でアップグレード可能な製品のスキーマのみをアップグレードできます。12c (12.2.1.2.6)でまだアップグレードできないコンポーネントを含むドメインをアップグレードしようとしないでください。