6 Oracle Access Managerのアウトオブプレース・アップグレードの実行

アップグレード前のアセスメント

アップグレードを開始する前に、次のアセスメントが完了していることを確認する必要があります。

  • アウトオブプレース・アップグレードには、新しいORACLE_HOMEおよびWLSドメインが必要です。
  • データベースが適切にアップグレードされています。
  • 「Oracle Fusion Middlewareのアップグレード前チェックリスト」の前提条件をすべて完了します
  • 既存の12c (12.2.1.4.0)環境を評価し、アップグレードのための重要なコンポーネントをリストします。これには、ソース環境とターゲット環境の評価が含まれます。

  • 12c (12.2.1.4.0)環境の上に最新のパッチをインストールします。
  • JDK jdk17.0.12またはjdk21.0.4をインストールします
  • 新しいホストまたはファイル・システムのOracle Homeに fmw_14.1.2.0.0_infrastructure.jarfmw_14.1.2.1.0_idm.jarをインストールします。

管理サーバーといずれかの管理対象サーバーがインストールされているサーバーでのpackコマンドの実行

このサンプル・トポロジの場合は、HOST1で次を実行します。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/12c_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

この例の説明:

  • 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12c (12.2.1.4.0) ビットのインストール・ディレクトリ)への実際のパスを表します。

  • 12c_DOMAIN_HOMEは、アップグレードするドメイン・ディレクトリの実際のパスに置き換えます。

  • domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

  • domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

  • デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

    ORACLE_COMMON_HOME/common/bin/
    

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

解凍前のターゲットへの12cバイナリのインストール

ドメインを解凍する前に、Oracle Access Manager 12c (12.2.1.4.0)をターゲット環境(OAMHOST2)にインストールする必要があります。

OAM 12c (12.2.1.4.0)バイナリは、ソース環境で使用されたファイルシステム上の同じパスを使用してインストールする必要があります。ターゲット環境がソース環境と同じレベルにパッチ適用されていることを確認します。『Oracle Fusion Middleware Oracle Identity and Access Managementのインストールと構成12c (12.2.1.4.0)』ガイドのOracle Access Managementソフトウェアのインストールと構成に関する項を参照してください。

HOST2で12c Oracle Homeからunpackコマンドを実行する。

管理サーバーと管理対象サーバーが停止していることを確認してから、unpackコマンドを実行して、リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用する完全ドメイン(またはドメインのサブセット)を作成します。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。

ノート:

既存のドメインの上にドメインを解凍しないようにしてください。ドメイン・アップグレード・テンプレートのjarファイルのコンテンツは、新しいドメイン・ロケーションに解凍することをお薦めします。

ドメインの解凍時に -overwrite_domain=true引数を使用する場合でも、既存ドメインのコンテンツは所定の場所に残り、サーバー起動時に問題が発生します。このため、ドメイン・テンプレートのjarファイルを新しい場所に解凍するか、解凍前に既存の場所のコンテンツを手動で削除することをお薦めします。

サンプルのunpackコマンドのコード・スニペットを次に示します。

cd /14c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=NEW_DOMAIN_LOCATION

この例の説明:

  • 14c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(14c (14.1.2.1.0)のインストール・ディレクトリ)への実際のパスを表します。

  • NEW_DOMAIN_LOCATIONを、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

  • domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

  • domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

アップグレード前の準備状況チェックの実行

アップグレードの潜在的な問題を特定するために、アップグレード・プロセスを開始する前に準備状況チェックを実行することをお薦めします。準備状況チェックで、アップグレードの潜在的な問題をすべて検出できない場合があることに注意してください。準備状況チェックで成功が報告されても、アップグレードが失敗する場合があります。

アップグレード前の準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。

Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックと異なることがあるためです。

ノート:

パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。

準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。

