Chat now with support
Chat with Support

Please note, you may experience access issues between 6am - 7am Eastern time on Saturday, May 28 2022 due to planned maintenance

SharePlex 8.6.6 - リファレンス・ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex コマンド SharePlex パラメータ SharePlex ユーティリティ 付録 B:SharePlex 環境変数

複製する Oracle データベースオブジェクトのセットアップ

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

行の一意性の保証

SharePlex では、ターゲット上で変更する行がソース行と一致する正しい行であることを保証できる必要があります。これは、キーとインデックスを使用して 1 対 1 の関係を保証することで実現できます。

キーの役割

SharePlex は複製するすべてのソーステーブルおよびターゲットテーブル、特に大きなテーブルや LONG 列を含むテーブルに対してプライマリキーまたは一意のキーが存在する場合に、最も速く動作します。使用するキーを選択するとき、SharePlex は最適なキー列を次の優先順位で使用します。

  • 主キー
  • 少なくとも列の 1 つが NULL でない、最小の列のある一意のキー
  • 最小の列ある一意のキー。

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

テーブルにプライマリキーまたは一意のキーがない場合、または 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 を含むキー

もしキーで 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 は Post で変更する行を見つけるためにテーブル全体をスキャンします。
  • いくつかのアプリケーションでは主キーの制約が使用されないため、デフォルトで一意のインデックスが作成されません。しかし、人の名前または従業員の ID 番号などの一意の値が入力された 1 つまたは複数の列に対してインデックスが作成されたのに、一意なインデックスとして名前が付けられない(CREATE UNIQUE INDEX コマンドが使用されなかった)場合もあります。テーブルに対して一意のインデックスが存在しない場合は、設定ファイルを作成するときに一意のインデックスを作成するか、ユーザー定義のキーを指定することをお勧めします。詳細については、次を参照: 一意のキーの定義
  • 一度一意のインデックスを識別または作成したら、SharePlex の hints 機能を使って Oracle が確実にそのインデックスを使用するようにできます。詳細については、次を参照: Oracle INDEX ヒントの使用
  • テーブルに外部キーがある場合は、外部キーへの変更によってフルテーブルスキャンが実行されることのないように、正しい列に対してインデックスを作成します。

  • インデックスは常に更新しないと、Post プロセスが遅くなります。断片化されたものは再構築します。

ターゲットテーブルのインデックスが多すぎると、行の追加や削除の際に、Oracle がそれらをすべて更新する必要があります。これにより複製を含み、システム全体が遅くなります。インデックスの数は、最も有用性が高いものに限定することを検討してください。

主に 1 種類の DML を実行するアプリケーションでは、以下の点を考慮します。

  • INSERT:メンテナンスを制限するために、使用するインデックスの数を数個に抑えます。
  • UPDATE:INSERT 文の後で変更されない列のインデックスを使用します。
  • DELETE:できる限りインデックスを削除します。

何百万もの SQL 操作を行う、大きなバッチジョブを実行するときは、不要なインデックス群をバッチジョブの前に削除し、最後に再構築します。これによって、SharePlex の動作速度が向上し、以後のインデックスが整理されます。

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

パフォーマンス向上のため、Post プロセスがデータを適用している間は、ビットマップインデックスを使用しないでください。これらのインデックスによって Post プロセスのパフォーマンスに悪影響が及ぶ可能性があります。

ターゲットテーブルでビットマップインデックスを使用する必要がある場合は、クエリの利点と Post によって適用されるトランザクションへの影響とを比較検討してください。

  • Oracle がビットマップエントリを追加または更新するとき、ビットマップセグメントに関連付けられたすべての行をロックします。
  • 1 つのビットマップセグメントは何百もの行への参照を含むことができます。その結果、異なる Post セッションによる変更(ソースシステムの 1 つのセッションについて 1 つの Post セッションがあります)が、同じビットマップセグメント内のビットマップエントリを更新する場合、互いにブロックする可能性があります。
  • 続行するには、Post がこのブロックを検出し解決しなければなりませんが、ロックされた数が多い場合は Post が著しく遅れます。
  • 一般的に、複数の同時セッションによるビットマップインデックスを持つテーブルへの頻繁な挿入はロック競合の原因となりますが、このようなテーブルへの任意の更新および削除は競合が発生することはありません。SharePlex では Oracle からの推奨に従い、静的なテーブル上にビットマップインデックスを持ちます。

