9 Enterprise Data Qualityのアップグレード

Enterprise Data Quality 12c (12.2.1.4.0)を14c (14.1.2.0.0)にアップグレードできます。

ノート:

Oracle Fusion Middleware 14c (14.1.2.0.0)へのアップグレードの準備のための追加のガイドラインについては、『Oracle Fusion Middlewareのアップグレードのプランニング』を参照してください。

Enterprise Data Quality (EDQ)から14c (14.1.2.0.0)へのアップグレードの概要

開始する前に、概要の情報をすべて確認して、Enterprise Data Quality 14c (14.1.2.0.0)の標準アップグレード・トポロジおよびアップグレード・パスを理解します。

このガイドのアップグレード手順では、既存のEnterprise Data Quality 12c (12.2.1.4)ドメインをOracle Fusion Middleware 14c (14.1.2.0.0)にアップグレードする方法を説明しています。アップグレードが必要なその他のコンポーネントがドメインに含まれる場合に備えて、サポート・ドキュメントへのリンクが提供されています。

ノート:

Fusion Middlewareのアップグレードのプランニングに関する一般情報と、アップグレードのその他の概念およびリソースについては、『Oracle Fusion Middlewareのアップグレードのプランニング』を参照してください。

次のトピックでは、Enterprise Data Quality EDQのアップグレードに関する概念について説明します。

アップグレード前の要件

Enterprise Data Quality 14c (14.1.2.0.0)のアップグレードを開始する前に、次のタスクを実行する必要があります。

ノート:

アップグレードを開始する前に、Oracle Fusion Middleware Upgrade Planningのロードマップを確認してください。

既存の12c (12.2.1.4.0)構成によっては、アップグレードを開始する前に追加のタスクを実行する必要がある場合があります。

Oracle Textを使用するためのCase Managementスキーマの変換

EDQ Case Managementを使用しており、データ量とアラートが多い場合は、バージョン14c (14.1.2.0.0)へのEDQの完全アップグレードに進む前に、これらのステップの一部またはすべてを実行して機能をテストできます。

Oracleテキストへの移行がすでに実行されている場合、移行はno-opである必要がありますが、この場合、索引に正しい名前があるのを確認することが重要です。移行スクリプトは名前で索引をチェックし、別の名前で索引がすでに存在する場合は、スクリプトによって索引の再作成が試行され、これは失敗します。

注意: 大量のケースおよびアラートが含まれている場合、移行にはかなり時間がかかることもあります。標準アップグレード・プロセスの前に、いくつかのステップを実行できます。

次のステップはすべて移行前に実行でき、既存のシステムでテストできます。14c (14.1.2.0.0)にアップグレードする前に、まずOracleテキストへの完全な変換を実行し、結果をテストできます。
  • 添付のLONG_RAWからBLOBへの変換
  • 補足データLONG_RAWからBLOBへの変換
  • JSON列の移入

ノート:

