1. Cloud Controlアップグレード・ガイド
  2. Enterprise Manager Cloud Control 13cリリース4へのアップグレード
  3. Enterprise Manager Cloud Control 13cリリース4へのアップグレードの前提条件

3 Enterprise Manager Cloud Control 13cリリース4へのアップグレードの前提条件

Enterprise Manager Cloud Control 13cリリース4にアップグレードする前に、次の前提条件が満たされていることを確認します。

ハードウェア、ソフトウェアおよびプラットフォームの要件

必ず『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』のEnterprise Manager Cloud Controlのインストールに関する章に記載されたハードウェア要件を含め、すべての前提条件を満たします。

また、Enterprise Manager Cloud Control 13cリリース4へのアップグレードでサポートされているプラットフォームで示されている、サポートされているプラットフォームのみでアップグレードを行うようにします。

サポートされているデータベース・リリースの要件

既存のデータベースが13cリリース4に対して動作保証されているデータベースであることを確認します。動作保証されたデータベースのリストは、My Oracle Supportで入手できるEnterprise Manager動作保証マトリックスで確認できます。手順については、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドのEnterprise Manager動作保証マトリックスへのアクセスを参照してください。

既存のデータベースが13cリリース4でサポートされているリリースではない場合は、サポートされているリリースにアップグレードしてから、OMSと管理リポジトリのアップグレードを開始してください。たとえば、13cリリース2からアップグレードする場合、データベースのリリースが古く、13cリリース4でサポートされていない可能性があります。この場合は、まずデータベースを13cリリース4でサポートされている最低限のデータベース・リリースにアップグレードしてから、Enterprise Managerシステムを13cリリース4にアップグレードします。

データベースをアップグレードする前に、必ずデータベースに接続されている旧リリースのOMSインスタンスを停止してください。データベースのアップグレード時に、リスナー・ポートを変更した場合は、次のステップに従います。

  1. 変更後のリスナー・ポートを使用してデータベース・アップグレードを完了します。

  2. 次のコマンドを実行して、データベースに接続されている旧リリースの最初のOMSの管理サーバーを起動します。

    emctl start oms -admin_only

  3. すべてのOMSインスタンスに対して次のコマンドを実行して、最初のOMSに加えて他のOMSインスタンスも変更後のリスナー・ポートで更新します。

    emctl config oms –store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman

    前述のコマンドを各OMSで実行すると、OMSを停止してから再起動して変更を反映するよう求められます。各OMSで、指示されたとおりに実行してください。いずれにせよ、13cへのアップグレードを開始する前に、すべて停止する必要があります。

  4. 13cへのEnterprise Managerシステム全体のアップグレードを続行します。

ノート:

OMSが正常に起動しており、接続記述子の変更の完了後にコンソールにアクセスできることを確認してください。OMSが正常に起動された後にのみ、OMSのアップグレードを進めることをお薦めします。

データベース・パッチの要件

必ずサポートされているデータベースに最新のPSUを適用します。

Enterprise Manager Cloud Control 13.4.0.0にアップグレードする前に、サポートされているデータベースに最新のDB PSUを適用する必要があります。

オプティマイザ適応機能の無効化の要件

  • 管理リポジトリがOracle Database 12.1.0.2.0を使用しており、データベース・パッチ22652097が適用されていない場合、データベースにSYSDBAとして接続して次のコマンドを実行することにより、オプティマイザ適応機能を無効にします。

    alter system set optimizer_adaptive_features=false scope=both;

    変更が有効になったことを確認するには、次のコマンドを実行します。

    show parameter adaptive;

    次の出力が表示されるはずです。

    NAME                          TYPE         VALUE
---------------------------------------------------------------------
optimizer_adaptive_features   boolean      FALSE
  • 管理リポジトリがOracle Database 12.1.0.2を使用しており、データベース・パッチ22652097が適用されている場合、データベースにSYSDBAとして接続して次のコマンドを実行します。 
    alter system set "_optimizer_nlj_hj_adaptive_join"= FALSE scope=both sid='*'; 
