目次


カンタン!DB2テクテク第1歩 拡張機能編

DPropR-第二話

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: カンタン!DB2テクテク第1歩 拡張機能編

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:カンタン!DB2テクテク第1歩 拡張機能編

このシリーズの続きに乞うご期待。

レプリケーションのソース

第一話では、DpropRを構成する要素についてとりあげました。今回は、DpropRでデータをレプリケーションするために重要な概念をいくつかご紹介します。

レプリケーション対象のソースには、ユーザー表あるいはビューが指定できます。データをレプリケーションするには、どの表をソースとするか、また、どんな情報をどんなタイミングで収集し反映するのかを事前に定義しておきます。その際には、特に次の点を考慮にいれます。

  1. 列の変更前イメージが必要かどうか
  2. 差分更新を収集し反映するのか、全件データをリフレッシュするのか
  3. レプリカタイプで双方向のレプリケーションをするのであれば、同一データに更新が発生した場合、どちらの情報を優先するのか

レプリケーションのソースを定義する際には、変更後のイメージだけ、または、変更前後のイメージ両方を収集するように指定ができます。どちらを選択するかは、アプリケーションの仕様によっても変わってきますが、アプリケーションで、監査が入ったり、ロールバックしてデータを回復したりする要件がある場合は、変更前のイメージを収集しておくのがよいでしょう。

DpropRは差分更新の反映だけでなく、ソース表の全件データをターゲット表に一括反映することもできます。この場合、Captureにより収集された更新情報をもとにするのではなく、次のようなしくみで行われます。

  1. ターゲット表のすべての行を削除する
  2. ソース表からすべての行を読む
  3. ターゲット表に行をコピーする

この場合、直接ソース表にアクセスがいくので、全件リフレッシュをする場合には実行する時間帯を考慮する必要があります。

レプリカタイプのレプリケーション構成をくむ場合、レプリケーションの同一サイクル内で、ソース表とターゲット表の同じ行に更新があった場合の処置を考慮にいれる必要があります。つまり、更新が対立をおこした場合、どちらの情報を優先する(どちらの表が親表になる)のかを事前に定義しておきます。DpropRはソース表とターゲット表で同じ行に更新があったかどうかを検出するしくみをもっており、この定義情報をもとに更新情報の破棄あるいは反映を行います。

レプリケーション対象のデータの選択

ソース表のサブセットだけをレプリケーションしたり、ビューやJOIN、UNIONを使ってソース表のデータ構造を変更してターゲット表にレプリケーションすることもできます。

レプリケーションのシナリオによっては、全ての列をタ−ゲット表にレプリケーションする必要がない場合もあります。ソース表にLOBのような非常に大きなデータの列があり、ターゲット表には不要な場合はパフォーマンス上、これを対象からはずしたほうがよいでしょう。また、ソース表に定義したすべてのデータタイプをターゲット表でサポートできない場合もあります。そこで、ターゲット表をソース表より列数の少ない列サブセットで定義することができます。(レプリカタイプの表では、列のサブセット化はできません。)

また、全ての行をターゲット表にレプリケーションする必要がない場合もあるでしょう。一定の条件(WHERE文節)と一致する行を行サブセットとして定義し、この条件に合致するソース表の行のみをレプリケーションすることができます。たとえば、センターと各拠点にある事業所間でレプリケーションをおこなう場合、センターのマスターデータから、各事業所に関連するデータに対する変更だけを取り出して適用することができます。

ソース表にビューを作成し、そのビューをレプリケーション対象とすることで、列と行のサブセット化を行うこともできます。また、複数の表にまたがるビューから1つのターゲット表に対してレプリケーションを実行することもできます。たとえば、社員番号をキーとして、住所などの個人データの格納された表と写真の格納された表に対してビューを作成し、これをソースとして、ターゲット表に新しい構造の表を作成してレプリケーションすることができます。

レプリケーションにJOINおよびUNIONを利用すると、単一および、複数のデータソースサーバーの表を一つのソース表として定義することができます。

ビューをレプリケーションのソースとした例

