プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Data Integratorのアップグレード
12c (12.2.1.1)
E77371-02
目次へ移動
目次
前
前 		次
次

4 Oracle Data Integrator Java EEエージェント環境の11gからのアップグレード

Oracle Data Integrator Java EEエージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.1)にアップグレードできます。

次の各項の手順に従って、アップグレードを実行します。

親トピック: 11gから12c (12.2.1.1)へのOracle Data Integratorのアップグレード

4.1 Oracle Data Integrator Java EEエージェントのアップグレード・プロセスの理解

Oracle Data Integrator Java EEエージェント環境のアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

図4-1 ODI Java EEエージェントのアップグレード・プロセス・フローチャート

図4-1の説明が続きます
「図4-1 ODI Java EEエージェントのアップグレード・プロセス・フローチャート」の説明
フローチャートの最初のタスクは、次で説明します。

この章の残りの各項では、Oracle Data Integrator Java EEエージェントのアップグレードに固有の手順について説明します。

4.2 Oracle Data Integrator Java EEエージェント環境のインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、Oracle Data Integratorの12cバージョンをインストールします。

「12c Oracle Fusion Middleware製品ディストリビューションのダウンロードとインストール」の一般情報を確認した後、『Oracle Data Integratorのインストールと構成』の手順に従ってください。

  1. 「Oracle Data Integratorインストールの計画」では、Oracle Data Integratorのインストール・トポロジに関する重要な情報を理解します。

    この項では、12cの重要な概念の一部を説明し、必要な製品ディストリビューションの入手場所に関する情報も提供します。Java EEエージェント環境の場合、Oracle Data Integratorをインストールするための前提条件として、Oracle Fusion Middleware Infrastructureも必要です。

  2. 「Oracle Data Integratorのインストール」では、特定の環境向けのOracle Data Integratorをインストールします。

    注意:

    構成ウィザードで新規の12c WebLogicドメインを構成しないでください。かわりに、スキーマのアップグレード後に再構成ウィザードを使用してドメインを構成します。WebLogicドメイン内のいずれかのOracle Java Required Files (JRF)コンポーネントを更新する必要がある場合は、再構成ウィザードの後にオプションでアップグレード・アシスタントを実行できます。

4.3 RCUを使用した必要な12cスキーマの作成

11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

注意:

Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

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)をアップグレードする場合、_IAUに加えて、_IAU_APPENDおよび_IAU_VIEWERを必ず選択します。これらを選択したときに、アップグレード・アシスタントによって自動的に作成されます。

RCUを使用して12cスキーマを作成する手順は次のとおりです。
  1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、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 ;
  2. まだ設定していない場合には、JAVA_HOME環境変数を設定し、$PATHに$JAVA_HOME/binを追加します。現在サポートされているJDKバージョンは、jdk1.8.0_77.です
  3. binディレクトリに移動します。

    UNIXオペレーティング・システムの場合:

    ORACLE_HOME/oracle_common/upgrade/bin

    Windowsオペレーティング・システムの場合:

    ORACLE_HOME\oracle_common\upgrade\bin
  4. RCUを起動します。

    UNIXオペレーティング・システムの場合:

    ./rcu

    Windowsオペレーティング・システムの場合:

    rcu.bat
  5. 「ようこそ」画面で「次へ」をクリックします。
  6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
    DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。「次へ」をクリックします
  7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

    表4-1 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

    オプション 説明および例
    ホスト名

    データベースが実行されるサーバーの名前を、次の書式で指定します。

    examplehost.exampledomain.com

    Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。
    ポート

    データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。
    サービス名

    データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

    Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。次に例を示します。

    examplehost.exampledomain.com
    ユーザー名 データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。
    パスワード データベース・ユーザーのパスワードを入力します。
    ロール

    ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

    「標準」またはSYSDBA

    表4-2 MySQLデータベースに対する接続資格証明

    オプション 説明および例
    ホスト名

    データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 管理者権限を持つユーザーの名前を指定します。
    パスワード データベース・ユーザーのパスワードを入力します。

    表4-3 Microsoft SQL Serverデータベースに対する接続資格証明

    オプション 説明および例
    Unicodeのサポート

    ドロップダウン・リストから「はい」または「いいえ」を選択します。
    サーバー名 データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 管理者権限を持つユーザーの名前を指定します。
    パスワード データベース・ユーザーのパスワードを入力します。

    表4-4 IBM DB2データベースに対する接続資格証明

    オプション 説明および例
    サーバー名 データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。
    パスワード データベース・ユーザーのパスワードを入力します。
    前提条件のチェックに成功したら、「OK」をクリックして次のページに進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。
  8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

    注意: デフォルトで、Common Infrastructure Services Table (prefix_STB)およびOPSS (prefix_OPSS)スキーマが選択されます(それらがまだ作成されていない場合)。
    インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。
  9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。
  10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
    この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。
  11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
    「次へ」をクリックし、確認プロンプト・ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。
    RCUの起動時にTransparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するために、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。
  12. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
    この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示できます。
  13. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

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

Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