alter system set "_optimizer_strans_adaptive_pruning" = FALSE scope=both sid='*'; 
alter system set "_px_adaptive_dist_method" = OFF scope=both sid='*'; 
alter system set "_sql_plan_directive_mgmt_control" = 0 scope=both sid='*'; 
alter system set "_optimizer_dsdir_usage_control" = 0 scope=both sid='*'; 
alter system set "_optimizer_use_feedback" = FALSE scope=both sid='*'; 
alter system set "_optimizer_gather_feedback" = FALSE scope=both sid='*'; 
alter system set "_optimizer_performance_feedback" = OFF scope=both sid='*';
  • 管理リポジトリがOracle Database 12.2、18.xまたは19.xを使用している場合は、アップグレード・プロセス中にパッチ30912308を適用するときに対処されるため、パラメータを設定する必要はありません。アップグレード・プロセス中にパッチを適用するには、お薦めの方法の1つに従います。
    それ以外の場合で、アップグレード・プロセス中に前述のお薦めの方法に従わずにパッチ30912308を適用する予定がある場合は、SYSDBAとしてデータベースに接続して次のコマンドを実行する必要があります。 
    alter system set "_optimizer_nlj_hj_adaptive_join"= FALSE scope=both sid='*';
alter system set "_optimizer_strans_adaptive_pruning" = FALSE scope=both sid='*';
alter system set "_px_adaptive_dist_method" = OFF scope=both sid='*';
alter system set "_sql_plan_directive_mgmt_control" = 0 scope=both sid='*';
alter system set "_optimizer_dsdir_usage_control" = 0 scope=both sid='*';
alter system set "_optimizer_use_feedback" = FALSE scope=both sid='*';
alter system set "_optimizer_gather_feedback" = FALSE scope=both sid='*';
alter system set "_optimizer_performance_feedback" = OFF scope=both sid='*';

Oracle Database 12.2.0.1.0/18.0.0.0.0のデータベース初期化パラメータ

管理リポジトリが存在するOracle Database 12.2.0.1.0/18.0.0.0.0以上で、データベース初期化パラメータがtrueに設定されていること(_allow_insert_with_update_check=TRUE)を確認してください。次のステップを実行します。

  1. _allow_insert_with_update_checkパラメータをTRUEに設定することでデータベース初期化パラメータを有効にします。これを行うには、次のSQLコマンドを実行します。

    alter system set _allow_insert_with_update_check=true scope=both

  2. データベースを再起動します。

  3. 変更が反映されていることを確認します。そのためには、次のSQLコマンドを実行します。

    show parameter _allow_insert_with_update_check;

    次の出力が表示されるはずです。

    NAME                          TYPE         VALUE
---------------------------------------------------------------------
_allow_insert_with_update_check   boolean      TRUE

ポートの要件

Oracle Management Service (OMS)で使用されているポートに1024以下の値が設定されていないことを確認します。この値以下に設定されている場合、アップグレードは失敗します。1024以下のポートは、一般にルート・ユーザー(スーパー・ユーザー)用に予約されています。このため、ポートは1024より大きくしてください。

カスタマイズの削除の要件

必ずOMSに対して実行した次のタイプのカスタマイズを削除します。アップグレードが完了した後で、再びカスタマイズすることができます。

  • Weblogic Serverで構成された追加のデータ・ソース・パラメータ。

  • Enterprise Managerログインのためのスマート・カード認証

Oracle BI Publisherの停止の要件

必ず以前のリリースにデプロイされているOracle BI Publisherを停止します。そのためには、次の方式のいずれかを使用します。

  • Enterprise Manager Cloud Control 13cリリース2 (13.2.0.0)または13cリリース3 (13.3.0.0)からアップグレードする場合は、BI Publisher Serverを実行しているインスタンスを含め、すべてのOMSインスタンスでemctl stop oms -allを実行します。

データベース・サービス・インスタンス作成リクエストの確認の要件

必ず未処理のデータベース・サービス・インスタンス作成リクエストがないか確認します。進行中のリクエストがある場合は、完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。