アップグレード・アシスタントを使用して、アップグレード前の環境に対して準備状況チェックを実行するには:
  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin

    ORACLE_HOMEは、14c (14.1.2.1.0) Oracleホームです。

  2. Upgrade Assistantを起動します。
    • (UNIX) ./ua -readiness
    • (Windows) ua.bat -readiness

    ノート:

    DISPLAY環境変数がGUIモードを有効にするように適切に設定されていないと、次に示すエラーが発生することがあります。
    Xlib: connection to ":1.0" refused by server
    Xlib: No protocol specified 

    この問題を解決するには、DISPLAY変数を、有効なX環境が動作しているホストおよびデスクトップに設定する必要があります。

    たとえば、デスクトップ6のローカル・ホストでVNC内部のX環境を実行している場合は、DISPLAY=:6を設定します。デスクトップ1のリモート・ホストでXを実行している場合は、これをDISPLAY=remoteHost:1に設定します。

    その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

Upgrade Assistantのパラメータ

コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。

表6-1 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-readiness

準備状況チェックの場合は必須

ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。

実際のアップグレードを実行せずに、アップグレードの準備状況チェックを実行します。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

オプション

次のいずれかの属性を指定して、ログイン・レベルを設定します。

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、失敗したアップグレードをトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

オプション

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX)

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

Upgrade Assistantを使用した準備状況チェックの実行

アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。
準備状況チェックを実行するには:
  1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次」をクリックします。
  2. 「準備状況チェック・タイプ」画面で、「ドメイン・ベース」を選択します。

    「ドメイン・ベース」オプションを使用すると、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内のアップグレード可能なスキーマまたはコンポーネントのすべてを、Upgrade Assistantが検出して選択できます。

    このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。

    Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。

    • 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。

    • 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

  3. 「ドメイン・ディレクトリ」フィールドで、14c (14.1.2.1.0)の設定マシンにコピーされた12c (12.2.1.4.0)ドメイン・フォルダを選択します。14c (14.1.2.1.0)設定が12cリリースと同じマシン上にある場合、準備状況チェック中に12cドメイン・ホームの場所を指定します。

    「次」をクリックします。

  4. 「コンポーネント・リスト」画面に、スキーマがアップグレードされるコンポーネントのリストが表示されます。

    「次」をクリックします。

  5. スキーマ資格証明画面で、選択した12c (12.2.1.4.0)スキーマに接続するためのデータベース資格証明を指定します(「データベース・タイプ」「DBAユーザー名」および「DBAパスワード」)。アップグレード前の要件の一部として、必要なユーザーをすでに作成しました。「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

    次に、「接続」をクリックします。

    ノート:

    Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。

    「スキーマ・ユーザー名」オプションを選択して、「スキーマ・パスワード」を指定します。

    ノート:

    Upgrade Assistantでは、デフォルトの資格証明が自動的に有効になります。接続できない場合、スキーマの資格証明を手動で入力し、続行します。

    すべてのスキーマ接続が検証されるまで、「次」をクリックします(選択したスキーマに基づいて画面名が変わります)。

    ノート:

    接続に失敗する場合は、原因を調べ、修正してください。
  6. 「準備状況サマリー」画面で、選択内容に基づいて実行される準備状況チェックのサマリーを確認します。
    選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。
    詳細レポートを表示するには、「ログの表示」をクリックします。
    「次」をクリックします。
  7. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
    複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。
    準備状況チェックが完了したら、「続行」をクリックします。
    次のコンポーネントはアップグレードされていませんが、アップグレードの準備ができていますとマークされます。次のコンポーネントに対するアップグレードの準備ができていますというメッセージは、無視してください。
    • Oracle JRF
    • 共通インフラストラクチャ・サービス
    • Oracle Web Services Manager。
  8. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。
    • 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

    • 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックして、ログ・ファイルを確認して問題を特定し、問題を修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションにより管理されます。

準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

準備状況レポート・ファイルの形式は、次のとおりです。

readiness_timestamp.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次の情報が含まれています。

表6-2 準備状況レポートの要素

レポートの情報 説明 必要なアクション
全体的な準備状況ステータス: SUCCESSまたはFAILURE レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻です。

アクションは必要ありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

アクションは必要ありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所です。

アクションは必要ありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

ドメインに、このリリースにアップグレードできないSOAコア拡張機能などのコンポーネントが含まれる場合は、アップグレードを試行しないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。ドメインに、このリリースにアップグレードできないスキーマが含まれる場合は、アップグレードを試行しないでください。

個別のオブジェクトのテスト・ステータス: FAIL