デフォルトで、準備状況チェック・レポート・ファイルはOracle 12cディレクトリ(ORACLE_HOME/oracle_common/upgrade/logs)に配置されます。

注意:

準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックはオフピーク時に実行することをお薦めします。
アップグレード前の環境に対して準備状況チェックを実行するには、-readinessモードでアップグレード・アシスタントを起動します。

  1. binディレクトリに移動します。

    UNIXオペレーティング・システムの場合:

    ORACLE_HOME/oracle_common/upgrade/bin

    Windowsオペレーティング・システムの場合:

    ORACLE_HOME\oracle_common\upgrade\bin

  2. Upgrade Assistantを起動します。

    UNIXオペレーティング・システムの場合:

    ./ua -readiness

    Windowsオペレーティング・システムの場合:

    ua.bat -readiness

    次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

    ./ua [-logLevel log_level] [-logDir log_directory]

    ここでlog_levelは次のいずれかになります。

    • TRACE

    • NOTIFICATION

    • WARNING

    • ERROR

    • INCIDENT_ERROR

    log_levelのデフォルト値はNOTIFICATIONです。

    トラブルシューティングする場合、log_levelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、アップグレード・アシスタントのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、log_level値を変更してください。

    注意:

    サービス表スキーマを作成していない場合、エラー・メッセージUPGAST-00328: スキーマ・バージョン・レジストリ表がこのデータベースに存在しません。これが発生した場合、アップグレード・アシスタントを実行するためにサービス表スキーマを作成する必要があります。が表示されます。

    これが発生した場合、リポジトリ作成ユーティリティ(RCU)を使用して必要な12c スキーマを作成する必要があります。

    表4-5 Upgrade Assistant画面: 準備状況チェック

    画面 画面が表示されるタイミング 説明
    ようこそ

    常時。

    この画面には、準備状況チェックの概要が示されます。

    準備状況チェックのタイプ:

    • 個別に選択されたスキーマ

    • ドメイン・ベース

    常時。

    準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。次の2つのオプションがあります。次にこれらのオプションについて説明します。

    • 「個別に選択されたスキーマ」オプションを使用すると、アップグレードする前に確認するスキーマを選択できます。

    • 「ドメイン・ベース」オプションを使用して、ドメインごとに準備状況チェックが実行されるようにします。
    使用可能なコンポーネント

    「個別に選択されたスキーマ」が選択されている場合。

    この画面には、スキーマが選択される使用可能なコンポーネントがリストされます。ここで何かを選択すると、そのコンポーネントのスキーマに対して準備状況チェックが実行されます。
    すべてのスキーマのコンポーネント・リスト

    スキーマの準備状況チェックが実行されるたび。

    		 この画面は、スキーマの準備状況チェックが実行されるたびに表示されます。これは、「すべてのスキーマのチェックを含める」オプションを使用して「個別に選択されたスキーマ」または「ドメイン・ベース」を選択する場合です。
    スキーマ資格証明

    常時。

    この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレードするスキーマが以前のFusion MiddlewareのリリースでRCUによって作成された場合は、使用可能なスキーマ名がリストされたドロップダウン・メニューが表示されます。

    DBAユーザー名: SYSDBAではなくFMWとしてUpgrade Assistantを実行することをお薦めします。まだFMWユーザーを作成していない場合は、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください
    準備状況サマリー

    常時。

    この画面には、選択に基づいて実行される準備状況チェックの概要が示されます。

    Upgrade Assistantを-response (またはサイレント)モードで再実行する場合は、「レスポンス・ファイルの保存」をクリックします。

    準備状況チェック

    常時。

    この画面には、準備状況チェックの現在のステータスが表示されます。チェック対象として選択した内容によっては、このプロセスには数分かかる場合があります。

    詳細レポートを表示するには、準備状況レポートのレビューをクリックします。このボタンは、準備状況チェックがすべて完了した後のみ表示されます。

    注意:

    パフォーマンスの低下を回避するには、準備状況チェックをオフピーク時に実行することを検討してください。
    準備状況成功

    準備状況チェックが正常に完了した場合。

    これで、完全なレポートをレビューできるようになります。

    準備状況チェックで問題またはエラーが発生した場合、ログ・ファイルをレビューして問題を特定し、問題を修正してから、準備状況チェックを再開してください。

    デフォルトで、準備状況チェック・レポート・ファイルは次のOracle 12cディレクトリに配置されます。

    ORACLE_HOME/oracle_common/upgrade/logs