これを行うには、次のステップを実行します。

  1. Cloud Controlで、「エンタープライズ」メニューから、「クラウド」、「セルフ・サービス・ポータル」の順に選択します。

  2. 「インフラストラクチャ・クラウド・セルフ・サービス・ポータル」ページで、ページ・タイトルのすぐ下で、「マイ・データベース」を選択してデータベース・リクエストのみを参照します。

  3. 「リクエスト」表で、進行中のリクエストについては完了するまで待ちます。スケジュールされているリクエストについては、一時停止します。

    スケジュールされたリクエストを一時停止するには、リクエスト名をクリックします。「デプロイメント」タブをクリックします。そこにリストされたデプロイメント・プロシージャをクリックして、一時停止します。

リポジトリ表スナップショットの確認の要件

管理リポジトリ内の表でスナップショットが作成されていないことを確認します。

これを確認するには、管理リポジトリにSYSMANユーザーとしてログインし、次のSQL問合せを実行します。

select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER>';

次に例を示します。

select master , log_table from all_mview_logs where log_owner='SYSMAN';

作成されたスナップショットが表にある場合、マスター表およびスナップショットの詳細が表示されます。次に例を示します。

SQL> master log_table

em-violations em$violation_log

スナップショットがある場合は、SYSMANユーザーとして次のコマンドを実行して削除します。

SQL> Drop snapshot log on <master>;

次に例を示します。

SQL> Drop snapshot log on em-violations;

ログオンおよびログオフ・トリガー設定の確認の要件

Oracle Management Repositoryが存在するOracle Databaseにログオンまたはログオフ・トリガーを設定していないことを確認してください。

これを確認するには、データベースにログオンして、次の問合せを実行します。問合せ結果がゼロ以外の場合、または行が選択されない場合は、トリガーを手動で無効にします。アップグレード完了後に、これらを再度有効化できます。

  • ログオン・トリガーが設定されているかどうかを確認するには、次を実行します。

    SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGON%' AND status='ENABLED';

    SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGON%' AND status='ENABLED';

  • ログオフ・トリガーが設定されているかどうかを確認するには、次を実行します。

    SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';

    SQL> SELECT trigger_name FROM sys.dba_triggers WHERE TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';

このようなトリガーを無効化するには、次の問合せを実行します。

SQL> alter trigger <trigger_name> disable;

次に例を示します。

SQL> alter trigger EXPFIL_ALTEREXPTAB_MAINT disable;

ターゲットの削除操作の監査の要件

必ずターゲットの削除操作の監査を有効にします。

  • 操作のリストを表示するには、次のコマンドを実行します。

    emcli show_operations_list

    削除操作には、ターゲットの削除、名前付き資格証明の削除、ロールの削除、ルールの削除、モニタリング・テンプレートの削除、ユーザーの削除などがあります。

  • 現在有効になっている削除操作を確認するには、次のコマンドを実行します。

    emcli show_audit_settings

  • ターゲットの削除操作がまで有効になっていない場合は、次のコマンドを実行して有効にします。

    emcli update_audit_settings

    -operations_to_enable="name_of_the_operations_to_enable._For_all_operations_use_ALL"

    -audit_switch="ENABLE"

    -directory="db_directory_name" (エクスポート・サービスが監査データ・ファイルをアーカイブするOSディレクトリで構成する必要があります)

    -file_prefix="file_prefix" (エクスポート・サービスによって使用され、監査データを書き込む必要がありファイル名を作成します。デフォルト値はem_auditです。すべてのサイトで標準に応じて変更できます)

    -file_size="file_size (Bytes)" (各ファイル・サイズの最小値。このデフォルト値は5000000バイトです)

    -data_retention_period="data_retention_period (Days)" (Enterprise Managerリポジトリに監査データが格納される最大期間。デフォルト値は365日です)

    前述のパラメータは、保存期間後に、監査データを管理リポジトリからファイル・システムにアーカイブするために、アーカイブの場所を設定または構成するのに役に立ちます。

