2 アップグレード前の要件

Oracle Data Integrator 14c (14.1.2.0.0)のアップグレードを開始する前に、バックアップ、現在の環境のレプリカの作成、システムが認定要件を満たしていることの確認など、アップグレード前のタスクを実行する必要があります。

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

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

アップグレードはサーバーの停止中に実行されます。チェックリストは、アップグレード前の重要な(かつ時間がかかる)タスクを識別するためのものであり、これをアップグレード前に実行することで停止時間を短縮できます。アップグレード・プロセスを開始する前の準備を十分行うほど、オフライン時間を減らすことができます。

ノート:

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

この表は、アップグレード前のチェックリストを示します。すべての必要なコンポーネントをリストし、それらについて詳細に説明します。

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

タスク 説明

必須

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

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

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

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

  • 既存のドメインの起動スクリプトまたは構成ファイルを変更またはカスタマイズした場合(たとえば、cookie-pathプロパティの値を設定するなど)、アップグレード中はそれらを一時ディレクトリ(既存のドメイン以外)の場所にコピーし、アップグレード後に再デプロイする必要があります。

省略可能

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

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

必須

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

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

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

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

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

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

省略可能

必要な権限でアップグレード・アシスタントを実行するための非SYSDBAユーザーを作成します。

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

「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

必須

auto_loginウォレットを使用している場合は、ウォレット・ファイルを更新する必要があります。

auto_login_onlyウォレットは、14c (14.1.2.0.0)でサポートされている唯一のウォレットです。14c (14.1.2.0.0)にアップグレードする前に、convert_to_auto_login_only.plを使用して、既存の12c (12.2.1.4.0) auto_loginウォレットすべてをauto_login_onlyに更新する必要があります。

「auto_loginウォレットのauto_login_onlyへの変換」を参照してください。

必須

LinuxおよびUNIXオペレーティング・システムのユーザーは、Fusion Middlewareツールを起動する前に、DISPLAY環境変数を設定する必要があります。

DISPLAY環境変数の設定

DISPLAY環境変数がGUIモードを使用できるように正しく設定されていないと、エラーが発生することがあります。

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

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

バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表を含める必要があります。これにより、アップグレードが失敗したときに、コンテンツをアップグレード前の状態にリストアできるようになります。

Upgrade Assistantの「前提条件」画面では、アップグレードを実際に進める前に、バックアップが実行されていることについての確認を求められます。ただし、Upgrade Assistantは、バックアップが作成されていることを検証しない点に注意してください。

参照:

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

システム・バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表またはFMWREGISTRY.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ファイルは、EXISTING_DOMAIN_HOME/binディレクトリに格納する必要があります。

ノート:

アップグレード前に、setUserOverridesスクリプトを作成できない場合は、Oracle WebLogic Serverのアップグレード起動スクリプトへのカスタマイズの再適用の説明に従って、設定を再適用する必要があります。

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

実際の環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを必ず確認してから、環境をアップグレードします。

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

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

ノート:

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

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

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

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

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

ノート:

クローン環境でアップグレード前の準備状況チェックを実行して、データに関する潜在的なアップグレードの問題を識別できますが、アップグレードを確実に成功させるには、クローン環境で完全なテスト・アップグレードを実行する必要があります。

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

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

ノート:

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

警告:

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

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

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

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

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

「システム要件と仕様の確認」ドキュメントとOracle Fusion Middleware動作保証マトリックスの両方を使用して、ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

Oracle Fusion Middlewareのシステム要件と仕様のドキュメントを使用して、Oracle Fusion Middlewareの動作保証マトリックスの要件が満たされていることを確認します。たとえば、動作保証マトリックスに、ご使用の製品を64ビットのOracle Linux 8上にインストールすることが動作保証されていると示されている場合、システム要件と仕様のドキュメントを使用して、Oracle Linux 8システムが最低限必要な仕様(ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチおよびその他のオペレーティング・システム固有のアイテムなど)を満たしていることを確認します。このドキュメントは、必要に応じて更新されるため、Oracle Technology Network (OTN)のドキュメント・ライブラリの外部に存在します。

ノート:

最小システム要件を満たせない場合は、アップグレードを試行しないでください。

具体的には、Oracle Fusion Middlewareのシステム要件と仕様のドキュメントを使用して、次のことを検証できます。
  • プロセッサ要件
  • Java Development Kit (JDK)の要件
  • 一般的なメモリーおよびディスク領域の要件
  • 製品固有のメモリーおよびディスク領域の要件
  •  ネットワーク要件
  • UNIXオペレーティング・システムの要件
  • Windowsオペレーティング・システムの要件
  • 仮想化の要件
  • データベース要件

使用しているオペレーティング・システムがサポートされていない場合はどうなりますか。

