3 Oracle WebCenterドメインのアップグレード
以降の項に記述される手順では、基本的なWebCenterドメインを12c (12.2.1.3.0)にアップグレードするプロセスの概要を説明しています。ほとんどの場合、アップグレードではこれらの一般的な手順に従いますが、実際に実行するアップグレード手順は、アップグレードするコンポーネントによって異なります。コンポーネントに関連して、アップグレードの前後に追加の手順を実行することが必要になる場合があります。そのため、ドメインのアップグレードを行うには、アップグレード前の環境に存在するコンポーネントごとにアップグレード手順を確認する必要があります。
たとえば、Oracle WebCenterドメインにOracle WebCenter ContentとWebCenter Portalが含まれている場合は、「Oracle WebCenter Contentのアップグレード」と「Oracle WebCenter Portal 11gインストールのアップグレード」で説明している手順に従う必要があります。
- Oracle WebCenterの12c (12.2.1.3.0)へのアップグレード・プロセスについて
WebCenter製品の12cへのアップグレードのプロセス・フローを確認して、実行する手順および実行する時期について理解します。 - 製品ディストリビューションのインストール
アップグレードを開始する前に、ターゲット・システムにOracle Fusion Middleware InfrastructureおよびWebCenter Contentのディストリビューションをダウンロードし、Oracle Universal Installerを使用してインストールします。 - RCUを使用した必要な12cスキーマの作成
アップグレード時、必要なスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズ・スキーマを作成するか、またはオプションで、Upgrade Assistantを使用してデフォルトのスキーマ設定を使用するスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する方法は、アップグレード手順で説明しています。 - アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックでは、アップグレードの潜在的な問題をすべて発見できるわけではないことに注意してください。準備状況チェック・レポートが成功しても、アップグレードが失敗する場合があります。 - サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。 - 製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。 - ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。 - ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。 - アップグレード後の構成タスクの実行
デプロイメントに含まれるコンポーネントによっては、アップグレード後に追加の構成タスクを実行することが必要になります。
Oracle WebCenterの12c (12.2.1.3.0)へのアップグレード・プロセスについて
WebCenter製品の12cへのアップグレードのプロセス・フローを確認して、実行する手順および実行する時期について理解します。
このプロセス・フローは、WebCenterドメインを12c (12.2.1.3.0)にアップグレードする大まかな手順を示しています。実際に実行するプロセスは、アップグレード前の環境およびアップグレードするコンポーネントによって異なります。
タスク | 説明 |
---|---|
必須 Oracle Fusion Middlewareの、標準のアップグレード前のタスクと、追加のコンポーネント固有の必須タスクをすべて実行します。 |
Oracle WebCenterコンポーネントのアップグレード前のタスク |
必須 ドメインに含まれるすべての製品の製品ディストリビューションをインストールします。 |
12cでは、WebLogic ServerとJRFはインフラストラクチャのディストリビューションに含まれているため、これを最初にインストールする必要があります。 バイナリは、既存のデプロイメントと同じホストの新規Oracleホームにインストールする必要があります。 |
11gから12cへのアップグレードのみ: 12cのリポジトリ作成ユーティリティ(RCU)を実行して、12cの必要なスキーマ( 12cにはサービス表( 11gでOIDベースのポリシー・ストアが使用されていた場合は、OPSS ( |
以前の12cリリースからアップグレードしている場合は、これらのスキーマがリポジトリ内にすでにあります。 |
オプション アップグレード・アシスタントでアップグレード前の準備状況チェックを実行します。 |
チェックはコンポーネントによって異なり、考えられる問題のトラブルシューティングに役立つ完了レポートが生成されます。 |
必須 管理サーバー、管理対象サーバー、および既存のデプロイメントで実行されている他のアプリケーションを停止します。 |
アップグレード中に既存の環境を停止しないと、スキーマまたはコンポーネント構成、あるいはその両方が破壊される可能性があります。 |
必須 アップグレード・アシスタントを実行して、選択したスキーマを個別に、またはドメインで使用されるスキーマをすべてアップグレードします。 |
アップグレード・アシスタントで、可能であればいつでも選択したドメイン内のすべてのスキーマをアップグレードできるようにすることをお薦めします。 |
必須 再構成ウィザードを実行してドメインを再構成します。再構成ウィザードは、Oracle Fusion Middleware 12cの新しいツールです。 |
|
WebCenter PortalおよびSitesのユーザーのみ: アップグレード・アシスタントを(再度)実行し、残りのコンポーネント構成をアップグレードします。 WebCenter Contentのユーザーのみ: 必要な構成変更は、サーバーの起動時(アップグレード後)に、ユーザーの介入なしに自動的に実行されるので、アップグレード・アシスタントは実行しません。 |
|
WebCenter Portalのユーザーのみ: Oracle WebCenter Portalを12cにアップグレードするには、一連の追加手順を実行する必要があります。 |
|
必須 コンポーネント固有のドキュメントで説明されている、アップグレード後に必要なすべてのタスクを実行します。 アップグレード後にこれらのタスクを実行しないと、一部のコンポーネントが正しく動作しないことがあります。 |
|
必須 管理サーバーおよび管理対象サーバーを再起動します。 |
|
必須 アップグレードが成功したこと(アプリケーションが予期したとおり機能するなど)を確認します。 |
|
オプション クラスタ・トポロジのWebCenterをアップグレードします(該当する場合)。 |
親トピック: Oracle WebCenterドメインのアップグレード
製品ディストリビューションのインストール
アップグレードを開始する前に、ターゲット・システムにOracle Fusion Middleware InfrastructureおよびWebCenter Contentのディストリビューションをダウンロードし、Oracle Universal Installerを使用してインストールします。
ノート:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middlewareディストリビューションをインストールする必要があります。Infrastructureのインストールが完了した後に、適切なディストリビューション名を使用して、残りのディストリビューションを同様にインストールします。たとえば、Oracle WebCenter Contentのインストール・プログラムを開始するには、ディストリビューション名としてfmw_12.2.1.3.0_wccontent_generic.jar
を使用します。
親トピック: Oracle WebCenterドメインのアップグレード
RCUを使用した必要な12cスキーマの作成
アップグレード時、必要なスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズ・スキーマを作成するか、またはオプションで、Upgrade Assistantを使用してデフォルトのスキーマ設定を使用するスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する方法は、アップグレード手順で説明しています。
ノート:
以前のOracle Fusion Middleware 12cリリースからアップグレードする場合は、これに該当するスキーマを再作成する必要はありません(そのスキーマがすでに存在する場合)。ドメインの既存のスキーマを特定するには、次のステップを参照してください。アップグレードの前に次のスキーマが存在する必要があります。12cからアップグレードする際、現在どのスキーマが存在しているか不明な場合は、次のステップを参照してドメイン内の既存のスキーマを識別します。これらのスキーマがすでに存在している場合、再作成する必要はありません。
-
サービス表スキーマ(
prefix_STB
)。このスキーマは、ドメインベースのアップグレードに必要です。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行すると自動的に作成されます。RCUでは他の12cスキーマに使用した既存のスキーマ所有者接頭辞を指定します。ノート:
サービス表スキーマが存在しない場合、
UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。
というエラー・メッセージが表示されることがあります。 -
Oracle Platform Security Services (OPSS)スキーマ(
prefix_OPSS
)。このスキーマは、12cでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)の実行時に自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。ノート:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。
-
監査スキーマ(
OPSS_AUDIT_VIEWER
)。XMLベースのOPSS_AUDIT
スキーマ、または11gのPortalまたはServicesスキーマを使用していた場合は、RCUを使用して新しい12cのOPSS_AUDIT_VIEWER
スキーマを作成する必要があります。そうしないと、ドメインの再構成は失敗します。
親トピック: Oracle WebCenterドメインのアップグレード
アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックでは、アップグレードの潜在的な問題をすべて発見できるわけではないことに注意してください。準備状況チェック・レポートが成功しても、アップグレードが失敗する場合があります。
- アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readiness
モードで実行することで、実際のアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、またはレスポンス・ファイルを使用してサイレント・モードで実行できます。 - 準備状況モードでのUpgrade Assistantの起動
-readiness
パラメータを使用して、Upgrade Assistantを準備状況モードで起動します。 - Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。 - 準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。
親トピック: Oracle WebCenterドメインのアップグレード
アップグレード前の準備状況チェックの実行について
アップグレード・アシスタントを-readiness
モードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、またはレスポンス・ファイルを使用してサイレント・モードで実行できます。
Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。
準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。
準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。
準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックと異なることがあるためです。
ノート:
パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。
親トピック: アップグレード前の準備状況チェックの実行
準備状況モードでのUpgrade Assistantの起動
-readiness
パラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表3-5 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
アップグレード・アシスタントを使用した準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
親トピック: アップグレード前の準備状況チェックの実行
準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。
準備状況レポート・ファイルの形式は、次のとおりです。
readiness_timestamp.txt
timestamp
は、準備状況チェックが実行された日時を示します。
準備状況レポートには、次の情報が含まれています。
表3-6 準備状況レポートの要素
レポートの情報 | 説明 | 必要なアクション |
---|---|---|
全体的な準備状況ステータス: SUCCESSまたはFAILURE | レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。 | 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。 |
タイムスタンプ |
レポートが生成された日付と時刻です。 |
必要なアクションはありません。 |
ログ・ファイルの場所
|
生成されたログ・ファイルのディレクトリの場所です。 |
必要なアクションはありません。 |
準備状況レポートの場所
|
生成された準備状況レポートのディレクトリの場所です。 |
必要なアクションはありません。 |
チェックされたコンポーネントの名前 |
チェックに含まれるコンポーネントの名前およびバージョンとステータス。 |
ドメインに、このリリースにアップグレードできない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を実行してスキーマと構成をアップグレードする前に、管理サーバーおよび管理対象サーバーを含むすべてのアップグレード前のプロセスとサーバーを停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。
ノート:
この項の手順では、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に関する項を参照してください。
親トピック: Oracle WebCenterドメインのアップグレード
製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
- アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。このレジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。 - Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。 - アップグレード・アシスタントを使用したOracle WebCenterスキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。 - スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registry
のスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
親トピック: Oracle WebCenterドメインのアップグレード
アップグレードで使用可能な既存のスキーマの識別
このオプションのタスクでは、スキーマのバージョン・レジストリを問い合せて、アップグレードを開始する前に使用可能なスキーマのリストを確認できます。このレジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。
アップグレード・アシスタントでは、ドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個々に選択することもできます。いずれかの方法を選択するために、次のステップに従って、アップグレードに使用可能なすべてのスキーマのリストを確認します。
-
Oracleデータベースを使用している場合、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;
-
生成されたレポートを確認します。
あるスキーマでアップグレードの必要がない場合、
schema_version_registry
表には、アップグレード前のバージョンでそのスキーマが保持されます。 -
既存のスキーマに使用されているスキーマ接頭辞名を確認します。新しい12cスキーマの作成時に、同じ接頭辞を使用することになります。
ノート:
-
既存のスキーマが、サポートされているバージョンからのものでない場合、12c (12.2.1.3.0)のアップグレード手順を使用する前に、それらをサポートされているバージョンにアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。
-
一部のコンポーネント(Oracle Enterprise Data Quality、Oracle GoldenGate Monitor、Oracle GoldenGate Veridataなど)では、標準的なOracle Fusion Middlewareのサポート対象バージョン以外のバージョンからのアップグレードがサポートされています。
-
11gでポリシー・ストアとしてOracle Internet Directory (OID)を使用していた場合、アップグレードの前に、ポリシー・ストアをデータベースベースのポリシー・ストアに再度関連付ける必要があります。
-
Oracle Fusion Middlewareリリース12c (12.2.1.3.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.3.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。
親トピック: 製品スキーマのアップグレード
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。
ノート:
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
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表3-7 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
アップグレード・アシスタントを使用したOracle WebCenterスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
親トピック: 製品スキーマのアップグレード
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、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.3.0になっていることを確認します。ノート:
ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。
-
STATUS
フィールドは、スキーマのパッチ適用操作中はUPGRADING
またはUPGRADED
のどちらかになり、パッチ適用操作が完了するとVALID
になります。 -
ステータスが
「INVALID」
と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。 -
IAU_APPEND
とIAU_VIEWER
が所有するシノニム・オブジェクトは、INVALID
と表示されますが、失敗を意味するものではありません。これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当する
INVALID
オブジェクトは、無視しても問題ありません。
親トピック: 製品スキーマのアップグレード
ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)に再構成します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
-
WebLogic Serverコア・インフラストラクチャ
-
ドメイン・バージョン
ノート:
ドメインの再構成を開始する前に、次の制限事項に注意してください。
-
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
-
アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。
-
アップグレードするインストールでOracle Access Management (OAM)が使用されない場合は、2つのファイルを編集して、再構成ウィザードが、存在しないOAMインフラストラクチャ・スキーマの更新(アップグレードが失敗する)を試みないようにする必要があります。
$DOMAIN/init-info/domain-info.xml
に次の例のような行をコメント・アウトします。<!--extention-template-ref name="Oracle Identity Navigator" version="11.1.1.3.0" location="/u01/app/oracle/product/fmw/iam111130/common/templates/applications/oracle.oinav_11.1.1.3.0_template.jar" symbol=""/--> <!--install-comp-ref name="oracle.idm.oinav" version="11.1.1.3.0" symbol="oracle.idm.oinav_11.1.1.3.0_iam111130_ORACLE_HOME" product_home="/u01/app/oracle/product/fmw/iam111130"/-->
また、同様に、
$DOMAIN/config/config.xml
に次の例のような行をコメント・アウトします。<!--app-deployment> <name>oinav#11.1.1.3.0</name> <target>AdminServer</target> <module-type>ear</module-type> <source-path>/u01/app/oracle/product/fmw/iam111130/oinav/modules/oinav.ear_11.1.1.3.0/oinav.ear</source-path> <deployment-order>500</deployment-order> <security-dd-model>DDOnly</security-dd-model> <staging-mode>nostage</staging-mode> </app-deployment-->
-
ドメインの
config.xml
ファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。 -
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
-
起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。
ノート:
ドメインの再構成プロセスを開始すると、それによって行われた変更を元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前のチェックリストに示されているようにドメインのバックアップを作成したことを確認します。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。- ドメインのバックアップ
- 再構成ウィザードの起動
- 再構成ウィザードを使用したドメインの再構成
再構成ウィザードの各画面を通じて既存のドメインを再構成します。
親トピック: Oracle WebCenterドメインのアップグレード
ドメインのバックアップ
再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには:
親トピック: ドメインの再構成について
再構成ウィザードの起動
ノート:
再構成プロセスを開始する前に、管理サーバーおよびすべてのコロケート管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照再構成ウィザードをグラフィカル・モードで起動するには:
親トピック: ドメインの再構成について
再構成ウィザードを使用したドメインの再構成
再構成ウィザードの各画面を通じて、既存のドメインを再構成します。
ノート:
ソースがクラスタ化環境の場合、プライマリ・ノードでのみ再構成ウィザードを実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。親トピック: ドメインの再構成について
ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。 - アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、WebLogicドメインのコンポーネント構成をアップグレードします。 - ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0であることを確認します。
親トピック: Oracle WebCenterドメインのアップグレード
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。
ノート:
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
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表3-8 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.3.0)に再構成した後に、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードする必要があります。
親トピック: ドメイン・コンポーネント構成のアップグレード
ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0になっていることを確認します。
管理コンソールにサインインするには、次に移動します。http://administration_server_host:administration_server_port/console
Oracle Enterprise Manager Fusion Middleware Control Consoleにサインインするには、次に移動します。http://administration_server_host:administration_server_port/em
ノート:
アップグレード後、管理ツールは、前のOracleホーム・ディレクトリからではなく新しい12cのOracleホーム・ディレクトリから必ず実行してください。
アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
Upgrade Assistantを実行するためにFMWユーザーを作成した場合は、アップグレードが成功したことを確認してからアカウントを削除してください。
親トピック: ドメイン・コンポーネント構成のアップグレード
アップグレード後の構成タスクの実行
デプロイメントに含まれるコンポーネントによっては、アップグレード後に追加の構成タスクを実行することが必要になります。
親トピック: Oracle WebCenterドメインのアップグレード
管理サーバーの起動と停止
Oracle WebLogic Server管理サーバーは、WLSTコマンドラインまたはスクリプトを使用して起動および停止できます。管理サーバーを起動または停止すると、WebLogic Server管理コンソールやFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動または停止されます。
たとえば、管理サーバーを起動するには、次のスクリプトを使用します。
DOMAIN_HOME/bin/startWebLogic.sh
管理サーバーを停止するには、次のスクリプトを使用します。
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
親トピック: アップグレード後の構成タスクの実行
ノード・マネージャの起動と停止
ノード・マネージャは、WLSTコマンド行またはスクリプトを使用して起動できます。
ノード・マネージャを起動するには、次のスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh (Windows) DOMAIN_HOME\bin\startNodeManager.cmd
ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。
親トピック: アップグレード後の構成タスクの実行
管理対象サーバーの起動と停止
Fusion Middleware Controlを使用してWebLogic Server管理対象サーバーを起動または停止するには:
-
ナビゲーション・ペインからドメインを展開します。
-
管理対象サーバーを選択します。
-
「WebLogic Server」メニューから、「コントロール」を選択してから、「起動」または「停止」を選択します。
また、サーバーを右クリックして、「コントロール」を選択してから、「起動」または「停止」も選択できます。
スクリプトまたはWLSTを使用して、WebLogic Server管理対象サーバーを起動および停止できます。
たとえば、WebLogic Server管理対象サーバーを起動するには、次のスクリプトを使用します。
(UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url (Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
WebLogic Server管理対象サーバーを停止するには、次のスクリプトを使用します。
(UNIX) NEW_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url username password (Windows) NEW_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url username password
親トピック: アップグレード後の構成タスクの実行
新規アプリケーションが予期したとおり動作することの確認
すべてのサーバーが正常に起動および停止されたら、コンポーネント・アプリケーションを開き、すべてが予期したとおりに動作していることを確認します。コンポーネント固有の管理者ガイドと開発者ガイドを使用して、アップグレード後の環境の新機能をナビゲートします。
親トピック: アップグレード後の構成タスクの実行