SharePlex 11.4 - 管理者ガイド

レプリケーションのためのOracleデータベースオブジェクトの設定

このトピックでは、SharePlexでレプリケートするOracleデータベースオブジェクトの特定の特性を設定する方法について説明します。

行の一意性の確保

SharePlexには、ターゲット上で変更している行がソース行と一致する正しい行であることを確認する方法が必要です。これは、キーとインデックスの使用によって1対1の関係を確保することで達成されます。

キーの役割

SharePlexは、レプリケートされるすべてのソーステーブルとターゲットテーブル、特に大きなテーブルやLONG列を含むテーブルにプライマリキーまたは一意キーがある場合に最も速く動作します。使用するキーを選択するときに、SharePlexは、利用できる最も適切なキー列を以下の優先度で使用します。

• プライマリキー
• 列数が最も少ない一意キーで、少なくとも1つの列がNOT NULL

• 列数が最も少ない一意キー

パフォーマンスを最大化するために、プライマリキーと一意キーのサプリメンタルロギングを有効にすることをお勧めします。

テーブルが主キーまたは一意キーを持たない場合、またはOracleがSharePlexに対して間違った一意キーを記録する場合、構成ファイルを作成するときにキーとして使用する列をSharePlexに指定できます。これはキー定義と呼ばれ、設定ファイルで指定されます。詳細については、『SharePlex管理ガイド』の「一意キーの定義 」を参照してください。

キー定義に代わる方法として、一意性を確立する1つまたは複数の列に基づく一意のインデックスを作成または使用する方法があります。

正しいキーが記録されていることの確認

プライマリキーと一意キーのサプリメンタルロギングが有効で、テーブルにプライマリキーがない場合、Oracleはログに記録する一意キーのタイプを決定する必要があります。テーブルに複数の一意キーがある場合、Oracleは使用する最適なキーを決定し、UPDATEごとにそれらの列の値をログに記録します。テーブルにどのタイプのキーもない場合、OracleはLONGまたはLOBではないすべての列をログに記録します。

SharePlexは、データのレプリケーションに使用するキーも特定しなければなりません。Oracleと同様に、SharePlexは次の順序でキーを選択します。

• プライマリキー（ある場合）
• 最適な（または唯一の）一意キー（ある場合）
• すべての列

SharePlexによってレプリケートされるテーブルにプライマリキーがなく、複数の一意キーがある場合、Oracleがログに記録するキー列がSharePlexで要求されるものでない可能性があります。

キーまたは一意のインデックスがないテーブル

SharePlexがテーブルのキーや一意のインデックスを検出できない場合、LONGとLOBを除くすべての列を使用してキーを構築します。このキーは内部で管理され、テーブル自体には作成されません。

これは好ましいオプションではありません。WHERE句の結果、Oracleは行を見つけるためにターゲットテーブルのフル・テーブル・スキャンを実行することになり、レプリケーションが著しく遅くなるからです。さらに、行の一意性を強制することはできません。

例えば、異なる行のLONG以外の列に同一の値が含まれていても、LONG列に異なる値が含まれる可能性がある場合は、テーブルの同期が外れていることをユーザやSharePlexが検出できないままになることがあります。以下の例でその問題を説明します。テーブルの行はLONG列を除いて同一であり、プライマリキーも一意キーもありません。

ソースシステムのあるユーザが、最初の行の列Aを15に変更したと仮定します。変更をターゲットテーブルに適用するようにSQLステートメントを構築するときに、SharePlexは列AおよびBを使用してキーを構築し（UPDATEtablename SET ColumnA to 15 WHERE Column A = 10 and Column B = 20）、変更する行を特定します。この条件を満たす行は3つあるので、SharePlexは、間違った行に変更を投稿してしまう可能性があります。

NULLを含むキー

キーがNULLを許容する場合、SharePlexは、UPDATEやDELETEに対して行の一意性を保証できないため、ターゲットシステム上で間違った行を変更する可能性があります。SharePlexがNULLを許可するキーを指定する方法を制御するには、SP_SYS_IN_SYNCパラメーターを設定します。詳細については『SharePlexリファレンスガイド』を参照してください。

キーの値の変更