Enterprise Managerシステムの停止時間を短縮するためのジョブ・タイプの更新の選択的なスキップ

Enterprise Managerシステムのアップグレード中に、ジョブ・タイプが登録されます。ジョブ・タイプ登録プロセスの一環として、ジョブ・タイプに対応するアクティブな実行がすべて新しく登録されたバージョンのジョブ・タイプに自動的にアップグレードされます。このジョブ・タイプ・アップグレード・プロセスは、キューされた実行および待機中の実行すべてについてスキップされ、これによりEnterprise Managerシステムの停止時間全体が短縮されます。ただし、場合によってはEnterprise Managerシステムでかなりのバックログが発生し、このようなバックログがアップグレードの開始前にクリアされないと、Enterprise Managerシステムの停止時間がずっと長くなることがあります。この問題を回避するには、停止時間の終了を待ってアップグレードされるように、特定のジョブ・タイプのアップグレードを選択してスキップまたは後回しにすることができます。

ジョブ・タイプがアップグレードされないようにスキップまたは後回しにするには、次のステップを実行します。

  1. 停止時間中のアップグレードから除外するジョブ・タイプを特定します。

    そのためには、SYSMANユーザーとしてOracle Management Repositoryを格納しているデータベースにログインし、次の問合せを実行します。特に、アクティブな実行を多数保有するジョブ・タイプを探します。

    SELECT job_type, COUNT(1) as n_execs

    FROM MGMT_JOB_EXEC_SUMMARY

    JOIN MGMT_JOB_TYPE_INFO USING (job_type_id)

    WHERE status NOT IN (3,4,5,8,18,19,23)

    GROUP BY job_type

    HAVING COUNT(1) > 5000

    ORDER BY COUNT(1) DESC;

  2. 特定した他のジョブ・タイプを除外します。

    そのためには、次の問合せを実行してMGMT_PARAMETERS表からジョブ・タイプを除外します。除外するジョブ・タイプごとに、INSERT文を1つ実行する必要があります。たとえば、除外するジョブ・タイプが3つある場合、INSERT文を3回実行しますが、それぞれに除外するジョブ・タイプを指定します。

    INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('mgmt_job_skip_job_type_upg.1', '<job type>');

    COMMIT;

EMKEYのコピーの要件

[複数OMSアップグレードの場合、最初のOMSアップグレードのみでこのステップを実行してください]

必ず既存のOMSから既存の管理リポジトリにemkeyをコピーします。これを実行するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

$<ORACLE_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

次に例を示します。

/u01/software/em13c/mw/oms/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

emkeyがコピーされているかどうかを確認するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

$<ORACLE_HOME>/bin/emctl status emkey

次に例を示します。

/u01/software/em13c/mw/oms/bin/emctl status emkey

emkeyがコピーされている場合、次のメッセージが表示されます。

The EMKey  is configured properly, but is not secure.
Secure the EMKey by running "emctl config emkey -remove_from_repos".

証明書キーの強度の要件

証明書キーの強度が1024ビット以上であることを確認します。

11gリリース1以下の場合、証明書はキーの強度512ビットで生成され、12cリリース(12.1.0.5)へのアップグレードと、それに続く13cリリース2および13cリリース3へのアップグレードで引き継がれます。したがって、11g リリース1以下からアップグレードする場合、証明書は512ビットのままであり、最終的に様々な通信問題につながります。そのため、証明書キーの強度は1024ビット以上であることを確認してください。

証明書キーの強度を1024ビット以上に設定する手順は、My Oracle Supportのノート1611578.1を参照してください。

13cリリース4以降では、サポートされる最小の証明書はSHA 512/1024です。MD5証明書はサポートされなくなりました。MD5証明書がある場合は、アップグレード処理が停止して次のメッセージが表示されます。

