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