移行を開始する前に、EDQ構成スキーマ・ユーザーには、CTXAPPロールおよびCREATE ANY JOBシステム権限が必要です。FMWアップグレード・アシスタントを使用して移行を実行する場合、これは自動的に処理されます。migration.jarツールを使用して手動で移行を実行する場合は、移行を実行する前に、ロールと権限をユーザーに追加する必要があります。スクリプトによって、ユーザーが存在することが確認されます。

  1. 添付データ列をLONG RAWからBLOBに変換します。

    ケース管理の添付データは、DN_ATTACHMENT表のATTACHMENT_BINARY列に格納されます。12.2.1.4.0 以前では、この列はLONG RAWとして作成されていました。移行プロセスでは、次のSQLを使用してこの列がBLOBに変換されます。
    ALTER TABLE dn_attachment MODIFY (attachment_binary BLOB);

    変換後には表の索引が無効になり、各索引は次のように再構築されます。

    ALTER INDEX xname REBUILD ONLINE;

    完全なプロセスは、このスクリプトを使用して実行されます。内部EDQ JDBCの簡易スクリプト言語を使用して記述されているスクリプトです。

    
    \if oracle
      \if count('user_tab_columns', "table_name = 'DN_ATTACHMENT' and COLUMN_NAME = 'ATTACHMENT_BINARY' and DATA_TYPE = 'LONG RAW'") > 0
     
        \message ++ Converting dn_attachment attachment_binary column to BLOB
        ALTER TABLE dn_attachment MODIFY (attachment_binary BLOB);
     
        -- rebuild indexes
     
        \set rs = select("SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'DN_ATTACHMENT' AND INDEX_TYPE = 'NORMAL'")
     
        \while rs -> next()
          \set xname = rs -> getString("INDEX_NAME")
          \print '++ Rebuilding index ' || xname
          ALTER INDEX ${xname} REBUILD ONLINE;
        \done   
     
      \else
        \message -- dn_supplementarydata the_data column does not need converting
      \fi
    \fi

    ノート:

    移行プロセスの実行に長時間かかるのを回避するために、この変換はアップグレード前に実行およびテストできます。既存の12.2.1.4.xは、列が変換済の場合でも問題なく機能します。これを行う場合、重大なパフォーマンスの問題を回避するために、表索引を前述のように再構築することが重要です。

  2. 廃止された索引を削除します。

    12.2.1.4.xでは、ケース管理表には、Lucene索引付けプロセスのパフォーマンスを向上させるために使用される索引があります。14c (14.1.2.0.0)ではLuceneが削除されたため、これらの索引は不要になりました。索引の削除に使用されるSQLは次のとおりです。

    ALTER TABLE dn_case DISABLE CONSTRAINT pk_dn_case; 
    DROP INDEX idx_dn_case_indl;
    ALTER TABLE dn_case ENABLE CONSTRAINT pk_dn_case;
    DROP INDEX idx_dn_case_indexed;
    DROP INDEX idx_dn_casecomment_ind;
    DROP INDEX idx_dn_casehistory_ind;
    DROP INDEX idx_dn_casetrans_ind;
    DROP INDEX idx_dn_supplementarydata2;

    いずれの場合も、DROPは索引が存在する場合にのみ実行されます。

  3. 新しい索引を作成します。

    SQLケース管理フィルタのパフォーマンスを向上させるために、新しい索引が作成されます。次のSQLが使用されます。
    CREATE INDEX idx_dn_case_permission ON dn_case(permission);
    CREATE INDEX idx_comment_cid ON dn_casecomment(case_id);
    CREATE INDEX idx_comment_del ON dn_casecomment(deleted_flag);

    いずれの場合も、同じ名前の索引がすでに存在する場合、CREATEは実行されません。Oracleテキストへの変換がすでに実行されている場合は、既存の索引の名前がここに示されていることが重要です。

  4. 補足データ列をLONG RAWからBLOBに変換します。

    ケース管理ソース・データは、DN_SUPPLEMENTARYDATA表のTHE_DATA列に格納されます。12.2.1.4.0 以前では、この列はLONG RAWとして作成されていました。移行プロセスでは、次のSQLを使用してこの列がBLOBに変換されます。

    ALTER TABLE dn_supplementarydata MODIFY (the_data BLOB);
    変換後には表の索引が無効になり、各索引は次のように再構築されます。
    ALTER INDEX xname REBUILD ONLINE;

    完全なプロセスは、このスクリプトを使用して実行されます。内部EDQ JDBCの簡易スクリプト言語を使用して記述されているスクリプトです。

    \if oracle
      \if count('user_tab_columns', "table_name = 'DN_SUPPLEMENTARYDATA' and COLUMN_NAME = 'THE_DATA' and DATA_TYPE = 'LONG RAW'") > 0
     
        \message ++ Converting dn_supplementarydata the_data column to BLOB
        ALTER TABLE dn_supplementarydata MODIFY (the_data BLOB);
     
        -- rebuild indexes
     
        \set rs = select("SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'DN_SUPPLEMENTARYDATA' AND INDEX_TYPE = 'NORMAL'")
     
        \while rs -> next()
          \set xname = rs -> getString("INDEX_NAME")
          \print '++ Rebuilding index ' || xname
          ALTER INDEX ${xname} REBUILD ONLINE;
        \done   
     
      \else
        \message -- dn_supplementarydata the_data column does not need converting
      \fi
    \fi

    ノート:

    移行プロセスの実行に長時間かかるのを回避するために、この変換はアップグレード前に実行およびテストできます。既存の12.2.1.4.xは、列が変換済の場合でも問題なく機能します。これを行う場合、後のJSON移入ステップで重大なパフォーマンスの問題を回避するために、表索引を前述のように再構築することが重要です。

  5. 補足データ表にJSON列を追加します。

    ソース・データ・フィルタは、DN_SUPPLEMENTARYDATA表のJSONという名前の列に格納されているJSON配列でOracleテキスト述語を使用します。このステップで、列を表に追加します。Oracleテキストへの変換がすでに実行されている場合、列は追加されず、この後のJSON移入ステップは実行されません。このSQLは次のように使用されます。

    ALTER TABLE dn_supplementarydata ADD json BLOB CONSTRAINT jcheck CHECK (json IS JSON);
  6. Oracleテキスト・サポート・オブジェクトを作成します。

    Oracle CTXオブジェクトは、テキスト索引で使用する目的で作成されます。DN_TEXTPPREFプリファレンスがすでに存在する場合、このステップは実行されません。そのため、Oracleテキストへの変換がすでに実行されている場合は、ここで何も実行されません。このSQLは次のように使用されます。

    BEGIN
      CTX_DDL.create_preference('dn_textpref', 'BASIC_LEXER');
      CTX_DDL.create_stoplist('dn_textstop', 'BASIC_STOPLIST');
      CTX_DDL.create_preference('dn_wordlist', 'BASIC_WORDLIST'); 
      CTX_DDL.set_attribute('dn_wordlist', 'PREFIX_INDEX', 'TRUE');
      CTX_DDL.set_attribute('dn_wordlist', 'PREFIX_MAX_LENGTH', '3');
    END;

    いずれかのプリファレンスをチューニングする場合は、移行プロセスを実行する前に、このSQLを変更して実行できます。

  7. Oracleテキスト索引を作成します。

    テキスト索引は、ケース・キー、説明およびコメント文字列に対するフリーテキスト検索を可能にするために作成され、ソース・データ検索をサポートするためにJSON索引が作成されます。次のSQLが使用されます。

    CREATE INDEX dn_case_key_text ON dn_case(key_label)           
      INDEXTYPE IS CTXSYS.CONTEXT
      PARAMETERS('sync (every "freq=secondly;interval=20") lexer dn_textpref stoplist dn_textstop wordlist dn_wordlist');
    
    CREATE INDEX dn_case_desc_text ON dn_case(description)
      INDEXTYPE IS CTXSYS.CONTEXT
      PARAMETERS('sync (every "freq=secondly;interval=20") lexer dn_textpref stoplist dn_textstop wordlist dn_wordlist');
    
    
    CREATE INDEX dn_casecomment_text ON dn_casecomment(case_comment)
      INDEXTYPE IS CTXSYS.CONTEXT
      PARAMETERS('sync (every "freq=secondly;interval=20") lexer dn_textpref stoplist dn_textstop wordlist dn_wordlist');
    
    CREATE SEARCH INDEX dn_supp_json ON ${dn_supplementarydata} (json) FOR JSON
      PARAMETERS('sync (every "freq=secondly;interval=20") wordlist dn_wordlist memory 1g');

    いずれの場合も、同じ名前の索引がすでに存在する場合、CREATEは実行されません。Oracleテキストへの変換がすでに実行されている場合は、既存の索引の名前がここに示されていることが重要です。

    ノート:

    JSON索引パラメータのmemory 1g句を使用すると、索引の作成に使用されるメモリーが増え、移入された索引の断片化レベルが大幅に低下します。データベースに使用可能なメモリーが限られている場合、この設定を減らすことができます。

  8. DN_LUCENEX8表を削除します。

    DN_LUCENEX8表は、Lucene索引ファイルをクラスタ環境に格納するため使用されていました。この表は、14.1.2.0.0では使用されません。

    DROP TABLE dn_lucenex8 PURGE;
  9. 補足データ表にJSON列を移入します。

    ステップ5でDN_SUPPLEMENTARYDATAにJSON列を追加した場合は、変換ツールを使用して既存のレコードに列が移入されます。大量な場合、この処理には数時間かかることがあります。標準移行ステップ外で変換を実行する場合は、移行の前にJSON列を追加し、後から変換を実行できます。sdjsonツールをデータベース・ホストで実行すると、変換パフォーマンスが向上してネットワーク・ラウンドトリップが減少します。

    変換を手動で実行するには、EDQに付属しているsdjson.jarツールを使用します。
    $ java -jar sdjson.jar oracle:#service@HOST:PORT/USER/PW