SharePlexは、特別な設定なしにキー列の値の変更を処理します。ただし、キーにシーケンスを使用している場合、またその値が更新される可能性がある場合は、更新によってターゲットシステム上でキーが重複しないようにシーケンスを作成します。そのようにしないと、新しい値が使用されて操作が適用され、その値がターゲットテーブルの別の行のキーとして既に存在する場合、SharePlexは一意キー制約違反と非同期エラーを返します。このタイプのエラーは、式「x+n」（nは増分）を使用して値を更新する場合に発生する可能性があります。値「x+n」のいずれかが既存の値と等しくなる可能性があります。

以下は、キー列の値を1だけ大きくする例です。

Key_Col

1

4

5

7

SQL> update table X set a=a+1; commit

新しい値は以下のようになり、ターゲットシステムにレプリケートされます。

Key_Col

2

5

6

8

SharePlexは、操作をREDOログに記録する順序で更新します。

updatexseta=2wherea=1;（成功）

updatexseta=5wherea=4;(5の値が既に存在するため失敗)

updatexseta=6wherea=5;（成功）

updatexseta=8wherea=7;（成功）

Postがターゲット配列に使用するプリイメージ値は、ソースからレプリケートされる増加値と同じです。Oracleはこの操作を一意制約違反として拒否します。別の例として、AをBに更新し、BをCに更新するトランザクションがあります。

重要!ピアツーピアレプリケーションを使用する予定がある場合は、キーに関する要件がさらにあります。詳細については、『SharePlex管理ガイド』の「複数のピアデータベースを維持するためのレプリケーションの設定」のセクションを参照してください

インデックス

レプリケーション環境では、インデックスを正しく使用することが重要です。インデックスはターゲットデータの完全性を維持します。

• 一意のインデックスを持つソーステーブルをレプリケートする場合、ターゲットテーブルにも一意のインデックスがなければなりません。
• すべての大規模なテーブルでは、ターゲットシステム上に一意のインデックスがなければなりません。一意のインデックスがない場合、OracleはPostによって変更される行を見つけるためにテーブル全体をスキャンします。
• アプリケーションによってはプライマリキー制約を使用しないため、デフォルトでは一意のインデックスは作成されません。しかし、一意のインデックスとして作成されたにもかかわらず、名前が付けられていない（CREATE UNIQUE INDEXコマンドを使用していない）インデックスが存在することが頻繁にあります。この例として、個人名や従業員識別番号など、一意の値を持つ1つまたは複数の列で作成されたものがあります。テーブルに一意のインデックスが存在しない場合は、設定ファイルを作成する際に一意のインデックスを作成するか、ユーザ定義キーを指定することをお勧めします。詳細については、『SharePlex管理ガイド』の「一意キーの定義」のセクションを参照してください。
• 一意のインデックスを特定または作成したら、OracleがSharePlexのヒント機能を使用してそのインデックスを使用することを確認できます。詳細については、『SharePlex管理ガイド』の「OracleのINDEXヒントの使用」のセクションを参照してください

• テーブルに外部キーがある場合は、外部キーの変更によってテーブルのフルスキャンが発生しないように、適切な列にインデックスが付けられていることを確認してください。

• インデックスを常に最新の状態に保ってください。最新の状態でないと、Postプロセスが低速化します。断片化したものを再構築します。

ターゲットテーブルにインデックスが多すぎる場合、Oracleは行の追加や削除に応じてインデックスをすべて更新しなければなりません。このため、レプリケーションを含むシステム全体の速度が遅くなります。インデックスの数を、最も有用性の高いものに限定することを検討してください。

ほぼ1つのタイプのDMLを実行するアプリケーションの場合、以下を考慮します。

• INSERT: メンテナンスの手間を省くため、いくつかのインデックスだけを使用します。
• UPDATE: INSERTステートメントの後に変更しない列のインデックスを使用します。
• DELETE: できるだけ多くのインデックスを削除します。

何百万ものSQL操作を行う大規模なバッチジョブを実行する場合は、バッチジョブの前に不要なインデックスを削除し、最後にインデックスを再構築します。これにより、SharePlexの実行速度が上がり、その後、インデックスがより整理された状態になります。

ビットマップインデックス

パフォーマンスの理由から、Postプロセスがデータを適用している間は、ビットマップインデックスの使用を避けてください。これらのインデックスは、Postプロセスのパフォーマンスにマイナスの影響を及ぼす可能性があります。

ターゲットテーブルでビットマップインデックスを使用しなければならない場合は、Postによって適用されるトランザクションへの影響と、クエリに対するその利点を比較します。

