| Oracle® Fusion Middleware Upgrade Assistantによるアップグレード 12c (12.2.1.1) E77370-01 |
|
 前 |
 次 |
注意:
このガイドはアップグレードのためのリファレンス・ツールとして使用するよう意図されています。サポートされるアップグレードの開始点、および特定のインストール・タイプの前提条件およびアップグレード・パスについての詳細情報は、必ずコンポーネント固有のアップグレード・ドキュメントを参照してください。ここでは、以下の項目について説明します。
Oracle Fusion Middleware Upgrade Assistantを使用して、サポートされている11gおよび12cのコンポーネント・スキーマ、コンポーネント構成およびスタンドアロン・システム・コンポーネント構成をFusion Middleware 12c (12.2.1.1)にアップグレードします。リリース12c (12.2.1.1)時点では、Upgrade Assistantを使用して、アップグレード前の準備状況チェックを実行することもできます。
oracle_common/upgrade/bin/ua
oracle_common\upgrade\bin\ua
Upgrade Assistantを実行すると、次のタスクが実行されます。
—readinessモードで実行すると、ドメインに関連付けられたスキーマおよびコンポーネント構成に対してアップグレード前のチェックが実行されます。このチェックは、ドメインがオンラインであるときに実行する必要があります。注意:
Upgrade Assistantを拡張する前に、SYSDBA以外のユーザーを作成することをお薦めします。SYSDBA以外のユーザーの作成を参照してください。Upgrade Assistantを他のFusion Middlewareツールおよびプロセスとともに使用して、サポートされているOracle Fusion Middleware 11gおよび12cコンポーネントの最新リリースへのアップグレードを実行します。
11gから12cへのアップグレード・プロセスは、以前のリリースからのアップグレードの場合と大きく異なります。アップグレード・プロセスにおけるUpgrade Assistantおよび他のアップグレード・ツールの使用方法を理解するには、12cアップグレード・プロセスの理解に関する項を参照してください
通常のアップグレードでは、次で説明するように、Upgrade Assistantを複数回使用できます。
Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。準備状況チェックは、システムがオンライン中に実行できます。準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。準備状況チェックでは、スキーマが特定のドメインの一部である必要はありません。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。
または、準備状況チェックを-responseモードで実行して、レスポンス・ファイルを使用してサイレント準備状況チェックを実行することもできます。Upgrade Assistantでのレスポンス・ファイルの使用の詳細は、「レスポンス・ファイル・モードでのUpgrade Assistantの起動」を参照してください。
調査フェーズと準備状況チェックの違いの理解
アップグレード・プロセスの調査フェーズは、準備状況チェックの実行とは別の操作です。通常、調査フェーズ中に実行されるチェックより、準備状況チェックの方が徹底しています。調査フェーズは「アップグレード」をクリックする直前に移行し、スキーマおよび構成問題に関する潜在的な問題を特定しますが、準備状況チェックは実際のアップグレードを開始する前に実行される読取り専用のプロセスです。
注意:
準備状況チェックは実際のアップグレードを開始する前に実行してください。すでにアップグレード手順を実行した場合、準備状況チェックを実行しないでください。実行しても結果が正しくない可能性があります。注意: アップグレードを実行した際に、アップグレードの正常な実行を妨げる問題が発生した場合、バックアップを使用してアップグレード前の環境に戻し、アップグレードを再実行する必要がある場合があります。準備状況チェックを実行すると、これらの問題の一部を特定し、システムのダウンタイムが延長されることを回避できます。
Upgrade Assistantにはスキーマのアップグレードに対して2つのオプションが用意されています。「個別に選択されたスキーマ」および「ドメインで使用されるすべてのスキーマ」です。
個別に選択されたスキーマ
このオプションを使用すると、アップグレードするコンポーネント・スキーマを選択できます。ドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合にこのオプションを選択します。
たとえば、ドメインの外部にあるRCUを使用してスキーマを作成してUpgrade Assistantを試行してから、Upgrade Assistantを使用してこれらをアップグレードします。
ドメインで使用されるすべてのスキーマ
このオプションにより、Upgrade Assistantは指定したドメイン内のすべての使用可能なスキーマを検出し、それらをアップグレードに含めることができます。これはドメイン支援スキーマ・アップグレードとも呼ばれます。
アップグレードを開始する前に、スキーマのバージョン・レジストリを問い合せて使用可能なスキーマのリストを確認します。
このオプションの手順は、アップグレード・プロセスを開始する前にschema_version_registry表を手動で問い合せる場合に使用できます。Upgrade Assistantではアップグレードできるすべてのスキーマを識別し、アップグレードするスキーマを個別に選択することも、Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることもできるという点に特に注意してください。さらに、Upgrade Assistantを—readinessモードで実行すると、すべてのスキーマおよびアップグレードする前の現在のバージョンが記載されたレポートを受信できます。
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 ;
SQLスクリプト(version.sqlなど)に保存されると、次のレポートが生成されます。
VERSIONの数値が11.1.1.7.0以上で、STATUS列がVALIDであれば、そのスキーマはアップグレードでサポートされます。
schema_version_registry表には、アップグレード後もアップグレード前のバージョンでそのスキーマが保持されます。ヒント:
スキーマ・バージョン・レジストリから収集した情報と対応するスキーマを比較し、ドメイン内にまだアップグレードできないスキーマがあるかどうかを判断します。
アップグレードが必要なスキーマに関する注意
ほとんどのコンポーネントで、アップグレードできるスキーマ・バージョンの開始点は、11gリリース1 (1.1.1.7.0、11.1.1.8.0、または11.1.1.9.0)または12c (12.1.2、12.1.3、または12.2.1.0)のみです。スキーマが、サポートされているバージョンでない場合、12c (12.2.1.1)のアップグレード手順を使用する前に、それらをアップグレードする必要があります。
Oracle Enterprise Data QualityやOracle Golden Gate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。
アップグレードに必要なスキーマに関する追加情報は、コンポーネント固有のインストールおよびアップグレードのドキュメントを参照してください。
11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードを実行する前に新しい12c (12.2.1.1) OPSSスキーマを作成していることを確認してください。アップグレード後も、OPSSスキーマはLDAPベースのストアのままです。
Oracle Fusion Middleware 12c (12.2.1.1)リリースでアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.1)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。
データベースにスキーマが作成されると、リポジトリ作成ユーティリティ(RCU)は、schema_version_registryという表を作成して維持します。一部のスキーマではアップグレードが必要ない場合があるため、アップグレードを実行する前にこの表を参照してください。
注意: 「スキーマ」列は、接頭辞とスキーマ名の間にアンダースコア(_)を使用したデフォルトのスキーマ名フォーマットを示します。デフォルトの接頭辞はDEVですが、RCUを使用すると、スキーマに新しく接頭辞を作成できます。
表1-1 Oracle Fusion Middleware 12c (12.2.1.1)へアップグレードできるスキーマ
| コンポーネント名 | スキーマ | アップグレード前のスキーマ・バージョン | アップグレード後のスキーマ・バージョン | 依存関係および追加情報 |
|---|---|---|---|---|
監査サービス1 |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.0 |
依存関係はありません。 このスキーマの最新バージョンは12.2.1.0です。 |
メタデータ・サービス |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
依存関係はありません。 |
プラットフォーム・セキュリティ・サービス2 |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.0 |
このスキーマの最新バージョンは12.2.1.0です。 |
共通インフラストラクチャ・サービス(LocalSvcTbl) |
|
12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
SOAINFRAなどの他のコンポーネントをアップグレードする場合は、 |
ユーザー・メッセージング・サービス |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
12.2.1の新規インストールであるシステムをアップグレードする場合、スキーマ名は |
WebLogic診断フレームワーク |
|
11.1.1.7 12.1.2.0 12.2.1.0 |
12.2.1.1 |
|
Data Integrator (マスターおよび作業リポジトリ) |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
なし。 |
SOAインフラストラクチャ(Oracle Business Activity Monitoring、Business Process ManagementおよびOracle Service Busを含む) |
|
11.1.1.7 11.1.1.9 12.1.3 12.2.1.0 |
12.2.1.1 |
|
Oracle Enterprise Scheduler |
|
11.1.1.7 11.1.1.9 12.1.3 12.2.1.0 |
12.2.1.1 |
|
Oracle Managed File Transfer。 |
|
12.1.3.0 12.2.1.0 |
12.2.1.1 |
prefix_MDS、prefix_IAUおよびprefix_UMSもアップグレードする必要があります。 |
Oracle WebCenter Contentサーバー |
|
11.1.1.7 11.1.1.83 11.1.1.9 12.2.1.0 |
12.2.1.1 |
prefix_MDSスキーマを最初にアップグレードする必要があります。 |
Oracle WebCenter Enterprise Capture |
|
11.1.1.8 12.2.1.0 |
12.2.1.1 |
prefix_MDSおよびprefix_OPSSスキーマを最初にアップグレードする必要があります。 |
Oracle WebCenterポータル |
|
11.1.1.74 11.1.1.8 12.2.1.0 |
12.2.1.1 |
prefix_MDSスキーマを最初にアップグレードする必要があります。 |
| Oracle WebCenter Sites | prefix_SITES |
12.2.1.0 | 12.2.1.1 | |
Enterprise Data Quality |
|
11.1.1.7.3 12.1.3.0 12.2.1.0 |
12.2.1.0 |
このスキーマの最新バージョンは12.2.1.0です。 |
Golden Gate Monitor |
|
11.1.1.7 12.1.3.0 12.2.1.0 |
12.2.1.0 |
このスキーマの最新バージョンは12.2.1.0です。 |
| GoldenGate Studio | prefix_OGGSTUDIO |
12.2.1.0 | 12.2.1.1 | |
Veridata |
|
11.2.1.0 12.1.3.0 12.2.1.0 |
12.2.1.0 |
このスキーマの最新バージョンは12.2.1.0です。 |
Upgrade Assistantを使用して、サポートされているコンポーネント構成を12c (12.2.1.1)にアップグレードできます。
Upgrade Assistantを使用して構成をアップグレードすると、構成されるコンポーネントおよび最新バージョンにアップグレードできるコンポーネントのリストがUpgrade Assistantによって自動的に作成されます。Upgrade Assistantを実行してスキーマをアップグレードした後は、再構成ウィザードを使用してドメインを再構成します。再構成した後、残りの構成プロパティをアップグレードするには、再度Upgrade Assistantを使用します。
Upgrade Assistantを使用して、次のコンポーネント構成を12c (12.2.1.1)にアップグレードできます。
注意: 推奨されないか12.2.1.1リリースではまだ使用できない既存のFusion Middleware 11gコンポーネントを使用し続ける場合は、アップグレードを試みないでください。
Oracle Data Integrator (ODI)
Oracle Enterprise Data Quality (EDQ)
Oracle Forms
Oracle Reports
Oracle Golden Gate Monitor (OGGMON)
Oracle Golden Gate Veridata
Oracle HTTP Server(OHS)
JRFインフラストラクチャ(WLS)
Oracle MapViewer
Oracle Managed File Transfer (MFT)
Oracle Traffic Director (OTD)
Oracle User Messaging Service(UMS)
Oracle WebCenter Content (WCC)
Oracle Web Services Manager。
注意:
これは、アップグレード・プロセスを開始する前に完了している必要があるであろうタスクの完全なリストではありません。正常なアップグレードのために必要となる可能性のあるすべてのタスクのリストは、Oracle Fusion Middlewareのアップグレード前チェックリストを参照してください。このチェックリストはコンポーネント固有のアップグレード・ガイドにあり、アップグレードを開始する前に必ず確認してください。Oracle Databaseを使用している場合は、Upgrade Assistantを実行する前にデータベース・オブジェクトを再コンパイルできます。そのためには、SYSとしてデータベースに接続し、SQL*Plusから次のコマンドを実行します。
SQL>@/rdbms/admin/utlrp.sql
これにより、データベース・オブジェクトがコンパイルされます。
その後、次の問合せを使用して、無効なデータベース・オブジェクトがないことを確認します。
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
アップグレードの前にINVALIDのデータベース・オブジェクトが存在していてはなりません。
無効なオブジェクトがある場合は、再度utlrp.sqlコマンドを実行してください。問題が続く場合は、サービス・リクエストを提出します。
新しい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$表が含まれている必要があります。SYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。システム・バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。
各Fusion MiddlewareスキーマではSYSTEM.SCHEMA_VERSION_REGISTRY$表に行があります。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。必ず、既存のデータベース・スキーマをバックアップしてから、Upgrade Assistantを実行してください。
注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。Upgrade Assistantを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよびアップグレードするスキーマまたは構成データを使用している可能性があるシステム・コンポーネント(OHSなど)を停止します。
また、Fusion Middlewareデータベース・スキーマを含むデータベースは、Upgrade Assistantを実行する前に停止する必要があります。データベース・サーバーをシャットダウンして再起動するか、Upgrade Assistantによってアップグレードされるデータベース・インスタンス上で他のデータベース・ユーザーが稼働していないことを確認します。これを行わないと、結果としてアップグレードが不完全になったり、障害が発生する場合があります。
ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。
Oracle Fusion Middlewareの停止手順は、Oracle Fusion Middleware環境の停止についての説明を参照してください。
FMWという名前でSYSDBA以外のユーザーを作成してUpgrade Assistantを実行することをお薦めします。FMWユーザーにはスキーマを変更するのに必要な権限がありますが、完全な管理者権限はありません。
注意:
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にアクセスしてパッチをダウンロードします。
このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。
このトピックで説明するオプションのコマンドライン・インタフェース引数を使用して、Oracle Fusion Middlewareコンポーネントを最新のバージョンにアップグレードできます。また、一部のアップグレード・タスクを自動化するレスポンス・ファイルを作成することもできます。
この節の内容は以下のとおりです。
Upgrade Assistantはスキーマのアップグレード、コンポーネント構成およびスタンドアロン・システムのコンポーネント構成に使用されます。
注意:
Upgrade Assistantは可能であればいつでも、SYSDBA以外のユーザーが実行する必要があります。スキーマのアップグレードに必要な権限を持つユーザーの作成手順については、「SYSDBA以外のユーザーの作成」に記載されています。表1-2に、Upgrade AssistantをGUIモードで実行する際に使用できるコマンドライン・パラメータをリストします。次の例は、これらのパラメータを各オペレーティング・システムで使用する方法を示します。
UNIXオペレーティング・システムの場合:
ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。
コマンドを入力します: ./ua -help
Windowsオペレーティング・システムの場合:
ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。
コマンドを入力します: ua.bat -help
注意:
Oracle Upgrade Assistantを起動するときに、「サーバーに接続できません。」、「サーバーによって接続が拒否されました」または「表示を開くことができません」などのXlibエラーが発生する場合、「DISPLAY環境変数の設定」の説明に従ってDISPLAY環境変数を設定して、Upgrade Assistantを再起動する必要があります。表1-2 Upgrade Assistant GUIコマンドライン・パラメータ
| パラメータ | 必須パラメータ/オプション・パラメータ | 説明 |
|---|---|---|
|
オプション。 |
ロギング・レベル。次のいずれかを選択します。
デフォルトのロギング・レベルはNOTIFICATIONです。 注意: トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。注意: TRACEメッセージは、Upgrade Assistantログ・ファイル・ビューアに含まれていません。TRACEメッセージを表示するには、別のツールを使用する必要があります。 |
|
オプション。 注意: Upgrade Assistantが読取り専用ディレクトリにインストールされている場合、ログ・ディレクトリを書込み可能にするには、このパラメータを指定する必要があります。ログ・ディレクトリが読取り専用である場合、Upgrade Assistantは機能しなくなります。 |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を変更します。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 |
|
オプション | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4スレッドです。 |
|
準備状況チェックに必要 | 実際の調査またはアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。 注意: -readinessオプションは、コマンドラインに-examineオプションとともには表示されない場合があります。詳細は、「準備状況チェックの実行」を参照してください |
|
オプション。 |
コマンドライン・オプションをすべてコンソールに出力します。 |
サイレントまたはハンズフリー・アップグレードはレスポンス・ファイルを使用して実行できます。レスポンス・ファイルはUpgrade Assistantの画面で情報を入力した後でのみ作成できます。
次のトピックでは、レスポンス・ファイルを使用して、サポートされているOracle Fusion Middlewareコンポーネントをサイレント・モードでアップグレードする方法について説明します。このレスポンス・ファイルは、Upgrade Assistantのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集し、Upgrade Assistantウィザードの機能とまったく同じ機能を実行します。
注意:
Upgrade AssistantをGUIモードでまず実行して、サイレント・アップグレードを完了するために使用されるレスポンス・ファイルを生成する必要があります。「アップグレード・サマリー」画面の「レスポンス・ファイルの保存」オプションは、Upgrade Assistant画面ですでに入力した情報を使用するファイルを作成します。レスポンス・ファイルにより、Upgrade Assistantウィザードの画面を介してデータを手動で入力するかわりに、保存された情報を使用できます。
「レスポンス・ファイルの保存」オプションを選択すると、このレスポンス・ファイルの名前と作成場所を入力するように求められます。作成されたら、そのファイルをそのまま使用して他のシステムにアップグレード・オプションを複製するか、必要に応じて変更できます。
詳細は、「レスポンス・ファイルを使用したFusion Middlewareのアップグレード」を参照してください。
コマンドライン・インタフェース(CLI)からレスポンス・ファイルを使用してアップグレードを実行するには、次のコマンドを使用します。
UNIXオペレーティング・システムでは、次のようにします。
ディレクトリをORACLE_HOME/oracle_common/upgrade/bin に変更します。
次を実行します。
./ua -response <response_file> [-examine] [-logLevel <log_level>] [-logDir <log_directory>] [-threads <number>]Windowsオペレーティング・システムの場合:
ディレクトリをORACLE_HOME/oracle_common/upgrade/bin に変更します。
次を実行します。
ua.bat -response <response_file> [-examine] [-logLevel <log_level>] [-logDir <log_directory>] [-threads <number>]表1-3 Upgrade Assistantのレスポンス・ファイル・モードのコマンドライン・パラメータ
| パラメータ | 必須パラメータ/オプション・パラメータ | 説明 |
|---|---|---|
|
準備状況チェックに必要 | 実際の調査またはアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。 注意: -examineパラメータを指定した場合、このパラメータを指定しないでください。詳細は、「準備状況チェックの実行」を参照してください |
|
オプション | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4スレッドです。 |
|
必須。 |
アップグレードを実行するには、入力が含まれているファイルが必要です。このファイルは、グラフィカル・モードでUpgrade Assistantを実行しているときに入力した入力から生成できます。 |
|
オプション。 |
このオプションが有効になっている場合、Upgrade Assistantは調査フェーズを実行しますが、実際のアップグレードは行いません。 注意: -readinessパラメータを指定した場合、このパラメータを指定しないでください。 |
|
オプション。 |
ロギング・レベル。次のいずれかを選択します。
デフォルトのロギング・レベルはNOTIFICATIONです。 注意: -logLevelをTRACEに設定すると、より多くの情報がロギングされます。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。 |
|
オプション。 |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を変更します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 UNIXオペレーティング・システムの場合、デフォルトの場所は次のとおりです。
Windowsオペレーティング・システムの場合、デフォルトの場所は次のとおりです。
|
|
オプション。 |
すべてのコマンドライン・オプションを表示します。 |
Upgrade Assistantを使用して、サポートされているスキーマをOracle Fusion Middlewareのこのリリースにアップグレードします。
スキーマをアップグレードするためにUpgrade Assistantを実行したときに表示される画面は、選択するオプションおよびアップグレード前の環境のコンテンツによって異なります。
表1-4 スキーマのアップグレード: Upgrade Assistantのナビゲート画面
| 画面のタイトル | 画面が表示されるタイミング | 説明 |
|---|---|---|
常時。 |
この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。 |
|
常時。 |
この画面で、実行するスキーマのアップグレード操作を選択します。画面上のオプションは、次で選択したオプションに応じて変わります。
|
|
個別に選択されたスキーマを選択した場合。 |
この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。 |
|
「ドメインで使用されるすべてのスキーマ」を選択した場合。 |
この画面は読取り専用で、アップグレードに含まれる特定のドメイン・ディレクトリ内のすべてのコンポーネントおよびスキーマが表示されます。 |
|
常時。 |
この画面では、アップグレードを続行する前にすべての前提条件が満たされていることを確認する必要があります。続行する前にボックスを確認します。 |
|
常時。 |
この画面で、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。 画面名は、選択したスキーマ・タイプによって変わります(例: MDSスキーマ)。 リリース12.1.2のUCSUMSスキーマでは、コンポーネントIDまたはスキーマ名が変わるため、Upgrade Assistantは、使用可能なスキーマを自動的に認識し、それらをドロップダウン・リストに表示することはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前は、アップグレードの開始点に応じて、prefix_ |
|
常時。 |
この画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。
注意: 調査フェーズ中に検出された問題は、バックアップからリストアしなくても修正できます。 |
|
常時。 |
この画面で、選択したオプションのサマリーをレビューし、アップグレード・プロセスを開始します。 |
|
常時。 |
この画面には、アップグレード処理のステータスが表示されます。 |
|
アップグレードに成功した場合。 |
アップグレードが成功しました。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。 |
|
アップグレードに失敗した場合。 |
アップグレードは特定のコンポーネントで失敗しました。Upgrade Assistantを再起動する必要があります。 Upgrade Assistantのログは
ORACLE_HOME/oracle_common/upgrade/logsにあります。注意: アップグレードで障害が発生した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再起動する必要があります。この操作中にファイルが変更されているため、この問題を修正してUpgrade Assistantを再起動することはできません。 |
管理対象WebLogicドメインのコンポーネントを含むOracleホームからUpgrade Assistantを実行する場合、「ドメインによって使用されるすべての構成」アップグレード・オプションを使用できます。
コンポーネント・スキーマをアップグレードした後、再構成ウィザードを実行して、ドメインを再構成する必要があります。詳細は、再構成ウィザードを使用したOracle WebLogicドメインの再構成に関する項を参照してください。ドメインを再構成した後、Upgrade Assistantを再度使用して、この項の説明に従ってコンポーネント構成をアップグレードします。
Oracle Web Services Manager (OWSM)などのWebLogicコンポーネント構成をアップグレードすると、Upgrade Assistantに次の画面が表示されます。
表1-5 Upgrade Assistant画面: Oracle WebLogicコンポーネント構成のアップグレード
| 画面 | 画面が表示されるタイミング | 説明 |
|---|---|---|
常時。 |
この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。 |
|
アップグレード・タイプとして「ドメインによって使用されるすべての構成」を選択したときの画面名は、「WebLogicコンポーネント」です。 |
管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「ドメインによって使用されるすべての構成」オプションを選択します。構成のアップグレードは、12.2.1ではオフラインです。アップグレードするドメインのドメイン・ディレクトリを入力してください。 |
|
「ドメインによって使用されるすべての構成」オプションが選択されている場合のみ。 |
この画面では、WebLogicドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。ドメインの名前は、ドメイン内にあるコンポーネントのリストとともに提供されます。 |
|
常時。 |
この画面では、アップグレードを続行する前にすべての前提条件が満たされていることを確認する必要があります。続行する前にボックスを確認してください。 |
|
UMS 11g構成ファイルをホストするリモート管理対象サーバーがある場合(つまり、管理サーバーで、必要な構成ファイルにローカルにアクセスできない場合)のみ。 |
この画面では、UMS 11g構成ファイルをホストするリモート管理対象サーバーのログイン資格証明を指定します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、アップグレード・アシスタントにより、リモート構成ファイルが自動的にコピーされます。 |
|
常時。 |
この画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するUpgrade Assistantのステータスが表示されます。 |
|
常時。 |
この画面を使用して、選択したオプションのサマリーをレビューし、アップグレード・プロセスを開始します。 |
|
常時。 |
この画面には、アップグレード処理のステータスが表示されます。 |
|
|
または |
常時。 |
アップグレードが成功しました。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。 または 特定のコンポーネントのアップグレードが失敗したため、Upgrade Assistantを再起動する必要があります。 |
次のトピックでは、アップグレードの完了後に実行する基本的なタスクについて説明します。リストされている製品がアップグレードされていないために、これらのタスクの一部が環境に適用されない場合があります。
アップグレード後の手順の詳細は、必ずコンポーネント固有のアップグレード・ドキュメントを参照してください。
注意: アップグレードした後は、この項で説明されたタスクを正常に完了できるようになっているはずです。これらのタスクのうち1つ以上が、新しくアップグレードした環境で完了できない場合、「アップグレードのトラブルシューティング」を参照してください。
この項では、新しくアップグレードしたドメインで実行できる一般的な管理タスクについて説明します。
注意: 次の表内の管理タスクはオプションです。アップグレードした環境に適用するタスクのみを実行してください。
表1-6 アップグレード後の基本的な管理タスク
| タスク | 説明 | 詳細 |
|---|---|---|
製品およびサーバーの起動と停止 |
Oracle Fusion Middleware(管理サーバー、管理対象サーバー、コンポーネントを含む)起動と停止の方法について学習します。 これらのタスクを実行することで、アップグレードが成功しているか検証されます。 |
「Oracle Fusion Middlewareの起動と停止」 |
アップグレードされたアプリケーションの起動および停止 |
新しい12.2.1環境でアップグレードされたアプリケーションを起動して、正常に動作するが確認する方法を説明します。 |
「アプリケーションの起動と停止」 |
Secure Sockets Layer (SSL)の構成 |
Oracle Fusion Middlewareコンポーネント間で、SSLを使用したセキュアな通信を設定する方法について学習します。 |
Oracle Fusion MiddlewareでのSSLの構成に関する項 |
アプリケーションのデプロイ |
アプリケーションをOracle Fusion Middlewareにデプロイする方法を学習します。 |
「アプリケーションのデプロイ」 |
Oracle Fusion Middlewareのモニタリング |
Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。 |
「Oracle Fusion Middlewareの監視」 |
Web層のフロントエンドのWebLogicドメインへの追加 |
OracleのWeb層でWebページ(静的と動的)をホストし、組込みのクラスタ、ロード・バランシングおよびフェイルオーバーの機能とともにセキュリティと高パフォーマンスを実現します。特にWeb層にはOracle HTTP Serverが含まれます。 |
Oracle HTTP Serverのインストールと構成 |
トポロジのCoherenceのチューニングと構成 |
標準インストール・トポロジには、記憶域が有効な管理対象Coherenceサーバーが含まれるCoherenceクラスタがあります。この構成はCoherenceの使用には適切な出発点ですが、特定の要件によっては、本番環境でのパフォーマンスを向上させるためにCoherenceをチューニングして再構成することを検討してください。 |
Coherenceクラスタの詳細は、「Coherenceクラスタの構成と管理」を参照してください Coherenceのチューニングの詳細は、『Oracle Coherenceの管理』を参照してください。 HTTPセッション・データの格納の詳細は、「WebLogic ServerでのCoherence*Webの使用方法」を参照してください。 Coherenceアプリケーションの作成とデプロイの詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発 』を参照してください。 |
次のSQLコマンドを使用して、schema_version_registryのスキーマ・バージョンが正しくアップグレードされていることを検証できます。
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 ;
VERSION列内の数値はすべて、アップグレード前のチェック時に指定したバージョンである必要があります。詳細は、「Upgrade Assistantでアップグレードできるスキーマの識別」を参照してください。
問合せ結果のSTATUSフィールドは、スキーマへのパッチ適用処理中は「UPGRADING」または「UPGRADED」に、処理が終了すると「VALID」になります。
ステータスが「INVALID」と表示された場合は、ステータスのアップグレードが失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
Oracle Databaseを使用している場合は、Upgrade Assistantを実行した後、データベース・オブジェクトを再コンパイルしてください。そのためには、SYSとしてデータベースに接続し、SQL*Plusから次のコマンドを実行します。
SQL>@/rdbms/admin/utlrp.sql
これによって、アップグレード・アシスタントによってアップグレードされたデータベース・オブジェクトがコンパイルされます。
その後、次の問合せを発行して、無効なデータベース・オブジェクトがなくなったことを確認します。
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
この時点では、アップグレードされたスキーマに、無効になっているデータベース・オブジェクトはないはずです。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が続く場合は、サービス・リクエストを提出します。
_IAUを11gの開始点からアップグレードすると、Upgrade Assistantは、2つの補助スキーマ(IAU_APPENDおよびIAU_VIEWER)を更新し、それらを12.2.1.1のschema_version_registryに追加します。これらのスキーマは、11.1.1.7のschema_version_registry表に含まれていませんでした。
リリース11.1.1.7より、OPSS監査データはJPS表ではなく、IAU共通の表に保存されます。_OPSSスキーマを11.1.1.6から12.2.1.1にアップグレードする場合、JPS表の既存データはレポートまたは監査目的では変更されないため、JPS表に列を追加してアップグレードする必要はありません。
エディション・ベースの再定義(EBR)対応のスキーマをサポートする最初のリリース
エディション・ベースの再定義(EBR)対応のスキーマをサポートする最初のリリース