12c (12.2.1.4.0)から14.1.2.0.0へのアップグレード

プラットフォームとしてOracleデータベースおよびWebLogicアプリケーション・サーバーを使用するEDQ 14.1.2.0.0のインストールから、EDQ 14.1.2.0.0にアップグレードするプロセスは、基本的に2つのパートで構成されます。

パート1: EDQ 14.1.2.0.0の部分インストールの実行

部分インストールを実行するには:

  1. 「サポートされているプラットフォームおよびコンポーネントのバージョン」の説明に従って、EDQ 14.1.2.0.0システム要件をすべて満たす環境であることを確認し、必要に応じて環境をアップグレードします。

  2. 「EDQのダウンロード」の説明に従い、EDQ 14.1.2.0.0をダウンロードします。

  3. Fusion Middleware Infrastructureリリース14.1.2.0.0をダウンロードします。

    ノート:

    12.2.1.4.0 リリースのEDQをサポートするために使用したOracle Fusion Middleware Infrastructureは、新しいリリースのEDQをサポートしません。そのため、他の目的のために14.1.2.0.0リリースのOracle Fusion Middleware Infrastructureをすでにインストールしている場合を除いて、今すぐダウンロードする必要があります。

  4. 環境の現在のJava Development KitがEDQ 14.1.2.0.0をサポートしていない場合、「EDQをサポートするJava Development Kitのインストール」の説明に従って、サポートされているJava Development Kitをインストールします。

  5. 環境の現在のOracle Fusion Middleware InfrastructureがEDQ 14.1.2.0.0をサポートしていない場合、「Oracle Fusion Middleware Infrastructureのインストール(Oracle WebLogic Serverを含む)」の説明に従って14c (14.1.2.0.0)をインストールします。

    ノート:

    新しいリリースのFusion Middleware Infrastructureは、古いリリースと異なるFusion Middlewareホームにインストールする必要があります。

  6. 環境の現在のOracle DatabaseがEDQ 14.1.2.0.0をサポートしていない場合、Oracle Databaseをサポートされているリリースにアップグレードします。

  7. 「Enterprise Data Qualityのインストール」の説明に従って、Enterprise Data Quality 14.1.2.0.0アセットをインストールし、新しいFusion Middleware InfrastructureのFusion MiddlewareホームにEDQがインストールされていることを確認します。このステップには、Oracle Fusion Middleware EDQディストリビューションのインストールが含まれます。通常、これはfmw_14.1.2.0.0_edq.jarのような名前の単一のファイルを含む.zipファイルとしてダウンロードされます。この.jarファイルを実行すると、Oracle Universal Installerが起動します。後のステージで再構成ウィザードを使用してWebLogicドメインをアップグレードするため、今すぐWebLogicドメインを構成または拡張する必要はありません。

    ノート:

    このステップでは、環境のFusion Middlewareホームの場所にEnterprise Data Qualityの要素を配置します。これらの一部は後のインストール・プロセスで使用されます。ただし、このステージでEDQ環境は動作しません。