• Oracleがビットマップエントリを追加、更新、または削除すると、ビットマップセグメントに関連するすべての行が効果的にロックされます。
• ビットマップセグメントには、数百個の行に対する参照を含めることができます。その結果、同じビットマップセグメント内のビットマップエントリを更新する場合、異なるPostセッション（ソースシステム上のセッションごとにPostセッションが存在する）で行う変更が互いをブロックし合う可能性があります。
• 操作を続けるには、Postがブロックを検出して解決する必要がありますが、ロックの数が多い場合はポストが大幅に遅れることになります。
• 一般的に、ビットマップインデックスを持つテーブルに複数の同時セッションを頻繁に挿入するとロックのコンフリクトが発生しますが、そのようなテーブルでのランダムな更新や削除ではコンフリクトは発生しません。SharePlexは、より静的なテーブルにビットマップインデックスを持たせるというOracleの推奨事項に従っています。

注意: ビットマップインデックスのレプリケーションは推奨されません。ビットマップインデックスを持つテーブルを変更するたびに、インデックスは再構築されます。この再構築に関連するコスト（Oracleの時間とリソース）は、SQL UPDATEステートメントに追加されます。

ターゲットでのトリガの起動の防止

ソースシステムでのトリガの起動によるDMLの変更は、REDOログに記録され、SharePlexによってターゲットシステムにレプリケートされます。その結果、同じトリガがターゲットシステムで起動され、同じDMLの変更（レプリケーションによって既に行われた）が開始された場合には非同期エラーが発生します。

例えば、ソースシステムでのテーブルAへのINSERTがテーブルBへのINSERTをトリガする場合、SharePlexは両方のINSERTをターゲットシステムにレプリケートします。Postプロセスは、ターゲットシステム上のTableAに最初のINSERTを適用し、TableBへのINSERTをトリガします。したがって、レプリケートされたINSERTをPostがTableBにポストしようとすると、一意キー違反が発生します。テーブルAに対してトリガが起動されたため、この行は既に存在しています。

トリガは、レプリケーション戦略に応じて以下のように処理できます。

レプリケーション設定にないオブジェクトのトリガは、アクティブのままにしておくことができます。

トリガスクリプトの使用方法に関する重要な情報については、『SharePlexリファレンスガイド』を参照してください。

整合性制約の設定

整合性制約はレプリケーションに影響を与えます。以下のガイドラインに従って確実に取り扱ってください。

外部キー制約

外部キー制約は、ターゲットテーブルで無効にする必要があります。SharePlexは、ソース外部キー制約の結果をレプリケートします。ソースの外部キーの結果を正確にレプリケートするためには、互いに対する外部キーを持つテーブルをすべてレプリケーションの設定に含める必要があります。参照制約を持つテーブルはすべてターゲットデータベースに存在していなければなりません。もし1つでも欠けると、参照整合性が崩れる可能性があります。

注意: ターゲットテーブルの制約がDEFERREDの場合、Postトランザクションは制約の検証で失敗する可能性があります。この問題を回避するには、SP_OPO_DISABLE_OBJNUMパラメーターを有効にして、トランザクションを成功させます。再同期されるまで、基礎となるターゲットテーブルは引き続き非同期のままになります。

ON DELETE CASCADE制約

SharePlexには、ON DELETE CASCADE制約をターゲットテーブル上で有効なままに維持する機能がありますが、パラメーターの設定を通じて、明示的に有効にする必要があります。PostはON DELETE CASCADEの依存関係を検出し、レプリケートされたカスケード削除の子テーブルへのポストを抑制します。

SharePlexを使用してこのサポートを有効にしていない場合、ターゲット上でこれらの制約を手動で無効にする必要があります。そのようにしないと、SharePlexは、プライマリ削除とカスケード削除の両方をレプリケートするため、ターゲット上で削除がカスケードされるとコンフリクトやエラーが発生します。

ON DELETE CASCADEのサポートを有効にするには:

1. ソース上のプライマリキー、一意のインデックス列、および外部キー列のロギングを有効にします。

2. 以下のSharePlexパラメーターを設定します。

   • SP_OPO_DEPENDENCY_CHECKパラメーターを2に設定
   • SP_OCT_REDUCED_KEYパラメーターを0に設定
   • SP_OPO_REDUCED_KEYパラメーターを0、1、または2に設定

注意: ピアツーピアレプリケーションでは、SP_OPO_REDUCED_KEYを0に設定する必要があります。