準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。

失敗した問題がすべて解決されるまではアップグレードしないでください。

個別のオブジェクトのテスト・ステータス: PASS

準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。

準備状況チェック・レポートに「成功」ステータスのみが表示されている場合は、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の準備状況チェックの完了ステータス: FAILURE 準備状況チェックで、スキーマ、索引またはデータ型などの特定のオブジェクトに対して解決する必要がある1つ以上のエラーが検出されました。 失敗した問題がすべて解決されるまではアップグレードしないでください。
<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS 準備状況チェック・テストによって問題が検出されませんでした。 アクションは必要ありません。
準備状況レポート・ファイルのサンプルを次に示します。レポートにはこれらのチェックのすべてが含まれない場合があります。
This readiness check report was created on Wed Dec 02 05:47:33 PST 2020 Log file is located at: 
/oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2020-12-02-05-35-03AM.log
Readiness Check Report File: 
/oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2020-12-02-05-47-33AM.txt
Domain Directory: 
/oracle/work/middleware_1212/user_projects/domains/oim_domain

Starting readiness check of components.

Oracle Platform Security Services
    Starting readiness check of Oracle Platform Security Services.
      Schema User Name: DEV_OPSS
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_OPSS is currently at version 11.1.1.9.0. 
Readiness checks will now be performed.
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
    Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
    Starting schema test:  Test that the schema does not contain any unexpected tables  TEST_UNEXPECTED_TABLES
    Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
    Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
    Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
    Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
    Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
    Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
    Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
    Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
    Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
    Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
    Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
    Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
    Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
    Starting datatype test for table CT_29: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
    Completed datatype test for table CT_29: TEST_COLUMN_DATATYPES_V2 
--> Test that all table columns have the proper datatypes +++ PASS
    Starting index test for table JPS_ENTITY_LOCK: TEST_REQUIRED_INDEXES 
--> Test that the table contains all the required indexes
    Completed index test for table JPS_ENTITY_LOCK: 
TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting index test for table CT_9_3:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
    Completed index test for table CT_9_3: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
    Starting schema test:  UPGRADE_SCRIPT_TEST  Test that the middleware contains the required Oracle Platform Security Services upgrade script
    Completed schema test: UPGRADE_SCRIPT_TEST --> Test that the middleware contains the required Oracle Platform Security Services upgrade script +++ PASS
    Starting schema test:  PRIVILEGES_TEST  Test that the Oracle Platform Security Services schema has appropriate system privileges
    Completed schema test: PRIVILEGES_TEST --> Test that the Oracle Platform Security Services schema has appropriate system privileges +++ PASS
    Starting schema test:  SEQUENCE_TEST  Test that the Oracle Platform Security Services schema sequence and its properties are valid
    Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid 
+++ PASS
    Finished readiness check of Oracle Platform Security Services with
status: SUCCESS.

Oracle Metadata Services
    Starting readiness check of Oracle Metadata Services.
      Schema User Name: DEV_MDS
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_MDS is currently at version 11.1.1.9.0. 
Readiness checks will now be performed.
    Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
    Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
    Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
    Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ PASS
    Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
    Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
    Starting index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES 
--> Test that the table contains all the required indexes
    Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
    Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
    Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
    Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Finished readiness check of Oracle Metadata Services with status: 
SUCCESS.

User Messaging Service
    Starting readiness check of User Messaging Service.
      Schema User Name: DEV_ORASDPM
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_ORASDPM is currently at version 11.1.1.9.0. Readiness checks will now be performed.
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Starting column test for table RULE_SET: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns
    Completed column test for table RULE_SET: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Starting column test for table STATUS: TEST_UNEXPECTED_TABLE_COLUMNS 
--> Test that the table does not contain any unexpected columns
    Completed column test for table STATUS: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Starting column test for table STATUS_ORPHAN: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns
    Completed column test for table STATUS_ORPHAN: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Starting column test for table USER_DEVICE: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns
    Completed column test for table USER_DEVICE: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Finished readiness check of User Messaging Service with status: SUCCESS.

