異種データの統合
更新 : 2006 年 4 月 14 日
多くの企業や組織では、データが複数の製造元のデータベースに格納されています。組織内で複数のシステムを連携させるには、これらのデータの統合がしばしば重要になります。レプリケーションを使用すると、次の 2 つの方法で異種データを統合できます。
- Microsoft SQL Server、IBM、Oracle の各データベースへのレプリケート可能なデータの統合元として Oracle を使用する。
- IBM および Oracle のデータベースへのレプリケート可能なデータの統合元として SQL Server を使用する。
異種データの統合に使用するレプリケーション構成の種類は、データの統合元と統合先によって決まります。
- 次の図は、SQL Server から、IBM DB2 および Oracle へのデータのレプリケーションを示しています。
.gif "SQL Server 以外のデータベースへのデータのレプリケーション")
- 以下の図は、Oracle データベースから他のデータベースへのデータのレプリケーションを示しています。データは最初に SQL Server データベースにレプリケートされ、次に SQL Server、IBM DB2、Oracle などの他のデータベースにレプリケートされます。
.gif "Oracle からのデータのレプリケーション")
Adventure Works Cycles の例
Adventure Works Cycles は、データベースの概念とシナリオを説明するために使用する架空の製造会社です。詳細については、「サンプル データとサンプル データベース」を参照してください。
Adventure Works Cycles は、企業の成長を見越してインフラストラクチャを拡充するために、最近、メキシコの企業である Importadores Neptuno を吸収合併しました。Importadores Neptuno は、Oracle データベースを使用して製造と財務のデータを保持しています。しかし、Adventure Works Cycles の製造資源計画 (MRP) アプリケーション内で、正確にスケジュールと在庫のデータを管理するために、データの基本的な要素を共有する必要があります。
現在 Importadores Neptuno データベースを移行する計画はありませんが、Adventure Works Cycles では毎日データを送受信し、既存の SQL Server オンライン トランザクション処理 (OLTP) データベースおよびオンライン分析処理 (OLAP) データベースに情報を転送する必要があります。Adventure Works Cycles を使用して、Oracle データベースから本社にある SQL Server データベースにデータをレプリケートします。
このシナリオの一般的な要件
異種データの統合に関連するアプリケーションには一般的に以下のような要件があり、適切なレプリケーション ソリューションで対処する必要があります。
- 異なる製造元のデータベース間でデータをレプリケートする必要があります。
- トランザクションの一貫性を保つ必要があります。
- 統合元サーバーに対するレプリケーション処理のオーバーヘッドをできるだけ少なくする必要があります。
- 増分変更のレプリケーションが必要な場合の待機時間を少なくする必要があります。
- 増分変更のレプリケーションが必要な場合に、高いスループットが必要です (多数のトランザクションのレプリケーションを処理する必要があるため)。
- 統合先サーバーで必要とされるデータは、統合元サーバーで利用可能なデータのサブセットである可能性があります。
このシナリオで使用するレプリケーションの種類
SQL Server では、出版業界にたとえてレプリケーション システムのコンポーネントを表しています。コンポーネントには、パブリッシャ、ディストリビュータ、サブスクライバ、パブリケーションとアーティクル、およびサブスクリプションがあります。
- 上記の最初の図では、Oracle データベースがパブリッシャです。パブリケーションには、Oracle データベースの一部またはすべてのデータが含まれます。各テーブルのデータはアーティクルです。データは最初に、ディストリビュータとして構成されている SQL Server にレプリケートされ、次に他の SQL Server、IBM、Oracle のデータベースに配信されます。各データベースは、パブリケーションのサブスクライバで、サブスクリプションとしてスキーマとデータを受信します。
- 上記の 2 番目の図では、SQL Server データベースがパブリッシャで、IBM および Oracle のデータベースがサブスクライバです。
システムのコンポーネントの詳細については、「レプリケーションのパブリッシング モデルの概要」を参照してください。
SQL Server では、さまざまなアプリケーション要件に対して各種のレプリケーション (スナップショット レプリケーション、トランザクション レプリケーション、およびマージ レプリケーション) を用意しています。このシナリオは、スナップショット レプリケーションとトランザクション レプリケーションの異種レプリケーション機能で最適に実装され、前のセクションで概説した要件によく適合します。
- アプリケーションで増分変更が発生するたびにそのレプリケーションが必要な場合は、トランザクション レプリケーションを使用します。
Oracle パブリッシングの場合、トランザクション レプリケーションでは、トリガと変更の追跡テーブルを使用してパブリッシャ側で変更を追跡しています。トランザクション レプリケーションの詳細については、「トランザクション レプリケーションの概要」、「トランザクション レプリケーションの動作方法」、および「Oracle パブリッシャのトランザクション レプリケーション ワークフロー」を参照してください。 - アプリケーションでデータのレプリケーションが 1 回のみ (たとえば、データの移行時のみ) 必要である場合、または増分更新を使用せずに定期的に更新する必要がある場合は、スナップショット レプリケーションを使用します。
スナップショット レプリケーションでは、増分更新の追跡と配信を行わないので、パブリッシュされたテーブルにトリガが使用されません。スナップショット レプリケーションの詳細については、「トランザクション レプリケーションの概要」および「トランザクション レプリケーションの動作方法」を参照してください。
スナップショット レプリケーションとトランザクション レプリケーションは、以下に示すこのシナリオの主な要件に対応するように作られています。
- 異なる製造元のデータベース間でのレプリケーション
- トランザクションの一貫性
- 最小限のオーバーヘッド
トランザクション レプリケーションでは、増分更新を必要とするシステムの以下の追加要件に対応します。
- 短い待機時間
- 高いスループット
このシナリオで考慮する必要がある主なオプションは、フィルタ選択です。スナップショット レプリケーションとトランザクション レプリケーションでは、サブスクライバのテーブルにアプリケーションで必要なデータのみが含まれるように、列や行をフィルタ選択することができます。詳細については、「パブリッシュされたデータのフィルタ選択」を参照してください。
このシナリオの実装手順
これらのシナリオを実装するには、最初にパブリケーションとサブスクリプションを作成してから、各サブスクリプションを初期化してください。詳細については、以下のリンクをクリックしてください。
- Oracle パブリッシング :
- Oracle サブスクライバおよび IBM DB2 サブスクライバ :
サブスクリプションの初期化が終わり、パブリッシャとサブスクライバ間でデータ フローが発生したら、共通の管理および監視作業の詳細について以下のトピックを参照してください。
- レプリケーションの監視
- スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式
- Oracle パブリッシャのバックアップと復元
- レプリケーションのトラブルシューティング
- Oracle パブリッシャのトラブルシューティング
- レプリケーションの削除