4.5 マスターおよび作業リポジトリ・スキーマのアップグレード

サーバーとプロセスを停止した後、アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードします。

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

アップグレード・アシスタントを実行してスキーマをアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンします。

詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。

注意:

リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、『Oracle Data Integratorの管理』の外部パスワード記憶域の設定に関する項を参照してください。

4.5.2 Upgrade Assistantの起動

アップグレード・アシスタントはOracle Data Integrator 11gリポジトリ・スキーマをOracle Data Integrator 12cへアップグレードします。

注意:

エディション・ベースの再定義(EBR)ユーザーのみ:

エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11gまたは12cエディションの子である必要があります。

再定義のためのサーバーでのエディション作成の詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のエディションベースの再定義のためのサーバーでのエディション作成に関する項を参照してください。

注意:

外部認証を使用している場合は、外部認証が内部認証に設定されていることを確認してください。詳細は、「ODIの外部認証の構成」を参照してください

必須ではありませんが、アップグレード・アシスタントを実行するには、非SYSDBAユーザーを作成することをお薦めします。非SYSDBAユーザーをまだ作成してない場合は、「非SYSDBAユーザーの作成」を参照してください。

Upgrade Assistantを起動するには、次の手順に従います。
  1. binディレクトリに移動します。

    UNIXオペレーティング・システムの場合:

    ORACLE_HOME/oracle_common/upgrade/bin

    Windowsオペレーティング・システムの場合:

    ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantを起動します。

    UNIXオペレーティング・システムの場合:

    ./ua

    Windowsオペレーティング・システムの場合:

    ua.bat

4.5.3 アップグレード・アシスタントを使用した製品スキーマのアップグレード

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意:

アップグレード・アシスタントは、ODIマスター・リポジトリのデータおよび構造を使用して、リポジトリがすでにアップグレード済でないかどうかを判定します。アップグレード・アシスタントは、次の状況の場合には、リポジトリがアップグレード済であることを示すメッセージを返します。

  • スキーマ・バージョン・レジストリが有効な状態で、リポジトリのバージョンを保持している

  • リポジトリが12cである

  • リポジトリのバージョンが、アップグレード・アシスタントが使用するODI SDKのバージョン以上である

リポジトリ・カタログ情報をデバッグまたは表示するには、(ODIスキーマ/リポジトリ内ではなく)Adminユーザーに格納されているschema_version_registry表に対して次の問合せを使用します。

Oracleデータベースでは、この表の名前はSYSTEM.SCHEMA_VERSION_REGISTRY$であり、SYSTEMスキーマに格納されています。また、SYSTEM.SCHEMA_VERSION_REGISTRYというビューと、このビューを示すパブリック・シノニムSCHEMA_VERSION_REGISTRYがあります。