Oracle SOA
    Starting readiness check of Oracle SOA.
      Schema User Name: DEV_SOAINFRA
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_SOAINFRA is currently at version 11.1.1.9.0. Readiness checks will now be performed.
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
    Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
    Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
    Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ PASS
    Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
    Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
    Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
    Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
    Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
    Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
    Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
    Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
    Starting schema test:  SOA_TABLESPACE_VALIDATION  Test SOAINFRA schema for enough default table space and temp table space.
    Completed schema test: SOA_TABLESPACE_VALIDATION --> Test SOAINFRA schema for enough default table space and temp table space. +++ PASS
    Starting schema test:  SOA_INSTANCE_VALIDATION  Test SOAINFRA schema for inconsistencies of instance data.
    Completed schema test: SOA_INSTANCE_VALIDATION --> Test SOAINFRA schema for inconsistencies of instance data. +++ PASS
    Finished readiness check of Oracle SOA with status: SUCCESS.

Oracle Identity Manager
    Starting readiness check of Oracle Identity Manager.
      Schema User Name: DEV_OIM
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
    Starting schema test:  examine  Calling examine method
      INFO Examine is successful
    Completed schema test: Examine --> Testing schema version +++ PASS
    Starting schema test:  TEST_MDS_BACKUP  Taking backup of MDS data related to OIM to handle any unseen situation during upgrade.
      INFO MDSBackup passes. Backup of MDS data related to OIM is here: 
/oracle/work/middleware_latest/oracle_common/upgrade/temp/mdsBackup/
    Completed schema test: TEST_MDS_BACKUP --> Taking backup of MDS data related to OIM to handle any unseen situration during upgrade. +++ PASS
    Finished readiness check of Oracle Identity Manager with status: 
SUCCESS.

User Messaging Service
    Starting readiness check of User Messaging Service.
    Starting config test:  TEST_USERMESSAGINGCONFIG  Test that configuration file usermessagingconfig.xml is accessible, in place and valid.
    Completed config test: TEST_USERMESSAGINGCONFIG --> Configuration file usermessagingconfig.xml is accessible, in place and valid. +++ PASS
    Starting config test:  TEST_ALREADY_UPGRADED  Test that configuration is not already upgraded.
    Completed config test: TEST_ALREADY_UPGRADED --> Configuration is not already upgraded. +++ PASS
    Finished readiness check of User Messaging Service with status: SUCCESS.

Oracle Identity Manager
    Starting readiness check of Oracle Identity Manager.
      INFO There are no configuration readiness tests for Oracle Identity Manager.
    Finished readiness check of Oracle Identity Manager with status: 
SUCCESS.

Oracle JRF
    Starting readiness check of Oracle JRF.
    Finished readiness check of Oracle JRF with status: SUCCESS.

System Components Infrastructure
    Starting readiness check of System Components Infrastructure.
    Starting config test:  TEST_SOURCE_CONFIG  Checking the source configuration.
      INFO
/oracle/work/middleware_1212/user_projects/oim_domain/opmn/topology.xml
was not found. No upgrade is needed.
    Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
    Finished readiness check of System Components Infrastructure with
status: ALREADY_UPGRADED.

Common Infrastructure Services
    Starting readiness check of Common Infrastructure Services.
    Starting config test:  CIEConfigPlugin.readiness.test  This tests the readiness of the domain from CIE side.
    Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
    Finished readiness check of Common Infrastructure Services with
status: SUCCESS.

Oracle Web Services Manager
    Starting readiness check of Oracle Web Services Manager.
    Completed config test: BOOTSTRAP_PROPERTIES_CHECK --> Bootstrap properties check +++ PASS
    Completed config test: CONFIGURATION_PROPERTIES_CHECK --> Configuration properties check +++ PASS
    Completed config test: TOKEN_TRUST_PROPERTIES_CHECK --> Trust issuer properties check +++ PASS
    Completed config test: MDS_REPOSITORY_CONNECTIVITY_CHECK --> MDS repository connectivity check +++ PASS
    Finished readiness check of Oracle Web Services Manager with status: 
SUCCESS.

Finished readiness check of components.

ノート:

準備状況レポートの索引欠落エラーは無視できます。これは既知の問題です。該当の欠落している索引は、スキーマ・アップグレード操作中に追加されます。アップグレードするスキーマがRCUを使用して12cで作成された場合、このエラーは発生しません。