サポートされていないオペレーティング・システムで環境を実行している場合は、アップグレードを開始する前に、サポートされる環境を作成する必要があります。サポートされていないオペレーティング・システムでアップグレードを試行しないでください。

環境の移行ステップを使用します。

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

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

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

ノート:

データベース・バージョンがもうサポートされていない場合は、アップグレードを開始する前にサポートされているバージョンにアップグレードする必要があります。

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

ご使用のJDKがサポートされていない場合、またはJDKをインストールしていない場合は、開始前に必要なJava SE JDKをダウンロードする必要があります。

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

サポート対象外のJDKを使用している場合やJDKをインストールしていない場合は、次に示すWebサイトから必須のJava SE JDKをダウンロードする必要があります。
http://www.oracle.com/technetwork/java/javase/downloads/index.html

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

WLSSchemaDataSourceデータ・ソースのデータベース・ユーザーの確認

既存のドメインにWLSSchemaDataSourceデータ・ソースがある場合は、このステップが必要です。

ドメインにWLSSchemaDataSourceデータ・ソースがある場合は、どのデータベース・ユーザーがそれに割り当てられているかを確認する必要があります。<PREFIX>_WLS_RUNTIMEが割り当てられている場合は、それを<PREFIX>_WLSに変更する必要があります。

これは、次の変更が行われたために必要です:
  • 14c (14.1.2.0.0) Upgrade Assistantは、ドメインベースのスキーマ・アップグレードの実行時に、WLSSchemaDataSourceデータ・ソースの情報を使用します。<PREFIX>_WLSデータベース・ユーザーがWLSSchemaDataSourceに割り当てられていない場合、またはUpgrade AssistantのWLSスキーマ・ページの「スキーマ・ユーザー名」に<PREFIX>_WLSが入力されていない場合、そのアップグレードは失敗します。
  • 12c Oracle WebLogic管理コンソールを使用して、WLSSchemaDataSourceデータ・ソースのデータベース・ユーザーを<PREFIX>_WLSに変更することをお薦めします。こうすると、Upgrade Assistantの失敗を回避でき、また再構成ウィザードでフィールドに正しい値が事前移入されます。
  • <PREFIX>_WLS_RUNTIMEデータベース・ユーザーは、14c (14.1.2.0.0)で導入された新しいWLSRuntimeSchemaDataSourceで使用するために予約されています。この新しいWLSRuntimeSchemaDataSourceは、14c (14.1.2.0.0)の再構成ウィザード(reconfig.sh)を使用してドメインをアップグレードするときに作成されます。
Oracle WebLogic 12c管理コンソールを使用して、WLSSchemaDataSourceのユーザーを<PREFIX>_WLS_RUNTIME から<PREFIX>_WLSに変更できます。
  1. 12c (12.2.1.4.0)管理コンソールにログインします。
  2. 管理コンソールの「ドメイン構造」で、「サービス」を展開(横にある「+」をクリック)します。次に、「データ・ソース」をクリックします。
  3. 「プロパティ」フィールドのユーザーに<PREFIX>_WLS_RUNTIME が含まれる場合は、<PREFIX>_WLSに変更します。
  4. 変更内容を保存します。
  5. ドメインが本番モードで実行されている場合、チェンジ・センターを使用して変更をコミットします。

強化された暗号化(AES 256)を使用している場合のポリシー・ファイルの更新

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

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

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

ノート:

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

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

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

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

ノート:

SYSDBAではないユーザーFMWは、Upgrade Assistantを実行するためにのみ作成されます。このステップが完了したら、このFMWユーザーを削除してください。Upgrade Assistantを実行するために必要な権限は、リリースごとに異なる可能性があります。

ノート:

この例では、SYSDBA以外の管理者にFMWという名前を使用しています。FMWは、ご自分の管理者名に置き換えてください。
権限を付与する際には、必ず、ドメイン内のスキーマの実際のユーザー名およびパスワードを指定します。
CREATE USER FMW IDENTIFIED BY "<FMW password>";
GRANT pdb_dba TO FMW;
GRANT MANAGE SCHEDULER TO FMW;
GRANT USE ON EDITION ORA$BASE TO FMW WITH GRANT OPTION;
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_aq 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 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_job 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 EXECUTE ON SYS.DBMS_ASSERT 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 dba_objects TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_queue_subscribers TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_subscr_registrations TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_RLS TO FMW WITH GRANT OPTION;
GRANT READ ON CTXSYS.CTX_PENDING TO FMW WITH GRANT OPTION;
GRANT SELECT ON SYS.V_$PARAMETER TO FMW WITH GRANT OPTION;
GRANT CREATE PROCEDURE TO FMW;
GRANT SELECT ON dba_users TO FMW WITH GRANT OPTION;
GRANT ALL ON sys.v_$parameter TO FMW WITH GRANT OPTION;

