このトピックでは、SharePlex を使用して複製する Oracle データベースオブジェクトの特定の特性を設定する方法について説明します。
SharePlex では、ターゲット上で変更する行がソース行と一致する正しい行であることを保証できる必要があります。これは、キーとインデックスを使用して 1 対 1 の関係を保証することで実現できます。
SharePlex は複製するすべてのソーステーブルおよびターゲットテーブル、特に大きなテーブルや LONG 列を含むテーブルに対してプライマリキーまたは一意のキーが存在する場合に、最も速く動作します。使用するキーを選択するとき、SharePlex は最適なキー列を次の優先順位で使用します。
最小の列ある一意のキー。
最高のパフォーマンスを実現するには、プライマリキーおよび一意のキーのサプリメンタルロギングを有効にすることをお勧めします。
テーブルにプライマリキーまたは一意のキーがない場合、または SharePlex の誤った一意のキーが Oracle によってログに記録された場合は、設定ファイルを作成するときに SharePlex でキーとして使用する列を指定できます。これはキー定義と呼ばれ、設定ファイルに指定します。詳細については、次を参照： 一意のキーの定義。
キー定義の別の手段として、一意性を確立する 1 つまたは複数の列を基とする一意のインデックスを作成または使用することもできます。
テーブルにキーまたは一意のインデックスが見つからない場合、SharePlex は、LONG と LOB を除くすべての列を使用してキーを構築します。このキーは内部で保守され、テーブル自体に作成されません。
この方法はお勧めしません。結果の WHERE 句によって、Oracle がターゲットテーブルに対してフルスキャンを実行して行を検索するため、複製速度が大幅に低下するためです。また、行の一意性を強制することもできません。
たとえば、さまざまな行の非 LONG 列に同じ値が含まれる一方で、LONG 列に異なる値が含まれる場合、ユーザーや SharePlex が認識することなくテーブルが非同期になる可能性があります。次の図を使って、この問題を説明します。テーブルにある行は LONG 列を除いて同一のもので、主キーまたは一意のキーはありません。
| 列 A | 列 B | 列 C (LONG) |
|---|---|---|
| 10 | 20 | 100 |
| 10 | 20 | 200 |
| 10 | 20 | 300 |
ソースシステムのユーザーが列 A の 1 行目を 15 に変更したとします。変更をターゲットテーブルに対して適用するために SQL 文を構築するとき、SharePlex は変更する行を検索するために列 A と B（UPDATE tablename SET Column A to 15 WHERE Column A = 10 and Column B = 20）を使用してキーを構築します。この条件を満たす行は 3 行あるため、SharePlex は誤った行への変更を post する可能性があります。
もしキーで NULL が許可されている場合は、SharePlex は UPDATE および DELETE で行の一意性を保証することができず、ターゲットシステムで誤った行を変更してしまう可能性があります。SharePlex で NULL が可能なキーを制御するには SP_SYS_IN_SYNC パラメータを設定します。詳細については、『 SharePlex リファレンスガイド』を参照してください。
SharePlex では、特別な設定をしなくてもキー列の値に対する変更が処理されます。ただし、キーにシーケンスが使用されている場合で、もしキーの値が更新される可能性がある場合は、更新によってターゲットシステムでキーが重複しないように、シーケンスを作成します。そうしないと、操作を適用するために新しい値が使用されたときにターゲットテーブルの他の行にその値がキーとしてすでに存在している場合、SharePlex は一意キー制約違反および非同期エラーを返します。このようなエラーは、「x +n」式（n は増分値）を使用して値を更新した場合に発生する可能性があります。「x +n」の値の 1 つが既存の値に等しい可能性があります。
以下の例では、キー列の値が 1 ずつ増分されます。
Key_Col
1
4
5
7
SQL> update table X set a=a+1; commit
新しい値は次のようになり、ターゲットシステムに複製されます。
Key_Col
2
5
6
8
SharePlex は、REDO ログに入力された順に更新操作を実行します。
update x set a=2 where a=1;（成功）
update x set a=5 where a=4;（これは、5 がすでに存在するため、失敗します。）
update x set a=6 where a=5;（成功）
update x set a=8 where a=7;（成功）
Post がターゲットシーケンスに対して使用するプリイメージ値は、ソースから複製された増加した値と同じです。Oracle は、一意の制約違反としてこの操作を拒否します。別の例として、A から B に更新し、そして B から C へ更新するトランザクションがあります。
重要! ピアトゥピアレプリケーションを使用する場合は、キーに関する追加の要件があります。詳細については、次を参照： 複数のピアデータベースを保持するための複製の設定。
複製環境ではインデックスを正しく使うことが重要です。インデックスにより、ターゲットデータの整合性が保たれます。
テーブルに外部キーがある場合は、外部キーへの変更によってフルテーブルスキャンが実行されることのないように、正しい列に対してインデックスを作成します。
ターゲットテーブルのインデックスが多すぎると、行の追加や削除の際に、Oracle がそれらをすべて更新する必要があります。これにより複製を含み、システム全体が遅くなります。インデックスの数は、最も有用性が高いものに限定することを検討してください。
主に 1 種類の DML を実行するアプリケーションでは、以下の点を考慮します。
何百万もの SQL 操作を行う、大きなバッチジョブを実行するときは、不要なインデックス群をバッチジョブの前に削除し、最後に再構築します。これによって、SharePlex の動作速度が向上し、以後のインデックスが整理されます。
パフォーマンス向上のため、Post プロセスがデータを適用している間は、ビットマップインデックスを使用しないでください。これらのインデックスによって Post プロセスのパフォーマンスに悪影響が及ぶ可能性があります。
ターゲットテーブルでビットマップインデックスを使用する必要がある場合は、クエリの利点と Post によって適用されるトランザクションへの影響とを比較検討してください。
注： ビットマップインデックスを複製することはお勧めしません。ビットマップインデックスを持つテーブルを変更するたびに、インデックスが再構築されます。この再構築に関連するコスト（Oracle の時間およびリソース）は、SQL UPDATE 文に追加されます。
ソースシステム上でトリガが実行された結果である DML 変更は、REDO ログに入力されるため、SharePlex によって複製され、ターゲットデータベースに post されます。その結果、同じトリガがターゲット上で実行され、（既に複製によって追加済みの）同じ DML 変更が開始された場合、非同期エラーが生じます。
たとえば、ソースシステム上で TableA への INSERT が TableB への INSERT をトリガした場合、SharePlex は両方の INSERT をターゲットシステムに複製します。Post プロセスは 1 つ目の INSERT をターゲットシステム上の TableA に適用し、それによってTableB へ INSERT がトリガされます。したがって、Post が複製された INSERT を TableB に post しようとすると、一意キー違反が発生します。TableA に対してトリガが起動されているため、この行はすでに存在します。
トリガは、複製方法に応じて以下のように処理できます。
| 複製方法 | ターゲットでのトリガの処理方法 |
|---|---|
|
高可用性 および ピアトゥピア |
|
| レポート作成、データ共有、その他の基本的な一方向の複製 |
|
トリガスクリプトの使用方法に関する重要な情報については、『 SharePlex リファレンスガイド』を参照してください。
整合性制約は複製に影響します。以下のガイドラインに従って、整合性制約が確実に処理されるようにしてください。
外部キー制約は、ターゲットテーブルで無効にする必要があります。SharePlex は、ソースの外部キー制約の結果を複製します。ソースの外部キーの結果を正確に複製するには、相互に外部キーを持つテーブルをすべて複製設定に含める必要があります。参照制約を持つすべてのテーブルが、ターゲットデータベースに存在している必要があります。1 つまたは複数のテーブルが欠けている場合は参照整合性が破損してしまう場合があります。
注： ターゲットテーブルで制約が DEFERRED の場合、Post トランザクションが制約の検証で失敗する可能性があります。この問題に対応するには、SP_OPO_DISABLE_OBJNUM パラメータを有効にして、トランザクションが成功するようにします。再同期するまで、基礎となるターゲットテーブルは非同期のままになります。
SharePlex では、ターゲットテーブルで ON DELETE CASCADE 制約を有効にしたままにできますが、この機能は有効にする必要があります。Post は、ON DELETE CASCADE 依存性を検出し、子テーブルへの複製されたカスケード削除の post 操作をすべて抑止します。
SharePlex を介してこのサポートを有効にしない場合は、ターゲットでこれらの制約を手動で無効にする必要があります。そうしないと、SharePlex によってプライマリ削除とカスケード削除の両方が複製され、ターゲットで削除がカスケードされたときに競合とエラーが発生します。
ON DELETE CASCADE のサポートを有効にするには
以下の SharePlex パラメータを設定します。
ターゲットシステムでチェック制約を無効にします。チェック制約により、不要なオーバーヘッドが増加します。これらのチェックはソースシステム上で満たされているため、適切に管理および同期された複製環境では冗長です。高可用性を目的とする場合は、フェイルオーバーの手順の一部として制約を再度有効にするスクリプトを構築することができます。
ピアトゥピアレプリケーションを除くすべてのシナリオにおいて、SharePlex データベースユーザーのみがターゲットオブジェクトに対して DML または DDL を実行できるようにする必要があります。他のユーザー、ジョブ、またはアプリケーションによってターゲットオブジェクトに DML または DDL の変更が加えられた場合、ターゲットデータはもはやソースシステム上のデータの状態を反映していない可能性があります。詳細については、次を参照： 同期の概念について。
SharePlex は、ALTER SEQUENCE および DROP SEQUENCE コマンドの実行、または DML トランザクション中に加えられた Oracle シーケンスの変更を複製します。必ずしも特定の複製方法のシーケンスを複製する必要はありません。
高可用性：はい
SharePlex がシーケンスを複製する方法によって、ユーザーはフェイルオーバーデータベースをシーケンスを増分したり、再利用したりすることなく、直ちに使用し始めることができます。
レポート作成、データ共有、その他の基本的な一方向の複製：いいえ
シーケンスがターゲットシステムで不要な場合は、複製しないでください。複製を低速する可能性があります。ソーステーブルでキーを生成するためにシーケンスを使用した場合でも、シーケンスの値は、複製された行がターゲットシステムに挿入されたときのキー列の一部です。シーケンスそのものは複製する必要がありません。
ピアトゥピア：いいえ
SharePlex は同一シーケンスのピアトゥピア複製をサポートしません。詳細については、次を参照： 複数のピアデータベースを保持するための複製の設定。
シーケンスを複製用に設定するには
シーケンスのターゲットシステムでの一意性を保証するには、ターゲットシーケンスの開始値がソースシーケンスの開始点より大きくなければなりません。次の公式を使って、ターゲットの 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) は、2 GB 以下でなければなりません。そうでないと、シーケンスの複製が失敗します。
SharePlex では、以下のように ALTER SEQUENCE コマンドを使用してターゲットデータベース内のシーケンスを更新します。
増分値を以下の値に変更します。
source_INCREMENT_BY_valuexsource_CACHE_value
次の値を設定して再度シーケンスを ALTER します。
Increment_value=source_INCREMENT_BY_value
Cache_value=source_CACHE_value
SharePlex では、ALTER SEQUENCE 操作はシーケンスに対する単純な SELECT（UPDATE）のように処理されます。これは、REDO ログレコードでこの 2 つの操作が区別されないためです。
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy
