| Oracle® Fusion Middleware Oracle WebCenterのアップグレード 12c (12.2.1.2) E82840-02 |
|
 前へ |
 次へ |
既存のOracle WebCenter Sitesインストールを12c (12.2.1.2)にアップグレードできます。
11gから12cへのアップグレードは、アウトオブプレース移行です。これには、Upgrade Assistantを使用したデータ表とプラットフォーム構成の移行が含まれます。
以前の12cリリース(12.2.1.0、12.2.1.0パッチ1、12.2.1.0パッチ2、および12.2.1.1)から12.2.1.2へのアップグレードは、インプレース・アップグレードです。
注意:
アップグレードする際に、要件にあわせて検討できる2つの方法があります。
配信環境をアップグレードし、アップグレード後にそのクローンを作成して、開発環境と管理環境を作成します。
この方法を検討する場合は、同期化が必要になります。アップグレードの前に、開発環境と管理環境から配信環境にコンテンツを公開する必要があります。その後、アップグレードした配信環境のクローンを作成して、開発環境と管理環境を作成します。
または、各環境を個別にアップグレードします。
この方法を検討する場合、同期化は必要ありません。
この章の内容は次のとおりです。
WebCenter Sitesを12.2.1.2にアップグレードするための11gの有効な開始ポイントは、WebCenter Sites 11.1.1.8以上です。これは、アウトオブプレース移行です。
注意:
11.1.1.6.xからアップグレードする場合は、『Fusion Middleware WebCenter Sitesアップグレード・ガイド』のWebCenter Sitesのアップグレード・プロセスに関する項に記載されているWebCenter Sites 11gのアップグレード手順を使用して、リリース11.1.1.8にアップグレードする必要があります。WebCenter Sitesを11gから12cにアップグレードするには、次のタスクを実行します。
Oracle WebCenter Sitesのアップグレード・プロセスの概要に関するフローチャートとロードマップを確認します。
図6-1 WebCenter Sitesの11gから12cリリースへのアップグレード・プロセスのフローチャート
表6-1に、WebCenter Sitesを11gから12cにアップグレードするために実行する必要がある、タスクのロードマップを示します。
表6-1 WebCenter Sitesの11gから12cリリースへのアップグレードに関するタスク
| タスク | 説明 |
|---|---|
必須 まだ実行していない場合は、このガイドの紹介トピックを確認し、必要なアップグレード前タスクを実行します。 |
アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。 アップグレード前タスクの完全なリストは、「Oracle WebCenterコンポーネントのアップグレード前のタスク」を参照してください。 |
必須 12c (12.2.1.2) Oracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードおよびインストールします。 |
インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。 このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。 12.2.1.2Infrastructureをインストールすると作成されるOracleホームにOracle WebCenter Sitesのディストリビューションをインストールする必要があります。製品ディストリビューションをインストールするには、「製品ディストリビューションのインストール」の手順に従います。 |
必須 必要なスキーマを作成します。 |
WebCenter Sites 11gからアップグレードする場合は、アップグレードを開始する前に、12cの必要なスキーマを作成する必要があります。 WebCenter Sitesに必要なスキーマは、Oracle Platform Security Services (OPSS)、Audit Services (IAU)およびWebCenter Sitesです。 「RCUを使用した必要な12cスキーマの作成」の説明に従い、リポジトリ作成ユーティリティ(RCU)を使用してスキーマを作成します。 |
必須 WebCenter Sitesドメインを構成します。 |
11gから12cへのアップグレードは、アウトオブプレース・アップグレードです。そのため、「WebCenter Sitesドメインの構成」の手順に従って、WebCenter Sites 12c (12.2.1.2)ドメインを構成します。 |
必須 WebCenter Sitesインスタンスを構成します。 |
「WebCenter Sitesインスタンスの構成」で説明している手順に従って、ブラウザベースのWebCenter Sitesコンフィギュレータを実行し、WebCenter Sitesインスタンスを構成します。 |
必須 構成後のタスクを実行します。 |
構成後のタスクには、LDAPベースまたはOAMベースの認証を使用した12c (12.2.1.2)ドメインの構成、ディレクトリ構造の検証、サインインとSitesのUIへのアクセス、管理対象サーバーの再起動などが含まれます。 これらのタスクは、「構成後のタスク」にリストされています。 |
必須 必要なタスクを実行してから、アップグレード・アシスタントを実行します。 |
アップグレード前のタスクは、アップグレード・アシスタントを使用してアップグレード・プロセスを開始する前に完了している必要がある、一連のタスクです。 これらのタスクは、「アップグレード・アシスタントを実行する前に」にリストされています。 |
必須 スキーマをアップグレードします。 |
「製品スキーマのアップグレード」の手順に従い、アップグレード・アシスタントを使用して、アップグレード可能なスキーマ・コンポーネントをアップグレードします。 |
必須 Sitesの構成をアップグレードします。 |
「アップグレード・アシスタントを使用したSitesの構成のアップグレード」の手順に従い、アップグレード・アシスタントを使用して、11g (11.1.1.8)のドメインに含まれるSitesの構成をアップグレードします。 |
必須 アップグレード後の検証タスクを実行します。 |
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。 検証スクリプトを使用するには、「アップグレード後の検証タスク」を参照してください。 |
必須 その他のアップグレード後のタスクを実行します。 |
その他のアップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、および「アップグレード後のタスク」にリストされているその他の管理タスクが含まれます。 |
アップグレードを開始する前に、ターゲット・システムに12c (12.2.1.2)のOracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードし、Oracle Universal Installerを使用してインストールします。
注意:
アップグレードにInfrastructureが必要な場合は、最初にOracle Fusion Middleware Infrastructureのディストリビューションをインストールしてから、その他のFusion Middleware製品をインストールする必要があります。Oracle HTTP Serverなど、ドメインを構成するすべてのOracle製品をダウンロードおよびインストールしたことを確認します。
11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。
注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。11gからアップグレードする場合は、アップグレード前のチェックリストを参照してドメインの既存のスキーマを識別します。12cにアップグレードする前に、次のスキーマが存在している必要があります。
サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。
Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。
監査サービス(IAU)
WebCenter Sites
WebCenter Sites 11gから12cにアップグレードする場合は、構成ウィザードを使用してWebCenter Sitesドメインを構成する必要があります。
注意:
IBM DB2, WebCenter Sitesでは、Fusion Middleware構成ウィザードによって作成されるデフォルトのデータ・ソースをサポートしません。DB2がサポートするドライバを使用して新しいデータ・ソースを作成する手順:WebCenter Sitesドメインのクラス・パスに、IBM DB2ドライバJARファイルを追加します。
WebLogic Server管理サーバーを停止します。
ドメインのクラス・パスに追加できる場所に、DB2のdb2jcc.jarおよびdb2jcc_license_cu.jarファイルをコピーします。
DOMAIN_HOME//bin/setDomainEnv.shを編集し、# ADD EXTENSIONS TO CLASSPATHSの後に次の行を追加します。
PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}"
管理サーバーを起動します。
前述のDB2ドライバを使用して新しいデータ・ソースを作成します。
Oracle WebCenter Sitesドメインを構成した後に、ブラウザベースのWebCenter Sitesコンフィギュレータを実行して、WebCenter Sitesインスタンスを構成できます。 WebCenter Sitesランタイムは、WebCenter Sites、CAS Webアプリケーション(WARファイル)およびクラスタ・メンバー間の共有コンポーネント(configディレクトリ、dataディレクトリおよびデータベース・インスタンス)で構成されています。
次のトピックでは、WebCenter Sitesの構成方法を説明します。
WebCenter Sitesコンフィギュレータを使用する前に、いくつかの前提条件タスクを実行する必要があります。これらのタスクには、OPSSのアクセス権限の付与、キャッシュ・ファイルの変更、および環境のプロパティ値の設定が含まれます。
WebCenter Sitesコンフィギュレータは、WebCenter Sitesが機能するために必要な表およびデータをデータベースに移入します。コンフィギュレータは、必要なユーザー・アカウントを設定し、データベース・オブジェクトの必要な権限も設定します。
注意:
低速ネットワーク上でWebCenter Sitesを構成する場合は、WebCenter Sitesコンフィギュレータを起動する前に、StuckThreadMaxTimeプロパティの設定をスレッドごとに1000秒に増加します。デフォルト値は600秒です。
ネットワーク関連の問題が発生する可能性のある特定の環境では、WebCenter Sites構成の設定プロセスで、サンプル・サイトのインポート・プロセスの1スレッド当たりの所要時間が600秒を超える可能性があります。これによって、インポート・プロセスまたはインストールが失敗し、ログ・ファイルに複数の例外が記録される可能性があります。サンプル・サイトのインストールが正常に完了するために、設定を1000秒に増加することをお薦めします。
StuckThreadMaxTimeの値を変更するには、ドメインのWebLogic Server管理コンソールで、「サーバー」、「wcsites_server1」、「構成」、「チューニング」の順に移動します。
注意:
cas.logのデフォルトの場所は、DOMAIN_HOME/servers/wcsites_server1/logs/です。CLASSPATH環境変数に次のディレクトリを設定します。ORACLE_HOME\wcsites\webcentersites\sites-home\lib\* ORACLE_HOME\oracle_common\modules\clients\*
追加のクラスタ・ノードを構成する方法の詳細は、「クラスタの設定」を参照してください。
外部LDAP認証プロバイダの構成方法の詳細は、「LDAPディレクトリに対する認証への切替え」を参照してください。
Oracle Access Managerの統合を構成する方法の詳細は、「Oracle Access Managerに対する認証への切替え」を参照してください。
WebCenter Sites構成のインポート/エクスポート・ユーティリティの使用方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』のプロパティ管理ツールの使用に関する項を参照してください。
WebCenter Sites 12cを構成した後に、このトピックにリストされているタスクを実行します。
LDAPベースの認証に切り替えるには、「LDAPディレクトリに対する認証への切替え」を参照してください。
LDAPベースの認証に切り替えるには、「Oracle Access Managerに対する認証への切替え」を参照してください。
このトピックでは、WebCenter Sitesを外部LDAP認証プロバイダ・ディレクトリに対する認証に切り替える方法について説明します。Oracle Access Managementとの統合を実行できない場合、これは本番環境のための推奨のソリューションです。
Oracle Access Managerに対する認証を行うようにWebCenter Sitesを構成できます。これは本番環境のための推奨のソリューションです。
サイト・キャプチャとOAMを統合するには、次の手順を実行します。
アップグレード・アシスタントを実行して11.1.1.8からアップグレードする前に、このトピックにリストされているタスクを実行します。
FMWという非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。 アップグレード・アシスタントを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。
注意:
以前のリリースで非SYSDBAユーザーFMWを作成した場合は、このユーザーを削除して再作成してからアップグレードを開始する必要があります。古いFMWユーザーでアップグレード・アシスタントを実行すると、新しい権限が追加されている場合があるため、アップグレードが失敗する可能性があります。既存のFMWユーザーを変更するのではなく、このユーザーを削除して再作成することをお薦めします。v$xatrans$表は存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。さらに、v$xatrans$表に対するgrant select権限は、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; grant select on dba_subscr_registrations to FMW with grant option; grant manage scheduler to FMW;
注意:
Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。
このパッチを適用しない場合、一部のスキーマ用に追加の権限を付与する必要があります。
スキーマをアップグレードする前に、Sites 11.1.1.8のスキーマをソースDB2データベースからターゲット・データベース(12.2.1.2のSitesスキーマが設定されている)にインポートする必要があります。
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードが成功したことを確認します。 アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。アップグレード・アシスタントを非SYSDBAユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンドラインで指定できるその他のパラメータは、次を参照してください。
アップグレード・アシスタントをコマンドラインから起動する際に、追加パラメータを指定できます。
表6-9 アップグレード・アシスタントのコマンドライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれか1つの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIX:
Windows:
|
|
オプション |
コマンドライン・オプションをすべて表示します。 |
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。
すべてのアップグレード手順の完了後に、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードが成功したことを確認します。
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 ;
問合せ結果で次を行います。
VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマはこのリリースにアップグレードする必要がなく、アップグレード前のバージョン番号が保持されます。
STATUSフィールドは、スキーマへのパッチ適用処理中はUPGRADINGまたはUPGRADEDになり、処理が終了するとVALIDになります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、これは失敗を意味するわけではありません。
ターゲット・オブジェクトがシノニムの作成後に変更されたため、これらのオブジェクトは無効になります。シノニム・オブジェクトは、アクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。
ドメインの再構成後に、アップグレード・アシスタントを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。アップグレード・アシスタントを非SYSDBAユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンドラインで指定できるその他のパラメータは、次を参照してください。
アップグレード・アシスタントをコマンドラインから起動する際に、追加パラメータを指定できます。
表6-10 アップグレード・アシスタントのコマンドライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれか1つの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIX:
Windows:
|
|
オプション |
コマンドライン・オプションをすべて表示します。 |
アップグレード・アシスタントを使用して、Sitesの構成をアップグレードする必要があります。
構成のアップグレードは、11gの開始ポイントと同様にApache TomcatおよびIBM WebSphereサーバーでサポートされます。
Oracle
Microsoft SQL
DB2
Oracle WebLogic Server
Apache Tomcat
IBM WebSphere
注意:
構成のアップグレードの準備状況チェックは、11gの開始ポイントでは使用できません。ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2であることを確認します。
管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console
Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em
注意:
アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。
アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。
アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。
正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。
これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。
注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバー、およびノード・マネージャの起動および停止に関する項を参照してください。Fusion Middleware環境を起動するには、次の手順に従います。
ステップ1: 管理サーバーの起動
管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。
管理サーバーを起動するには、startWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
ステップ2: ノード・マネージャの起動
ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
ステップ3: Oracle Identity Managementコンポーネントの起動
環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
ステップ4: 管理対象サーバーの起動
WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。ステップ5: システム・コンポーネントの起動
Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
システム・コンポーネントは任意の順序で起動できます。
11gから最新の12cリリースにアップグレードしている場合および既存のインスタンスが配信インスタンスである場合は、ユーザーが公開したSitesのアプリケーションを手動で再度割り当てる必要があります。
WebCenter Sitesを12.2.1.2にアップグレードするための12cの有効な開始ポイントは、WebCenter Sitesリリース12.2.1.0、12.2.1.0パッチ1、12.2.1.0パッチ2および12.2.1.1です。これは、インプレース・アップグレードです。
注意:
既存のSites環境がデータベースへのNIOベースの共有ファイル・システムで構成されている場合は、アップグレード・プロセスを開始する前に、これをディスク・ストレージに戻します。次の各項の手順に従って、アップグレードを実行します。
WebCenter Sitesのアップグレード・プロセスの概要に関するフローチャートとロードマップを確認します。
図6-2 WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスのフローチャート
表6-11に、WebCenter Sitesを以前の12cリリースからアップグレードするために実行する必要がある、タスクのロードマップを示します。
表6-11 WebCenter Sitesの以前の12cリリースからのアップグレードに関するタスク
| タスク | 説明 |
|---|---|
必須 まだ実行していない場合は、このガイドの紹介トピックを確認し、必要なアップグレード前タスクを実行します。 |
アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。 アップグレード前タスクの完全なリストは、「Oracle WebCenterコンポーネントのアップグレード前のタスク」を参照してください。 重要: アップグレード・プロセスを開始する前に、WebLogicドメイン、Sites構成ディレクトリ、Sites共有ディレクトリ、およびSitesスキーマをバックアップする必要があります。 |
必須 12c (12.2.1.2) Oracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードおよびインストールします。 |
インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。 このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。 12.2.1.2Infrastructureをインストールすると作成されるOracleホームにOracle WebCenter Sitesのディストリビューションをインストールする必要があります。製品ディストリビューションをインストールするには、「製品ディストリビューションのインストール」の手順に従います。 |
WebCenter SitesをInsightsとともにインストールした場合は必要 拡張テンプレートを削除し、Insights、アプリケーション・サーバーinsights_server1、およびその依存関係へのコンポーネント参照をインストールします。 |
Oracle WebCenter Sites Insightsは、12.2.1.1から非推奨になっています。その結果、アップグレード時に再構成テンプレートを使用できません。既存のデプロイメントにSites Insightsが含まれている場合は、トピック「InsightsとともにSitesをインストールした場合...」の手順を実行する必要があります。 |
オプション アップグレード前の準備状況チェックを実行します。 |
「アップグレード前の準備状況チェックの実行」を参照してください。 |
必須 既存の環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。 |
警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。「サーバーとプロセスの停止」を参照 |
必須 既存の12cドメインを再構成します。 |
既存のドメインで再構成ウィザードを実行した場合、再構成テンプレートを選択および適用することで、ドメインのアップグレード準備が行われます。 「ドメインの再構成」で説明している手順に従って、ドメインを再構成します。 |
必須 必要なタスクを実行してから、アップグレード・アシスタントを実行します。 |
アップグレード前のタスクは、アップグレード・アシスタントを使用してアップグレード・プロセスを開始する前に完了している必要がある、一連のタスクです。 これらのタスクは、「アップグレード・アシスタントを実行する前に」にリストされています。 |
必須 アップグレード・アシスタントを使用して製品スキーマをアップグレードします。 |
「製品スキーマのアップグレード」の手順に従い、アップグレード・アシスタントを使用して、アップグレード可能なスキーマ・コンポーネントをアップグレードします。 |
必須 ドメイン構成をアップグレードします。 |
「ドメイン・コンポーネント構成のアップグレード」で説明している手順に従い、アップグレード・アシスタントを使用して、12.2.1.0のドメインに含まれるすべての構成をアップグレードします。 |
必須 アップグレード後の検証タスクを実行します。 |
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。 検証スクリプトを使用するには、「アップグレード後の検証タスク」を参照してください。 |
必須 その他のアップグレード後のタスクを実行します。 |
その他のアップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、および「アップグレード後のタスク」にリストされているその他の管理タスクが含まれます。 |
必須 サーバーおよびプロセスを再起動します。 |
「サーバーとプロセスの起動」を参照してください。 |
アップグレードを開始する前に、ターゲット・システムに12c (12.2.1.2)のOracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードし、Oracle Universal Installerを使用してインストールします。
注意:
アップグレードにInfrastructureが必要な場合は、最初にOracle Fusion Middleware Infrastructureのディストリビューションをインストールしてから、その他のFusion Middleware製品をインストールする必要があります。Oracle HTTP Serverなど、ドメインを構成するすべてのOracle製品をダウンロードおよびインストールしたことを確認します。
Oracle WebCenter Sites Insightsは、12.2.1.1から非推奨になっています。その結果、アップグレード時に再構成テンプレートを使用できません。既存のデプロイメントにSites Insightsが含まれている場合は、このトピックの手順を実行する必要があります。
注意:
12.2.1.0からアップグレードしており、Oracle WebCenter SitesをInsightsとともにインストールした場合にのみ、この手順を実行します。アップグレードの潜在的な問題を識別するには、準備状況チェックを実行してからアップグレード・プロセスを開始することをお薦めします。準備状況チェックでは、アップグレードの潜在的な問題をすべて発見できるわけではないことに注意してください。準備状況チェック・レポートが成功しても、アップグレードが失敗する場合があります。
-readinessモードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、またはレスポンス・ファイルを使用してサイレント・モードで実行できます。 -readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。アップグレード・アシスタントを-readinessモードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、またはレスポンス・ファイルを使用してサイレント・モードで実行できます。
アップグレード・アシスタントの準備状況チェックでは、サポートされている開始ポイントのFusion MiddlewareスキーマおよびWebLogicドメインの読取り専用のアップグレード前確認を行います。この確認は読取り専用操作です。
準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。
準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。
実際のアップグレードを実行する前に、準備状況チェックを何回でも実行できます。ただし、アップグレード後はレポートの結果がアップグレード前の準備状況チェックの結果と異なる場合があるため、準備状況チェックを実行しないでください。
注意:
パフォーマンスが影響を受けないようにするには、準備状況チェックをオフピーク時に実行することをお薦めします。
-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。
アップグレード・アシスタントをコマンドラインから起動する際に、追加パラメータを指定できます。
表6-12 アップグレード・アシスタントのコマンドライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれか1つの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIX:
Windows:
|
|
オプション |
コマンドライン・オプションをすべて表示します。 |
アップグレード・アシスタントの各画面を移動して、アップグレード前の準備状況チェックを実行します。
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。
準備状況レポート・ファイルの書式は次のとおりです。
readiness_timestamp.txt
timestampは、準備状況チェックが実行された日時を示します。
準備状況レポートには、次の情報が含まれています。
表6-13 準備状況レポートの要素
| レポートの情報 | 説明 | 必要なアクション |
|---|---|---|
| 全体的な準備状況ステータス: SUCCESSまたはFAILURE | レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。 | 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。 |
タイムスタンプ |
レポートが生成された日付と時刻。 |
アクションは必要ありません。 |
ログ・ファイルの場所
|
生成されたログ・ファイルのディレクトリの場所。 |
アクションは必要ありません。 |
準備状況レポートの場所
|
生成された準備状況レポートのディレクトリの場所。 |
アクションは必要ありません。 |
チェックされたコンポーネントの名前 |
チェックに含まれるコンポーネントの名前およびバージョンとステータス。 |
ドメインに、このリリースにアップグレードできないSOAコア拡張機能などのコンポーネントが含まれる場合は、アップグレードを試行しないでください。 |
チェックされたスキーマの名前 |
チェックに含まれるスキーマの名前および現在のバージョンとステータス。 |
スキーマのバージョン番号をレビューします。ドメインに、このリリースにアップグレードできないスキーマが含まれる場合は、アップグレードを試行しないでください。 |
個別のオブジェクト・テスト・ステータス: FAIL |
準備状況チェック・テストによって、特定のオブジェクトの問題が検出されました。 |
失敗した問題がすべて解決されるまではアップグレードしないでください。 |
個別のオブジェクト・テスト・ステータス: PASS |
準備状況チェック・テストによって、特定のオブジェクトの問題が検出されませんでした。 |
準備状況チェック・レポートに「成功」ステータスのみが表示されている場合は、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。 |
| <Object>の完了した準備状況チェックのステータス: FAILURE | 準備状況チェックで、スキーマ、索引またはデータ型などの特定のオブジェクトに対して解決する必要がある1つ以上のエラーが検出されました。 | 失敗した問題がすべて解決されるまではアップグレードしないでください。 |
| <Object>の完了した準備状況チェックのステータス: 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: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log Readiness Check Report File: 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で作成された場合、このエラーは発生しません。アップグレード・アシスタントを実行してスキーマと構成をアップグレードする前に、管理サーバーおよび管理対象サーバーを含むすべてのプロセスとサーバーを停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。
注意:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。Fusion Middleware環境を停止するには、次の手順を実行します。
ステップ1: システム・コンポーネントの停止
Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
システム・コンポーネントは任意の順序で停止できます。
ステップ2: 管理対象サーバーの停止
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
ステップ3: Oracle Identity Managementコンポーネントの停止
Oracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を停止します。(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
ステップ4: 管理サーバーの停止
管理サーバーを停止する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも停止します。
管理サーバーを停止するには、stopWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
ステップ5: ノード・マネージャの停止
ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。
またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、『Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。
WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。
WebLogic Serverコア・インフラストラクチャ
ドメイン・バージョン
注意:
ドメインの再構成を開始する前に、次の制限事項を確認します。
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
アップグレード・プロセス時の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
再構成ウィザードの実行時に動的クラスタ機能を使用できますが、非動的クラスタ・アップグレードのアップグレードおよび動的クラスタの追加のみがサポートされます。アップグレード・プロセス中に動的クラスタを追加することはできません。
ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。
変更した起動スクリプトを保存する場合は、起動スクリプトのバックアップを作成してから再構成ウィザードを起動してください。
注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前のチェックリストに示されているようにドメインのバックアップを作成したことを確認します。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには、次の手順を実行します。
再構成ウィザードの各画面を移動して、既存のドメインを再構成します。
注意:
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。欠落としてレポートされたテンプレートが表示されている場合、ドメインに該当するOracle製品をインストールしたかどうかを確認します。たとえば、既存のドメインにOracle HTTP Serverが含まれている場合は、12c (12.2.1.2)のOracle HTTP Server製品ディストリビューションをインストールしていることを確認します。注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。アップグレード・アシスタントを実行して12.2.1.xのドメインをアップグレードする前に、このトピックにリストされているタスクを実行します。
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードが成功したことを確認します。 アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。アップグレード・アシスタントを非SYSDBAユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンドラインで指定できるその他のパラメータは、次を参照してください。
アップグレード・アシスタントをコマンドラインから起動する際に、追加パラメータを指定できます。
表6-15 アップグレード・アシスタントのコマンドライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれか1つの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIX:
Windows:
|
|
オプション |
コマンドライン・オプションをすべて表示します。 |
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。
すべてのアップグレード手順の完了後に、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードが成功したことを確認します。
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 ;
問合せ結果で次を行います。
VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマはこのリリースにアップグレードする必要がなく、アップグレード前のバージョン番号が保持されます。
STATUSフィールドは、スキーマへのパッチ適用処理中はUPGRADINGまたはUPGRADEDになり、処理が終了するとVALIDになります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、これは失敗を意味するわけではありません。
ターゲット・オブジェクトがシノニムの作成後に変更されたため、これらのオブジェクトは無効になります。シノニム・オブジェクトは、アクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。
ドメインの再構成後に、アップグレード・アシスタントを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。
アップグレード・アシスタントを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。アップグレード・アシスタントを非SYSDBAユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンドラインで指定できるその他のパラメータは、次を参照してください。
アップグレード・アシスタントをコマンドラインから起動する際に、追加パラメータを指定できます。
表6-16 アップグレード・アシスタントのコマンドライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれか1つの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIX:
Windows:
|
|
オプション |
コマンドライン・オプションをすべて表示します。 |
アップグレード・アシスタントの各画面を移動して、WebLogicドメインのコンポーネント構成をアップグレードします。
再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後に、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードする必要があります。
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2であることを確認します。
管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console
Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em
注意:
アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。
アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。
アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。
正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。
これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。
注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバー、およびノード・マネージャの起動および停止に関する項を参照してください。Fusion Middleware環境を起動するには、次の手順に従います。
ステップ1: 管理サーバーの起動
管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。
管理サーバーを起動するには、startWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
ステップ2: ノード・マネージャの起動
ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
ステップ3: Oracle Identity Managementコンポーネントの起動
環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
ステップ4: 管理対象サーバーの起動
WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。ステップ5: システム・コンポーネントの起動
Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
システム・コンポーネントは任意の順序で起動できます。
アップグレード前の環境でWebアプリケーションにカスタムJavaライブラリまたは静的Webリソースが追加されており、アップグレード後の環境でこれらを引き続き使用する場合にのみ、このオプション手順を実行します。
WebアプリケーションにカスタムJavaライブラリ(jarファイル)またはカスタムWebリソース(css、js、イメージなど)が含まれている場合は、アップグレード後に、それらをアップグレード後の環境に手動で移行する必要があります。これらのリソースを移行しないと、アップグレード後の環境でその機能にアクセスできなくなります。
WebCenter SitesのWebアプリケーションは、WARファイルとして出荷されます。Webアプリケーションは、最初に構成ウィザードの処理中にデプロイされ、アプリケーション・ライフサイクルでの処理中に何度でも再デプロイすることができます。変更はアップグレード・プロセスでの処理中に上書きされるため、実装固有のカスタマイズをSites WARファイルに含めないことをお薦めします。
WebLogic Server共有ライブラリ・フレームワークを拡張する場合、Sitesではextend.sites.webapp-lib.warが共有ライブラリとして提供されます。このファイルはORACLE_HOME/wcsites/webcentersites/sites-home/ディレクトリにあります。静的Webリソースなどの実装固有のカスタマイズやJavaライブラリを、このWARファイルに含めることができます。この共有ライブラリは、アプリケーションのライフサイクルの進行中にデプロイされ、Sitesと同じコンテキスト・ルーツ(/sites/)を共有します。この共有ライブラリのコンテンツは、パッチ適用プロセスでの処理中に上書きされることはありません。
また、Sites UIがカスタマイズされている場合は、コードの変更もアップグレード後の環境に移行する必要があります。