SELECT COMP_ID,COMP_NAME,MRC_NAME,OWNER,VERSION,STATUS,UPGRADED FROM schema_version_registry;

DB2/400オペレーティング・システムの場合、AdminユーザーはQSECOFRで、schema_version_registry表はスキーマ'NULLID'内に配置されています。

ODIコンポーネントの行は、ODIリポジトリの追跡に使用されます。

  1. アップグレード・アシスタントの導入

    「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

  2. アップグレード操作の選択

    「スキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

    • 「個別に選択されたスキーマ」では、「使用可能なコンポーネント」画面にアップグレード可能なスキーマがあるインストール済みOracle Fusion Middlewareコンポーネントのリストが表示されます。マスターおよび作業リポジトリ・スキーマをアップグレードするには、「Oracle Data Integrator」を選択します。依存スキーマは自動的に選択されることに注意してください。

    • ドメインで使用されるすべてのスキーマでは、すべてのスキーマ・コンポーネントのリスト画面にアップグレードに含まれる特定のドメイン・ディレクトリ内のすべてのコンポーネントおよびスキーマが表示されます。

  3. 前提条件の検証

    「前提条件」画面で、アップグレードの前提条件が満たされていることを確認してチェックを外します。

    続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

  4. データベースおよびスキーマ資格証明の指定

    ODIスキーマ画面で、アップグレードするスキーマが含まれるデータベースの接続資格証明を入力して「接続」をクリックします。

  5. ODIアップグレード・オプションの選択

    「ODIオプション」画面で、すべてのオプションを選択します。

    GUID-0D1C1836-387D-4108-B8F8-0D8D052741E2-default.pngの説明が続きます
    GUID-0D1C1836-387D-4108-B8F8-0D8D052741E2-default.pngの説明

    次の表で、各オプションを説明します。

    表4-6 ODIのオプション

    オプション 説明

    ナレッジ・モジュールを必須更新で置換

    これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

    ODIのアップグレードを行わない場合は、『Oracle Data Integratorでの統合プロジェクトの開発』の互換性モードの使用に関する項を参照してください。

    トポロジおよびセキュリティ・メタデータのアップグレード

    これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

    手動でのアップグレード方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。

    高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

  6. スーパーバイザ・アカウント資格証明の指定

    「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

    インストールされているスーパーバイザ・アカウントはSUPERVISOR (すべて大文字)です。正しいアカウント名およびパスワードについては、ODI管理者に確認してください。ODIのマスター・リポジトリおよび作業リポジトリの作成時にリポジトリ作成ユーティリティで求められたときにSupervisorが指定されました。

    GUID-7CDFA583-C70D-4F84-B6CC-783B36C85619-default.gifの説明が続きます
    図GUID-7CDFA583-C70D-4F84-B6CC-783B36C85619-default.gifの説明

    注意:

    「スキーマ」画面でドメインで使用されるすべてのスキーマが選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。
  7. ODIアップグレード・キーの選択

    11gから12cへのアップグレードのみ。 「ODIアップグレード・キー」画面では、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換するための一意の識別子または アップグレード・キー を生成します。自動生成されたアップグレード・キーを使用するか、「アップグレード・キー」フィールドで独自のキーを指定することができます。

    推奨事項

    • 自動生成されたキーを編集して、覚えやすい意味のあるキーを指定します。

    • ODIオブジェクトがXMLファイルからインポートされるときに同じアップグレード・キーを指定できるように、アップグレード・キーを書き留めます。

    ODIオブジェクトは、ODIリポジトリ、ならびにこうしたリポジトリからエクスポートされたXMLファイルに存在し、リポジトリ間のメタデータ交換などで使用できます。そのため、同一オブジェクトの複数のコピーが異なるリポジトリおよびXMLファイルに含まれる場合があります。

    12cでは、ODIはオブジェクト識別に数字の内部IDではなくGUIDを使用します。アップグレード後にオブジェクトIDが保持されるようにするため、決定性アルゴリズムが適用され、既存のオブジェクトの内部IDからGUIDが計算されます(新規オブジェクトの場合、ODIにより無作為のGUIDが生成されます)。

    数字の内部IDが実際にはユニバーサルに一意ではなく、疑似的な一意性を実現するためにリポジトリIDに依存していたため、ODIではユーザーがアップグレード・キーを指定して、重複したGUIDが生成される可能性を下げることができます。アップグレード・キーが数字の内部IDとともにGUID生成アルゴリズムに提供され、GUIDが計算されます。

    このように異なるアップグレード・キーを選択することで、偶然同じ数字の内部IDを持つオブジェクトについて重複したGUIDを取得せずに済みます。ただし、同じオブジェクトの複数のコピーが(リポジトリ内に、またはXMLファイルにエクスポートされて)存在する場合、オブジェクトのすべてのコピーに対して同じGUIDが生成される必要があります。そのため、その特定のオブジェクトのコピーに関係するすべてのアップグレード操作に対して、同じアップグレード・キーを使用する必要があります。

    たとえば、11gリポジトリにIDとして1001を持つ製品があり、また同じリポジトリからエクスポートされたファイルに、同じプロジェクト(ID = 1001)が含まれるとします。この場合、リポジトリのアップグレードに使用されるアップグレード・キーは、アップグレード済の12cリポジトリにXMLファイルをインポートする際に使用されるアップグレード・キーと同じである必要があります。これによって、インポート・ファイルのプロジェクト・オブジェクトは、リポジトリのプロジェクト・オブジェクトと正しく一致します(いずれかのSYNONYMインポート・モードを使用した場合)。ただし、別のリポジトリで作成されたオブジェクトを含むソースから11g XMLエクスポート・ファイルが提供され、そのリポジトリの情報がない場合、偶然同じ内部ID (1001)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

  8. アップグレードの検証の完了

    「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

  9. アップグレードの開始と完了

    「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

  10. スキーマ・バージョンの確認

    スキーマがアップグレードされたことを確認するには、データベース・ホストからSQL*Plusを実行し、次のコマンドを使用します。

    select owner, version, status from schema_version_registry where owner = 'prefix_ODI_REPO';

    prefixを、RCUで作成されたリポジトリ・スキーマのカスタム接頭辞で置き換えます。次に、例を示します。

    select owner, version, status from schema_version_registry where owner = DEV1221_ODI_REPO