製品スキーマのアップグレード

サーバーとプロセスの停止後、Upgrade Assistantを使用して、12.2.1.4.0スキーマをOracle Fusion Middlewareの14c (14.1.2.1.0)リリースにアップグレードします。

ノート:

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

ノート:

14c (14.1.2.1.0)では、将来のリリースへのゼロ・ダウンタイム・アップグレードを支援するために、次のスキーマが変更されています:
  • 14c (14.1.2.1.0)より前に作成された、エディションが無効になっているスキーマを、14c (14.1.2.1.0)にアップグレードすると、エディションが有効になります。

  • Oracle Access Managerは、エディションをサポートしていません。エディションを無効にしてOracle Access Managerスキーマを作成する必要があります。

  • 14c (14.1.2.1.0)で作成されたスキーマは、エディションが有効になった状態で作成されます。

Upgrade Assistantを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるUpgrade Assistantの画面は異なります。

Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを14c (14.1.2.1.0)にアップグレードします。

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

Upgrade Assistantを起動する前に、Upgrade Assistantが実行されるプラットフォームのJVM文字コードがUTF-8に設定されていることを確認します。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字が含まれるファイルをダウンロードできません。そのため、アップグレードが失敗する可能性があります。文字エンコーディングを設定するには、次を実行します。

UNIXオペレーティング・システム:

export UA_PROPERTIES="-Dfile.encoding=UTF-8 ${UA_PROPERTIES}"

Windowsオペレーティング・システム:

set UA_PROPERTIES=-Dfile.encoding=UTF-8 %UA_PROPERTIES%
  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantの起動:
    • (UNIX) ./ua
    • (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

Upgrade Assistantのパラメータ

コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。

表6-3 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-readiness

準備状況チェックの場合は必須

ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。

実際のアップグレードを実行せずに、アップグレードの準備状況チェックを実行します。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

オプション

次のいずれかの属性を指定して、ログイン・レベルを設定します。

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、失敗したアップグレードをトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

オプション

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX)

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

Upgrade Assistantを使用したスキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意: アップグレードを開始する前に、必要なすべての前提条件を実行してください。たとえば、既存のドメインにWLSSchemaDataSourceデータ・ソースがある場合、14.1.2.0.0からは、どのデータベース・ユーザーが割り当てられているかを確認する必要があります。<PREFIX>_WLS_RUNTIMEが割り当てられている場合は、それを<PREFIX>_WLSに変更する必要があります。詳細は、「WLSSchemaDataSourceデータ・ソースのデータベース・ユーザーの確認」を参照してください。
アップグレード・アシスタントを使用して製品スキーマをアップグレードするには:
  1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

    ノート:

    Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
  2. 「選択したスキーマ」画面で、「ドメインで使用されるすべてのスキーマ」を選択します。
    • ドメインで使用されるすべてのスキーマ。アップグレード・アシスタントは、「ドメイン・ディレクトリ」シールドに指定されているドメイン内のアップグレード可能なスキーマがあるすべてのコンポーネントを検索し、選択できます。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

      ノート:

      必要なすべてのスキーマがアップグレードに確実に含まれるようにするため、ほとんどのアップグレードについて「ドメインで使用されるすべてのスキーマ」を選択することをお薦めします。ただし、スタンドアロン・インストールには「個別に選択されたスキーマ」オプションを使用します。

    「次」をクリックします。

  3. 「ドメインで使用されるすべてのスキーマ」を選択した場合: 「コンポーネント・リスト」画面で、2つのリストのスキーマが表示されます。最初のリストには、スキーマがドメインに存在しアップグレードされるコンポーネントが示されています。2番目のリストには、作成が必要であると考えられる不足のスキーマのリストが示されています。必要なスキーマが不足していない場合は、最初のリストのみが表示されます。両方のリストを確認し、「次へ」をクリックします。
    Upgrade Assistantでは、既存のドメイン・スキーマの作成に使用されたスキーマ資格証明を使用して、不足しているスキーマの作成を試行します。リポジトリ作成ユーティリティを起動する必要はありません。
    一部のコンポーネントやスキーマをリストから除外する場合は、「すべてのスキーマ」画面に戻り、「個別に選択されたスキーマ」を選択します。このオプションにより、アップグレードに含めるスキーマのみを選択できます。
  4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

    ノート:

    Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
  5. スキーマ資格証明画面で、アップグレードする各スキーマのデータベース接続詳細を指定します(選択したスキーマに応じて画面名が変更されます)。
    • 「Database Type」ドロップダウン・メニューからデータベース・タイプを選択します。

    • データベース接続の詳細を入力して、「接続」をクリックします。

    • 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

      ノート:

      リリース12.1.2の時点で、UCSUMSスキーマのスキーマ名が変更されています。つまり、Upgrade Assistantは可能性のあるスキーマを自動的に認識できずにドロップダウン・リストに表示しないということです。テキスト・フィールドに手動で名前を入力する必要があります。名前はアップグレードの開始ポイントに応じて、prefix_ORASDPMまたはprefix_UMSのいずれかになります。
  6. 「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードアップグレードのトラブルシューティングで参照してください。

    ノート:

    • 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

    • 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

  7. 「アップグレード・サマリー」画面で、アップグレードまたは作成、あるいはその両方が行われるスキーマのサマリーを確認します。
    アップグレード対象のスキーマごとに、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。
    これらのオプションを保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。
    「次へ」をクリックします。
  8. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

    注意:

    Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。
    正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

    ノート:

    この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

    「次」をクリックします。

  9. アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。

    アップグレードが失敗した場合: 「アップグレード失敗」画面で「ログの表示」をクリックして、エラーを確認し、トラブルシューティングします。ログはNEW_ORACLE_HOME/oracle_common/upgrade/logsにあります。

    ノート:

    アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

