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

前
次

3 Oracle Data Integratorスタンドアロン・エージェント環境(WebLogicドメインなし)の11gからのアップグレード

WebLogicドメインに登録されていないOracle Data Integratorスタントアロン・エージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.1)にアップグレードできます。

次のアップグレード・シナリオについて説明します。

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

3.1 Oracle Data Integratorスタンドアロン・エージェント(WebLogicドメインなし)のアップグレード・プロセスの理解

WebLogicドメインに登録されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すプロセス・フローチャートを確認します。

図3-1 ODIスタンドアロン・エージェント(WebLogicドメインなし)のアップグレード・プロセス・フローチャート

図3-1の説明が続きます
「図3-1 ODIスタンドアロン・エージェント(WebLogicドメインなし)のアップグレード・プロセス・フローチャート」の説明

この章の残りの各項では、WebLogicドメインに登録されていないOracle Data Integratorスタンドアロン・エージェントのアップグレードに固有の手順について説明します。

3.2 Oracle Data Integratorスタンドアロン環境(WebLogicドメインなし)のインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、WebLogicドメインに登録されていないOracle Data Integratorスタンドアロン・エージェントの12cバージョンをインストールします。

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

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

    この項では、12cの重要な概念の一部を説明し、必要な製品ディストリビューションの入手場所に関する情報も提供します。

  2. 「Oracle Data Integratorのインストール」では、Oracle Data Integratorスタンドアロン・エージェント環境をインストールします。

    注意:

    構成ウィザードで新規のOracle Data Integratorインストールを構成しないでください。アップグレード中にアップグレード・アシスタントでスタンドアロン・エージェント環境の構成が行われます。

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

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

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

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

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

注意:

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

3.3.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

3.3.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オプション」画面で、すべてのオプションを選択します。

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

    表3-1 ODIのオプション

    オプション 説明

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

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

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

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

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

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

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

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

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

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

    注意:

    「スキーマ」画面でドメインで使用されるすべてのスキーマが選択されている場合、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であることを確認します。

3.4 スタンドアロン・エージェント環境(WebLogicドメインなし)のアップグレード

リポジトリ・スキーマをアップグレードした後、スタンドアロン・エージェント(WebLogicドメインなし)環境でスタンドアロン・システム・コンポーネント構成をアップグレードできます。

3.4.1 Upgrade Assistantの起動

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

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

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

./ua

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

ua.bat

3.4.2 アップグレード・アシスタントを使用したスタンドアロン・システム・コンポーネント構成のアップグレード

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

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

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

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

    12cより、スタンドアロン・システム・コンポーネントには、独自のスタンドアロン・ドメインがそれぞれ作成されます。11gスタンドアロン・システム・コンポーネント(以前にドメインの関連付けをしていない)をアップグレードする場合、最初にシステム・コンポーネントに新規スタンドアロン・ドメインを作成する必要があります。

    「スタンドアロン・コンポーネント」画面で、「スタンドアロン・システム・コンポーネント構成」を選択し、次に「新規ドメインの作成」を選択します。

    「ドメイン・ディレクトリ」フィールドで、作成するドメインのフルパスを指定します。ドメイン・ホームがOracleホーム・ディレクトリの外部にある場合、「推奨されるディレクトリ構造の理解」に要約されているディレクトリ構造に従って、ドメイン・ホームを配置することをお薦めします。このディレクトリ構造は、ソフトウェアのアップグレードや再インストールが必要になったときに問題を回避するために役立ちます。

    ヒント:

    「既存のドメインの更新」オプションは、別のシステム・コンポーネントのアップグレードまたは以前の部分的なOracle Data Integratorアップグレードのいずれかにより、アップグレードがすでに実行され、ドメインが作成されている場合に使用できます。このような場合、新規ドメインの作成が不要となります。

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

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

    • システム・コンポーネント・インフラストラクチャ

    • Oracle Data Integrator

  4. 前提条件の検証

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

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

  5. インスタンス・ディレクトリの指定

    「インスタンス・ディレクトリ」画面で、アップグレード対象となる1つ以上のOracleインスタンス・ディレクトリの場所を指定します。

  6. ノード・マネージャの作成

    「ノード・マネージャ」画面で、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。

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

    すべての検証が成功していることを確認します。

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

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

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

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

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

  • ノード・マネージャを起動します。

    詳細は、『Oracle Data Integratorのインストールと構成』のノード・マネージャの起動に関する項を参照してください。

  • Oracle Data Integratorスタンドアロン・エージェントを起動します。

    詳細は、『Oracle Data Integratorのインストールと構成』のノード・マネージャでのスタンドアロン・エージェントの起動に関する項を参照してください。