| Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド リリース11.2.1 B56053-02 |
|
 戻る |
 次へ |
| Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド リリース11.2.1 B56053-02 |
|
戻る |
次へ |
この章では、TimesTenレプリケーションの概要を説明します。内容は次のとおりです。
レプリケーションとは、複数のデータベースにデータのコピーを保持するプロセスのことです。レプリケーションは、パフォーマンスへの影響を最小限に抑えながら、アプリケーションでのデータの高可用性を実現することを目的としています。最大限の高可用性を実現するには、アクティブ・スタンバイ・ペア構成をお薦めします。アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、データは読取り専用サブスクライバにコピーされる前に、アクティブ・データベースからスタンバイ・データベースにコピーされます。
障害からのリカバリ以外に、レプリケーション・スキームでは、アプリケーションのワークロードを複数のデータベースに分散して最高のパフォーマンスを実現し、オンラインによるアップグレードおよびメンテナンスを簡素化することもできます。
レプリケーションとは、データをマスター・データベースからサブスクライバ・データベースにコピーするプロセスのことです。レプリケーションは、各データベースのレプリケーション・エージェントによって制御されます。マスター・データベースのレプリケーション・エージェントは、マスター・データベースのトランザクション・ログからレコードを読み取ります。レプリケーション・エージェントは、レプリケート対象の要素に対する変更をサブスクライバ・データベースのレプリケーション・エージェントに転送します。その後、サブスクライバ・データベースのレプリケーション・エージェントが、それらの更新をサブスクライバ・データベースに適用します。マスターからの更新転送時にサブスクライバのレプリケーション・エージェントが稼働していない場合、サブスクライバ・データベースで更新が適用されるようになるまで、マスターはその更新をトランザクション・ログに保持します。
データベース間でレプリケートされるエンティティは、レプリケーション要素と呼ばれます。TimesTenでは、レプリケーション要素として、データベース、キャッシュ・グループ、表および順序がサポートされています。また、TimesTenではXLAブックマークもレプリケートされます。アクティブ・スタンバイ・ペアは、キャッシュ・グループが構成されたデータベースでサポートされる唯一のレプリケーション・スキームです。
マスター・データベースとサブスクライバ・データベースは、オペレーティング・システム、CPUタイプおよびワード・サイズが同じであるマシンに存在する必要があります。同一マシン上のデータベース間でレプリケートすることもできますが、通常、レプリケーションは、別のマシン上のデータベースに更新をコピーするために使用します。こうすることで、ノード障害によるデータの損失を防ぐことができます。
データベースには、同じDatabaseCharacterSetデータベース属性およびTypeModeデータベース属性を持つDSNが必要です。
|
注意: 現在のリリースのTimesTenのデータベースと7.0より前のTimesTenのデータベース間でレプリケーションが構成されている場合は、レプリケーションの互換性の要件に追加の制限があります。データベースは、TIMESTEN8のDatabaseCharacterSetデータベース属性を指定して構成されている場合、7.0より前のTimesTenリリースに対してのみレプリケートできます。また、データベースでは、列が本来のTimesTenデータ型（接頭辞がTT_のデータ型またはBINARY_FLOATデータ型とBINARY_DOUBLEデータ型）の表のみをレプリケートできます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のOracle型モードで下位互換用にサポートされている型に関する説明を参照してください。 |
データベース間でのレプリケーションは、レプリケーション・エージェントによって制御されます。各データベースは、次の情報によって識別されます。
データベースに対するファイル・システムのパス名から導出されるデータベース名
ホスト名
マスター・データベースのレプリケーション・エージェントは、トランザクション・ログからレコードを読み取り、レプリケート対象の要素への変更を検出した場合はそれらをサブスクライバ・データベースのレプリケーション・エージェントに転送します。その後、サブスクライバ・データベースのレプリケーション・エージェントが、それらの更新をサブスクライバ・データベースに適用します。マスター・エージェントは、更新転送時にサブスクライバ・エージェントが稼働していない場合、転送可能になるまでそれらの更新をログに保持します。
レプリケーション・エージェントは、TCP/IPストリーム・ソケットを介して通信します。レプリケーション・エージェントは、TCP/IPアドレス、ホスト名およびその他の構成情報をレプリケーション表から取得します。詳細は、Oracle TimesTen In-Memory Databaseのシステム表および制限についてのマニュアルを参照してください。
デフォルトでは、更新はデータベース間で非同期にコピーされます。非同期レプリケーションでは、最高のパフォーマンスが実現しますが、レプリケート対象の更新がサブスクライバ・データベースでコミットされたことを示す確認応答はアプリケーションに送信されません。マスター・データベースとサブスクライバ・データベース間でのレプリケート・データの一貫性をより高いレベルで保証する必要があるアプリケーションでは、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスのいずれかを有効にできます。
RETURN RECEIPTサービスでは、サブスクライバが更新を受信したことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、アプリケーションをレプリケーション・メカニズムと緩やかに同期化します。RETURN TWOSAFEサービスでは、サブスクライバが更新を受信およびコミットしたことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、完全な同期化が行われます。
RETURN RECEIPTレプリケーションでは、同期性を低くすることによって、RETURN TWOSAFEレプリケーションよりパフォーマンスへの影響が小さくなっています。非同期、RETURN RECEIPTおよびRETURN TWOSAFEのレプリケーションの動作の詳細は、次の項を参照してください。
デフォルトのTimesTenレプリケーションを使用した場合、アプリケーションは、マスター・データベースを更新すると、サブスクライバがその更新を受信および適用するまで待機せずに処理を続行します。マスターおよびサブスクライバのデータベースには、サブスクライバが更新を正常に受信およびコミットしたことを確認するための内部メカニズムがあります。これらのメカニズムは、更新がサブスクライバで1回のみ適用されることを保証しますが、アプリケーションからは完全に独立しています。
デフォルトのTimesTenレプリケーションは、最高のパフォーマンスを実現しますが、アプリケーションは、サブスクライバ上のレプリケート対象の要素の受信プロセスと完全に切り離されます。
デフォルトのTimesTenレプリケーション・サイクルは次のとおりです。
アプリケーションは、ローカル・トランザクションをマスター・データベースにコミットし、他のトランザクションを続行できます。
コミット時に、TimesTen Data Managerがトランザクションの更新レコードをトランザクション・ログ・バッファに書き込みます。
マスター・データベースのレプリケーション・エージェントは、コミット済トランザクションの更新レコードのバッチをログ・バッファからトランザクション・ログ・ファイルにフラッシュするようにData Managerに指示します。マスターで障害が発生して、チェックポイント・ファイルおよびトランザクション・ログ・ファイルからデータベースをリカバリする必要がある場合は、この手順によって、リカバリされたマスターにサブスクライバにレプリケートしたすべてのデータが含まれていることが保証されます。
マスター・レプリケーション・エージェントは、トランザクション更新レコードのバッチをサブスクライバ・レプリケーション・エージェントに転送します。サブスクライバ・レプリケーション・エージェントは、それらをサブスクライバ・データベースに適用します。更新レコードは、マスター・データベースのトランザクション・ロードに応じて256KB以下のバッチでディスクにフラッシュされ、サブスクライバに転送されます。バッチは、トランザクション・ログ・バッファにログ・データがなくなった場合、または現在のバッチがほぼ256KBの場合に作成されます。
サブスクライバ・レプリケーション・エージェントは、更新レコードのバッチを受信したことを示す確認応答をマスター・レプリケーション・エージェントに返信します。確認応答には、サブスクライバが最後にディスクにフラッシュしたレコードのバッチに関する情報が含まれます。これで、マスター・レプリケーション・エージェントは、すべてのサブスクライバが受信、適用およびディスクへのフラッシュを完了した更新レコードをトランザクション・ログからパージし、別の更新レコードのバッチを送信できます。サブスクライバ・レプリケーション・エージェントは、非同期で手順6の処理に進みます。
サブスクライバ・レプリケーション・エージェントは、データベースを更新し、そのData Managerにトランザクション更新レコードをトランザクション・ログ・バッファに書き込むように指示します。
サブスクライバ・データベースのレプリケーション・エージェントは、個別のスレッドを使用して、トランザクション・ログ・ファイルに更新レコードをフラッシュするようにData Managerに指示します。
RETURN RECEIPTサービスは、マスターでのコミット後、コミットされたトランザクションの更新をサブスクライバが受信するまでアプリケーションをブロックして、マスター・データベースとサブスクライバ・データベース間に特定のレベルの同期を提供します。
RETURN RECEIPTをリクエストするアプリケーションは、基本的な非同期の場合と同じ方法でマスター・データベースを更新します。ただし、レプリケート対象の要素を更新するトランザクションをアプリケーションでコミットすると、マスター・データベースは、そのトランザクションの更新がサブスクライバで受信されたことを示す確認応答を受信するまでアプリケーションをブロックします。
RETURN RECEIPTレプリケーションでは、パフォーマンスは低下しますが、マスター・データベースとサブスクライバ・データベース間でのより高いレベルのデータの整合性および一貫性がアプリケーションで保証されます。このアプリケーションでは、マスターで障害が発生した場合でも、マスターでコミットされたトランザクションがサブスクライバ・データベースに保持されることが高度なレベルで保証されます。
図1-2は、RETURN RECEIPTレプリケーション・サイクルが図1-1に示した基本的な非同期サイクルと同じであることを示しています。ただし、マスター・レプリケーション・エージェントは、トランザクションをコミットした後でアプリケーション・スレッドをブロックし（手順1）、サブスクライバが更新バッチの受信を確認する（手順5）までそのアプリケーション・スレッドを制御します。サブスクライバからRETURN RECEIPTの確認応答を受信した時点で、そのアプリケーション・スレッドの制御をアプリケーションに返し（手順6）、アプリケーションでトランザクションを続行できるようにします。
構成可能なタイムアウト時間（デフォルトは10秒）内にサブスクライバがトランザクションの受信を確認できない場合、マスター・レプリケーション・エージェントは、サブスクライバから更新の確認応答を受信しなかったことを示す警告を返し、スレッドの制御をアプリケーションに返します。その後、アプリケーションは、マスターに対して別のトランザクションをコミットできるようになり、マスターは以前と同様にサブスクライバへのレプリケーションを続行します。RETURN RECEIPTトランザクションでタイムアウトが発生する原因は多数考えられます。最も可能性の高い原因は、ネットワークの問題、レプリケーション・エージェントの障害、またはマスター・レプリケーション・エージェントでトランザクション・ロードに対して大幅な遅延が発生しているため、タイムアウトが発生する前にRETURN RECEIPTトランザクションをレプリケートできない場合です。RETURN RECEIPTタイムアウトの管理方法については、「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。
RETURN RECEIPTレプリケーションの構成方法については、「RETURN RECEIPT」を参照してください。
RETURN TWOSAFEサービスは、マスターとサブスクライバ間の完全な同期レプリケーションを実現します。トランザクションがマスターでコミットされた後にサブスクライバに送信される前述のレプリケーション・モードとは異なり、TWOSAFEモードのトランザクションは、マスターでコミットされる前に、まずサブスクライバでコミットされます。
|
注意: RETURN TWOSAFEサービスは、双方向レプリケーション・スキームでのみ使用できます。このスキームには、単一のマスターおよびサブスクライバが存在し、データベース全体がレプリケーション要素です。 |
RETURN TWOSAFEレプリケーションに構成された、マスターとサブスクライバ間でのレプリケーションの動作を次に説明します。
アプリケーションが、マスター・データベースでトランザクションをコミットします。
マスター・レプリケーション・エージェントが、トランザクション・レコードをログに書き込み、特殊なプリコミット・ログ・レコードをコミット・レコードの前に挿入します。このプリコミット・レコードは、サブスクライバでのコミットのステータスを示す確認応答をマスター・レプリケーションが受信するまで、ログ内でプレース・ホルダとして機能します。
|
注意: RETURN TWOSAFEトランザクションの送信は非永続的です。このため、マスター・レプリケーション・エージェントは、サブスクライバに送信する前のログ・レコードをディスクにフラッシュすることはできません。この処理は、レプリケーションが非同期またはRETURN RECEIPTのレプリケーションに構成されている場合、デフォルトで行われます。 |
マスター・レプリケーション・エージェントが、更新レコードのバッチをサブスクライバに送信します。
サブスクライバ・レプリケーション・エージェントが、サブスクライバ・データベースでトランザクションをコミットします。
サブスクライバ・レプリケーション・エージェントが、サブスクライバでトランザクションがコミットされたかどうか、およびコミットが成功したかどうかについての通知とともに確認応答を返します。
サブスクライバでコミットが成功した場合、マスター・レプリケーション・エージェントが、マスター・データベースでトランザクションをコミットします。
マスター・レプリケーション・エージェントが、制御をアプリケーションに返します。
構成可能なタイムアウト時間（デフォルトは10秒）内にサブスクライバがトランザクションのコミットを確認できない場合、またはサブスクライバからの確認応答がコミットの失敗を示している場合、レプリケーション・エージェントは、マスター・データベースでトランザクションをコミットせずに制御をアプリケーションに返します。その後、アプリケーションは、無条件にコミットするか、コミットを再試行するかを決定できます。必要に応じて、マスター・レプリケーション・エージェントに指示してタイムアウトしたすべてのトランザクションをコミットするようにレプリケーション・スキームを構成できます。
RETURN TWOSAFEレプリケーションの構成方法については「RETURN TWOSAFE」を参照してください。
レプリケーション・スキームを作成して、マスターおよびサブスクライバのデータベースの特定の構成を定義できます。この項では、レプリケーション・スキームの作成時に、マスター・データベースとサブスクライバ・データベース間に定義可能な関係について説明します。
マスターとサブスクライバ間の関係を定義する場合、次のレプリケーション・スキームついて考慮する必要があります。
図1-4に、アクティブ・データベース、スタンバイ・データベースおよび4つの読取り専用サブスクライバ・データベースで構成されたアクティブ・スタンバイ・ペアのレプリケーション・スキームを示します。
アクティブ・スタンバイ・ペアはデータベース全体をレプリケートすることも、表およびキャッシュ・グループなどの要素を選択することもできます。
アクティブ・スタンバイ・ペアでは、2つのデータベースがマスターとして定義されます。1つは、アクティブ・データベースで、もう1つはスタンバイ・データベースです。アクティブ・データベースは、アプリケーションで直接更新されます。スタンバイ・データベースは、直接更新できません。スタンバイ・データベースは、アクティブ・データベースからの更新を受信し、それらの変更を最大127の読取り専用サブスクライバ・データベースに伝播します。この設定では、スタンバイ・データベースがサブスクライバ・データベースより常に先行し、アクティブ・データベースで障害が発生した場合は、スタンバイ・データベースに即時にフェイルオーバーできます。
1つのマスター・データベースのみが、特定の時間にアクティブ・データベースとして機能できます。Oracle Clusterwareを使用して、アクティブ・スタンバイ・ペアのフェイルオーバーおよびリカバリを管理できます。第7章「Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理」を参照してください。また、フェイルオーバーおよびリカバリを手動で管理することもできます。第4章「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの管理」を参照してください。
スタンバイ・データベースで障害が発生した場合、アクティブ・データベースで読取り専用サブスクライバに変更を直接レプリケートできます。スタンバイ・データベースは、リカバリ後、アクティブ・データベースに接続し、スタンバイ・データベースの停止またはリカバリ中にサブスクライバに送信された更新を受信します。アクティブ・データベースとスタンバイ・データベースで同期が取られている場合、スタンバイ・データベースは、サブスクライバへの変更の伝播を再開します。
アクティブ・スタンバイ・ペアの設定方法の詳細は、「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定」を参照してください。
図1-5に、マスター・データベース全体をサブスクライバにレプリケートする全体レプリケーション・スキームを示します。
また、マスター・データベースとサブスクライバ・データベースを構成して、マスター・データベース内の一部の要素を選択してサブスクライバにレプリケートできます。図1-6に、選択レプリケーションの例を示します。図の左側のマスター・データベースでは、同じ要素を選択して複数のサブスクライバにレプリケートしています。一方、右側のマスターでは、サブスクライバごとに異なる要素をレプリケートしています。
この章ではこれまで、マスター・データベースから1つ以上のサブスクライバ・データベースに更新を送信する単方向レプリケーションについて説明しました。ただし、各データベースがマスターおよびサブスクライバの両方である場合に、双方向に処理するようにデータベースを構成できます。
双方向レプリケーションには、次の基本的な使用方法があります。
分割ワークロード構成では、各データベースが一部の要素に対してはマスターとして、他の要素に対してはサブスクライバとして機能します。
図1-7の例について考えてみます。ここでは、ChicagoのアカウントはデータベースAで処理され、New YorkのアカウントはデータベースBで処理されます。
分散ワークロード・レプリケーション・スキームでは、ユーザーのアクセスは、すべての要素に対する更新を互いにレプリケートする複製アプリケーション/データベースの組合せに分散されます。障害が発生した場合、その影響を受けたユーザーをアプリケーション/データベースの組合せに切り替えることができます。図1-8に、分散ワークロード構成を示します。ユーザーは、他方のデータベースでマスターおよびサブスクライバの両方として機能する、各データベースの複製アプリケーションにアクセスします。
データベースが分散ワークロード構成でレプリケートされる場合、個々のユーザーが同じ行を同時に更新し、互いにその更新をレプリケートする可能性があります。アプリケーションでは、このような更新が発生しないこと、発生した場合でもその競合が許容可能であること、または第14章「レプリケーション競合の解消」で説明している競合解消メカニズムを利用して、競合を適切に解消できることが保証されている必要があります。
|
注意: RETURN TWOSAFE戻りサービスを構成して分散ワークロードを使用しないでください。 |
サブスクライバは、レプリケート対象の更新をマスターから受信して自身のサブスクライバに渡すプロパゲータとして機能するように定義できます。
プロパゲータは、より低い帯域幅のネットワーク接続（イントラネットでのサーバー間の接続など）でのレプリケーション・パフォーマンスの最適化に有効です。たとえば、図1-9に示す直接レプリケーション構成について考えてみます。この構成では、マスターがイントラネット接続を介して4つのサブスクライバに直接レプリケートします。この方法でネットワーク接続を介して各サブスクライバにレプリケートすると、ネットワークの帯域幅が効率的に使用されません。
最適なパフォーマンスを実現するために、図1-10に示す構成について考えてみます。この構成では、マスターは、ネットワーク接続を介して1つのプロパゲータにレプリケートします。その後、このプロパゲータが、自身のローカル・エリア・ネットワーク上の各サブスクライバに更新を転送します。
また、プロパゲータは、多数のサブスクライバにレプリケートする必要があるマスター・データベースを含む構成でレプリケーション・ロードを分散する場合にも有効です。たとえば、図1-11に示すとおり、マスターで、12のサブスクライバに直接レプリケートするより、3つのプロパゲータにレプリケートする方がより効率的です。
|
注意: 各プロパゲータはワン・ホップです。つまり、更新を1回のみ転送できます。プロパゲータを階層化して、プロパゲータ間で更新を転送することはできません。 |
『Oracle In-Memory Database Cacheユーザーズ・ガイド』で説明されているように、キャッシュ・グループとは、中央のOracle Databaseに保存されている表のグループが、ローカルのOracle In-Memory Database Cache（IMDB Cache）にキャッシュされたものです。この項では、TimesTenデータベース間でキャッシュ・グループをレプリケートする方法について説明します。アクティブ・スタンバイ・ペアを使用して、ASYNCHRONOUS WRITETHROUGHキャッシュ・グループまたは読取り専用キャッシュ・グループをレプリケートすることにより、高可用性を実現できます。
この項では、キャッシュ・グループをレプリケートする次の方法について説明します。
キャッシュ・グループのレプリケーションの構成の詳細は、第5章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。
ASYNCHRONOUS WRITETHROUGH（AWT）キャッシュ・グループを、オプションの読取り専用サブスクライバを持つアクティブ・スタンバイ・ペアの一部として構成すると、高可用性を実現し、アプリケーションのワークロードを分散できます。図1-12にこの構成を示します。
アプリケーションによる更新は、アクティブ・データベースに対して行われ、スタンバイ・データベースにレプリケートされてから、そのスタンバイによってOracle Databaseに非同期で書き込まれます。同時に、これらの更新は、スタンバイから読取り専用サブスクライバにレプリケートされ、読取り専用サブスクライバによって、読取りアプリケーションのロードが分散されます。読取り専用サブスクライバにある表は、キャッシュ・グループにはありません。
スタンバイ・データベースが存在しない場合、アクティブによって、アプリケーションによる更新の受入れおよびOracle Databaseと読取り専用サブスクライバへの非同期での更新の書込みの両方が実行されます。このような状況は、スタンバイが作成されていない場合、またはアクティブで障害が発生し、スタンバイが新しいアクティブになった場合に発生します。TimesTenでは、スタンバイが新しいアクティブになった場合、AWTキャッシュ・グループが再構成されます。
アクティブ・データベースのあるノードで障害が発生した場合、スタンバイ・ノードが新しいアクティブ・ノードになります。TimesTenは、アプリケーションから直接更新され、Oracleへ非同期に更新の伝播を続行できるように、自動的にAWTキャッシュ・グループを再構成します。
アクティブ・スタンバイ・ペアのレプリケーション構成の一部として、障害時リカバリ用の特別な読取り専用サブスクライバをリモート・サイトに作成することによって、サイトの完全な障害からリカバリできます。図1-13にこの構成を示します。
スタンバイ・データベースは、読取り専用サブスクライバのキャッシュ・グループ表に更新を送信します。この特別なサブスクライバはリモートの障害時リカバリ・サイトに配置されており、（同様に障害時リカバリ・サイトに配置されている）2番目のOracle Databaseに更新を伝播できます。読取り専用サブスクライバおよびOracle Databaseを持つ障害時リカバリ・サイトを2つ以上設定できます。「アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用」を参照してください。
読取り専用キャッシュ・グループのキャッシュ動作では、Oracle表でコミットされた更新が対応するTimesTenキャッシュ表に自動的にリフレッシュされます。図1-14に、アクティブ・スタンバイ・ペアによってレプリケートされた読取り専用キャッシュ・グループを示します。
図1-14 アクティブ・スタンバイ・ペアによる読取り専用キャッシュ・グループのレプリケーション
読取り専用キャッシュ・グループがアクティブ・スタンバイ・ペアによってレプリケートされると、アクティブ・データベースのキャッシュ・グループがOracle Databaseから自動リフレッシュされ、更新がスタンバイにレプリケートされます。スタンバイのキャッシュ・グループにもAUTOREFRESHが構成されていますが、状態はPAUSEDになっています。アクティブに障害が発生した場合に備えてAUTOREFRESH STATEをONに設定しておくと、スタンバイは、障害が発生したマスター・データベースの役割を引き継ぐ際に自動リフレッシュされるように、自動的に再構成されます。また、TimesTenでは、Oracle Databaseからアクティブ・データベースに自動リフレッシュされた更新が、スタンバイにレプリケートされたかどうかも追跡されます。これによって、アクティブで障害が発生した場合でも、自動リフレッシュ・プロセスを適切な時点から継続できるようになり、自動リフレッシュされた更新が失われなくなります。この構成には、読取り専用サブスクライバ・データベースを含めることもできます。これによって、読取りワークロードを多数のデータベースに分散させることができます。スタンバイ・データベースのキャッシュ・グループは、サブスクライバの通常の（キャッシュされていない）表にレプリケートします。
一部のレプリケーション構成では、複数のデータベース間で順序の同期を保持する必要があります。たとえば、順序を使用して各行の主キー値を指定するレプリケート表が含まれているマスター・データベースが存在するとします。サブスクライバ・データベースは、マスター・データベースのホット・バックアップとして使用されています。順序の現在値に対する更新がレプリケートされない場合、マスターで障害が発生した後にサブスクライバで新しい行を挿入すると、最初にマスターで挿入した行と競合する可能性があります。
TimesTenレプリケーションでは、いずれのデータベースで挿入した行もこの構成で競合しないようにするために、順序の値の増分をサブスクライバ・データベースにレプリケートできます。順序をレプリケートするレプリケーション・スキームの作成方法の詳細は、「順序のレプリケート」を参照してください。
ON DELETE CASCADEで構成された外部キーを持つ表をレプリケートする場合は、サブスクライバ上の対応する外部キーもON DELETE CASCADEで構成されている必要があります。また、その表に対して外部キーで関連付けられている他のすべての表もレプリケートする必要があります。この要件によって、マスター・データベースでカスケード削除を実行した場合にサブスクライバ表で競合が発生しなくなります。
TimesTenでは、カスケード削除が1つの操作としてレプリケートされ、親表で行が削除された場合に子表で発生する個々の行削除はサブスクライバにレプリケートされません。そのため、親表で削除された外部キーの値を含む行がサブスクライバ・データベースの子表に存在する場合は、その行も削除されます。その行がマスター・データベースの子表に存在していなかった場合でもこの処理は実行されます。
表またはキャッシュ・グループに最低使用頻度（LRU）または時間ベースのエージングが構成されている場合は、レプリケーションの実行に次のルールが適用されます。
レプリケートされる表およびキャッシュ・グループのエージング構成は、すべてのピア・データベースで同じにする必要があります。
レプリケーション・スキームがアクティブ・スタンバイ・ペアの場合、エージングはアクティブ・データベースでのみ実行されます。エージングによる削除は、スタンバイ・データベースにレプリケートされます。アクティブ・データベースおよびスタンバイ・データベースの両方で、エージング構成がONに設定されている必要があります。TimesTenでは、データベースの役割がアクティブかスタンバイかに基づいて、実際にエージングを実行しているデータベースが自動的に判別されます。
レプリケーション・スキームがアクティブ・スタンバイ・ペアではない場合、エージングは各データベースで個々に実行されます。エージングによって実行された削除は、他のデータベースにレプリケートされません。
アクティブ・スタンバイ・ペアによってレプリケートされたデータベースにASYNCHRONOUS WRITETHROUGHキャッシュ・グループがある場合、エージングによる削除処理はOracle Databaseには伝播されません。