スキーマのアップグレードの確認

すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。必ず<PREFIX>をスキーマ接頭辞に置き換えてください。

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, EDITION NAME, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY where owner like '<PREFIX>_%';

問合せ結果について:

  • EDITION NAME列がORA$BASEとして表示されることを確認します。
  • VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が14.1.2.1.0であることを確認します。

    ノート:

    すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。

  • STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。

  • ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

  • IAU_APPENDIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。

    これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当するINVALIDオブジェクトは、無視しても問題ありません。

WebLogicドメインの再構成

再構成ウィザードを使用してドメインを再構成するには、まずDOSコマンド・プロンプトまたはUNIXシェルからこれを起動し、表示される一連の画面に必要なアップグレードの詳細を入力します。

Windowsコマンド・プロンプトまたはUNIXシステムから、再構成ウィザードをグラフィカル・モードで起動するには:

  1. ドメインが存在するシステムにログインします。
  2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開きます。
  3. 次のディレクトリに移動します。ここでORACLE_HOMEは、14c Oracleホーム・ディレクトリです。

    Windowsの場合: ORACLE_HOME\oracle_common\common\bin

    UNIX:の場合: ORACLE_HOME/oracle_common/common/bin

  4. 次のコマンドを実行します:

    Windowsの場合: reconfig.cmd

    UNIXの場合: sh reconfig.sh

「再構成セットアップの進行状況」画面が表示されます。

ドメイン・コンポーネント構成のアップグレード

ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを14c (14.1.2.1.0)にアップグレードします。

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

Upgrade Assistantを起動する前に、Upgrade Assistantが実行されるプラットフォームのJVM文字コードがUTF-8に設定されていることを確認します。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字が含まれるファイルをダウンロードできません。そのため、アップグレードが失敗する可能性があります。文字エンコーディングを設定するには、次を実行します。

UNIXオペレーティング・システム:

export UA_PROPERTIES="-Dfile.encoding=UTF-8 ${UA_PROPERTIES}"

Windowsオペレーティング・システム:

set UA_PROPERTIES=-Dfile.encoding=UTF-8 %UA_PROPERTIES%
  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantの起動:
    • (UNIX) ./ua
    • (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

Upgrade Assistantのパラメータ

コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。

表6-4 Upgrade Assistantコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-readiness

準備状況チェックの場合は必須

ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。

実際のアップグレードを実行せずに、アップグレードの準備状況チェックを実行します。

スキーマと構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを指定しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

オプション

次のいずれかの属性を指定して、ログイン・レベルを設定します。

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

-logLevel TRACE属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、失敗したアップグレードをトラブルシューティングする際に役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

オプション

アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX)

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