レプリケーション対象のソースにビューを指定して効果的な例を次にご紹介しましょう。

各地に散在する複数データサーバーの各テーブルとセンターサーバーの1テーブルとの間でレプリカタイプのレプリケーションをするケースです。

  1. 各拠点のデータサーバーでは売上データなどの情報が逐次更新されていきます
  2. センターサーバーには各拠点のマスターデータ、サマリーデータが格納されています
  3. 各拠点のデータサーバーでも他の拠点のデータの参照が必要なため、センターサーバーにある各拠点のサマリーデータが必要です
  4. センターサーバーには各拠点のデータサーバーに蓄積されていくデータを一定間隔で反映します

こういうケースでは、差分更新の反映を一定間隔でおこなうのが一般的ですが、H/W障害・N/W障害などの発生で、ある拠点のデータサーバーとセンターサーバーとの間のレプリケーションが長時間停止してしまった場合、全件リフレッシュを行ったほうが、効率よくデータのリカバリーができる場合があります。

差分更新はCaptureが収集した変更情報分のみを反映しますが、全件リフレッシュの場合は、ターゲット表の全削除がおこなわれます。この例で、あるデータサーバーから全件リフレッシュ要求が発生した場合、センターサーバーのデータが全削除され、最新ではないデータサーバーのデータに置き換わってしまいます。

これを回避する方法として以下の2つがあります。

  1. センターサーバーのターゲットテーブルに対して、各拠点対応のためのビューを作成する。
    各拠点のデータサーバーからは、このビューをターゲットにレプリケーションを行う。
    その際に、キーレンジを考慮して重複するデータがないように、ビューを作成しておく 。
  2. センターサーバーにターゲットテーブルとして各拠点ごとのテンポラリーテーブルを作成する。
    各拠点のデータサーバーからは、このテンポラリーテーブルをターゲットにレプリケーションを行う。
    センターサーバーでは、各拠点からレプリケーションされたテンポラリーテーブルをUNIONで一つにまとめて使用する 。

サブスクリプション

サブスクリプションとは、レプリケーション対象のソース表と、ターゲット表の間の一連の関係を設定した定義体です。サブスクリプションはターゲットとなる表あるいはビューごとに一つ作成する必要があります。これをサブスクリプション・メンバーといいます。いくつかのサブスクリプション・メンバーを集めたものを、サブスクリプション・セットといい、レプリケーションはサブスクリプション・セットを一つのコミット効力範囲内で処理します。つまり、複数の表・ビューに対するレプリケーションを同一作業単位内で実行するので、複数の表の保全性が保たれるのです。

下図は、同一サブスクリプション・セット内のある一つのサブスクリプションメンバーで、4月分のデータへの更新が失敗した場合、他の表でも同期をとって3月分のデータにロールバックされるという例です。

サブスクリプション・メンバーには次のような項目を定義します。

  1. どの表またはビューをソースにするか、どの表またはビューをターゲットにするか
  2. ターゲット表またはビューの構造 − 新規に作成するか、既存の表を利用するか
  3. 複製する列 (レプリケーション対象の列をある条件で選択する)
  4. 複製する行 (レプリケーション対象の行をある条件で選択する)

サブスクリプション・セットには次のような項目を定義します。

  1. サブスクリプション・セットの名前
  2. ソース表のあるサーバー名、ターゲット表のあるサーバー名
  3. レプリケーションの開始時間とそのインターバル、または、レプリケーションのトリガーとなるイベント
    これら2種類のレプリケーション起動方法は併用することもできる

下図はサブスクリプション・セットとサブスクリプション・メンバーの関係を模式化したものです。

適用修飾子 (Apply Qualifier)

適用修飾子(Apply Qualifier)はApplyと1つ以上のサブスクリプション・セットを関連付けたものです。つまり、適用修飾子の単位でApplyを開始できます。適用修飾子を分けることにより、異なるタイミングでデータをレプリケーションすることができます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=320554
ArticleTitle=カンタン!DB2テクテク第1歩 拡張機能編: DPropR-第二話
publish-date=11302005