パート2: 12c (12.2.1.4.0) EDQ環境のアップグレード

14c (14.1.2.0.0) EDQ環境にアップグレードする前に、次のいくつかの考慮事項があります。

  • 高可用性のために構成されるEDQインスタンスをアップグレードする場合:

    同じWebLogicクラスタ内の複数のWebLogic管理対象サーバーを構成して、高可用性のためにEnterprise Data Quality 14c (14.1.2.0.0)を有効化できます。

    EDQ 12.2.1.4.0では、高可用性用の構成が単純化されました。クラスタのすべてのWebLogic管理対象サーバーで、同じデータベース・リポジトリを共有できます。つまり、構成および結果データソースの1つのペアのみが必要で、クラスタのすべてのWebLogic管理対象サーバーで同じベースおよびローカル構成ディレクトリを共有できます。

    高可用性のために構成されるEDQ 12.2.1.4.0 to 14c (14.1.2.0.0)のインスタンスをアップグレードする場合、構成を変更して高可用性への単純化された方法を利用することをお薦めします。そのためには、次のタスクを実行します。
    • アップグレード・アシスタントを使用して、1つのデータベース・リポジトリのみ(つまり、構成および結果スキーマの1つのペアのみ)をアップグレードします。

    • Oracle Fusion Middleware再構成ウィザードを1回実行して、アップグレードしたデータベース・リポジトリの接続詳細を提供します。「拡張オプション」画面でウィザードを実行する場合、「管理対象サーバー、クラスタおよびCoherence」オプションを選択していることを確認し、リリース14c (14.1.2.0.0)のEDQ高可用性ガイドを参照して、新しい単純化されたアーキテクチャを使用して高可用性のためのアップグレードしたEDQインスタンスを構成します。

    • 'startup arguments'や'Java options'を含むすべてのWebLogic管理対象サーバーのサーバー・パラメータが同じベースおよびローカル構成ディレクトリを指すよう構成されていることを確認します。

  • また、引き続き複数のスキーマおよび構成領域を使用して、アップグレード後に既存の高可用性の構成を維持できます。これを実行するには:

    • 各ペアの構成および結果スキーマに対して、個別にアップグレード・アシスタントを実行します。

    • director.propertiesファイルでcoherence.clustering = falseを設定して、Coherenceを無効化します。

