STORE属性の設定
CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文およびALTER REPLICATION文のSTORE属性句は、RETURNサービス、圧縮、タイムアウト、永続コミット動作および表定義チェックのオプション動作を設定するために使用されます。
クラシック・レプリケーション・スキームでは、競合レポートを表レベルで定義することもできます。
ノート:
このマニュアル内の「RETURNサービスの使用」、および『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE ACTIVE STANDBY PAIRとCREATE REPLICATIONを参照してください。
クラシック・レプリケーション・スキームを使用している場合、FAILTHRESHOLDおよびTIMEOUT属性は、特定のクラシック・レプリケーション・スキーム定義に対して固有に設定できます。つまり、レプリケート・データベースごとに異なるクラシック・レプリケーション・スキーム定義を適用している場合、これらの属性は個別に設定できます。これは他の属性には適用されず、他の属性は、すべてのクラシック・レプリケーション・スキーム定義で同じである必要があります。たとえば、1つのクラシック・レプリケーション・スキームにPORT属性を設定すると、すべてのクラシック・レプリケーション・スキームにその設定が適用されます。STORE句を使用してFAILTHRESHOLD属性を設定するクラシック・レプリケーション・スキームの例は、「クラシック・レプリケーション・スキームでのRETURNサービスの使用」を参照してください。
ノート:
ALTER ACTIVE STANDBY PAIRを使用してSTORE属性のいずれかを変更する場合は、「アクティブ・スタンバイ・ペアに対するその他の変更」で説明されている手順に従う必要があります。
次の各項では、いくつかのSTORE属性について説明します。
レプリケートされた表の列定義オプション
レプリケーション・スキームに含まれるレプリケート表の列の定義は、必ずしも同一である必要はありません。
-
TABLE DEFINITION CHECKING値がEXACTに設定されている場合、列の定義は、アクティブ・データベースとスタンバイ・データベースの間で同一である必要があります。この属性は、物理構造が同一の表のレプリケーションを可能にします。 -
TABLE DEFINITION CHECKING値がRELAXED(デフォルト)に設定されている場合、レプリケート表の列の定義は、同一である必要はありません。RELAXED属性を使用する場合、レプリケート表に同じキー定義、列数、列名および列のデータ型が必要です。表定義チェックが、スタンバイ・データベースで発生します。アクティブ・データベースとスタンバイ・データベースの両方に対してこの属性を
RELAXEDに設定しても、スタンバイ・データベースのみにこの属性値を設定した場合と同じ効果となります。
ノート:
『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE ACTIVE STANDBY PAIRまたはCREATE REPLICATIONを参照してください。
TABLE DEFINITION CHECKING RELAXED属性では、両方のマスター・データベースで表の物理的構造が同じである必要はありません。たとえば、表の列の順序が異なっていたり、表のパーティション数が異なる場合は、データをレプリケートできるのは、RELAXED属性を使用した場合です。このため、列を追加または削除して表を変更する場合、RELAXED属性を使用する必要があります。『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER TABLEに示されているとおり、表の変更時に列を追加すると、さらにパーティションが作成されます。列を削除しても、自動的に領域が解放されることはありません。表を変更するDML文は、マスターで実行された後、スタンバイ・データベースおよびサブスクライバにレプリケートされるようにすることをお薦めします。
異なる物理構造を補っている場合、RELAXED設定によってパフォーマンスがわずかに低下する可能性があります。表の物理構造が同じ場合は、パフォーマンスへの影響はありません。ttMigrate -r -relaxedUpgrade (表定義チェックがRELAXEDに設定されたデータベースでのみ有効)を使用して、表のすべての追加パーティションを1つのパーティションに結合し、削除された列によって発生した余分な領域をなくすことによって、パフォーマンスの問題(異なる物理構造、追加のパーティションまたは余分な領域によるもの)は排除できます。レプリケーション・スキームに含まれるすべてのデータベースでこれを行うと、結果として物理構造が同じになるため、パフォーマンスを最大にすることができます。
ノート:
『Oracle TimesTen In-Memory Databaseモニタリングおよびトラブルシューティング・ガイド』の表のパーティション数の確認を参照してください。
TABLE DEFINITION CHECKINGのEXACTおよびRELAXED属性のパフォーマンスに関する考慮事項は、「レプリケートされる表を変更するときのパフォーマンスの考慮事項」を参照してください。
表定義チェックを確実にRELAXEDに設定するには、アクティブ・データベースまたはマスター・データベースでレプリケーション・エージェントを停止した後、ALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文を実行して、表定義チェックをRELAXEDに設定します。最後に、ttRepAdmin -duplicateコマンドを使用して、これらの変更をスタンバイ・データベースとサブスクライバにロールアウトします。『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER ACTIVE STANDBY PAIRおよびALTER REPLICATIONを参照してください。
次の項では、表定義チェックをRELAXEDに設定する例を示します。
アクティブ・スタンバイ・ペアの表定義チェックをRELAXEDに設定
この例では、アクティブ・スタンバイ・ペア・レプリケーション・スキームで同一の複数の表をレプリケートする方法を実際に示します。この例では、TABLE DEFINITION CHECKING属性をEXACTに設定します。
-
master1データベースに表t1を作成します。CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c INT);
-
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
master2スタンバイ・データベースに対して、TABLE DEFINITION CHECKINGをEXACTに設定します。Command> CREATE ACTIVE STANDBY PAIR master1, master2 STORE master2 TABLE DEFINITION CHECKING EXACT; -
残りのステップを実行してアクティブ・データベースをスタンバイ・データベースに複製し、レプリケーション・エージェントを両方のデータベースで起動して、アクティブ・データベースの状態を設定します(スタート・ガイドを参照)。
次は、表定義チェックが正確に有効になっていることを確認します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームの表定義チェックをrelaxedに変更できます。まず、アクティブ・データベースを変更する前に、アクティブ・データベースのレプリケーション・エージェントを停止します。次のようにすると、dsn1アクティブ・データベースが変更されるため、表定義チェックはRELAXEDに設定されます。
ALTER ACTIVE STANDBY PAIR ALTER STORE master1 SET TABLE DEFINITION CHECKING RELAXED;
処理が完了したら、複製を使用して変更をスタンバイ・データベースにロールアウトします。最後に、複製によってサブスクライバに変更がロールアウトされます。
表定義チェックをRELAXEDに設定したクラシック・レプリケーション・スキームの例
この例では、クラシック・レプリケーション・スキームで同一の複数の表をレプリケートする方法を実際に示します。この例では、TABLE DEFINITION CHECKING属性をEXACTに設定します。
-
dsn1データベースに表t1を作成します。CREATE TABLE ttuser.t1 (a INT PRIMARY KEY, b INT, c INT);
-
ttuser.t1表をdsn2データベースに、dsn1データベースの表と完全に同じに作成します。 -
レプリケーション・スキーム
ttuser.rep1を作成します。サブスクライバdsn2で、TABLE DEFINITION CHECKINGをEXACTに設定します。CREATE REPLICATION ttuser.rep1 ELEMENT e1 TABLE ttuser.t1 MASTER dsn1 SUBSCRIBER dsn2 STORE dsn2 TABLE DEFINITION CHECKING EXACT; -
両方のデータベースのレプリケーション・エージェントを起動します。
dsn1のttuser.t1に行を1つ挿入します。Command> INSERT INTO ttuser.t1 VALUES (4,5,6); 1 row inserted.
-
dsn2のttuser.t1の結果を確認します。Command> SELECT * FROM ttuser.t1; < 4, 5, 6> 1 row found.
次の例では、クラシック・レプリケーション・スキームで異なる位置に列がある表をレプリケートします。この例では、TABLE DEFINITION CHECKING属性をRELAXEDに設定します。
-
dsn1データベースに表t1を作成します。CREATE TABLE ttuser.t1 (a INT PRIMARY KEY, b INT, c INT);
-
dsn1データベースのttuser.t1の列とは異なる順番の列を持つ表ttuser.t1をdsn2データベースに作成します。両方の表で列名およびデータ型が同じであり、両方の表でaが主キーであることに注意します。CREATE TABLE ttuser.t1 (c INT, a INT PRIMARY KEY, b INT);
-
レプリケーション・スキーム
ttuser.rep1を作成します。サブスクライバdsn2で、TABLE DEFINITION CHECKINGをRELAXEDに設定します。CREATE REPLICATION ttuser.rep1 ELEMENT e1 TABLE ttuser.t1 MASTER dsn1 SUBSCRIBER dsn2 STORE dsn2 TABLE DEFINITION CHECKING RELAXED; -
両方のデータベースのレプリケーション・エージェントを起動します。
dsn1のttuser.t1に行を1つ挿入します。Command> INSERT INTO ttuser.t1 VALUES (4,5,6); 1 row inserted.
-
dsn2のttuser.t1の結果を確認します。Command> SELECT * FROM ttuser.t1; < 5, 6, 4 > 1 row found.
次の例では、クラシック・レプリケーション・スキームでパーティションの数が異なる表をレプリケートします。表を変更して列を追加すると、その後その新しい列を削除しても、表のパーティション数は増加します。TABLE DEFINITION CHECKINGをRELAXEDに設定すると、パーティションの数が異なる表をレプリケートできます。
クラシック・レプリケーション・スキームの表定義チェックをRELAXEDに変更できます。まず、マスター・データベースのレプリケーション・スキームを変更する前に、マスター・データベースのレプリケーション・エージェントを停止します。次の例では、dsn1マスター・データベースを変更して、表定義チェックをRELAXEDに設定します。
ALTER REPLICATION reppart ALTER STORE dsn1 SET TABLE DEFINITION CHECKING RELAXED;
処理が完了したら、複製を使用して変更をスタンバイ・マスターにロールアウトします。最後に、複製によってサブスクライバに変更がロールアウトされます。
レプリケートの通信量の圧縮
低帯域幅のネットワークを介してレプリケーションを行う場合、または大量のデータのレプリケーションを行う場合は、レプリケーションに必要な帯域幅の量を減らすCOMPRESS TRAFFIC属性を設定できます。
COMPRESS TRAFFIC属性を使用すると、CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文のSTOREパラメータで指定されたデータベースからレプリケートされたデータが圧縮されます。TimesTenでは、他のデータベースからの通信量は圧縮されません。
圧縮アルゴリズムは速度に関しては最適化されますが、COMPRESS TRAFFIC属性を有効にすると、レプリケーションのスループットおよび待機時間に影響を与えます。
たとえば、アクティブ・データベースdsn1からのレプリケートの通信量は圧縮し、スタンバイ・データベースdsn2からのレプリケートの通信量は圧縮しない場合、CREATE ACTIVE STANDBY PAIR文は次のようになります。
CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2" SUBSCRIBER dsn3 ON "host3" STORE dsn1 ON "host1" COMPRESS TRAFFIC ON;
アクティブ・データベースdsn1とスタンバイ・データベースdsn2の両方からレプリケートされた通信量を圧縮するには、次を使用します。
CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2" SUBSCRIBER dsn3 ON "host3" STORE dsn1 ON "host1" COMPRESS TRAFFIC ON STORE dsn2 ON "host2" COMPRESS TRAFFIC ON;
クラシック・レプリケーション・スキーム内の1つのデータベースdsn1からレプリケートされた通信量のみを圧縮し、他のデータベース(dsn2など)からレプリケートされた通信量は圧縮しないで残すことができます。次のようにCREATE REPLICATION文を使用します。
CREATE REPLICATION repscheme
ELEMENT d1 DATASTORE
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT d2 DATASTORE
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 COMPRESS TRAFFIC ON;クラシック・レプリケーション・スキームのdsn1データベースとdsn2データベース間のレプリケートの通信量を圧縮するには、次を使用します。
CREATE REPLICATION scheme
ELEMENT d1 DATASTORE
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT d2 DATASTORE
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 COMPRESS TRAFFIC ON
STORE dsn2 ON host2 COMPRESS TRAFFIC ON;ポート割当て
CREATE ACTIVE STANDBY PAIR文およびCREATE REPLICATION文のSTORE属性に対するPORTパラメータは、別のデータベースから更新をリスニングするためにデータベースにより使用されるポート番号を設定します。
-
アクティブ・スタンバイ・ペアでは、スタンバイ・データベースは、アクティブ・データベースからの更新をリスニングします。読取り専用サブスクライバは、スタンバイ・データベースからの更新をリスニングします。
-
クラシック・レプリケーション・スキームでは、サブスクライバは、マスター・データベースからの更新をリスニングします。1つのクラシック・レプリケーション・スキームに
PORT属性を設定すると、すべてのクラシック・レプリケーション・スキームにその設定が適用されます。
静的ポートの割当てをお薦めします。PORT属性を設定しない場合、TimesTenデーモンが動的にポートを選択します。ポートがレプリケーション・エージェントに動的に割り当てられる場合は、TimesTenデーモンのポートも一致させる必要があります。
ノート:
オンラインによるアップグレードを行う場合は、静的ポートを割り当てる必要があります。
ポートを静的に割り当てる場合は、STORE属性に完全なホスト名、DSNおよびポートを指定する必要があります。
アクティブ・スタンバイ・ペアに静的ポートを割り当てる例
CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2" SUBSCRIBER dsn3 ON "host3" STORE dsn1 ON "host1" PORT 16080 STORE dsn2 ON "host2" PORT 16083 STORE dsn3 ON "host3" PORT 16084;
クラシック・レプリケーション・スキームに静的ポートを割り当てる例
CREATE REPLICATION repscheme
ELEMENT el1 TABLE ttuser.tab
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT el2 TABLE ttuser.tab
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 PORT 16080
STORE dsn2 ON host2 PORT 16083;リモート・レプリケーション・エージェントからの応答の待機タイムアウトの設定
TIMEOUT STORE属性は、レプリケーション・エージェントがリモート・レプリケーション・エージェントからの応答を待機する最大秒数を設定します。
大規模なトランザクションがある場合は、デフォルトのタイムアウト(120秒)を使用することをお薦めします。レプリケーション・エージェントは、リモート・レプリケーション・エージェントからの応答の遅延の原因となる可能性のある大規模なトランザクションに対応するために、トランザクションのサイズに基づいてタイムアウトをスケーリングします。ユーザーがTIMEOUTを60秒以下に設定している場合、レプリケーション・エージェントによる自動スケーリングは無効になっています。
ノート:
何度もタイムアウトが発生し、エラー・ログに多数のトランスミッタおよびレシーバ・スレッドの再開始が記録されていた場合は、レプリケーション・エージェントが現在のタイムアウト値でスケーリングできるよりもトランザクションが大きい可能性があります。トランザクションに対してレプリケーションを進行できるようになるまで、タイムアウト値を増やしてください。
次の例では、マスター・データベースがrep1およびrep2であるアクティブ・スタンバイ・ペアを作成します。サブスクライバrep3が1つあります。レプリケーションのタイプはRETURN RECEIPTです。また、この文では、PORTおよびTIMEOUT属性をマスター・データベースに対して設定します。アクティブ・マスターとスタンバイ・マスターの両方で、TIMEOUT属性は80秒に設定されます。
CREATE ACTIVE STANDBY PAIR rep1, rep2 RETURN RECEIPT SUBSCRIBER rep3 STORE rep1 PORT 21000 TIMEOUT 80 STORE rep2 PORT 22000 TIMEOUT 80;
トランザクション・ログ障害しきい値の設定
しきい値を設定でき、この値を超えると、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なデータベースがfailed状態に設定されます。
-
アクティブ・スタンバイ・ペアでは、トランザクション・ログのしきい値を超えると、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なスタンバイ・データベースまたは読取り専用サブスクライバが
failed状態に設定されます。CREATE ACTIVE STANDBY PAIR文またはALTER ACTIVE STANDBY PAIR文のSTORE句にFAILTHRESHOLD値を指定して、トランザクション・ログのしきい値を設定します。アクティブ・データベースは、スタンバイ・データベースまたは読取り専用サブスクライバ・データベースを
failed状態に設定すると、障害が発生したデータベースのすべてのデータをトランザクション・ログから削除し、障害が発生したデータベースにメッセージを送信します。アクティブ・レプリケーション・エージェントが障害の発生したデータベースのレプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。 -
クラシック・レプリケーション・スキームでは、トランザクション・ログのしきい値を超えると、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なサブスクライバが
failed状態に設定されます。CREATE REPLICATION文またはALTER REPLICATION文のSTORE句にFAILTHRESHOLD値を指定して、トランザクション・ログのしきい値を設定します。例については、「クラシック・レプリケーション・スキームでのRETURNサービスの使用」を参照してください。マスター・データベースは、サブスクライバ・データベースを
failed状態に設定すると、障害が発生したサブスクライバのすべてのデータをトランザクション・ログから削除し、障害が発生したサブスクライバ・データベースにメッセージを送信します。マスター・レプリケーション・エージェントでサブスクライバ・レプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。ただし、サブスクライバは、双方向レプリケーションの場合または他のサブスクライバに更新を伝播するように構成されている場合、マスターからメッセージを受信すると、レプリケーションの状態が損なわれたために、それ以上更新を送信しません。
デフォルトのしきい値は0(ゼロ)で、「制限なし」を意味します。トランザクション・ログ障害しきい値の詳細は、「ロギング用の接続属性の設定」を参照してください。
障害が発生したデータベースに接続中のアプリケーションは、データベースがレプリケーション・ピアによってfailedとマークされたことを示すtt_ErrReplicationInvalid (8025)警告を受信します。データベースにその障害状態が通知されると、アクティブ・データベースまたはマスター・データベースでのその状態はfailedからstopに変更されます。
ノート:
データベースの状態の詳細は、表11-1を参照してください。
アプリケーションでは、ODBCのSQLGetInfo関数を使用して、アプリケーションが接続されているデータベースがfailed状態に設定されているかどうかを確認できます(「サブスクライバの障害」を参照)。
競合への対応としてのクラシック・レプリケーションの一時停止と再開
クラシック・レプリケーションでは、CONFLICT REPORTING SUSPEND属性を使用して、1秒当たりのレプリケーション競合数を表レベルで指定できます。競合数がこの数に到達すると、競合レポート処理が一時停止されます。また、CONFLICT REPORTING RESUME属性を使用して、競合レポート処理が再開する1秒当たりのレプリケーション競合数を指定できます。
レプリケーション競合の解消を参照してください。