アップグレード・プロセスで、一部のエージェント-OMS間の通信にMD5証明書が使用されていることを検出しました。該当するホストと関連ターゲットはアップグレード後も引き続き管理されます。ただし、Enterprise Managerの将来のバージョンではMD5証明書がサポートされない可能性があるため、SHAベースの証明書を使用するよう、これらを再構成することを強くお薦めします。 ファイル/tmp/OraInstall<time_stamp>/md5Target.txtを確認し、MD5ベースの証明書が使用されているエージェントを探します。My Oracle Supportのノート2179909.1に記載されている手順に従って、これらをSHAベースの証明書を使用して再構成してください。

それに対処した後に、アップグレード処理を再開できます。

即時利用可能なメモリー設定のバックアップの要件

OMSインスタンス用のデフォルトの即時利用可能なメモリー設定を変更している場合、アップグレード中に失われないようにデフォルト値をバックアップとして保存できます。

コマンドORACLE_HOME/bin/emctl get property -name property_nameを使用して、デフォルト値を確認することができます。

次に例を示します。

ORACLE_HOME/bin/emctl get property -name OMS_PERMGEN_MAX

12cリリース4 (12.1.0.4)からは、Enterprise ManagerはOMS 固有のJAVAヒープ・メモリー引数として設定できる次の新しいパラメータを導入しています。

  • OMS_HEAP_MIN (最小ヒープ・サイズの場合)

  • OMS_HEAP_MAX (最大ヒープ・サイズの場合)

  • OMS_PERMGEN_MIN (最小permGenサイズの場合)

  • OMS_PERMGEN_MAX (最大permGenサイズの場合)

OMSインスタンスのデフォルトの即時使用可能なメモリー設定を保存するには、これらのステップを実行します:

  1. 次のコマンドを使用して、JAVAヒープ・メモリーのプロパティの値を設定します。

    ORACLE_HOME/bin/emctl set property -name <property_name> -value <number_followed_by_G_or_M>

    次に例を示します。

    ORACLE_HOME/bin/emctl set property -name OMS_PERMGEN_MAX -value 1024M

  2. 次のコマンドを実行して、すべてのOMSインスタンスを再起動します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

    $<ORACLE_HOME>/bin/emctl stop oms -all

    $<ORACLE_HOME>/bin/emctl start oms

    次に例を示します。

    /u01/software/em13c/mw/oms/bin/emctl stop oms -all

    /u01/software/em13c/mw/oms/bin/emctl start oms

前提条件チェックおよび環境の検証の要件

アップグレードを開始する前に、必ずEM前提条件キットを実行し、リポジトリ関連の前提条件をすべて満たします。

EM前提条件キットを実行するには、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドで説明されているパラメータに従います。

OMSのバックアップの要件

必ずOMS (ミドルウェア・ホームおよびインベントリ)、Oracle Management RepositoryおよびOracle Software Libraryをバックアップします。リストアでは、インスタンス・ホーム(gc_inst)のバックアップが必要になります。アップグレードが失敗した場合、常にバックアップを使用してリストアできます。バックアップの手順は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

OMSの停止の要件

必ずこれからアップグレードするOMSと、それに接続されているその他のOMSインスタンスも停止します。

重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、このステップをスキップします。OMSインスタンスは、Enterprise Manager Cloud Control 13cリリース4ソフトウェア・バイナリのインストール(グラフィック・モード)またはEnterprise Manager Cloud Control 13cリリース4ソフトウェア・バイナリのインストール(サイレント・モード)で説明されているように、ソフトウェア・バイナリをインストールした後に停止できます。

  1. ノート:

    ステップ1は、12cから13cへアップグレードする場合にのみ該当します。

    JVMDおよびADPエンジンを明示的に停止します。

    グラフィック・モードでこれらを停止するには、WebLogicコンソールにアクセスし、JVMDおよびADP WebLogic管理対象サーバーを手動で停止します。

    サイレント・モードで停止するには、これからアップグレードするOMSで次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

    $<ORACLE_HOME>/bin/emctl extended oms jvmd stop -all

    $<ORACLE_HOME>/bin/emctl extended oms adp stop –all

    次に例を示します。

    /u01/software/em12c/mw/oms/bin/emctl extended oms jvmd stop -all

    /u01/software/em12c/mw/oms/bin/emctl extended oms adp stop –all

  2. これからアップグレードするOMSを停止して、これに接続されているその他のOMSインスタンスも停止します。これを行うには、次のコマンドを実行します。<ORACLE_HOME>は、OMSのOracleホームを指しています。

    $<ORACLE_HOME>/bin/emctl stop oms -all

    次に例を示します。

    /u01/software/em12c/mw/oms/bin/emctl stop oms -all