注: ビットマップインデックスを複製することはお勧めしません。ビットマップインデックスを持つテーブルを変更するたびに、インデックスが再構築されます。この再構築に関連するコスト(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 に対してトリガが起動されているため、この行はすでに存在します。

トリガは、複製方法に応じて以下のように処理できます。

複製方法 ターゲットでのトリガの処理方法

高可用性

および

ピアトゥピア

  1. フェイルオーバーに備えて、またはトランザクションが複数のソースシステムで実行されるため、SharePlex 以外のユーザーのトリガを有効にします。
  2. sp_add_trigger.sql スクリプトを実行して、SharePlex ユーザーのトリガを無効にします。このスクリプトは個々のトリガの文に、SharePlex ユーザーによって post された操作を無視するように指示する WHEN 句を置きます。
レポート作成、データ共有、その他の基本的な一方向の複製
  • ターゲットシステムでトリガを完全に無効にするか、または sp_add_trigger.sql スクリプトを実行して、SharePlex ユーザーによって post される操作を無視します。
  • トリガスクリプトの使用方法に関する重要な情報については、『 SharePlex リファレンスガイド』を参照してください。

    整合性制約の設定

    整合性制約は複製に影響します。以下のガイドラインに従って、整合性制約が確実に処理されるようにしてください。

    外部キー制約

    外部キー制約は、ターゲットテーブルで無効にする必要があります。SharePlex は、ソースの外部キー制約の結果を複製します。ソースの外部キーの結果を正確に複製するには、相互に外部キーを持つテーブルをすべて複製設定に含める必要があります。参照制約を持つすべてのテーブルが、ターゲットデータベースに存在している必要があります。1 つまたは複数のテーブルが欠けている場合は参照整合性が破損してしまう場合があります。

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

    ON DELETE CASCADE 制約

    SharePlex では、ターゲットテーブルで ON DELETE CASCADE 制約を有効にしたままにできますが、この機能は有効にする必要があります。Post は、ON DELETE CASCADE 依存性を検出し、子テーブルへの複製されたカスケード削除の post 操作をすべて抑止します。

    SharePlex を介してこのサポートを有効にしない場合は、ターゲットでこれらの制約を手動で無効にする必要があります。そうしないと、SharePlex によってプライマリ削除とカスケード削除の両方が複製され、ターゲットで削除がカスケードされたときに競合とエラーが発生します。

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

    • ソースでのプライマリキー、一意のインデックス列、および外部キー列のロギングを有効にします。
    • 以下の SharePlex パラメータを設定します。

      • SP_OPO_DEPENDENCY_CHECK パラメータを 2
      • SP_OCT_REDUCED_KEY パラメータを 0
      • SP_OPO_REDUCED_KEY パラメータを 0、1、または 2(:ピアトゥピアレプリケーションでは、このパラメータは 0 に設定する必要があります)

    チェック制約

    ターゲットシステムでチェック制約を無効にします。チェック制約により、不要なオーバーヘッドが増加します。これらのチェックはソースシステム上で満たされているため、適切に管理および同期された複製環境では冗長です。高可用性を目的とする場合は、フェイルオーバーの手順の一部として制約を再度有効にするスクリプトを構築することができます。

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

    ピアトゥピアレプリケーションを除くすべてのシナリオにおいて、SharePlex データベースユーザーのみがターゲットオブジェクトに対して DML または DDL を実行できるようにする必要があります。他のユーザー、ジョブ、またはアプリケーションによってターゲットオブジェクトに DML または DDL の変更が加えられた場合、ターゲットデータはもはやソースシステム上のデータの状態を反映していない可能性があります。詳細については、次を参照: 同期の概念について

    シーケンスの設定

    SharePlex は、ALTER SEQUENCE および DROP SEQUENCE コマンドの実行、または DML トランザクション中に加えられた Oracle シーケンスの変更を複製します。必ずしも特定の複製方法のシーケンスを複製する必要はありません。

    • 高可用性はい

      SharePlex がシーケンスを複製する方法によって、ユーザーはフェイルオーバーデータベースをシーケンスを増分したり、再利用したりすることなく、直ちに使用し始めることができます。

    • レポート作成、データ共有、その他の基本的な一方向の複製いいえ

      シーケンスがターゲットシステムで不要な場合は、複製しないでください。複製を低速する可能性があります。ソーステーブルでキーを生成するためにシーケンスを使用した場合でも、シーケンスの値は、複製された行がターゲットシステムに挿入されたときのキー列の一部です。シーケンスそのものは複製する必要がありません。

    • ピアトゥピアいいえ

      SharePlex は同一シーケンスのピアトゥピア複製をサポートしません。詳細については、次を参照: 複数のピアデータベースを保持するための複製の設定

    シーケンスを複製用に設定するには

    • キャッシュを使用して、キャッシュの増分を 20 以上に設定します。シーケンスがキャッシュに格納されると、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

    • NOCACHE に設定します。
    • シーケンスを UPDATE します。
    • 次の値を設定して再度シーケンスを ALTER します。

      Increment_value=source_INCREMENT_BY_value

      Cache_value=source_CACHE_value

    SharePlex では、ALTER SEQUENCE 操作はシーケンスに対する単純な SELECT(UPDATE)のように処理されます。これは、REDO ログレコードでこの 2 つの操作が区別されないためです。

    Related Documents

    The document was helpful.

    Select Rating

    I easily found the information I needed.

    Select Rating