Upgrade Assistantを使用したアップグレードの実行

2 Upgrade Assistantを使用したアップグレードの実行

Upgrade Assistantは、スキーマのアップグレード、コンポーネント構成のアップグレード、およびアップグレード前の環境に対する準備状況チェックの実行といった、様々な方法で使用されます。

注意:

この章では、Upgrade Assistantを使用してOracle Fusion Middlewareアップグレードを実行する方法の高度な概要について説明します。実際のアップグレードを実行するときには、コンポーネント固有のアップグレード・ガイドを使用します。

アップグレード・アシスタントを使用する前に
Upgrade Assistantを使用してアップグレードを開始する前に、完全バックアップを作成し、他のアップグレード前のチェックおよびタスクを実行する必要があります。
Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。
アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。
製品スキーマのアップグレードの理解
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
コンポーネント構成のアップグレードの理解
アップグレード・アシスタントの各画面を移動して、WebLogicドメインのコンポーネント構成をアップグレードします。
アップグレード後の手順の実行
アップグレードの後に追加のアップグレード後構成タスクをすべて完了して、新しくアップグレードしたドメインが期待どおりに機能していることを検証します。ドメイン構成に適用するタスクのみを実行します。

Upgrade Assistantを使用する前に

Upgrade Assistantを使用してアップグレードを開始する前に、完全バックアップを作成し、他のアップグレード前のチェックおよびタスクを実行する必要があります。

注意:

実際のアップグレード・プロセスを開始する前に、追加のタスクの実行が必要になる場合があります。それぞれのコンポーネントに固有のアップグレード・ガイドには、アップグレードの開始前に実行する必要のあるアップグレード前のタスクの完全なリストを含むチェックリストが記載されています。

完全なバックアップの作成
アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。
オンライン・バックアップおよびリカバリに関する特別な考慮事項
環境に複数のミドルウェア・ホームが含まれ、アップグレードの障害後の完全データベース・リストアの実行が望ましいオプションでない場合は、これらの追加のバックアップを実行します。
アップグレード前の無効なデータベース・オブジェクトのチェック
アップグレードの失敗につながる可能性のある無効なオブジェクトを特定して、Upgrade Assistantの実行前にデータベース・オブジェクトを再コンパイルします。
Upgrade Assistantを実行するための非SYSDBAユーザーの作成
Upgrade Assistantを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーには、スキーマを変更するために必要な権限を付与しますが、完全な管理者権限は付与しません。
サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

親トピック: Upgrade Assistantを使用したアップグレードの実行

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

アップグレードを開始する前に、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を実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。アップグレード・アシスタントを実行する前に、既存のデータベース・スキーマおよびスキーマ・バージョン・レジストリを必ずバックアップします。

注意:

アップグレード・アシスタントを使用してスキーマをアップグレードする前に、完全なデータベースのバックアップを実行する必要があります。アップグレード中に、バックアップが実行されていることを確認する必要があります。

親トピック: 完全なバックアップの作成

カスタマイズされたドメインおよび環境設定のメンテナンス

アップグレード前の環境でドメイン生成スクリプト、サーバー起動スクリプトまたは構成ファイルを変更した場合、こうした変更はインストール、ドメイン更新および再構成操作の際に上書きされることに注意する必要があります。アップグレード後に引き続き使用できるように、カスタマイズされたファイルを共有ライブラリの場所に保存します。