アップグレード可能な既存のスキーマの特定

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

Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個別に選択することもできます。この判断には、次に示すステップを実行して、アップグレードに対応可能なすべてのスキーマのリストを表示することが役立ちます。

  1. 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 WHERE OWNER LIKE UPPER('<PREFIX>_%');
    

  2. 生成されたレポートを調査します。

ノート:

  • アップグレード後、レポートを再度生成して、更新されたバージョンのスキーマを表示できます。あるスキーマでアップグレードの必要がない場合、schema_version_registry表には、アップグレード前のバージョンでそのスキーマが保持されます。

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

  • 以前のバージョンでOIDベースのポリシー・ストアを使用していた場合、アップグレードを実行する前に新しいOPSSスキーマを必ず作成します。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。

  • Oracle Fusion Middlewareリリース14c (14.1.2.0.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ14c (14.1.2.0.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

auto_loginウォレットのauto_login_onlyへの変換

Oracle HTTP Server (OHS)インスタンスを14c (14.1.2.0.0)にアップグレードする前に、convert_to_auto_login_only.plを使用して、既存のすべてのOHS auto_login walletsauto_login_onlyに変換する必要があります。

Oracle HTTP Server (OHS) 14c (14.1.2.0.0)でサポートされているウォレットはauto_login_only ウォレットのみです。サーバーを起動する前に、auto_loginウォレットを識別してauto_login_onlyに変換する必要があります。

  1. すべてのauto_loginウォレットを識別します。auto_login ウォレットには、次の2つの追加ファイルがあります。
    cwallet.sso
    ewallet.p12
  2. convert_to_auto_login_only.plスクリプトを使用して、各auto_loginウォレットをauto_login_onlyに変換します。
    Usage:
    perl <path_to_convert_to_auto_login_only.pl> <auto_login_wallet directory> <auto_login_only_wallet directory>
    <Password of auto_login_wallet>
    auto_login_wallet directory - Directory path to the existing auto_login wallet directory
    auto_login_only_wallet directory - Directory path to the new auto_login_only wallet directory, directory will be created
    by the tool
    Password of auto_login_wallet - Optional: Password of the existing auto_login wallet
    次のコマンドは、デフォルト・ウォレットを例として使用します。次のコマンドを実行する前に、特定の環境-DOMAIN_HOMEおよびORACLE_HOME環境変数のディレクトリ・パスを調整する必要があります。
    Linux/Unix:
    cd $DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/keystores/
    $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/ohs/common/bin/convert_to_auto_login_only.pl default default/auto_login_only
    Windows:
    cd %DOMAIN_HOME%\config\fmwconfig\components\OHS\ohs1\keystores
    %ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\ohs\common\bin\convert_to_auto_login_only.pl default default\auto_login_only
  3. 新しいauto_login_only_walletディレクトリを使用するようにすべてのウォレット・ディレクティブを更新します。
    サンプル・エントリ(特定の環境のディレクトリ・パスを調整する必要があります):
    #SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores
    /default"
    SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default
    /auto_login_only"
    #WLSSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores
    /default"
    WLSSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores
    /default/auto_login_only"

ノート:

convert_to_auto_login_only.plスクリプトは、リクエストされた証明書(CSR)をインポートしません。証明書署名リクエスト(CSR)が必要な場合は、新しいauto_login_onlyウォレットを作成する必要があります。

アップグレード後、別のスクリプトを実行して、htdocsディレクトリにあるファイルからバージョン情報を削除する必要があります。unresolvable-reference.html#GUID-FA91B77F-3539-40AC-83CE-AB638C491453を参照してください。

DISPLAY環境変数の設定

DISPLAY環境変数がGUIモードを使用できるように正しく設定されていないと、エラーが発生することがあります。

LinuxおよびUNIXオペレーティング・システム・ユーザー:

GUIモードを許可するようにDISPLAY環境変数を適切に設定していない場合、次のエラーが発生することがあります。

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified 

この問題を解決するには、使用するローカル・ワークステーションのシステム名またはIPアドレスにDISPLAY環境変数を設定して、アップグレード・アシスタントを再実行します。

DISPLAYを設定してもこのエラーが引き続き発生する場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

ODIの外部認証の構成

アップグレード・アシスタントを起動する前に、外部認証モードを内部認証に切り替えます。

ODIが外部認証モードで構成されている場合、アップグレード・アシスタントで特定のODI資格証明を認証できるように、アップグレードの前に認証メカニズムを内部認証に切り替える必要があります。アップグレード・プロセスが完了したら、アップグレードした環境でこの外部認証を再度切り替える必要があります。

ノート:

これは、外部認証を使用している場合にのみ適用されます。外部認証を使用していない場合は、このステップをスキップします。

『Oracle Data Integratorの管理』の次の各項を参照してください。