3 SOA SuiteおよびBusiness Process Managementのアップグレード
ノート:
実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。
潜在的なアップグレードの問題をクローン環境で特定しておくと、本番環境で無駄な停止時間を排除できます。
- SOA SuiteおよびBPMのアップグレード・プロセス・フローについて
このフローチャートおよび付随するテキストでは、Oracle Fusion Middleware SOA Suite 11gを12c (12.2.1.4.0)にアップグレードするための大まかなステップを示します - Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.4.0)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastructureディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.4.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。 - RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合、必要な12cスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズされたスキーマを作成するか、オプションでUpgrade Assistantを使用してデフォルトのスキーマ設定を使用したスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する詳細は、アップグレード手順で説明します。 - アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。 - サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。 - Upgrade Assistantを使用したスキーマのアップグレード
パーティション化されていないスキーマをアップグレードする場合は、「Upgrade Assistantを使用したスキーマのアップグレード」で説明されているステップに従ってください。パーティション化されているスキーマをアップグレードする場合は、「パーティション化されているスキーマのアップグレード」で説明されているステップに従ってください。 - ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.4.0)にあわせて再構成します。 - ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
SOA SuiteおよびBPMのアップグレード・プロセス・フローについて
既存のドメインをアップグレードするために実行するステップは、ドメインがどのように構成されているか、およびどのコンポーネントをアップグレードするかによって異なります。各自のデプロイメントに該当するステップにのみ従ってください。
表3-1 Oracle SOA Suiteのアップグレード・タスクの説明
説明 | 詳細情報 |
---|---|
必須 アップグレードするコンポーネントに必要なアップグレード前タスクをすべて実行します(まだそうしていない場合)。 |
Oracle BAMを含むSOAドメインについては、「Oracle BAMのアップグレード前タスクの実行」を参照してください Oracle Service Busをアップグレードする場合(Oracle SOAを含む場合も含まない場合も)、「Oracle Service Bus (OSB)のアップグレード前タスクの実行」を参照してください |
必須 アップグレードを開始する前に、11g本番デプロイメントと同じホスト上の新しいOracleホームに、Fusion Middleware Infrastructure 12c (12.2.1.4.0)をインストールする必要があります。 12cでは、11g Middlewareホームを表現するために、Oracleホームを使用します。 |
インストールしますが、新しくインストールしたドメインを構成するために構成ウィザードを使用しないでください。アップグレード中、再構成ウィザードを使用して既存の11gドメインを構成します。 |
必須 SOA SuiteおよびBusiness Process Management 12c (12.2.1.4.0)と、統合されたSOA統合ディストリビューション(Oracle HTTP Server、Oracle Service Busなど)を、新しく作成したOracleホームにインストールします。 |
Fusion Middleware 12c (12.2.1.4.0)ディストリビューションは、アップグレードするSOA統合製品ごとにインストールする必要があります。たとえば、Oracle Service Busを含むSOA 11g環境をアップグレードする場合は、Oracle SOA SuiteおよびBPM 12c (12.2.1.4.0)ディストリビューションのほかに、Oracle Service Busディストリビューションも入手する必要があります。 |
オプション Upgrade Assistantでアップグレード前の準備状況チェックを実行します |
アップグレードを開始する前にUpgrade Assistantを—readinessモードで実行し、アップグレードを失敗させる可能性がある、アップグレード前環境での潜在的な問題を識別します。必要な場合は、問題を修正し、準備状況チェックを再度実行します。 |
必須 11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。 |
警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。 |
オプション リポジトリ作成ユーティリティ(RCU)を起動して、カスタマイズされた設定を使用して必要な12cスキーマを作成します(必要に応じて)。 または: Upgrade Assistantを使用して、デフォルト設定とともに必要なスキーマを作成します。 |
作成するスキーマは、既存のスキーマ構成によって異なります。 ほとんどの場合、このステップが適用されるのは11g環境からアップグレードしていて、必要なインフラストラクチャ・スキーマが欠落している場合のみです。 |
必須 アップグレード・アシスタントを実行して、データベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。 |
12c (12.2.1.4.0)以降、Upgrade Assistantは欠落スキーマを検出して作成できるようになりました。これらのスキーマはデフォルトのスキーマ設定を使用して作成し、変更できません。スキーマの特定の設定が必要な場合、リポジトリ作成ユーティリティ(RCU)を使用します。 ノート: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが新しい12c (12.2.1.4.0)環境に正常にアップグレードされたら、Upgrade Assistantを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。 |
オプション アップグレード中、SOAインスタンスが自動的に移行されます。ただし、進行中のクローズ済インスタンスのアップグレードは、管理SQLスクリプトまたはOracle Fusion Middleware Enterprise Manager Controlを使用してアクティブに管理できます。 |
|
Oracle BAMがアップグレードの一部である場合のみ、必須。 アップグレードする11g SOAドメインにOracle Business Activity Monitoring (BAM)が含まれる場合、再構成ウィザードを実行する前に、BAM固有のアップグレード前作業をすべて完了する必要があります。これらのステップを再構成ウィザードの実行前に完了していないと、アップグレードに失敗します。 |
「Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード」を参照 12cのBusiness Activity Monitoring (BAM)は完全に再設計されており、ドメインの再構成前とアップグレード後にさらにステップが必要になります。 |
必須 再構成ウィザードを実行して、ドメインとノード・マネージャを再構成します。 |
アップグレード中に、構成ウィザードを再構成モードで実行し、新しくインストールしたソフトウェアを使用するよう既存のドメインをアップグレードします。 |
必須 アップグレード・アシスタントを(再度)実行して、ドメイン構成をアップグレードします。 |
Upgrade Assistantは、再構成したドメインのコンポーネント構成を更新するために使用します。 |
必須 必要なアップグレード後の構成タスクを実行します(必要な場合)。 |
コンポーネントには、その他のアップグレード後手順は必要ない場合があります。 |
必須 アップグレード検証プロセスの一部として、新しい管理サーバー、管理対象サーバーおよびノード・マネージャを起動して、問題がないか確認することをお薦めします。 |
バックアップを削除する前に、アップグレードしたすべてのコンポーネントが予想どおりに動作することを確認することをお薦めします。 |
クラスタ・アップグレードに必要
アップグレードが正常に終了したことを確認したら、環境を他のホストに伝播する必要があります。 |
「別のホストへのドメイン構成の伝播」 |
Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.4.0)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastructureディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.4.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。
ノート:
Infrastructureがアップグレードに必要な場合、他のFusion Middleware製品をインストールする前にOracle Fusion Middlewareディストリビューションを最初にインストールする必要があります。-
以前の12cリリースからアップグレードする場合は、12c (12.2.1.4.0)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.4.0)へのアップグレードは、パッチ・リリースではありません。
-
Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。
- SOAドメインにOracle Service Bus、Managed File TransferまたはOracle B2Bなどのその他のSOA統合コンポーネントがある場合は、それらのディストリビューションを同じ新しいOracleホームにインストールする必要があります。Oracle Business Activity MonitoringおよびBusiness Process Managementは、汎用のSOAディストリビューションの一部です。
RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合、必要な12cスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズされたスキーマを作成するか、オプションでUpgrade Assistantを使用してデフォルトのスキーマ設定を使用したスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する詳細は、アップグレード手順で説明します。
ノート:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次のステップを参照してください。12cにアップグレードする前に、次のスキーマが存在している必要があります。11gからアップグレードし、現在使用しているスキーマがわからない場合、次のステップを参照して、ドメインの既存のスキーマを識別します。すでに存在する場合、これらのスキーマを再作成する必要はありません
-
サービス表スキーマ(
prefix_STB
)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。ノート:
サービス表スキーマが存在しない場合、
UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。
というエラー・メッセージが表示されることがあります。 -
Oracle Platform Security Services (OPSS)スキーマ(
prefix_OPSS
)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。ノート:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。
-
Audit Services (IAU) 既存の11gドメインにPlatform Security (_OPSS)スキーマ(データベース・ベースのOPSS)およびファイル・ベースのAudit Services (_IAU)スキーマがある場合、新しいAudit Servicesスキーマ(_IAU)および補助スキーマ(_IAU_APPENDと_IAU_VIEWER)を12cドメイン用に作成する必要があります。
-
次の表では、存在する必要があるその他のスキーマを示します。
表3-2 SOAおよびSOA統合製品に必要なスキーマ
アップグレードする内容 存在する必要がある12cスキーマ SOA Suite (SOA)
Service Table (_STB)
Audit Services (_IAU)および補助スキーマ(_IAU_APPEND)と(_IAU_VIEWER) — 11gから12cへのアップグレードでは、11gソース・ドメインにOracle Platform Services (_OPSS)スキーマがある場合は、これらのスキーマを作成する必要があります。
ノート: Oracle Platform Security Services (_OPSS)が選択されている場合は、必要なAudit Services (_IAU)スキーマおよび補助スキーマ(_IAU_APPENDおよび_IAU_VIEWER)が自動的に選択されます。
既存の11gドメインにPlatform Security (_OPSS)スキーマ(データベース・ベースのOPSS)およびファイル・ベースのAudit Services (_IAU)スキーマがある場合、新しいAudit Servicesスキーマ(_IAU)および補助スキーマ(_IAU_APPENDと_IAU_VIEWER)を12cドメイン用に作成する必要があります。
Business Process Monitoring (BPM)
Service Table (_STB)
Audit Services (_IAU)および補助スキーマ(_IAU_APPEND)と(_IAU_VIEWER)
Business Activity Monitoring(BAM)
SOA Suiteに必要なスキーマ
および
WebLogic Services (_WLS)および補助スキーマ(_WLS_RUNTIME)
Managed File Transfer (MFT) Service Table (_STB)
Audit Services (_IAU)および補助スキーマ(_IAU_APPEND)と(_IAU_VIEWER)
Oracle Service Bus(OSB)
Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでOracle Service Bus (OSB)を実行することもできました。ただし、12cでは、Oracle Service Bus 12c (12.2.1.4.0)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。
SOAインフラストラクチャ(_SOAINFRA)
Service Table (_STB)
ユーザー・メッセージング(_UMS)
ノート: Oracle SOAを実行しなくてもOracle Service Busはインストールできますが、
_SOAINFRA
スキーマと_STB
スキーマを作成する必要があります。ユーザー・メッセージング・サービス(UMS)
Service Table (_STB)
Audit Services (_IAU)および補助スキーマ(_IAU_APPEND)と(_IAU_VIEWER)
アップグレード前の準備状況チェックの実行
アップグレードに関する潜在的な問題を識別するために、アップグレード・プロセスの開始前に準備状況チェックを実行することをお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。
- アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readiness
モードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用してGUIモードで、またはレスポンス・ファイルを使用してサイレント・モードで準備状況チェックを実行できます。 - 準備状況モードでのUpgrade Assistantの起動
-readiness
パラメータを使用して、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を起動します。
アップグレード・アシスタントのパラメータ
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表3-7 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックに必要
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。
親トピック: アップグレード前の準備状況チェックの実行
準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。
準備状況レポート・ファイルのフォーマットは、次のとおりです。
readiness<timestamp>.txt
ここで、timestamp
は、準備状況チェックが実行された日付と時刻を示します。
準備状況レポートには、次の情報が含まれています。
表3-8 準備状況レポートの要素
レポートの情報 | 説明 | 必要なアクション |
---|---|---|
全体的な準備状況ステータス: 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 Fri Aug 16 13:29:41 PDT 2019
Log file is located at: /oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2019-08-16-13-23-36PM.log
Readiness Check Report File: /oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2019-08-16-13-29-41PM.txt
Domain Directory: /oracle/work/middleware_1212/user_projects/domains/jrf_domain
Starting readiness check of components.
Oracle Platform Security Services
Starting readiness check of Oracle Platform Security Services.
Schema User Name: DEV3_OPSS
Database Type: Oracle Database
Database Connect String:
VERSION Schema DEV3_OPSS is currently at version 12.1.2.0.0. Readiness checks will now be performed.
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test: Test that the schema does not contain any unexpected tables TEST_UNEXPECTED_TABLES
Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
Starting schema test: TEST_ENOUGH_TABLESPACE Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test: TEST_USER_TABLESPACE_QUOTA Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test: TEST_ONLINE_TABLESPACE Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting permissions test: TEST_DBA_TABLE_GRANTS Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test: SEQUENCE_TEST Test that the Oracle Platform Security Services schema sequence and its properties are valid
Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid +++ PASS
Finished readiness check of Oracle Platform Security Services with status: SUCCESS.
Oracle Audit Services
Starting readiness check of Oracle Audit Services.
Schema User Name: DEV3_IAU
Database Type: Oracle Database
Database Connect String:
VERSION Schema DEV3_IAU is currently at version 12.1.2.0.0. Readiness checks will now be performed.
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test: TEST_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_ENOUGH_TABLESPACE Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test: TEST_USER_TABLESPACE_QUOTA Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test: TEST_ONLINE_TABLESPACE Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting permissions test: TEST_DBA_TABLE_GRANTS Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test: TEST_UNEXPECTED_COLUMNS Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting schema test: SEQUENCE_TEST Test that the audit schema sequence and its properties are valid
Completed schema test: SEQUENCE_TEST --> Test that the audit schema sequence and its properties are valid +++ PASS
Starting schema test: SYNONYMS_TEST Test that the audit schema required synonyms are present
Completed schema test: SYNONYMS_TEST --> Test that the audit schema required synonyms are present +++ PASS
Finished readiness check of Oracle Audit Services with status: FAILURE.
Common Infrastructure Services
Starting readiness check of Common Infrastructure Services.
Schema User Name: DEV3_STB
Database Type: Oracle Database
Database Connect String:
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
Completed schema test: ALL_TABLES --> TEST_REQUIRED_TABLES +++ Test that the schema contains all the required tables
Starting schema test: TEST_UNEXPECTED_TABLES Test that the schema does not contain any unexpected tables
Completed schema test: ALL_TABLES --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
Starting schema test: TEST_REQUIRED_VIEWS Test that the schema contains all the required database views
Completed schema test: ALL_TABLES --> TEST_REQUIRED_VIEWS +++ Test that the schema contains all the required database views
Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns
Completed schema test: ALL_TABLES --> TEST_MISSING_COLUMNS +++ Test that tables and views are not missing any required columns
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Completed schema test: ALL_TABLES --> TEST_DATABASE_VERSION +++ Test that the database server version number is supported for upgrade
Finished readiness check of Common Infrastructure Services with status: SUCCESS.
Oracle JRF
Starting readiness check of Oracle JRF.
Finished readiness check of Oracle JRF with status: SUCCESS.
System Components Infrastructure
Starting readiness check of System Components Infrastructure.
Starting config test: TEST_SOURCE_CONFIG Checking the source configuration.
INFO /oracle/work/middleware_1212/user_projects/domains/jrf_domain/opmn/topology.xml was not found. No upgrade is needed.
Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
Finished readiness check of System Components Infrastructure with status: ALREADY_UPGRADED.
Common Infrastructure Services
Starting readiness check of Common Infrastructure Services.
Starting config test: CIEConfigPlugin.readiness.test This tests the readiness of the domain from CIE side.
Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
Finished readiness check of Common Infrastructure Services with status: SUCCESS.
Finished readiness check of components.
親トピック: アップグレード前の準備状況チェックの実行
サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプアップグレード前のプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。
ノート:
この項内の手順では、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
プロンプトが表示されたらユーザー名とパスワードを入力します。
SOAサーバーおよびプロセスは、次の順番で停止してください。
-
Business Activity Monitoring (BAM)管理対象サーバー
-
Oracle Service Bus (OSB)管理対象サーバー
-
サービス指向アーキテクチャ(SOA)管理対象サーバー
-
Oracle Web Services Manager (OWSM)管理対象サーバー
ステップ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を使用したスキーマのアップグレード」で説明されているステップに従ってください。パーティション化されているスキーマをアップグレードする場合は、「パーティション化されているスキーマのアップグレード」で説明されているステップに従ってください。
ノート:
必ずスキーマ構成のための手順を選択するようにしてください。パーティション化されたスキーマは、Upgrade Assistantを使用してアップグレードできません。- 製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。 - 11gからのパーティション化されたスキーマ表のアップグレード
Oracle SOA Suite 11gの管理ガイドの説明に従ってパーティション化されたスキーマを含むOracle SOA 11gインストールをアップグレードしようとする場合、12c (12.2.1.4.0)でもこの特定の表パーティション化戦略を使用するには、これらの必要なステップを完了して、パーティション化されたスキーマ表をアップグレードする必要があります。
製品スキーマのアップグレード
サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。 - Upgrade Assistantの使用によるSOAスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。 - スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registry
のスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantを実行しているプラットフォームにJVM文字エンコーディングがUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗することがあります。
oracle_common/upgrade/bin
ディレクトリに移動します。- (UNIX)
ORACLE_HOME/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表3-9 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックに必要
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
アップグレード・アシスタントを使用したSOAスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
注意:
パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。
パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。
アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。
親トピック: 製品スキーマのアップグレード
スキーマのアップグレードの確認
すべてのアップグレード・ステップが完了したら、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.4.0になっていることを確認します。ノート:
すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。
-
STATUS
フィールドは、スキーマのパッチ適用処理中はUPGRADING
またはUPGRADED
のどちらかになり、その処理が完了するとVALID
になります。 -
ステータスが
「INVALID」
と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。 -
IAU_APPEND
およびIAU_VIEWER
に所有されているシノニム・オブジェクトは、INVALID
と表示されますが、失敗を示しているわけではありません。それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらの
INVALID
オブジェクトは無視してかまいません。
親トピック: 製品スキーマのアップグレード
11gからのパーティション化されたスキーマ表のアップグレード
Oracle SOA Suite 11gの管理ガイドの説明に従ってパーティション化されたスキーマを含むOracle SOA 11gインストールをアップグレードしようとする場合、12c (12.2.1.4.0)でもこの特定の表パーティション化戦略を使用するには、これらの必要なステップを完了して、パーティション化されたスキーマ表をアップグレードする必要があります。
ノート:
この手順は、アップグレード済の12c環境で既存のOracle SOA 11g表パーティション化戦略を使用しようとする場合にのみ必要です。以前の12cリリースからアップグレードする場合は、この手順を完了する必要はありません。パーティション化されたスキーマ表のアップグレードの理解
COMPOSITE_INSTANCE
パーティションに基づいて新しいファブリック12c表パーティションがモデル化されます(他の既存のパーティションはすべて調整済です)。均等パーティション化戦略を実施する新しい12cファブリック表は、SCA_FLOW_INSTANCE
という名前です。
始める前に
-
新しいSOA 12cファブリック表を調整するために、現在非推奨となった11g
composite_instance
表に基づいてモデル化された、ダミーで空のRANGE
パーティションが追加されます。つまり、約10個の新しいファブリック表が再作成されて、パーティション化された表になります。 -
このプロセス中に、
RANGE
パーティション化をINTERVAL-RANGE
パーティション化に変換できます(Oracle Fusion Middleware SOA Suite 12cでは両方のパーティション化がサポートされるようになりました)。引き続き
RANGE
パーティション化を使用するか、このプロセスの一部としてINTERVAL-RANGE
パーティション化に変換するかを選択できます。INTERVAL-RANGE
表は、RANGE
パーティションとINTERVAL-RANGE
パーティションの両方を格納でき、最初のパーティションは常に(遷移ポイントと呼ばれる)RANGE
パーティションになります。表がINTERVAL-RANGE
に変換されても、新しいINTERVAL-RANGE
パーティションが自動的に割り当てられるまで、既存のRANGE
パーティションは残ります。 -
11g SOAパーティション化戦略では、MAXVALUEパーティションの使用に関する推奨は提供されませんでした。
INTERVAL-RANGE
パーティション化への変換を選択した場合、MAXVALUE
パーティションが空でなければ、表を再ビルドする必要があります。ただし、MAXVALUE
パーティションが空の場合は、INTERVAL-RANGE
への変換の一部として削除されます。ただし、MAXVALUE
パーティションが空の場合は、変換の一部として削除されます。(INTERVAL-RANGE
パーティション化では、パーティションが自動的に割り当てられるため、MAXVALUE
パーティションは許可されません。) -
このプロセスでは、TRS (Table Recreation Scripts)ユーティリティが使用されます。生成されたスクリプトの一部を編集する必要があります。生成されたDDLは個々のインストールやRDBMSバージョン間で異なっていたり、カスタマイズされた可能性もあるため、DDL構文を修正するために編集が必要です。
-
12.2.1.4.0の検証スクリプトはアップグレードに対応しており、12c
sca_flow_instance
表と11gcomposite_instance
表の両方のインスタンスが考慮されます。
ノート:
このプロセスを開始する前に、スキーマおよびデータベースの完全バックアップを作成することをお薦めします。また、本番での試行前に、テスト環境でこの手順を実行しておくこともお薦めします(検証スクリプトを含む)。プロセスの概要
パーティション化されたスキーマ表のアップグレードは、次の2つのフェーズで行われます。
フェーズ1: DDLスクリプトを生成します。
-
パーティション・キーを修正します
-
DDL変更を受け入れます
-
新しい12cファブリック表をパーティション化します
composite_instanceに基づいてモデル化されたダミーの
RANGE
パーティションが作成されます。 -
MAXVALUEパーティションを処理します(間隔が必要な場合)
フェーズ2: DDLスクリプトを編集し、実行します。
-
DDLスクリプトを編集します。
-
DDLスクリプトを実行します。
-
ログ・ファイルを確認します。
フェーズ1: DDLスクリプトの生成
-
SYSDBAとして、TRS_DIRを作成し、<soainfra>への読取りおよび書込みを許可します。
SQL > create directory TRS_DIR as ‘/../../..’; SQL> grant read,write on directory TRS_DIR to <soainfra>
-
デバッグ・モードを有効化します。
ALTER PROCEDURE debug_purge COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' ║ REUSE SETTINGS; ALTER PROCEDURE log_info COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' REUSE ║ SETTINGS;
-
次のディレクトリに移動します。
12C_mwhome/soa/common/sql/soainfra/sql/oracle/122140/trs12/
-
必要な変更があれば、trs_migrate_exec.sqlを編集します。次の表は、パラメータおよび使用可能なオプションを示しています。
パラメータ オプション range_interval R (レンジ)またはI (間隔) interval_clause 'NUMTOYMINTERVAL(1, ''MONTH'')‘ SQL変換関数によって指定します-
NUMTODSINTERVALは、nをINTERVAL DAY TO SECONDリテラルに変換します。
-
NUMTOYMINTERVALは、数値nをINTERVAL YEAR TO MONTHリテラルに変換します。
partition G (グループ1または2)またはP (一部) 11gパーティション化戦略を識別します
drop_flag 元の表を削除します(true、false) redo_flag REDOを生成します(true、false) DOP 並列度 sql_trace SQLトレース(true、false) trueの場合、soainfraユーザーに"alter session"権限が付与されていることを確認してください。
コード・スニペットのサンプルを次に示します。必ず、各自のパラメータ・オプションを指定してください。set echo on; set serverout on; DECLARE range_interval varchar2(1) := 'I'; interval_clause varchar2(40) := 'NUMTOYMINTERVAL(1, ''MONTH'')'; partition varchar2(1) := 'G'; drop_flag boolean := true; redo_flag boolean := false; DOP number := 0; sql_trace boolean := false; BEGIN trs_mig.trs_migrate (range_interval, interval_clause, partition, drop_flag, redo_flag, DOP, sql_trace); END; /
-
-
trs_migrate_exec.sqlを実行して、DDLスクリプトを生成します。
フェーズ2: DDLスクリプトの編集および実行
ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.4.0)に再構成します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
-
WebLogic Serverコア・インフラストラクチャ
-
ドメイン・バージョン
ノート:
ドメイン再構成を開始する前に、次の制限事項に注意してください。
-
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
-
アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。
-
アップグレードするインストールで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/yourcomany.oinav_11.1.1.3.0_template.jar" symbol=""/--> <!--install-comp-ref name="oracle.idm.oinav" version="11.1.1.3.0" symbol="yourcompany.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バージョンと互換性を持つために必要な再構成タスクを定義します。
-
起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。
ノート:
ドメインの再構成プロセスを開始すると、行う変更を元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストに示されているようにドメインをバックアップしてあることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、ドメインが再構成前の元の状態に戻されたことを確認する唯一の方法です。- ドメインのバックアップ
- 再構成ウィザードの起動
- 再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。
ドメインのバックアップ
再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには:
親トピック: ドメインの再構成について
再構成ウィザードの起動
ノート:
再構成プロセスを開始する前に管理サーバーおよびすべてのコロケートされた管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照再構成ウィザードをグラフィカル・モードで起動するには:
親トピック: ドメインの再構成について
再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。
ノート:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。親トピック: ドメインの再構成について
ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。 - Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantを実行しているプラットフォームにJVM文字エンコーディングがUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗することがあります。
oracle_common/upgrade/bin
ディレクトリに移動します。- (UNIX)
ORACLE_HOME/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表3-10 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックに必要
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。
再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.4.0)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。
親トピック: ドメイン・コンポーネント構成のアップグレード