管理エージェントの停止の要件

管理エージェントがメトリック収集のために管理リポジトリに接続しないように、必ず「管理サービスとリポジトリ」ターゲットをモニターする管理エージェントを停止します。この管理エージェントを停止しないと、OMSアップグレードが失敗する可能性があります。

重要: ソフトウェアのみのアップグレードの方式を使用して複数OMS環境をアップグレードする場合は、このステップをスキップします。管理エージェントは、Enterprise Manager Cloud Control 13cリリース4ソフトウェア・バイナリのインストール(グラフィック・モード)またはEnterprise Manager Cloud Control 13cリリース4ソフトウェア・バイナリのインストール(サイレント・モード)で説明されているように、ソフトウェア・バイナリをコピーした後に停止できます。

管理エージェント・プロキシの削除の要件

必ずスタンドアロン管理エージェント用に構成されているプロキシを削除します。そうしないと、スタンドアロン管理エージェントのアップグレードが失敗します。この要件はむしろ管理エージェントのアップグレードに対することで、OMSのアップグレードには影響しませんが、OMSのアップグレードを開始する前に、管理エージェント側のプロキシを削除することをお薦めします。

DR準備状況へのアップグレードおよび移行の実行に必要な追加の準備およびステップ

記憶域レプリケーションDRアーキテクチャを使用したスタンバイOMSへの移行のプロセスを支援するため、「DR準備状況へのアップグレードおよび移行」というインストーラの新しいモードが作成されました。標準のアップグレードの前提条件に加えて、「DR準備状況へのアップグレードおよび移行」のアップグレードでは、従う必要のある準備およびアップグレード後のステップに固有のフローが必要になります。

この新しいモードは次のようなものです。

  • UPGRADE_TRANSITIONというパラメータを渡すことによって有効化

  • 最初のOMS上での使用のみサポート

  • 標準のGUIインストールを介してのみサポート

ConfigureGC.shに従ってのみインストールするソフトウェアでは、「DR準備状況へのアップグレードおよび移行」のサポートは提供されません。また、「DR準備状況へのアップグレードおよび移行」を使用した追加のOMSのアップグレードはサポートされていません。複数OMS環境では、追加のOMSは最初にアンインストールされ、移行に関連付けられた最初のOMSおよび関連するアップグレード後プロセスが完了している必要があります。そうなっている場合には、追加のOMSをデプロイできます。標準のアップグレードのかわりにDR準備状況へのアップグレードおよび移行を実行する方法の詳細は、Enterprise ManagerのアップグレードとDR準備状況への移行を参照してください。

廃止されたプラグインのアンデプロイ

次のプラグインのサポートは中止されており、現在は廃止されています。

  • Oracle Audit Vault (oracle.em.soav)

  • Oracle Virtual Networking (oracle.em.sovn)

  • Oracle Engineered System Healthchecks (oracle.em.sehc)

  • Oracle Ops Center Infrastructureスタック(oracle.em.sooc)

アップグレードを進める前に、Oracle Management AgentsとOracle Management Servicesからこれらのプラグインを必ずアンデプロイする必要があります。

古いプラグインをアンデプロイする前にインストーラを閉じることをお薦めします。また、これらのプラグインを自己更新からも削除することをお薦めします。詳細は、Oracle Enterprise Manager Cloud Control管理者ガイドのプラグインのアンデプロイを参照してください。

サーバー・ロード・バランサ(SLB)の要件

サーバー・ロード・バランサ(SLB)を使用している場合、アップグレードを続行する前にSLB設定を確認することをお薦めします。詳細は、My Oracle Support Doc ID 2671586.1を参照してください。