チェック制約

ターゲットシステムのチェック制約を無効にします。これらの制約により不必要なオーバーヘッドが増えます。これらのチェックはソースシステム上で行われるため、十分にメンテナンスされ同期化されたレプリケーション環境では冗長になります。高可用性を目的とする場合は、フェールオーバー手順の一環として制約を再アクティベーションするスクリプトを作成できます。

ターゲットオブジェクトへのアクセスの防止

ピアツーピアレプリケーション以外のすべての状況では、SharePlexデータベースユーザは、ターゲットオブジェクトでDMLまたはDDLを実行できる唯一のユーザでなければなりません。他のユーザ、ジョブ、またはアプリケーションによってターゲットオブジェクトにDMLまたはDDLの変更が加えられた場合、ターゲットデータはソースシステム上のデータの状態を反映しなくなる可能性があります。詳細については、『SharePlex管理ガイド』の「同期の概念の理解」のセクションを参照してください。

シーケンスの設定

SharePlexは、ALTER SEQUENCEおよびDROP SEQUENCEコマンドやDMLトランザクションで行われたOracleシーケンスへの変更をレプリケートします。特定のレプリケート戦略では、配列をレプリケートする必要がない場合があります。

• 高可用性:必要あり

  SharePlexがシーケンスをレプリケートする方法により、ユーザはシーケンスの増分や再利用を気にすることなく、直ちにフェールオーバーデータベースを使い始めることができます。

• レポート作成、データ共有、その他の基本的な一方向レプリケーション:必要なし

  ターゲットシステムでシーケンスが不要な場合は、レプリケートしないでください。レプリケーションが遅くなる可能性があります。ソーステーブルのキー生成にシーケンスが使用されている場合でも、レプリケートされた行がターゲットシステムに挿入されると、シーケンス値がキー列の一部になります。シーケンス自体をレプリケートする必要はありません。

• ピアツーピア:必要なし

  SharePlexは同一シーケンスのピアツーピアレプリケーションをサポートしていません。詳細については、『SharePlex管理ガイド』の「複数のピアデータベースを維持するためのレプリケーションの設定」のセクションを参照してください

レプリケーション用にシーケンスを設定するには:

1. シーケンスをレプリケートするには、データベースレベルでプライマリキーとユニークキーのサプリメンタルロギングを有効にするか、sys.seq$テーブルでプライマリキーのサプリメンタルロギングを有効にする必要があります。

2. キャッシュを使用し、増分を少なくとも20に設定します。シーケンスがキャッシュされると、SharePlexはグループとして値を複製することができます。シーケンスをキャッシュしない場合、SharePlexは、シーケンスから値を取得するたびにディスクに移動しなければならないため、より重要なデータのレプリケーションが遅くなります。

3. ターゲットシステムでのシーケンスの一意性を確保するために、ターゲットシーケンスの開始値をソースシーケンスの開始値よりも大きくする必要があります。以下の式を使用して、ターゲットのSTART_WITH値を決定します。

   source_current_value+ (source_INCREMENT_BY_value x source_CACHE_value) =target_START_WITH_value

   重要!(source_INCREMENT_BY_value x source_CACHE_value)は2GBを超えてはなりません。超えるとシーケンスのレプリケーションに失敗します。

4. 設定では、テーブルと同様にオーナーと名前でシーケンスを指定します。

5. シーケンスの変更はDDLコマンドであるため、Postプロセスはシーケンスの更新が終了するまですべてのポストを一時停止します。そのため、特にシーケンスがキャッシュされていない場合は、テーブルとは別のpostキューでシーケンスをポストすることをお勧めします。詳細については、『SharePlex管理ガイド』の「データをレプリケートするためのSharePlexの設定」のセクションを参照してください。

SharePlexは、ALTER SEQUENCEコマンドを使用して、以下のようにターゲットデータベースのシーケンスを更新します。

• 増分値を以下のように変更します。

  source_INCREMENT_BY_valuexsource_CACHE_value

• NOCACHEに設定します。
• シーケンスを更新します。

• 以下の値を設定して、シーケンスを再度変更します。

  Increment_value=source_INCREMENT_BY_value

  Cache_value=source_CACHE_value

SharePlexは、シーケンスに対する単純なSELECT（UPDATE）操作と同じようにALTER SEQUENCE操作を扱います。これは、REDOログレコードではこれらの2つの操作が区別されないからです。