Upgrade Assistantを使用したドメイン構成のアップグレード

Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを14c (14.1.2.1.0)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには:
  1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

    ノート:

    Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
  2. 「すべての構成」画面で、「ドメインによって使用されるすべての構成」を選択し、ドメインの場所を「ドメイン・ディレクトリ」フィールドに直接入力するか、「参照」をクリックしてナビゲーション・ツリーで有効なドメイン・ディレクトリを選択して指定します。「次へ」をクリックします。
  3. 「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
    アップグレードするコンポーネントが表示されない場合は、「戻る」をクリックして前の画面に移動し、異なるドメインを指定します。
  4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

    ノート:

    Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
  5. ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

    ノート:

    Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。
  6. 「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードアップグレードのトラブルシューティングで参照してください。

    ノート:

    • 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

    • 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。

  7. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
    レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。
    「アップグレード」をクリックして、アップグレード・プロセスを開始します。
  8. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

    注意:

    Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。
    正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

    ノート:

    この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

    「次」をクリックします。

  9. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後のステップがある場合のみ表示されます。
    アップグレードが失敗した場合: 「アップグレード失敗」画面で「ログの表示」をクリックして、エラーを確認し、トラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

    ノート:

    アップグレードが失敗した場合は、アップグレード前の環境をバックアップからリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

ドメイン固有コンポーネント構成のアップグレードの確認

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、リモート・コンソールにサインインし、アップグレードされた各コンポーネントのバージョン番号が14.1.2.1.0になっていることを確認します。

ノート:

ホストされたWebLogicリモート・コンソールにアクセスする前に、ホストされたWebLogicリモート・コンソールをデプロイする必要があります。詳細は、Remote Consoleオンライン・ヘルプを参照してください。

リモート・コンソールにサインインするには、http://hostname:port/rconsole、またはHTTPSの場合は https://hostname:port/rconsoleに移動します。

ノート:

アップグレードに成功したら、管理ツールは、前のOracleホーム・ディレクトリではなく新しい14c (14.1.2.1.0)のOracleホーム・ディレクトリから必ず実行してください。

アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。

Upgrade Assistantを実行するためにFMWユーザーを作成した場合は、アップグレードが成功したことを確認してからアカウントを削除してください。

サーバーおよびプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

ノート:

この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Serverリモート・コンソールを使用することもできます。管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

リリース14c (14.1.2.0.0)以降、WebLogic Server管理コンソールは削除されました。同等の機能を使用するには、WebLogicリモート・コンソールを使用する必要があります。詳細は、Oracle WebLogicリモート・コンソールを参照してください。

Fusion Middleware環境を起動するには、次のステップに従います。

ノート:

既存のセキュリティ設定によっては、保護された本番モードが有効なドメインを管理するために、追加の構成が必要な場合があります。詳細は、WebLogicリモート・コンソールを使用した管理サーバーへの接続に関する項を参照してください

.

ステップ1: ノード・マネージャを起動する

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

  • (UNIX) NEW_DOMAIN_HOME/bin/startNodeManager.sh

  • (Windows) NEW_DOMAIN_HOME\bin\startNodeManager.cmd

ステップ2: 管理サーバーの起動

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

  • (UNIX) NEW_DOMAIN_HOME/bin/startWebLogic.sh

  • (Windows) NEW_DOMAIN_HOME\bin\startWebLogic.cmd

    ノート:

    保護された本番モードを使用する場合は、管理サーバーを起動するための追加パラメータを指定する必要があります。『Oracle WebLogic Serverセキュリティの管理』WLSTを使用した管理サーバーへの接続に関する項を参照してください。

プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。

ステップ3: 管理対象サーバーを起動する

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

  • (UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

  • (Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

    ノート:

    保護された本番モードを使用する場合は、管理対象サーバーを起動するための追加パラメータを指定する必要があります。Oracle WebLogic Serverセキュリティの管理起動スクリプトを使用した管理対象サーバーの起動に関する項を参照してください。

ノート:

通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

ステップ4: システム・コンポーネントを起動する

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

  • (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。