どのドメインのインストールにも、動的に生成されたドメインおよびサーバーの起動スクリプト(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のアップグレードの起動スクリプトへのカスタマイズの再適用の説明に従って、設定を再適用する必要があります。

親トピック: 完全なバックアップの作成

オンライン・バックアップおよびリカバリに関する特別な考慮事項

環境に複数のミドルウェア・ホームが含まれ、アップグレードの障害後の完全データベース・リストアの実行が望ましいオプションでない場合は、これらの追加のバックアップを実行します。

完全データベース・リストアの影響を理解する

バックアップおよびリカバリ計画を作成する場合、完全データベース・リストアの影響を理解することが重要です。アップグレードが失敗した場合は、完全データベース・リストアの実行が必要な場合があります。しかし、これが可能でない場合や、望ましくない場合もあります。

単一のFMWホームがアップグレードされるときにオンラインのままになる必要がある、本番環境によって共有されているデータベースであるか。
失敗したアップグレードからリカバリするときにデータベースはオンラインのままになる必要があるか。
完全データベース・リストアの実行は、失敗したアップグレードからリカバリするための望ましくない解決策か。

次のいずれかの質問に対する答えが「はい」の場合は、開始する前に、これらの追加のアップグレード前タスクを完了します。

SYSが所有するオブジェクトに対する権限の保存
アップグレードが失敗した場合、SYSが所有するオブジェクトに対するすべての権限は、スキーマが削除されたときに失われます。必要に応じて権限の再適用に使用できるスクリプトを作成することをお薦めします。
アップグレード前のスキーマのエクスポート
データ・ポンプ・エクスポートを使用して、アップグレードされるスキーマをバックアップします。
アップグレードの前のキューの状態の識別
アップグレードが失敗した場合は、キューを手動で再起動する必要があります。これらのキューのインベントリを取得して、その再起動を支援します。

親トピック: Upgrade Assistantを使用する前に

SYSが所有するオブジェクトに対する権限の保存

アップグレードが失敗した場合、SYSが所有するオブジェクトに対するすべての権限は、スキーマが削除されたときに失われます。必要に応じて権限の再適用に使用できるスクリプトを作成することをお薦めします。

このスクリプトの作成方法の例を次に示します。生成されたSQLスクリプトについては次の点に注意してください。

スプールされた出力をSQLPlusによって実行する前に編集する必要があり、SQL問合せのテキストと"spool off"コマンドをスプールされたファイルから削除する必要があります。
一部の権限は、スキーマの削除/インポート後に適用される場合にエラーを返すことがあります。これが致命的なエラーとならない例を次にいくつか示します。
- 権限がすでに存在する

- 権限オブジェクトの名前がスキーマの作成時に動的に生成される。たとえば、詳細なキューイング・ビューの名前はQTnnnnnnnn_BUFFERです。

権限を再適用するスクリプトを作成するためのサンプルSQLPlusコマンド:

# The schema prefix in this example is "DEV"
$ORACLE_HOME/bin/sqlplus username/password
exec dbms_metadata.set_transform_param(dbms_metadata.SESSION_TRANSFORM,'SQLTERMINATOR',TRUE); 
set long 100000
set longchunksize 100000
set lines 1000
set termout off echo off newp 0 spa 0 pages 0 feed off head off trims on tab off
spool /tmp/create-grants.sql
select dbms_metadata.get_granted_ddl ('OBJECT_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('SYSTEM_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('DEFAULT_ROLE',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS');
spool off

親トピック: オンライン・バックアップおよびリカバリに関する特別な考慮事項

アップグレード前のスキーマのエクスポート

データ・ポンプ・エクスポートを使用して、アップグレードされるスキーマをバックアップします。

Oracle Data Pumpの使用に関する情報は、『Oracle Databaseユーティリティ』ガイドを参照してください。

次の例はエクスポートのサンプルです。

# The schema prefix in this example is "DEV"
# The schemas being exported are for the SOA, BPM and ESS environments
$ORACLE_HOME/bin/sqlplus username/password
create directory data_pump_directory as '/scratch/db12cr2/export';
 
expdp username/password schemas=DEV_STB,DEV_SOAINFRA,DEV_IAU_VIEWER,DEV_MDS,DEV_IAU_APPEND,DEV_WLS,DEV_UMS,DEV_OPSS,DEV_IAU,DEV_ESS directory=data_pump_directory dumpfile=export.dmp compression=ALL

親トピック: オンライン・バックアップおよびリカバリに関する特別な考慮事項

アップグレードの前のキューの状態の識別

アップグレードが失敗した場合は、キューを手動で再起動する必要があります。これらのキューのインベントリを取得して、その再起動を支援します。

単一スキーマのリストアでは、インポートされるキューは再起動されません。有効になっているキューをすべて再起動する必要があります。次の例は、アップグレードが失敗した場合に再起動する必要のあるキューのリストの生成に使用できるSQLコマンドを示しています。各スキーマ所有者に適切なスキーマ接頭辞を提供します。

set pagesize 20;
set linesize 200;
COLUMN OWNER FORMAT A50
COLUMN NAME FORMAT A50
select owner,name,enqueue_enabled,dequeue_enabled from dba_queues where owner='DEV_SOAINFRA';

親トピック: オンライン・バックアップおよびリカバリに関する特別な考慮事項

アップグレード前の無効なデータベース・オブジェクトのチェック

アップグレードの失敗につながる可能性のある無効なオブジェクトを特定して、Upgrade Assistantの実行前にデータベース・オブジェクトを再コンパイルします。

Oracle Databaseを使用している場合は、Upgrade Assistantを実行する前にデータベース・オブジェクトを再コンパイルできます。そのためには、データベース・オブジェクトをコンパイルするためにSYSとしてデータベースに接続し、SQL*Plusから次のコマンドを実行します。

SQL> @oracle_home/software/rdbms/admin/utlrp.sql

その後、次の問合せを使用して、無効なデータベース・オブジェクトがないことを確認します。

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

無効なオブジェクトがある場合は、再度utlrp.sqlコマンドを実行してください。問題が続く場合は、サービス・リクエストを提出します。

親トピック: Upgrade Assistantを使用する前に

Upgrade Assistantを実行するための非SYSDBAユーザーの作成

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

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

注意:

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

デフォルトでは、v$xatrans$表は存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。さらに、v$xatrans$表のgrant select権限は、Oracle Identity Governanceでのみ必要です。構成にOracle Identity Governanceが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。

   grant select on v$xatrans$ to FMW with grant option;

次の例では、passwordはFMWユーザーに対して設定されたパスワードです。権限を付与する際は、必ず実際のパスワードを指定してください。

create user FMW identified by password;
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_TABLESPACE_USAGE_METRICS to FMW with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

Oracle Identity Manager (OIM)スキーマをアップグレードする場合は、FMWユーザーに次の追加の権限が付与されていることを確認します。

grant execute on SYS.DBMS_FLASHBACK to fmw with grant option;
grant execute on sys.DBMS_SHARED_POOL to fmw with grant option;
grant execute on SYS.DBMS_XMLGEN to FMW with grant option;
grant execute on SYS.DBMS_DB_VERSION to FMW with grant option;
grant execute on SYS.DBMS_SCHEDULER to FMW with grant option;
grant execute on SYS.DBMS_SQL to FMW with grant option;
grant execute on SYS.DBMS_UTILITY to FMW with grant option;
grant ctxapp to FMW with admin option;
grant execute on SYS.DBMS_FLASHBACK TO FMW with grant option;
grant create MATERIALIZED VIEW to FMW with admin option;
grant all on SCHEMA_VERSION_REGISTRY TO FMW with grant option;
grant create SYNONYM to FMW with admin option;
grant execute on CTXSYS.CTX_ADM to FMW with grant option;
grant execute on CTXSYS.CTX_CLS TO FMW with grant option;
grant execute on CTXSYS.CTX_DDL TO FMW with grant option;
grant execute on CTXSYS.CTX_DOC TO FMW with grant option;
grant execute on CTXSYS.CTX_OUTPUT TO FMW with grant option;
grant execute on CTXSYS.CTX_QUERY TO FMW with grant option;
grant execute on CTXSYS.CTX_REPORT TO FMW with grant option;
grant execute on CTXSYS.CTX_THES TO FMW with grant option;
grant execute on CTXSYS.CTX_ULEXER TO FMW with grant option;
grant create JOB to FMW with admin option;

親トピック: Upgrade Assistantを使用する前に

サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、1つのOracle WebLogic Serverドメイン、1つの管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント(Identity Managementのコンポーネントなど)およびメタデータのリポジトリとして使用する1つのデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

注意:

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

アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動し、次のステップに従います。

ステップ1: システム・コンポーネントを停止する

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

(UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

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

ステップ2: 管理対象サーバーを停止する

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

(UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

ステップ3: Oracle Identity Managementのコンポーネントを停止する

Oracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を停止します。

(UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

ステップ4: 管理サーバーを停止する

管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

(UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

ステップ5: ノード・マネージャを停止する

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesの属性QuitEnabledをtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

親トピック: Upgrade Assistantを使用する前に

アップグレード・アシスタントの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。

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

注意:

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

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat

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

Upgrade Assistantのパラメータ

親トピック: Upgrade Assistantを使用したアップグレードの実行

Upgrade Assistantのパラメータ

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

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

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックの場合は必須注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。スキーマと構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを指定しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須	レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ロギング・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。 `-logLevel TRACE`属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。デフォルトの場所は次のとおりです。 (UNIX) `NEW_ORACLE_HOME/oracle_common/upgrade/logs` `NEW_ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `NEW_ORACLE_HOME/oracle_common/upgrade/logs` `NEW_ORACLE_HOME/oracle_common/upgrade/temp`
`-help`	オプション	すべてのコマンドライン・オプションを表示します。

親トピック: Upgrade Assistantの起動

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

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

アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。
準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。
Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

親トピック: Upgrade Assistantを使用したアップグレードの実行

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

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

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

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

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

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

注意:

パフォーマンスへの影響を避けるため、準備状況チェックはピーク時以外に実行するようにしてください。

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

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

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

Upgrade Assistantを使用して、アップグレード前の環境に対する準備状況チェックを実行するには:

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
Upgrade Assistantを起動します。
- (UNIX) ./ua -readiness
- (Windows) ua.bat -readiness
注意:
DISPLAY環境変数がGUIモードを有効にするように適切に設定されていないと、次に示すエラーが発生することがあります。
```
Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified 
```
この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

このようなエラーがDISPLAYの設定後にも続く場合は、別のGUIツール(vncconfigなど)を起動してみてください。同じエラーが表示される場合は、DISPLAY環境変数の設定に間違いが残っている可能性があります。
その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

Upgrade Assistantのパラメータ

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

Upgrade Assistantのパラメータ

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

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

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックの場合は必須注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。スキーマと構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを指定しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須	レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ロギング・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。 `-logLevel TRACE`属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。デフォルトの場所は次のとおりです。 (UNIX) `NEW_ORACLE_HOME/oracle_common/upgrade/logs` `NEW_ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `NEW_ORACLE_HOME/oracle_common/upgrade/logs` `NEW_ORACLE_HOME/oracle_common/upgrade/temp`
`-help`	オプション	すべてのコマンドライン・オプションを表示します。

親トピック: 準備状況モードでのUpgrade Assistantの起動

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

Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには:

「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。
「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。
- 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかをレポートします。
  このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。
- 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。
  このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。
  Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。
  - 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。
  - 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。
「次へ」をクリックします。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。
「ドメイン・ベース」を選択した場合: 「コンポーネント・リスト」画面で、準備状況チェックを実行するドメインに存在するコンポーネントのリストを確認します。

依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。
選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。
- ドメイン・ディレクトリを指定します。
- 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に、「接続」をクリックします。
  
  注意:
  Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。
- 「スキーマ・ユーザー名」オプションを選択して、「スキーマ・パスワード」を指定します。
「次」をクリックして、準備状況チェックを開始します。
「準備状況サマリー」画面で、選択内容に基づいて実行される準備状況チェックのサマリーを確認します。
選択内容を保存して、今後、レスポンス(サイレント)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次へ」をクリックします。
「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。
「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。
- 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。
- 準備状況チェックで問題またはエラーが発生した場合は、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定して修正してから、準備状況チェックを再開します。ログ・ファイルは、設定したコマンドライン・オプションにより管理されます。

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

準備状況レポートの理解

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

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

readiness_timestamp.txt

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

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

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

レポートの情報	説明	必要なアクション
全体的な準備状況ステータス: SUCCESSまたはFAILURE	レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。	1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。
タイムスタンプ	レポートが生成された日付と時刻です。	必要なアクションはありません。
ログ・ファイルの場所 `NEW_ORACLE_HOME/oracle_common/upgrade/logs`	生成されたログ・ファイルのディレクトリの場所です。	必要なアクションはありません。
準備状況レポートの場所 `NEW_ORACLE_HOME/oracle_common/upgrade/logs`	生成された準備状況レポートのディレクトリの場所です。	必要なアクションはありません。
チェックされたコンポーネントの名前	チェックに含まれるコンポーネントの名前およびバージョンとステータス。	ドメインに、このリリースにアップグレードできないSOAコア拡張機能などのコンポーネントが含まれる場合は、アップグレードを試行しないでください。
チェックされたスキーマの名前	チェックに含まれるスキーマの名前および現在のバージョンとステータス。	スキーマのバージョン番号をレビューします。ドメインに、このリリースにアップグレードできないスキーマが含まれる場合は、アップグレードを試行しないでください。
個別のオブジェクトのテスト・ステータス: FAIL	準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。	失敗した問題がすべて解決するまでアップグレードしないでください。
個別のオブジェクトのテスト・ステータス: PASS	準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。	準備状況チェック・レポートに「成功」ステータスのみが表示されている場合は、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。
<オブジェクト>の準備状況チェックの完了ステータス: FAILURE	準備状況チェックで、スキーマ、索引またはデータ型などの特定のオブジェクトに対して解決する必要がある1つ以上のエラーが検出されました。	失敗した問題がすべて解決するまでアップグレードしないでください。
<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS	準備状況チェック・テストによって問題が検出されませんでした。	必要なアクションはありません。

準備状況レポート・ファイルのサンプルを次に示します。レポートにはこれらのチェックのすべてが含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: NEW_ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: NEW_ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
   Starting readiness check of Oracle Metadata Services.
     Schema User Name: DEV11_MDS
     Database Type: Oracle Database
     Database Connect String: machinename@yourcompany.com
     VERSION Schema DEV11_MDS is currently at version 12.1.1.1.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
     EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
   Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
   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
   Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
   Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
   Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ 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_TABLES  Test that the schema does not contain any unexpected tables
   Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
   Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
   Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
   Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
   Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
   Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
   Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ 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 MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   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_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 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.3.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: FAILURE.

12.1.3.0バージョンのOracle Fusion Middleware IAU Schemasを実行しており、それらのスキーマが11g (11.1.1.7以上)または12c (12.1.2.0)からアップグレードされた場合、準備状況チェックが次のエラーで失敗する場合があります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes 
     INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
   Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes +++ FAIL

注意:

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

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

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

Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。

次の表は、ほとんどのスキーマのアップグレードで示されるUpgrade Assistantの基本的な画面について説明しています。コンポーネントによっては、追加のカスタム画面が含まれることがあります。これに該当するカスタム画面は、製品固有のアップグレード・ドキュメントに記載されています。

注意:

スキーマのアップグレード時に表示されるUpgrade Assistantの各画面は、選択したオプションとアップグレード前の環境の内容によって大きく異なります。アップグレードを完了するために、製品固有のアップグレード・ガイドを必ず使用してください。

表2-4 アップグレード・アシスタント画面: 製品スキーマのアップグレード

画面のタイトル	説明
ようこそ	Upgrade Assistantの概要と、アップグレード前の重要なタスクについての情報を示します。
スキーマ	実行するスキーマ・アップグレード操作の選択を示します。個別に選択されたスキーマドメインで使用されるすべてのスキーマ
使用可能なコンポーネント	「個別に選択されたスキーマ」を選択すると、アップグレード可能なスキーマを持つOracle Fusion Middlewareのインストール済コンポーネントのリストが示されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
すべてのスキーマ・コンポーネントのリスト	「ドメインで使用されるすべてのスキーマ」を選択すると、この読取り専用の画面に、特定のドメイン・ディレクトリ内のアップグレードに含まれるコンポーネントとスキーマがすべて表示されます。
前提条件	アップグレードを続行する前に、すべての前提条件を満たしていることの確認が求められます。続行する前にボックスを確認します。注意: Upgrade Assistantは、前提条件が満たされていることを確認しません。たとえば、Upgrade Assistantでは、サーバーとプロセスが必要に応じて停止されているかどうかを確認できません。
スキーマ資格証明画面画面名は、選択したスキーマのタイプによって変わります。	選択したスキーマとスキーマをホストするデータベースに接続するために必要な情報を入力できます。データベース・タイプメニューで使用できるデータベースのタイプは、アップグレードしようとするスキーマによって異なります。アップグレード用に選択されたデータベース・タイプは、RCUがスキーマを作成したときに選択されたデータベース・タイプと同一である必要があります。データベース・タイプとしてOracle Edition-Based Redefinition (EBR)を選択した場合は、アップグレードしているスキーマも、EBRデータベース・タイプを使用してRCUによって作成されている必要があります。たとえば、Upgrade Assistantによって、スキーマが、あるデータベース・タイプから別のタイプに変換されることはありません。データベース接続文字列データベースの場所。たとえば、Oracleデータベースを選択する場合には次の形式のURLを使用できます。 `host:port/db_service_name` Microsoft SQL ServerまたはIBM DB2データベースを使用している場合は、ドロップダウン・メニューからデータベース・タイプを選択し、フィールドの下のテキストを確認してください。ここには、データベース・タイプごとに必要な構文が表示されます。注意: Upgrade Assistantは、その他の有効な形式の接続文字列を受け入れます。たとえば、Oracle Database TNSスタイルの接続文字列も使用できます。 DBAユーザー名データベースへの接続に使用するデータベース・ユーザー名。注意: このDBAユーザーには、Upgrade Assistantを実行するための十分な権限を付与する必要がありますが、SYSまたはSYSDBA権限を付与する必要はありません。「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。特定のデータベース・プラットフォーム上では、ユーザー名で大文字と小文字が区別され、DBAユーザー名に小文字が含まれる場合があります。Upgrade Assistantは、入力された名前に接続し、大文字に変換しません。 DBAパスワード指定したDBAデータベース・ユーザーに対応するパスワード。「接続」をクリックしてデータベースに接続してからアップグレードするスキーマを選択します。アップグレードするスキーマが以前のFusion MiddlewareのリリースでRCUによって作成された場合は、使用可能なスキーマ名がリストされたドロップダウン・メニューが表示されます。注意: コンポーネントIDまたはスキーマ名は、12c (12.1.2.0)からUCSUMSスキーマにあわせて変更されました。そのため、Upgrade Assistantは使用可能なスキーマを自動的に認識してドロップダウン・リストに表示しません。この場合、テキスト・フィールドに手動で名前を入力する必要があります。この名前は、アップグレードの開始ポイントに応じて、`prefix_ORASDPM`または`prefix_UMS`のどちらかになります。スキーマ所有者スキーマ・ユーザー名。たとえば、DEV11g_MDSなどです。注意: すべてのデータベース・プラットフォーム上で、すべてのOracle Fusion Middlewareスキーマ名は大文字のみで構成されている点に注意してください。また、すべてのスキーマ名は、`schema_version_registry`表に大文字で格納されます。「スキーマ・ユーザー名」フィールドに小文字の文字が入力された場合、Upgrade Assistantは、その名前を大文字に変換しますスキーマ所有者パスワード特定のスキーマ・ユーザー名に関連付けられているパスワード。エディション名エディションベースの再定義に対応したOracle Databaseをデータベース・タイプとして選択する場合、既存のエディション名を指定する必要があります。注意: EBR対応のスキーマをFusion Middleware 11gリリースまたは以前の12cリリースからアップグレードする前に、まず、データベース・サーバーに接続し、データベース・サーバーで12c (12.2.1.3.0)用にエディションを作成する必要があります。12c (12.2.1.2)用の新しいエディションは、11.1.1.7.0、11.1.1.9.0、12.1.2.0、12.1.3.0、12.2.1.0または12.2.1.1エディションの子にする必要があります。エディション・ベースの再定義のためにサーバー上にエディションを作成する方法の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディション・ベースの再定義のためにサーバー上にエディションを作成する方法に関する項を参照してください。
スキーマの作成	アップグレード・アシスタントによって一部のコンポーネント・スキーマが欠落している可能性があり、アップグレード前に作成する必要があることが検出される場合、この画面が表示されます。アップグレード・アシスタントは、デフォルトの表領域と一時表領域の設定を使用してこれらのスキーマを作成できます。これらの設定をカスタマイズするには、リポジトリ作成ユーティリティを実行してスキーマを作成します。指定したドメインの欠落スキーマの作成デフォルトでは、このオプションは有効になっています。アップグレード・アシスタントは、指定されたデータベース接続詳細とスキーマ所有者名を使用して、ドメインの欠落スキーマの作成を試行します。すべてのスキーマに同じパスワードが使用されている場合は、「すべてのスキーマに同じパスワードを使用」を選択します。表のパスワードを入力して確認します。パスワードを指定する必要があるのは1回のみです。アップグレード・アシスタントでこれらのスキーマを作成しない場合は、このオプションの選択を解除し、「次」をクリックします。リポジトリ作成ユーティリティを使用してスキーマを作成する必要があります。
スキーマ・デフォルトの作成	アップグレード・アシスタントを使用して欠落スキーマを作成する場合は、デフォルトのスキーマ設定が使用されます。表領域データファイルのサイズを変更するか、デフォルトのスキーマ設定にその他の変更を加える必要がある場合は、リポジトリ作成ユーティリティを使用してスキーマを作成します。アップグレード・アシスタントから表領域設定を変更することはできません。各コンポーネント・スキーマと補助スキーマのデフォルトのデータファイル・サイズがリストされます。領域を追加する必要がある場合は、リポジトリ作成ユーティリティを使用します。
スキーマの作成の進行状況	スキーマ作成プロセスのステータスを表示します。必要なアクションはありません。
調査	各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを表示します。 Upgrade Assistantは、アップグレード・プロセスを開始する前に各コンポーネントを調査し、最低基準を満たしていることを検証します。情報がスキーマ・バージョン・レジストリ表に示されている場合、この画面にスキーマのソース・バージョンが表示されます。スキーマがRCUを使用して作成されたものではない場合、またはソース・バージョンが見つからない場合、ソース・バージョンは`「使用不可」`と表示されます。ステータスの定義: `in progress`: Upgrade Assistantがコンポーネントのアップグレード項目を調査しています。 `pending`: コンポーネントは、Upgrade Assistantが前のコンポーネントの処理を完了した後に調査されます。 `failed`: アップグレード項目が欠落しているか、アップグレード基準を満たしていません。Upgrade Assistantは、問題が解決されるまではコンポーネントをアップグレードできません。「ログの表示」をクリックし、エラーをトラブルシューティングしてから、Upgrade Assistantを再起動します。 `succeeded`: アップグレード項目が検出され、アップグレードに対して有効です。 `canceled`: 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。 `upgrade not necessary`: コンポーネントはすでにアップグレード済バージョンであるか、コンポーネントは以前のUpgrade Assistantの実行でアップグレードされています。 `skipped`: 依存コンポーネントに障害があるため、このコンポーネントの調査はスキップされます。注意: 調査フェーズ中に検出された問題は解決でき、Upgrade Assistantは再起動できます。ただし、アップグレード・フェーズが開始されていた場合は、Upgrade Assistantを再実行する前に、バックアップからアップグレード前の環境をリストアする必要があります。
アップグレード・サマリー	アップグレード・プロセスの開始前に選択したオプションのサマリーを表示します。ツリーを展開または縮小して、ウィザードの画面で提供されるデータの詳細(スキーマの詳細、Oracle WebLogicドメイン・ディレクトリ情報など)を表示または非表示にします。サマリー画面には、アップグレードするスキーマのソース・バージョンとアップグレード後の結果のターゲット・バージョンも表示されます。アップグレードに進む前に、両方のバージョンが正しいことを確認してください。「アップグレード」をクリックして、アップグレード・プロセスを開始します。スキーマをアップグレードする場合は、そのスキーマをホストしているデータベースのバックアップがあることを確認してください。「レスポンス・ファイルの保存」をクリックして、サイレント・アップグレード用にUpgrade Assistantへの入力として後で使用できるファイルを作成します。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。
アップグレードの進行状況	アップグレード処理のステータスを表示します。警告: アップグレード・プロセスは、開始後に取り消さないでください。そうした場合、コンポーネントは不整合な状態になり、バックアップからのリストアが必要になります。
アップグレード成功	アップグレードに成功した場合に表示されます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。ただし、アップグレード後に実行する追加のタスクが存在することがあります。アップグレード・ドキュメントを参照してください。
アップグレード失敗	アップグレードが特定のコンポーネント・スキーマで失敗する場合に表示されます。Upgrade Assistantを再起動する必要があります。 Upgrade Assistantのログは`ORACLE_HOME/oracle_common/upgrade/logs`にあります注意: アップグレードで障害が発生した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。この操作中にファイルが変更されているため、単純に問題を修正してUpgrade Assistantを再起動することはできません。

親トピック: Upgrade Assistantを使用したアップグレードの実行

コンポーネント構成のアップグレードの理解

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

管理対象WebLogicドメインのコンポーネントを含むOracleホームからUpgrade Assistantを実行する場合、「ドメインによって使用されるすべての構成」アップグレード・オプションを使用できます。

注意:

コンポーネント構成のアップグレード時に表示されるUpgrade Assistantの各画面は、選択したオプションとアップグレード前の環境の内容によって大きく異なります。アップグレードを完了するために、製品固有のアップグレード・ガイドを必ず使用してください。

表2-5 Upgrade Assistant画面: Oracle WebLogicコンポーネント構成のアップグレード

画面	説明
ようこそ	Upgrade Assistantの概要と、アップグレード前の重要なタスクについての情報を示します。
ドメインによって使用されるすべての構成	選択されたアップグレード・タイプが「ドメインによって使用されるすべての構成」である場合、Upgrade Assistantは管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードします。構成のアップグレードは、オフラインで実行されます。アップグレードするドメインのドメイン・ディレクトリを入力する必要があります。
WebLogic Serverのコンポーネント・リスト	選択されたアップグレード・タイプが「ドメインによって使用されるすべての構成」である場合、この画面では、WebLogicドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。ドメインの名前は、ドメイン内にあるコンポーネントのリストとともに提供されます。
前提条件	アップグレードを続行する前に、すべての前提条件を満たしていることの確認が求められます。続行する前にボックスを確認します。注意: Upgrade Assistantは、前提条件が満たされていることを確認しません。たとえば、Upgrade Assistantでは、サーバーとプロセスが必要に応じて停止されているかどうかを確認できません。
調査	各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを表示します。 Upgrade Assistantは、アップグレード・プロセスを開始する前に各コンポーネントを調査し、最低基準を満たしていることを検証します。情報がスキーマ・バージョン・レジストリ表に示されている場合、この画面にスキーマのソース・バージョンが表示されます。スキーマがRCUを使用して作成されたものではない場合、またはソース・バージョンが見つからない場合、ソース・バージョンは`「使用不可」`と表示されます。ステータスの定義: `in progress`: Upgrade Assistantがコンポーネントのアップグレード項目を調査しています。 `pending`: コンポーネントは、Upgrade Assistantが前のコンポーネントの処理を完了した後に調査されます。 `failed`: アップグレード項目が欠落しているか、アップグレード基準を満たしていません。Upgrade Assistantは、問題が解決されるまではコンポーネントをアップグレードできません。「ログの表示」をクリックし、エラーをトラブルシューティングしてから、Upgrade Assistantを再起動します。 `succeeded`: アップグレード項目が検出され、アップグレードに対して有効です。 `canceled`: 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。 `upgrade not necessary`: コンポーネントはすでにアップグレード済バージョンであるか、コンポーネントは以前のUpgrade Assistantの実行でアップグレードされています。 `skipped`: 依存コンポーネントに障害があるため、このコンポーネントの調査はスキップされます。注意: 調査フェーズ中に検出された問題は解決でき、Upgrade Assistantは再起動できます。ただし、アップグレード・フェーズが開始されていた場合は、Upgrade Assistantを再実行する前に、バックアップからアップグレード前の環境をリストアする必要があります。
アップグレード・サマリー	アップグレード・プロセスの開始前に選択したオプションのサマリーを表示します。
アップグレードの進行状況	アップグレード処理のステータスを表示します。警告: アップグレード・プロセスは、開始後に取り消さないでください。そうした場合、コンポーネントは不整合な状態になり、バックアップからのリストアが必要になります。
アップグレード成功	アップグレードに成功した場合に表示されます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。ただし、アップグレード後に実行する追加のタスクが存在することがあります。アップグレード・ドキュメントを参照してください。
アップグレード失敗	アップグレードが特定のコンポーネントで失敗する場合に表示されます。Upgrade Assistantを再起動する必要があります。 Upgrade Assistantのログは`ORACLE_HOME/oracle_common/upgrade/logs`にあります注意: アップグレードで障害が発生した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。この操作中にファイルが変更されているため、単純に問題を修正してUpgrade Assistantを再起動することはできません。

親トピック: Upgrade Assistantを使用したアップグレードの実行

アップグレード後の手順の実行

アップグレードの後に追加のアップグレード後構成タスクをすべて完了して、新しくアップグレードしたドメインが期待どおりに機能していることを検証します。ドメイン構成に適用するタスクのみを実行します。

正常にアップグレードされたら、サーバーが起動できること、スキーマのバージョンがレジストリ表で更新されていること、およびコンポーネントの構成が正しいことを検証することが重要です。ドメインの内容に基づいて追加のアップグレード後タスクを実行することが必要な場合もあります。タスクのリスト全体を確認して、どれが適用できるかを判別します。

注意:

これらのタスクのうち1つ以上が、新しくアップグレードした環境で完了できない場合、「アップグレードのトラブルシューティング」を参照してください。アップグレード後の手順の詳細は、必ずコンポーネント固有のアップグレード・ドキュメントを参照してください。

アップグレード後の基本的な管理タスクの実行
アップグレード後タスクのリストを確認して、アップグレード後環境とドメイン構成に適用するものを実行します。
正常なスキーマ・アップグレードの検証
アップグレード後の無効なデータベース・オブジェクトのチェック
Oracleデータベースを使用している場合は、Upgrade Assistantの実行後に、データベース・オブジェクトを再コンパイルします。

親トピック: Upgrade Assistantを使用したアップグレードの実行

アップグレード後の基本的な管理タスクの実行

アップグレード後タスクのリストを確認して、アップグレード後環境とドメイン構成に適用するものを実行します。

これらの管理タスクはオプションですが、タスクを実行してアップグレードを検証することをお薦めします。

表2-6 アップグレード後の基本的な管理タスク

タスク	説明	詳細情報
製品およびサーバーの起動と停止	管理サーバー、管理対象サーバー、コンポーネントを含め、Oracle Fusion Middlewareを起動および停止します。これらのタスクを実行することで、アップグレードが成功しているか検証されます。	Oracle Fusion Middlewareの起動と停止
アップグレードされたアプリケーションの起動および停止	新しい環境でアップグレードされたアプリケーションを起動して、正常に動作することを確認します。	アプリケーションの起動と停止
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クラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』の「Coherenceクラスタの構成と管理」を参照してください。 Coherenceのチューニングの詳細は、『Oracle Coherenceの管理』を参照してください。 CoherenceにおけるHTTPセッション・データの格納の詳細は、『Oracle CoherenceWebでのHTTPセッション・マネージメントの管理』のWebLogicサーバーでのCoherenceWebの使用を参照してください。 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列の番号が更新されていることを確認します。変更が必要なかった場合、一部のスキーマがアップグレード前のバージョンのままである可能性があります。詳細は、表1-1を参照してください。

問合せ結果のSTATUSフィールドは、スキーマへのパッチ適用処理中はUPGRADINGまたはUPGRADEDに、処理が終了するとVALIDになります。

ステータスがINVALIDと表示された場合は、スキーマのアップグレードが失敗しています。ログ・ファイルを調べて、失敗した理由を判定できます。

親トピック: アップグレード後の手順の実行

アップグレード後の無効なデータベース・オブジェクトのチェック

Oracleデータベースを使用している場合は、Upgrade Assistantの実行後に、データベース・オブジェクトを再コンパイルします。

アップグレード時に破損したオブジェクトがあるかどうかを判断するには、SYSとしてデータベースに接続して、SQL*Plusから次のコマンドを実行することでUpgrade Assistantがアップグレードしたデータベース・オブジェクトを再コンパイルします。

SQL> @oracle_home/software/rdbms/admin/utlrp.sql

次の問合せを入力して、無効なデータベース・オブジェクトが残っていないことを確認します。

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

この時点では、アップグレードされたスキーマに、無効になっているデータベース・オブジェクトはないはずです。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が続く場合は、サービス・リクエストを提出します。

親トピック: アップグレード後の手順の実行