OWNER                          VERSION                        STATUS
------------------------------ ------------------------------ -----------
DEV1221_ODI_REPO               12.2.1.1.0                     VALID

    出力で、VERSION列においてスキーマ・バージョン番号が12.2.1.1.0であることを確認します。

4.6 再構成ウィザードを使用したドメインの再構成

スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

  • WLSコア・インフラストラクチャ

  • ドメイン・バージョン

注意:

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
具体的には、ドメインを再構成すると、次のようになります。

  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

  • すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

  • 起動スクリプトが更新されます。

注意:

ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしていることを確認してください。再構成ウィザードの実行中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般的な情報は、WebLogicドメインの再構成に関する項を参照してください。

4.6.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

  1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
    たとえば、C:\domains\mydomain to C:\domains\mydomain_backupにコピーします。
  2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。
  3. ドメインのバックアップしたバージョンが完全であることを確認します。
ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

4.6.2 再構成ウィザードの起動

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

  1. ドメインが存在するシステムにログインします。
  2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
  3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

    次のSQLコマンドを実行して、デフォルト・エディションを設定します。 

    ALTER DATABASE DEFAULT EDITION = edition_name;

    ここで、edition_nameは、子エディションの名前です。

  4. binディレクトリに移動します。

    UNIXオペレーティング・システムの場合:

    ORACLE_HOME/oracle_common/upgrade/bin

    Windowsオペレーティング・システムの場合:

    ORACLE_HOME\oracle_common\upgrade\bin
  5. 再構成ウィザードをロギング・オプションとともに起動します。

    UNIXオペレーティング・システムの場合:

    ./reconfig.sh -log=log_file -log_priority=ALL

    Windowsオペレーティング・システムの場合:

    reconfig.cmd -log=log_file -log_priority=ALL

    log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

    パラメータ -log_priority=ALLは、ログを詳細モードで出力します。

    注意:

    このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

    *sys-package-mgr*: can't create package cache dir

    環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