アップグレード・プロセスを開始するには:
  1. 古いEDQ環境をバックアップします。

    開始する前に、EDQドメインを含む、古いEDQ環境の完全バックアップを作成することをお薦めします。

  2. WebLogic Server管理サーバーとすべての管理対象サーバーを停止します。

  3. アップグレード・アシスタントを起動して、EDQリポジトリ・データベース内のEDQCONFIG (構成)、EDQRESULTS (結果)、EDQSTAGING (ステージング)スキーマと、OPSS、IAUおよびSTBスキーマをアップグレードします。

    1. 次のディレクトリに移動します。ここで、14.1.2.0.0_FMW_HOMEはバージョン14.1.2.0.0のOracleホーム・ディレクトリです。

      UNIXの場合:

      14.1.2.0.0_FMW_HOME/oracle_common/upgrade/bin

      Windowsの場合:

      14.1.2.0.0_FMW_HOME\oracle_common\upgrade\bin

    2. 次のプログラムを実行します。

      LinuxまたはUNIXの場合:

      ./ua

      Windowsの場合:

      ua.bat

  4. 「ようこそ」画面で、先に進む前に重要な注意事項を確認します。「ようこそ」画面には、アップグレードに進む前に考慮する注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。画面の詳細は、「ヘルプ」をクリックしてください。それ以外の場合は、「次へ」をクリックします。

  5. アップグレードのタイプ、「ドメインで使用されるすべてのスキーマ」オプションの順に選択します。「ドメイン・ディレクトリ」フィールドで、古いEDQ環境のドメイン・ディレクトリ(これは/OLD_FMW_HOME/user_projects/domains/edq_domainと似ています)を選択します。「次へ」をクリックします

  6. 「コンポーネント・リスト」画面には、古いEDQ環境のドメインのアップグレードするコンポーネント(つまり、スキーマ)のリストが表示されます。次のコンポーネントがリストされます。
    • Oracle Enterprise Data Quality結果

    • Oracle Audit Services

    • Oracle Platform Security Services

    • Common Infrastructure Services

    • Oracle Enterprise Data Quality構成

    コンポーネントを選択し、「次へ」をクリックします。

  7. 「前提条件」画面で、前提条件を満たしていることを確認し、満たされている場合は関連するボックスを選択します。Upgrade Assistantは前提条件が満たされていることを確認しないことに注意してください。「次」をクリックします。

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

    1. EDQ結果スキーマ、IAU、OPSS、STBおよびEDQ構成スキーマ画面が連続して表示されます。

    2. 最初の画面で、EDQ結果(EDQRESULTS)スキーマを含むデータベースの接続詳細を指定してから、「接続」をクリックします。次に、スキーマ・ユーザーのパスワードを求められます。

    3. 残りの画面には、EDQ結果スキーマ画面で指定したデータベース接続とスキーマ資格証明が自動的に移入されます。いずれかのスキーマでこれらのエントリが正しくない場合、エントリを変更して、データベース接続が確立されるのを確認します。

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

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

  11. EDQドメインを再構成します。このステップでは、Oracle Fusion Middleware再構成ウィザードを実行して、WebLogic Serverドメイン環境のアップグレードを完了します。

  12. 次のステップを実行して、ステージング・モードが「nostage」に設定されていることを確認します。
    1. 任意のWebブラウザからWebLogicリモート・コンソールにログインします。

    2. 左側のペインで、「環境」を開き、「サーバー」をクリックします。「サーバーのサマリー」画面が表示されます。

    3. 「サーバーのサマリー」画面で、EDQ WebLogic管理対象サーバー(edq_server1など)をクリックします。

    4. 「構成」タブ、「デプロイメント」タブの順に選択します。

    5. 「ステージング・モード」メニューから、「nostage」が選択されていることを確認し、選択されていない場合は選択します。その他のサーバーの設定を変更しないでください。

    6. 「保存」をクリックします

  13. ノード・マネージャを停止します。

    1. ノード・マネージャがまだ実行されておらず、前述のコマンドを使用して起動した場合、実行しているコマンド・シェルを閉じて停止します。

    2. ノード・マネージャがすでに実行されている場合(たとえば、環境でのサービスとしてすでに実行されている場合など)、適切な方法を使用して停止します(たとえば、ノード・マネージャ・サービスの停止など)。

  14. 再構成ウィザードを起動してEDQドメインを再構成します。

    1. 次のディレクトリに移動します。ここで、14.1.2.0.0_FMW_HOMEはバージョン14c (14.1.2.0.0)のOracleホーム・ディレクトリです。

      Windowsの場合:

      14.1.2.0.0_FMW_HOME\oracle_common\common\bin

      UNIXの場合:

      14.1.2.0.0_FMW_HOME/oracle_common/common/bin

    2. ドメインの再構成ウィザードを開始します。

      Windowsの場合:

      reconfig.cmd -log=log_file

      UNIXの場合:

      ./reconfig.sh -log=log_file

  15. log_fileに完全パスおよびファイル名を指定します。ログ・ファイルの作成は、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

    ノート:

    次のエラー・メッセージが表示される場合、デフォルトのキャッシュ・ディレクトリが有効ではないことを示します。

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

    環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。たとえば、次のようになります。

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

  16. ドメインを指定します。「ドメインの選択」画面で、12.2.1.4.0 EDQドメインの場所への完全パスを指定します(FMW_HOME/user_projects/domains/edq_domainまたはFMW_HOME\user_projects\domains\edq_domainに似ています)。また、「参照」をクリックし、ファイル・マネージャのウィンドウを使用してドメインの場所を選択できます。

  17. 再構成セットアップの進行状況を表示します。

    「再構成セットアップの進行状況」は再構成の進行状況を表示し、選択したベース・ドメインを再構成できるかどうかを検証します。「コアWLSインフラストラクチャの再構成に成功しました。」というメッセージは、ドメインが14.1.2.0.0ドメインに再構成できることを示し、「次へ」をクリックして次のステップに進むことができます。このメッセージが戻されない場合、ドメインは14.1.2.0.0ドメインに再構成できません。これが発生する場合、EDQバージョンがバージョン12c (12.2.1.4.0)以前かどうかを確認します。そうである場合、最初にEDQ 12cにアップグレードし、次にバージョン14.1.2.0.0にアップグレードする必要があります。

  18. ドメイン・モードおよびJDKを選択します。ドメイン・モードを開発から本番または本番から開発に変更できません。

    ドメイン・モードとJDK画面で、新しいEDQドメインで使用するJava Development Kit (JDK)の場所を指定します。これは、新しいEDQ環境のシステム要件に準拠するJDKである必要があります。特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成を参照してください。

    ノート:

    このステージでは、「ドメイン・モード」を変更することはできません。ドメインは、アップグレード前のドメイン・モードを保持します。
  19. データベース構成タイプを選択します。

    1. 「データベース構成タイプ」画面で、デフォルトで「RCUデータ」オプションを選択する必要があります。EDQリポジトリ・データベースの接続詳細は自動的に移入されます。共通インフラストラクチャ・スキーマ(STB)のスキーマ所有者およびパスワードが表示されます。この情報が自動的に移入されない場合または正しくない場合、必要な修正を行います。

    2. 「RCU構成の取得」をクリックします。再構成ウィザードにより、データベース・サーバーに接続可能でスキーマ・データを取得してローカルのスキーマ・コンポーネントを取得したデータにバインドできることがレポートされます。これらのステップに失敗した場合、接続データを修正して、RCU構成の再取得をクリックします。それ以外の場合は、「次へ」をクリックします。

  20. JDBCコンポーネント・スキーマを選択します。「JDBCコンポーネント・スキーマ」画面で、古いEDQドメインに関連付けられているスキーマが画面の下半分に表示されます。変更する必要がある場合は、データ・ソース各の横のチェック・ボックスを選択してから、変更します。

    ノート:

    前述のステップ5のリポジトリ作成ユーティリティを使用して作成したEDQステージング・スキーマの正しい接続詳細が表示されない場合があります。そうでない場合、正しくなるように修正します。
  21. JDBCコンポーネント・スキーマをテストします。「JDBCコンポーネント・スキーマ・テスト」画面で、検出されたデータ・ソース接続をテストします。テストするスキーマを選択し、「選択された接続のテスト」をクリックします。

    ノート:

    接続をテストするには、接続中のデータベースが実行している必要があります。
  22. オプションの拡張構成オプションを選択して、追加のドメイン・オプションを選択します。

    1. 管理対象サーバー構成を変更するには、「管理対象サーバー、クラスタおよびCoherence」を選択します。オプションの詳細は、「ヘルプ」ボタンをクリックしてください。

    2. 変更をスキップするには、「次へ」をクリックします。

  23. ドメインの再構成を開始します。「構成のサマリー」画面で、構成を確認してから、再構成プロセスを開始するには「再構成」をクリックし、変更するには「戻る」をクリックします。

  24. 再構成を完了します。「ドメイン再構成が正常に適用されました。」ことを示すメッセージが表示されるまで待機してから、「次へ」をクリックします。

    チェックマークとOracle WebLogic Serverの再構成に成功しましたというメッセージにより、再構成が成功したことが示されます。「次へ」「終了」の順にクリックして再構成ウィザードを閉じます。

  25. 次の手順に従ってアップグレード・アシスタントを起動し、EDQのドメイン構成をアップグレードします。

    1. 次のディレクトリに移動します。ここで、14.1.2.0.0_FMW_HOMEはバージョン14c (14.1.2.0.0)のOracleホーム・ディレクトリです。

      Windowsの場合:

      14.1.2.0.0_FMW_HOME\oracle_common\upgrade\bin

      UNIXの場合:

      14.1.2.0.0_FMW_HOME/oracle_common/upgrade/bin

    2. 次のプログラムを実行します。

      LinuxまたはUNIXの場合:

      ./ua

      Windowsの場合:

      ua.bat

    3. 「ようこそ」画面で、先に進む前に重要な注意事項を確認します。「ようこそ」画面には、アップグレードに進む前に考慮する注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。画面の詳細は、「ヘルプ」をクリックしてください。それ以外の場合は、「次へ」をクリックします。

    4. 「選択したスキーマ」画面で、「ドメインによって使用されるすべての構成」を選択します。この時点で、画面の名前が「すべての構成」に変更されます。「ドメイン・ディレクトリ」フィールドで、古いEDQ環境のドメイン・ディレクトリ(これは/OLD_FMW_HOME/user_projects/domains/edq_domainと似ています)を選択して、「次へ」をクリックします。

    5. 「コンポーネント・リスト」画面で、アップグレードするコンポーネントのリスト(Oracle JRF、System Components InfrastructureおよびOracle Enterprise Data Quality Configurationから構成)を確認して、「次へ」をクリックします。

    6. 「前提条件」画面で、前提条件を満たしていることを確認し、満たしている場合は関連するボックスを選択します(アップグレード・アシスタントは前提条件が満たされていることを確認しないことに注意してください)。次に、「次」をクリックします。

    7. 「調査」画面では、アップグレード・アシスタントにより、アップグレード不要またはそれぞれ成功のステータスが戻され、コンポーネントをアップグレード可能であることが検証されます。調査が完了したら、「次へ」をクリックします。

    8. 「アップグレード・サマリー」画面で、「アップグレード」をクリックします。

    9. 「アップグレードの進行状況」画面で、アップグレードが完了するまで待機し、「次」をクリックします。

    10. 「アップグレード成功」画面で「閉じる」をクリックします。

  26. 次のステップを使用して、ベース・ドメインへのアップグレード変更を適用します。

    1. アップグレードしたEDQドメインのWebLogicノード・マネージャを起動します。

    2. アップグレードしたEDQドメインからWebLogic Server管理サーバーを起動します。実行中の場合、停止してから再起動します。

      Windowsの場合:

      DOMAIN_HOME\bin\startWebLogic.cmd

      UNIXの場合:

      DOMAIN_HOME/bin/startWebLogic.sh

    3. WebブラウザからWebLogic Server管理サーバー・コンソールにログインします。

    4. 「ドメイン構造」リストで、「デプロイメント」をクリックします。

    5. 「デプロイ」の下で、edqを選択してから、「更新」をクリックします。

    6. 「次」をクリックします。

    7. 「終了」をクリックします。

    8. アップグレードを完了するには、EDQ管理対象サーバーを起動します。

      ノート:

      startManagedWebLogic.shスクリプトは、EDQ WebLogicドメインのbinディレクトリにあります。このスクリプトの実行は、EDQ WebLogic管理対象サーバーを起動する方法の1つです。EDQ WebLogicドメインを再構成すると、startManagedWebLogic.shスクリプトが上書きされる可能性があります。そのため、スクリプトをカスタマイズした場合、アップグレード・プロセス中にカスタマイズが失われる可能性があります。これは、このスクリプト内にEDQのサーバー・パラメータ(つまり、'startup arguments'または'Java options')を組み込んだ場合に注意する特に重要な点です。これらがないと、EDQ管理対象サーバーは正しく動作しません。

  27. Webブラウザを開き、アップグレードしたEDQ環境のLaunchpadに移動します。EDQのインストール時にデフォルトのオプションを変更しないかぎり、アドレスはhttp://<your-server-name>:8001/edqです。

  28. Launchpadから、ディレクタ・ユーザー・インタフェースを開き、EDQのバージョンを確認してバージョンがアップグレードされていることを確認します。ディレクタのメニューから、「ヘルプ」「情報」オプションの順にクリックして、バージョンを確認します。

  29. すべてのプロジェクトが正常に移行されていることを確認します。

    ノート:

    正しくアップグレードしたシステムで、Oracleなどのデータ・ストアのパスワードを指定する必要はありません。パスワードを再指定しないことを確認するために追加の設定を行う必要はありません。
  30. プロセスで一致レビューを使用する場合、一致レビューにアクセスする前にインテリジェント実行をオフにしてこれら(またはそれらが一部であるジョブ)を実行する必要があります。ジョブまたはプロセスの「実行プリファレンス」のインテリジェント実行をオフにできます。