| Oracle Warehouse Builderインストレーションおよび管理ガイド 11gリリース1（11.1）for Microsoft Windows and UNIX Systems E05735-03 |
|
 前へ |
 次へ |
| Oracle Warehouse Builderインストレーションおよび管理ガイド 11gリリース1（11.1）for Microsoft Windows and UNIX Systems E05735-03 |
|
前へ |
次へ |
この章では、開発、テスト、本番など、複数の環境を管理するための計画について説明します。この章では、次の項について説明します。
ミッション・クリティカルなプロジェクトを系統的に実施するために、組織は一般的に、プロジェクトを本番環境にリリースする前に、開発用の環境とテスト用の環境を別々に確保します。複数の環境に同一のWarehouse Builderプロジェクトをレプリケートすることはできますが、環境ごとに別々の物理プロパティを割り当てたほうが好ましい場合があります。たとえば、本番環境にターゲット表をロードするときには、エラー・メッセージをすべてログ・ファイルに保存するが、同じターゲットを開発環境にロードするときには、エラー・メッセージを保存しないなどです。
また、最初は各環境に同一の論理デザインがレプリケートされていても、それらが別々に発展する場合があります。開発環境では、開発チームが新機能の実装や変更を継続的に行ってパフォーマンスの改善を図ります。本番環境では、不具合の検出および修正に基づいて、デザインが徐々に、そして制御された方法で発展していきます。
したがって、開発、テスト、本番それぞれに別々の環境を維持するには、異なる物理環境で同一の論理デザインを利用し、同時に、各環境間のデザインの違いを管理する必要があります。
Warehouse Builderでは、次のいずれかのソリューションを実施することによって複数の環境を管理できます。
1つの設計環境に基づいた複数の環境（Warehouse Builder Enterprise ETLオプションが必要）
この計画では、次に示すとおり、すべての設計作業は1つのWarehouse Builderリポジトリ内で行います。
1つのデザイン・リポジトリで、ランタイム環境ごとに構成とコレクションを定義します。適切な構成をアクティブ化し、関連付けられているコレクションを配布して、1つの環境から次の環境にデザインを昇格させます。
複数のランタイム環境に1つのデザインを昇格させる一般的な手順は次のとおりです。
必要なコンピュータにWarehouse Builderコンポーネントがインストールされていることを確認します。
設計作業用に指定されたすべてのコンピュータには、Warehouse Builderリポジトリが必要です。ランタイム環境として指定されてたすべてのコンピュータには、Warehouse Builderコントロール・センター・サービスが必要です。ソース・データのホスティングのみを行うコンピュータには、Warehouse Builderコンポーネントは不要です。
図11-1は、デザイン・リポジトリがそのOracle Databaseで排他的にホスティングされている様子を示しています。ただし、実際には、同じOracle Databaseでデザイン・リポジトリと開発ランタイムをホスティングするようなことも可能です。
「複数の環境を管理するための構成の使用」の説明に従って、ランタイム環境ごとに構成を作成します。
DEV構成をアクティブにしてWarehouse Builderを使用するように、開発チームに指示します。
開発チームは、マッピングやプロセス・フローなどのオブジェクトを作成して論理デザインを実装します。配布されたオブジェクトはその後、DEV環境で実行されます。
どのオブジェクトがテスト環境および本番環境に配布する準備が整ったかを管理するには、『Oracle Warehouse Builderユーザーズ・ガイド』の説明に従って、コレクションを作成します。
コレクションとは、同じプロジェクト内のオブジェクトへのショートカットのグループのことです。この例では、Deploy To TestおよびDeploy To Productionという名前の2つのコレクションを作成します。
開発チームは、各種設計オブジェクトのテストの準備が整ったと判断したら、Deploy To Testコレクションにショートカットを追加できます。
TEST構成をアクティブにしてWarehouse Builderを使用するように、QAユーザーに指示します。
これでQAユーザーは、Deploy To Testコレクションにオブジェクトを配布できるようになります。各オブジェクトを1つずつ配布することも、コレクション内のオブジェクトをすべて一括配布することもできます。
コレクション内のショートカットを選択すると、ユーザーは参照先のオブジェクトに対するロックを取得します。
QAユーザーは、オブジェクトを配布した後に、Deploy To Testコレクションのオブジェクトを実行できます。
実行されたジョブは、TEST構成に関連付けられたターゲットにのみ影響します。開発環境および本番環境には影響しません。
このパターンは、QAユーザーがDeploy To Productionコレクションにショートカットを追加するたびに継続します。本番ユーザーは、Warehouse Builderを使用するときに、PROD構成がアクティブであることを確認します。
複数の環境を管理するには、まず環境ごとに構成を作成することをお薦めします。構成とは、データ・システムの配置に必要なすべてのオブジェクトの物理的な詳細を含めるための、Warehouse Builderのエンティティのことです。
注意: 複数構成の機能を使用するには、Warehouse Builder Enterprise ETLオプションが必要です。組織にこのオプションのライセンスがない場合は、「複数の環境を管理するためのスナップショットの使用」の説明に従ってください。
開発、テスト、本番のそれぞれに個別の環境を用意するのが一般的です。すべての環境に同一の設計オブジェクトがあっても、オブジェクトには別々の物理構成設定を適用するほうが好ましい場合もあります。
表11-1は、環境に応じて別々の構成プロパティを使用するように表を指定するときの例を示しています。
表11-1 異なる環境における表の構成プロパティ
| 構成プロパティ | 開発環境 | テスト環境 | 本番環境 |
|---|---|---|---|
|
表領域 |
|
|
|
|
パラレル・アクセス・モード |
|
|
|
|
ロギング・モード |
|
|
|
このシナリオを実装するには、環境ごとに構成を作成し、各環境で一意の表領域設定を定義します。
Warehouse Builderをインストールするとき、または新しいリポジトリを作成するときに、プロジェクト・エクスプローラで「構成」ノードを開きます。そこにDEFAULT_CONFIGURATIONという構成があります。また、デザイン・センターの左下隅に、この構成が「アクティブな構成: DEFAULT_CONFIGURATION」と示されています。
このデフォルトの構成には、これらのオブジェクトの配布に必要な、デザイン・センターのすべてのデータ・オブジェクトの物理プロパティが含まれています。単一のエンティティであるDEFAULT_CONFIGURATIONは、Warehouse Builderの内部動作に必要なデバイスにすぎません。つまり、デフォルトのコントロール・センターDEFAULT_CONTROL_CENTERに配布できるようになります。
ただし、新しい構成を定義するときには、同一の論理オブジェクトを複数の環境でどのように定義するか管理できます。つまり、単一の表やビューなどのデータ・オブジェクトに、複数の物理的なプロパティおよび配布の詳細を定義できます。
DEV、TEXT、PRODという3つの新しい構成を作成するのが一般的です。各構成は、図11-2に示すように、1つのコントロール・センターおよびそのロケーションと連動して機能します。
構成では、オブジェクトが配布される環境に対応するオブジェクトの物理的なプロパティを指定します。構成には、一度に1つのコントロール・センターしか関連付けることができません。構成に関連付けられているコントロール・センターは変更できます。
コントロール・センターとは、ターゲット・マシン上のリポジトリのことで、ソースおよびターゲットのロケーションのセットを管理します。コントロール・センターには、一度に1つの構成しか関連付けることができません。
ロケーションは、Warehouse Builderがデータの取得元または配布先とするデータベース、ファイルまたはアプリケーションに対応しています。ロケーションは、1つのコントロール・センターでのみ所有されます。各ロケーションには1つ以上のコネクタがあり、これによって他のロケーションと接続されます。
オブジェクトを配布すると、Warehouse Builderによって、現在アクティブな構成に関連付けられているターゲットにこれらのオブジェクトが作成されます。1つのセッションでは、一度に1つの構成のみがアクティブです。「構成のアクティブ化」の説明に従って別の構成に切り替えた場合は、デザイン・センターの左下隅には、新しくアクティブ化された構成の名前が表示されます。
構成プロパティの値は構成オブジェクトに属し、保持されます。構成を切り替えても、構成値をリセットする必要はありません。デザイン・センターに表示される構成プロパティは、アクティブな構成に関連付けられている設定です。デザイン・センター下部のステータス・バーには、アクティブな構成の名前が表示されます。
たとえば、開発環境に関連付けられている構成が現在アクティブであるとします。そのため、構成プロパティの値を変更すると、その変更内容が開発環境に反映されます。表MY_TABLEで、「表領域」構成パラメータを「DEV」に設定します。次に、本番環境に関連付けられている構成をアクティブ化します。表示される構成値は、最後に本番構成がアクティブだったときに設定した値と同一になります。MY_TABLEの「表領域」構成パラメータはNULLです。これを「PROD」に変更します。この変更は、本番構成にのみ影響します。開発構成に戻ると、MY_TABLEの「表領域」構成パラメータは「DEV」のままです。プロジェクト内のすべてのオブジェクト・インスタンスの構成値は一意です。そのため、この例で、MY_TABLEの表領域の値を設定しても、他の表には影響がありません。各表のインスタンスは個別に構成する必要があります。
複数の構成を使用することの別のメリットとして、既存の環境を簡単に変更できることがあります。たとえば、オブジェクトを設計し、開発環境を実装し、オブジェクトを配布してから、テスト環境に移るとします。その場合、開発環境の一部のオブジェクトを変更することが必要になります。この変更を行うには、開発環境に関連付けられている構成をアクティブ化し、オブジェクトを変更し、スクリプトを再生成してオブジェクトを配布するという作業を行います。テスト環境に戻るには、テスト構成をアクティブ化します。
複数の構成を作成すると、複数の環境に同じデザインを配布できます。特定の環境にデザインを配布するには、環境に関連付けられている構成をアクティブ化してデザインを配布します。
複数の環境に一連のデザイン・オブジェクトを配布するには:
「新しい構成の作成」の説明に従って、デザイン・オブジェクトの配布先になっている環境ごとに構成を作成します。
構成ごとに、その環境を指すコントロール・センターが個別に作成されていることを確認します。
「構成用構成プロパティの設定」の説明に従って、各構成でデザイン・オブジェクトの構成プロパティを設定します。
「構成のアクティブ化」の説明に従って、デザイン・オブジェクトを配布する必要のある環境に関連付けられている構成をアクティブ化します。
配布または実行に関連するエラーを解決します。
配布前にデータ・オブジェクトを検証しても、エラーが発生する場合があります。これらのエラーの原因としては、設定した構成プロパティが考えられます。物理的なプロパティ情報である構成プロパティの値は、配布前に意味的にはチェックされません。たとえば、「表領域名」プロパティに指定した値は、検証時にはデータベースに対してチェックされません。このようなエラーは配布時に発生します。
デザイン・オブジェクトを配布します。
デザイン・オブジェクトを配布する必要のある環境ごとに、手順2〜5を繰り返します。
新しい構成を作成するには:
プロジェクト・エクスプローラで、プロジェクトを選択してナビゲーション・ツリーを開きます。
「構成」を選択します。
「設計」メニューから、「新規」を選択します。
構成作成ウィザードが開きます。
「名前」ページで、名前と説明を入力します（説明は省略可能）。
「このプロジェクトのアクティブな構成として設定および保存」をクリックして、新しい構成をアクティブな構成に設定します。設計オブジェクトに設定したすべての構成パラメータは、この構成に保存されます。また、配布するすべてのオブジェクトは、この新しい構成に関連付けられているコントロール・センターに配布されます。
「詳細」ページで、この構成に関連付ける必要のあるコントロール・センターを選択します。
コントロール・センターをまだ作成していない場合は、「新規」をクリックして作成し、構成に関連付けます。
「終了」をクリックしてウィザードを閉じ、構成を作成します。
「構成」フォルダに新しい構成が表示されます。
特定の構成に構成プロパティを設定するには:
目的の構成がアクティブになっていることを確認します。
アクティブな構成の名前がデザイン・センターの左下隅に表示されます。別の構成に切り替えるには、「構成のアクティブ化」を参照してください。
プロジェクト・エクスプローラで、構成するオブジェクトを右クリックし、「構成」を選択します。
選択したオブジェクトの構成プロパティを指定します。
プロジェクト内で構成プロパティを設定するすべてのオブジェクトに対し、手順2〜3を繰り返します。
これで設計オブジェクトを配布できるようになりました。デプロイメント・マネージャに表示されているコントロール・センターが、アクティブな構成に関連付けられているコントロール・センターです。
構成は一度に1つしかアクティブにできません。配布するすべてのオブジェクトは、このアクティブな構成に関連付けられているコントロール・センターに配布されます。異なる環境にデザインを実装するには、その環境に関連付けられているコントロール・センターにオブジェクトを配布する必要があります。これは、コントロール・センターに関連付けられている構成をアクティブ化することによって実行できます。
構成をアクティブ化するには:
アクティブ化する構成を右クリックして、「エディタを開く」を選択します。
「名前」タブで、「このプロジェクトのアクティブな構成として設定および保存」を選択します。
現在のセッションのみで構成をアクティブ化するには:
プロジェクト・エクスプローラで、プロジェクトを選択してナビゲーション・ツリーを開きます。
「構成」フォルダを開きます。
構成を選択します。
「設計」メニューから、「アクティブな構成として設定」を選択します。
選択した構成が、現在のセッションでアクティブな構成として設定されます。Warehouse Builderをいったん終了してログインした場合は、この変更は保存されていません。
オブジェクトの構成プロパティ変更はすべて、アクティブな構成に保存されます。前の構成に戻った場合は、これらのパラメータには以前の設定が保持されています。これで、この構成に関連付けられているコントロール・センターがアクティブになり、プロジェクト内のオブジェクトの検証、生成および配布に関するすべての新しい情報が格納されています。
この計画では、図11-3に示すように、ランタイム環境ごとに別々の設計環境があります。
この計画では、3つの設計環境間の違いを管理することが必要になります。設計環境間で設計コンポーネントを共有するには、スナップショットとメタデータ・ローダーのいずれかを使用できます。環境内にデザイン・メタデータを実装するか、またはデザイン・メタデータを変更するたびに、該当するランタイム環境にデザインを配布することが必要になります。
シナリオ
ある会社は、開発およびテスト期間後に、データ統合プロジェクトを本番用に組み込んでいます。ただし、プロジェクトの本番バージョンは固定されたものではありません。不具合の検出および修正によって変更される場合があります。その間、開発チームが新機能が差分実装すると、それに応じて開発バージョンも発展し続けます。この会社は、すべての会社に共通する課題に直面しています。これは、システムの様々なバージョンの変更を最も適切に管理する方法に関する課題です。
この一般的なシナリオの1つのバージョンが、図11-4に示されています。図では、開発環境は本番環境よりも一貫して機能が先行しており、QA（品質保証）環境は開発環境と本番環境の間にあります。開発環境を変更すると、その変更は少しずつQA環境に伝播し、続いて本番環境にも伝播します。しかも、本番環境には独自の変更サイクルがあり、図11-4に示すように、「本番1」というもう1つの環境が存在していますが、問題解決用に限定して使用されています。「本番」および「本番1」は、同じ段階で開発され、本番環境で発生するエラーを実証するのに役立っています。本番環境で直接、発生したエラーを修正し実装していますが、開発環境にマージする必要があります。他の会社では、この会社の環境とは多少異なる場合がありますが、同じ管理上の課題を抱えています。
図11-4に示すように、会社が環境を複数必要とするのは、通常、システムに対して追加変更を行うためです。ただし、本番環境にのみ全プロジェクトを実装する会社もあります。図11-4は、このような会社には適用されません。
この事例では、本番マッピングに問題があることを会社が検出します。図11-5に示すように、最初の手順では、マッピングの本番バージョンとマッピングの開発バージョンとを比較します。両方の環境内でマッピングが同一である場合は、解決は簡単です。いずれかの環境に変更を加え、マッピングをコピーして古いバージョンを上書きします。本番のマッピングと開発のマッピングが異なる場合は、プロジェクトが初期フェーズにあるか、または成熟フェーズにあるかによって対策が異なります。
通常、プロジェクトのライフサイクルの特徴として、初期フェーズおよび成熟フェーズという2つのフェーズがあります。この2つのフェーズには、2つの異なるバージョンの管理方法がそれぞれ必要で、互いに長所と短所があります。
図11-6に示すように、本番環境にプロジェクトを実装した後は、システムは初期フェーズにあります。初期フェーズの特徴として、開発環境内での変更が頻繁で、本番環境でエラーが発生する場合もあります。本番環境の不具合はこのフェーズで発生する傾向があるため、各環境の更新を早く容易にする管理方法を検討します。
会社には、多くの場合、2つから5つの異なる環境があります。初期フェーズでは、この会社はそれぞれの環境（この場合は、開発、QAおよび本番）内に別々のメタデータの定義を保持しています。本番環境での変更を伝播するには、会社はシステムの変更部分のみをエクスポートし、その部分を開発環境の定義にインポートします。
会社では、最近本番環境にデータ統合プロジェクトが実装されましたが、システムはまだ初期フェーズにあり、追加機能の多くがまだテストおよび展開されていません。本番環境のシステムはまだ新しいので、初期フェーズでの問題の発生頻度は高くなります。
図11-7に示すように、会社は各環境に対して別々のデザイン・リポジトリ（またはシステム設計の定義）を保持することを決定しています。さらに、プロセスを各環境の別々のランタイム・リポジトリに実装しています。
この例では、本番マッピングにエラーが発生するとします。図11-8に示すように、会社は本番マッピングを変更し、次に定義をエクスポートし、開発環境にマージします。
初期フェーズで本番マッピング内で検出されたエラーを修正するには:
バックアップのために、変更する前にすべてのマッピングの定義を取得します。
本番環境のデザイン・リポジトリに、マッピングの完全なメタデータ・スナップショットを作成します。マッピングの開発バージョンおよびQAバージョンでも同様にスナップショットを作成します。オブジェクトは完全なスナップショットからしかリストアできないため、バックアップを作成する場合は完全なスナップショットが不可欠になります。
本番環境のデザイン・リポジトリでマッピングを修正し、本番環境のターゲット・スキーマに配布します。
これにより、マッピングの変更バージョンが発生し、この変更バージョンは他の環境に伝播する必要があります。
メタデータ・エクスポート・ユーティリティを使用して、本番環境から変更されたマッピングのみをエクスポートします。
「設計」メニューから、「エクスポート」→「Warehouse Builderメタデータ」を選択します。「メタデータのエクスポート」ダイアログ・ボックスが表示されます。
メタデータ・インポートを使用して、開発およびQAに対する変更をインポートおよびマージします。
「メタデータのインポート」ダイアログ・ボックスの「インポート・オプション」から、「メタデータのマージ」を選択します。
「メタデータのインポート」ダイアログ・ボックスの「一致基準」オプションから、「ユニバーサルID」オプションを選択します。
ユニバーサルIDによるオブジェクトの一致は、複数の個別に変更される環境を維持する場合に重要です。
開発およびQAへの変更部分のマージの複雑性は、変更されたオブジェクトに応じて様々です。この例のマッピングの変更が、表の列幅の増加によるものである場合は、マージは単純です。たとえば、結合条件が変更され、他の依存性が存在する場合などは、マージはより複雑になり、時間がかかる可能性があります。
図11-9に示すように、2番目は成熟フェーズです。成熟フェーズの特徴として、開発環境では引き続いて変更がありますが、本番環境で必要になる変更は減ります。
成熟フェーズでは、会社は領域および管理コストを節約する方法を選択します。ここでは、設計のアクティブな定義を1つのみ保守し、この定義にはシステムの開発状態が反映されます。会社は、QAおよび本番環境の設計定義をバックアップに保存し、必要に応じてこれらのシステムの変更された部分を抽出してリストアします。
この段階では、プロジェクトは安定しており、今は成熟フェーズにあります。追加機能のいくつかは開発環境内で開発途上にありますが、本番環境に起因する修正はほとんどありません。
各環境の別々のランタイム・リポジトリへのプロセスの実装は続行されますが、図11-10に示すように、会社は1つのみのデザイン・リポジトリを保持することを決定します。
1つのデザイン・リポジトリのみに開発環境が反映されます。その理由は、そのデザイン・リポジトリが設計の変更を定期的に行うアクティブな環境であるためです。QAおよび本番環境からのデザイン・リポジトリは、開発デザイン・リポジトリ内にメタデータ・スナップショットとして格納されます。スナップショットは、最小限の領域を消費するバックアップ・メカニズムで、リストアする必要のあるすべてのオブジェクトへのアクセスを可能にします。本番またはQAに起因する設計の変更はほとんどないため、スナップショット内にそれらの定義を格納しておくことは有効な方法です。
成熟フェーズではほとんど発生しませんが、本番環境内でエラーが発生する場合があります。この例では、本番マッピングにエラーが発生するとします。図11-11に示すように、会社は本番内のマッピングを変更し、次に開発環境のスナップショットから定義をリストアし、開発環境に同じ変更を加えます。
成熟フェーズで本番マッピング内で検出されたエラーを修正するには:
本番スナップショット内のマッピングの本番バージョンと、デザイン・リポジトリ内の同じマッピングの開発バージョンとを比較します。
2つが異なる場合は、会社は残りの手順に従います。
2つが同一である場合は、手順8で示すようにマッピングを修正し、設計環境および本番環境のランタイム・リポジトリにマッピングを配布し、変更されたマッピングを使用して本番環境のスナップショットを更新します。
スナップショットとオブジェクトの比較、配布およびスナップショットの更新の手順については、オンライン・ヘルプを参照してください。
マッピングの完全なメタデータ・スナップショットを作成することにより、マッピングの開発バージョンのバックアップを作成します。
開発者がマッピングを新規に繰り返し適用していた場合は、マッピングの開発バージョンは本番バージョンと異なる可能性があります。この手順では開発者の作業を保持します。リストアは完全なスナップショットからしか実行できないため、完全なスナップショットを作成することは重要です。
本番環境のスナップショットからマッピングをリストアします。
このマッピングは、本番環境で実行しているマッピングと同一である必要があります。
メタデータ・スナップショットからのオブジェクトのリストアの手順については、オンライン・ヘルプを参照してください。
本番環境のスナップショットからリストアしたマッピングを修正します。
修正されたマッピングを本番環境のランタイム・リポジトリに配布します。
本番環境のデザイン・リポジトリのスナップショットからマッピングの既存の定義を削除し、マッピングの新規バージョンを使用してスナップショットを更新します。
手順2でバックアップとして取得した完全なスナップショットからマッピングをリストアします。
これは開発環境のデザイン・リポジトリからのマッピングです。通常、新機能の開発に伴って、このマッピングには他の作業が行われています。
オプションで、QAに対しても同様の手順を繰り返します。
手順4でマッピングの本番バージョンに対して行った修正と同じ修正をマッピングの開発バージョンに対しても行います。
この方法を使用する場合、少なくとも2回（オブジェクトの本番バージョンおよび開発バージョンで）すべての変更を行う必要があります。成熟フェーズでは、本番環境に起因する頻繁な変更が必要ないという理由のみで、会社はこの方法を使用します。この方法の利点は、管理コストが最小であることおよびデータベースで必要となる領域が少なくなることです。