4.6.3 ODIドメインの再構成

再構成ウィザードの各画面で、必要なアクションを実行します。下の表に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

表4-7 再構成ウィザードの画面

再構成ウィザードの画面 説明および必要なアクション

ドメインの選択

既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードおよびJDK

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utility (RCU)はサービス表スキーマを自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。

JDBCコンポーネント・スキーマ

各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。

注意:

  • アップグレードしたスキーマに、11gスキーマの詳細を指定する必要があります。それ以外については、12c (12.2.1.1)スキーマの詳細を指定します。

  • このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として得られる構成は、「ノード・マネージャ・タイプ」と「ノード・マネージャ構成」に選択したオプションの組合せによって異なります。

ドメインごとおよびホストごとのノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルトの構成に関する項を参照してください。

拡張構成

この画面に表示されるカテゴリは、ドメインの構成中にドメインに選択したテンプレートで定義されているリソースによって異なります。

管理対象サーバー

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

サーバーのマシンへの割当て

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当て

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

4.7 JRFコンポーネントのアップグレード

WebLogicドメイン内のOracle Java Required Files (JRF)コンポーネントをアップグレードできます。

JRFは、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークの共通機能を提供するOracle WebLogic Serverインストールに含まれていないコンポーネントで構成されています。

WebLogicドメイン内のいずれかのJRFコンポーネントを更新する必要がある場合は、再構成ウィザードの後にアップグレード・アシスタントを再度実行します。

4.7.1 Upgrade Assistantの起動

アップグレード・アシスタントを再度実行して、コンポーネント構成を12cにアップグレードします。

アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

4.7.2 アップグレード・アシスタントを使用したWebLogicドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントを起動した後、各画面を移動してWebLogicドメイン・コンポーネント構成をアップグレードできます。

  1. アップグレード・アシスタントの導入

    「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

  2. アップグレード操作の選択

    管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」を選択します。求められたら、ドメインを管理しているWebLogic Administration Serverに接続するために必要な接続詳細を入力します。

    GUID-316648C4-6C86-43C8-A267-49128EE233BD-default.gifの説明が続きます
    GUID-316648C4-6C86-43C8-A267-49128EE233BD-default.gifの説明

    ヒント:

    この画面の詳細は、『Upgrade Assistantによるアップグレード』のWebLogicコンポーネント構成に関する項を参照してください。

  3. アップグレード対象のコンポーネントの確認

    「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。

  4. 前提条件の検証

    「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。

    続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

  5. アップグレードの検証の完了

    「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

    ヒント:

    この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

  6. アップグレードの開始と完了

    「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

4.8 アップグレードの実行および確認

アップグレード手順がすべて完了したら、アップグレードが成功したことを確認します。

次のタスクを実行します。

4.8.1 ノード・マネージャの構成および起動

ノード・マネージャを構成および起動するには、次を参照してください。

  • 『Oracle WebLogic Serverのアップグレード』のノード・マネージャ構成の完了に関する項。

  • 『Oracle Fusion Middlewareの管理』のノード・マネージャの起動と停止に関する項。

4.8.2 管理サーバーの再起動

詳細は、『Oracle Fusion Middlewareの管理』の管理サーバーの起動と停止に関する項を参照してください。

  • 管理コンソールのURL:

    http://administration_server_host:administration_server_port/console

  • Fusion Middleware Control:

    http://administration_server_host:administration_server_port/em

注意:

アップグレード後に、11g Oracleホームではなく、新しい12c Oracleホームから管理ツールを実行する必要があります。

4.8.3 管理対象サーバーの起動

ドメイン内の管理対象サーバーを起動するには、『Oracle Data Integratorのインストールと構成』の管理対象サーバーの起動に関する項を参照してください。

前
前 		次
次
目次へ移動
目次