10 レプリケート・システムの設定

この章では、レプリケーションの設定方法および開始方法について説明します。レプリケート・システムの設定および起動に関連する通常のタスクは、次のとおりです。

タスク	参照先
ネットワークの構成	「ネットワークの構成」
データベースおよび環境の設定	「レプリケーション環境の設定」
レプリケーション・スキームの定義	第9章「レプリケーション・スキームの定義」
データベースへのレプリケーション・スキームの適用	「データベースへのレプリケーション・スキームの適用」を参照してください。
各データベースに対するレプリケーション・エージェントの起動および停止	「レプリケーション・エージェントの起動および停止」を参照してください。
サブスクライバのレプリケーション状態の設定	「サブスクライバのレプリケーション状態の設定」を参照してください。

注意: アクティブ・スタンバイ・ペアを設定する場合は、次の項を参照してください。 「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定」 「読取り専用キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定」 「AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定」

この章の内容は次のとおりです。

• ネットワークの構成

• レプリケーション環境の設定

• 異なるリリース間でのデータベースのレプリケート

• データベースへのレプリケーション・スキームの適用

• レプリケーション・エージェントの起動および停止

• サブスクライバのレプリケーション状態の設定

ネットワークの構成

この項では、ネットワーク上でTimesTenデータをレプリケートする場合に考慮する必要があるいくつかの問題について説明します。主な内容は次のとおりです。

• ネットワーク帯域幅要件

• WAN環境でのレプリケーション

• ホストIPアドレスの構成

• レプリケート・データベースのローカル・ホストの識別

ネットワーク帯域幅要件

TimesTenレプリケーションに必要なネットワーク帯域幅は、レプリケートしているデータの量および頻度によって異なります。ここでは、データ範囲の上位と下位、およびTimesTenデータベース間でデータをレプリケートするために必要なネットワーク帯域幅を特徴付けるトランザクションのタイプについて説明します。

データ範囲の上位は、少量のデータの更新または挿入で特徴付けることができます。これらの更新または挿入では、約1.5から1.6MB/秒でデータをレプリケートできます。データ範囲の下位は、RETURN RECEIPTを指定して実行中の単一のCHAR(10)列更新で特徴付けることができます。この更新では、約125KB/秒でデータをレプリケートできます。

次の表に、レプリケート・レコードのサイズを計算するためのガイドラインを示します。

レコード・タイプ	サイズ
開始トランザクション	48バイト
更新	116バイト ＋18バイト（更新された列ごとに） ＋古い列値のサイズ ＋新しい列値のサイズ ＋主キーまたは一意キーのサイズ
削除	104バイト ＋主キーまたは一意キーのサイズ
挿入	104バイト ＋主キーまたは一意キーのサイズ ＋挿入された行のサイズ

トランザクションはレプリケート対象のデータベース間をバッチで送信されます。マスター・データベースのトランザクション・ログ・バッファにデータがなくなった場合、または現在のバッチがほぼ256KBである場合にバッチが作成されます。詳細は、「データベース間の更新のコピー」を参照してください。

次の表に示すとおり、LANで通常使用される100 Base-Tイーサネットでは、10MB/秒の速度を持続できます。これは、ほとんどのレプリケーションで必要とされる速度に十分対応できる持続帯域幅です。ただし、サーバーがWANで通信している場合、レプリケーション・スキームおよびトランザクション・ロードの構成は、ネットワークの使用可能帯域幅に一致させる必要があります。

ネットワーク領域	ネットワーク	持続速度
LAN	100 Base-Tイーサネット	10MB/秒
WAN	T3	4.8MB/秒
WAN	T2	780KB/秒
WAN	T1	197KB/秒

前述の表のとおり、T3回線では、4.8MB/秒の使用可能帯域幅によって、パフォーマンスを損なうことなく、実行可能な最速のトランザクション速度（合計で3.2MB/秒）で稼働する2つのサブスクライバを十分にサポートできる帯域幅が提供されます。

対照的に、T1回線では、行に1KB未満を挿入するユーザーのRETURN RECEIPTレプリケーションに十分対応できる帯域幅が提供されます。

WAN環境でのレプリケーション

TimesTenレプリケーションでは、TCP/IPプロトコルを使用していますが、このプロトコルはWAN環境用には最適化されていません。WANでのレプリケーションのパフォーマンスは、サードパーティのTCPスタック製品を使用して向上できます。TCPスタックの交換を実行できない場合は、CREATE REPLICATION文にCOMPRESS TRAFFIC属性を設定して、TCP/IPプロトコルで処理する必要があるネットワーク通信量を削減します。詳細は、「レプリケートの通信量の圧縮」を参照してください。

パフォーマンスを向上させるためにTCP/IPカーネル・パラメータを変更する方法については、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』でご使用のプラットフォームに関するインストール情報を参照してください。

ホストIPアドレスの構成

レプリケーション・スキームでは、データベースが存在するホスト・マシンの名前を指定する必要があります。そのホスト名は、オペレーティング・システムによって1つ以上のIPアドレスに変換されます。この項では、各ホスト・マシンに対して正しいホスト名とIPアドレスが使用されるようにレプリケーションを構成する方法について説明します。

この項の内容は次のとおりです。

• ROUTE句を使用したデータベース・ホストとネットワーク・インタフェースの指定

• UNIX上にあるデータベース・ホストのROUTE句を使用しない指定

• Windowsでのホスト名の解決

• TimesTenデーモンおよびサブデーモンのユーザー指定アドレス

ROUTE句を使用したデータベース・ホストとネットワーク・インタフェースの指定

レプリケーション要素でデータベースのホストを指定する場合は、hostnameコマンドによって返される名前を常に使用する必要があります（レプリケーションでは、それと同じホスト名を使用して、現在のホストがレプリケーション・スキームに含まれていることを確認します）。現在のホストが含まれないレプリケーション・スキームは作成できません。

ホストに（IPアドレスが異なる）複数のネットワーク・インタフェースがある場合は、レプリケーションで使用するインタフェースをROUTE句で指定する必要があります。また、各インタフェースに対して優先順位を指定する必要もあります。レプリケーションでは、まず優先順位が最も高いアドレスを使用して接続が試行され、その接続を確立できなかった場合は、接続が確立されるまで優先順に残りのアドレスが試されます。あるIPアドレスを使用しているときにホストへの接続が失敗すると、ROUTE句で複数のアドレスが指定されている場合は、別のIPアドレスへの再接続（フォールバック）が試行されます。

注意: ROUTE句のアドレスは、ホスト名またはIPアドレスのいずれかとして指定できます。ただし、あるホスト名に対して複数のIPアドレスが構成されているホストの場合は、IPアドレスを使用してROUTE句を構成する必要があります。これは、意図したIPアドレスのみをレプリケーションで確実に使用するためです。

詳細は、「ネットワーク操作の構成」を参照してください。

UNIX上にあるデータベース・ホストのROUTE句を使用しない指定

レプリケーション構成がIPアドレスではなくホスト名で指定されている場合、レプリケーションではピアのホスト名をIPアドレスに変換できる必要があります。Windowsでこれを効率的に行うには、有効なWINSサーバーまたは有効なDNSサーバーのいずれかを問い合せるように各Windowsマシンが設定されていることを確認してください。これらのサーバーにはネットワーク上のホストに関する正しい情報があります。このようなサーバーがない場合、次のいずれかの方法で静的なHOST-to-IPエントリを入力できます。

データベース・ホストと、レプリケーションに使用するネットワーク・インタフェースを指定するには、可能な場合は、レプリケーション・スキームのROUTE句を使用する必要があります。ただし、この項では、ROUTE句を使用しないレガシー・レプリケーション構成がある場合に、複数のネットワーク・インタフェースを持つレプリケーション・ホストのオペレーティング・システムおよびDNSファイルを構成する方法について説明します。

ホストに（IPアドレスが異なる）複数のネットワーク・インタフェースがあり、レプリケーションがROUTE句で構成されていない場合、TimesTenレプリケーションでは、gethostbynameコールによって返される順序と同じ順序でIPアドレスへの接続が試行されます。最初のアドレスを使用して接続が試行され、その接続を確立できなかった場合は、接続が確立されるまで順番に残りのアドレスが試行されます。TimesTenレプリケーションでは、ホストへの新しい接続を確立するたびに、この同じ順序が使用されます。あるIPアドレスでホストへの接続が失敗すると、前述の方法と同じ方法でホストの別のIPアドレスへの再接続（フォールバック）が試行されます。

UNIXプラットフォームで複数のIPアドレスを使用するようにホストを構成する方法には、DNSまたは/etc/hostsファイルの2つの基本的な方法があります。

注意: ネットワーク・インタフェース・カード（NIC）が複数ある場合は、/etc/host.confファイルで「multi on」を指定してください。指定しないと、gethostbynameは複数のアドレスを返しません。

たとえば、マシンに2つのNICがある場合は、/etc/hostsファイルに次の構文を使用します。

127.0.0.1  localhost
IP_address_for_NIC_1  official_hostname optional_alias
IP_address_for_NIC_2  official_hostname optional_alias

ホスト名official_hostnameは、hostnameコマンドによって返される名前です。

/etc/hostsファイルを編集する場合は、次のことに注意してください。

• /etc/hostsファイルを変更するには、rootとしてログインする必要があります。

• 1つのIPアドレスにつき使用できるのは1行のみです。

• 各行には複数の別名を含めることができます。

• 同じホスト名に対して複数のIPアドレスがある場合、IPアドレスは連続した行に入力する必要があります。

• ホスト名は最大30文字です。

たとえば、UNIXプラットフォームにある/etc/hostsファイルの次のエントリは、2つのIPアドレスがあるMachine1というサーバーを示します。

127.0.0.1        localhost
10.10.98.102     Machine1
192.168.1.102    Machine1

DNSに同じ構成を指定する場合、ドメイン・ゾーン・ファイルに次のように入力します。

Machine1     IN     A     10.10.98.102
             IN     A     192.168.1.102

いずれの場合も、レプリケーション・スキームでホスト名としてMachine1を指定するだけで、レプリケーションでは接続の確立時に最初の使用可能なIPアドレスが使用されます。

複数のIPアドレスが使用される環境では、レプリケーション接続を特定のIPアドレスに制限するために、1つのIPアドレスに複数のホスト名を割り当てることもできます。たとえば、/etc/hostsファイルに次のように入力できます。

127.0.0.1        localhost
10.10.98.102     Machine1
192.168.1.102    Machine1 RepMachine1

または、DNSゾーン・ファイルに次のように入力できます。

Machine1     IN     A     10.10.98.102
             IN     A     192.168.1.102
RepMachine1  IN     A     192.168.1.102

レプリケーション接続をこのホストのIPアドレス192.168.1.102に制限する場合は、レプリケーション・スキームにホスト名としてRepMachine1を指定できます。別の方法として、レプリケーション・スキームの構成に使用するCREATE REPLICATION文で、ホスト名として単にIPアドレスを指定する方法をあげることができます。

Windowsでのホスト名の解決

レプリケーション構成がIPアドレスではなくホスト名で指定されている場合、レプリケーションではピアのホスト名をIPアドレスに変換できる必要があります。Windowsでこれを効率的に行うには、有効なWINSサーバーまたは有効なDNSサーバーのいずれかを問い合せるように各Windowsマシンが設定されていることを確認してください。これらのサーバーにはネットワーク上のホストに関する正しい情報があります。このようなサーバーがない場合、次のいずれかの方法で静的なhost-to-IPエントリを入力できます。

%windir%\system32\drivers\etc\hosts

または

%windir%\system32\drivers\etc\lmhosts

これらのオプションを指定しなかった場合、Windowsマシンはブロードキャスト（非常に低速）を実行してピア・ノードを検出します。

また、Windowsマシンで定義済のWINSサーバーまたはDNSサーバーと通信できない場合、またはホスト名の解決がこれらのサーバーで正しく設定されていない場合は、ホスト名の解決に非常に時間がかかる場合があります。pingコマンドを使用して、ホストを効率的に検出できるかどうかをテストします。pingコマンドのレスポンスは、ホスト名の解決が適切に設定されている場合はすぐに返されます。

注意: レプリケーション・スキームでのデータベース・ホストの指定は一貫している必要があります。あるデータベースにIPアドレスを使用してホストを指定した後、同じデータベースまたは別のデータベースにそのホスト名は使用しないでください。

TimesTenデーモンおよびサブデーモンのユーザー指定アドレス

デフォルトでは、TimesTenのメイン・デーモン、すべてのサブデーモン、およびすべてのエージェントは、使用可能な任意のアドレスを使用してソケット上でリクエストをリスニングします。ttendaemon.optionsファイルを変更して-listenaddrオプションを設定すると、エージェントとデーモン間の通信用アドレスを指定できます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモン・オプションの管理に関する説明を参照してください。

マシンに2つのNICがあり、NICのアドレスがそれぞれ10.10.10.100と10.10.11.200であるとします。ループバック・アドレスは127.0.0.1です。ループバック・アドレスをレプリケーション・エージェントに適用する場合は次のことに注意してください。

• ttendaemon.optionsファイルに-listenaddrオプションを設定しない場合は、すべてのプロセスでデーモンおよびエージェントと対話できます。

• -listenaddrを10.10.10.100に設定した場合、ローカル・ホストのすべてのプロセスまたは10.10.10ネットで、10.10.10.100のデーモンおよびエージェントと対話できます。10.10.11ネット上のプロセスでは、10.10.10.100のデーモンおよびエージェントと対話できません。

• -listenaddrを127.0.0.1に設定した場合、ローカル・ホストのプロセスのみでデーモンおよびエージェントと対話できます。他のホストのプロセスでは、デーモンおよびエージェントと対話できません。

レプリケート・データベースのローカル・ホストの識別

通常、TimesTenレプリケーションでは、レプリケーション構成に含まれるホストは、オペレーティング・システムの一般的なホスト名の解決方法で識別できます。ただし、ホスト名の構成が一般的でない場合、レプリケーション・スキームに指定されたホスト名とローカル・ホストが一致しているかどうかをTimesTenで判別できないことがまれにあります。このような状態でttRepStartまたはttAdmin -repStartを使用してレプリケーションを開始しようとすると、エラー8191「This store is not involved in a replication scheme」を受信することになります。この場合は、ttHostNameSet組込みプロシージャを使用して、現在のデータベースが、レプリケーション・スキームで指定されているデータベースであることをTimesTenに明示的に示すことができます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttHostNameSetに関する説明を参照してください。

レプリケーション環境の設定

レプリケーション環境の設定に関連する内容は次のとおりです。

• データベースの設定

• サブスクライバへのマスター・データベースのコピー

• レプリケート・データベースでのトランザクション・ログの管理

• アクティブ・スタンバイ・ペアのレプリケーション・スループットの向上

• 他のレプリケーション・スキームのレプリケーション・スループットの向上

• 多数のサブスクライバの構成

データベースの設定

既存のデータベースの1つ以上の表をレプリケーションできます。レプリケートする必要があるデータベースが存在しない場合は、まず『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明に従って、そのデータベースを作成する必要があります。

マスター・データベースを指定または作成した後、受信マシンでサブスクライバ・データベースのDSN定義を作成します。マスターおよびサブスクライバのデータベースの接続属性を設定します（「レプリケート・データベースの接続属性」を参照）。

サブスクライバのDSNを設定した後、次の2つの方法のいずれかの方法で、マスターからレプリケートする表をサブスクライバ・データベースに移入できます。

• データベースに接続し、SQL文を使用して、マスターからレプリケートする表と一致する新しい表をサブスクライバ・データベースに作成します。

• ttRepAdmin -duplicateユーティリティを使用して、マスター・データベースの内容全体をサブスクライバにコピーします。詳細は、「サブスクライバへのマスター・データベースのコピー」を参照してください。

レプリケート・データベースの接続属性

レプリケート・データベースのDSN定義には、次の属性の設定が必要です。

• Logging

• LogBufMB

• LogFileSize

これらの属性の詳細は、「レプリケート・データベースでのトランザクション・ログの管理」を参照してください。

また、相互にレプリケーションを行うすべてのデータベースで、DatabaseCharacterSetデータ・ストア属性が同じである必要があります。TimesTenでは、レプリケート・データベース間のキャラクタ・セット変換は実行されません。

アクティブ・スタンバイ・ペア以外のレプリケーション・スキームで並行レプリケーションを構成する場合は、「他のレプリケーション・スキームのレプリケーション・スループットの向上」のReplicationParallelismデータ・ストア属性およびReplicationApplyOrderingデータ・ストア属性の設定に関する説明を参照してください。

注意: TypeModeデータ・ストア属性の設定が異なるデータベース間でもレプリケーションは実行できます。ただし、各レプリケーション列の基礎となるデータ型は各ノードで同じにする必要があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTypeModeに関する説明を参照してください。

レプリケーション・スキームの表要件および制限

任意のレプリケーション・スキームでレプリケートする表には、次の特性が必要です。

• レプリケーション・スキームに関連する表の名前、所有者および列の定義は、CREATE REPLICATION文でTABLE DEFINITION CHECKINGの値にRELAXEDを指定しないかぎり、マスターとサブスクライバの両方のデータベースで一致している必要があります。RELAXEDを指定する場合は、表のキー定義、列の数および列のデータ型が同じである必要があります。「STORE属性の設定」を参照してください。

• レプリケートする表には、次の特性が必要です。

  • 主キー

  • NOT NULL列に定義された一意索引

  レプリケーションでは、主キーまたは一意索引を使用して、レプリケート表の各行を一意に識別します。レプリケーションでは、表の索引配列の順次確認で検出された最初の使用可能な索引を常に選択します。主キーがない場合、レプリケーションでは、NULL列が含まれていない最初の一意索引を選択します。また、マスター・データベース内のレプリケート表に対して選択された索引は、サブスクライバ内の対応する表にも存在している必要があります。

  
  

  注意: レプリケート表のキーは、各更新レコードでサブスクライバに転送されます。キーが小さいほど、より効率的に転送されます。

  
  

• レプリケート表のVARCHAR2、NVARCHAR2、VARBINARYおよびTT_VARCHAR列のサイズは、4MBに制限されます。VARCHAR2列の場合、文字長セマンティクスを使用する際の最大長は、特定のデータベース・キャラクタ・セットを使用する際に1文字が占めるバイト数によって異なります。たとえば、1文字に4バイトが必要なキャラクタ・セットでは、最大長は64,000文字になります。NVARCHAR2の列の場合、1文字に2バイトが必要なため、文字長セマンティクスを使用する際の最大長は、128,000文字になります。

• レプリケーション・スキームが定義されているデータベースでは、一時表を定義および使用することができますが、一時表自体をレプリケートすることはできません。

これらの要件および制限に問題がある場合は、トランザクション・ログAPI（XLA）をレプリケーション・メカニズムとして使用することを検討できます。『Oracle TimesTen In-Memory Database C開発者ガイド』のレプリケーション・メカニズムとしてのXLAの使用に関する説明を参照してください。

サブスクライバへのマスター・データベースのコピー

マスター・データベースを完全にレプリケートするサブスクライバ・データベースに内容を移入する簡単な方法は、マスター・データベースの内容をコピーする方法です。また、障害が発生したデータベースのリカバリ時にも、この方法でデータベースをコピーする必要があります（第11章「データベースのフェイルオーバーおよびリカバリの管理」を参照）。

ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。「データベースの複製」を参照してください。

マスター・データベースの内容をコピーしてサブスクライバ・データベースに移入する前に、次の手順を実行する必要があります。

1. 新しいサブスクライバ・データベースのDSNを作成します。

2. レプリケーション・スキームを作成または変更して、新しいサブスクライバ・データベースおよびそのホストを指定します。「レプリケーション・スキームの定義」を参照してください。

3. レプリケーション・スキームをマスター・データベースに適用します。「データベースへのレプリケーション・スキームの適用」を参照してください。

4. マスター・データベースのレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

たとえば、ホストserver1にはmasterdsデータベースについて記述するmasterDSNという名前のDSNがあります。ホストserver2にはnewdatabaseデータベースについて記述するnewdatabaseDSNという名前のDSNがあります。masterDSNのttuserユーザーにはADMIN権限があります。

newdatabaseデータベースにmasterdsの内容を移入するには、「ソース・ホストで実行する手順」および「ターゲット・ホストで実行するタスク」で説明する手順を実行します。

ソース・ホストで実行する手順

レプリケーション・スキームを定義し、ttRepStartプロシージャをコールしてレプリケーションを開始するnewrepscheme.sqlという新しいSQLファイルを、テキスト・エディタを使用して作成します。

CREATE REPLICATION repscheme
  ELEMENT e TABLE tab
  MASTER masterds ON "server1"
  SUBSCRIBER newdatabase ON "server2";

call ttRepStart;

コマンドラインから、レプリケーション・スキームを指定してmasterdsを構成し、レプリケーション・エージェントを起動します。

> ttIsql -f newrepscheme.sql masterds

ターゲット・ホストで実行する手順

コマンドラインから、masterdsデータベースの内容をnewdatabaseデータベースにコピーします。

> ttRepAdmin -dsn newdatabase -duplicate -from masterds -host "server1" -uid ttuser

ttuserのパスワードを入力するよう求められます。

これで、newdatabaseデータベースとmasterdsデータベースの内容が同じになります。

注意: -hostは、リモート・ホストの名前またはTCP/IPアドレスのいずれかで指定できます。TCP/IPアドレスを使用してホストを指定する場合は、-localhostオプションを使用してローカル・ホスト（この例ではserver2）のアドレスを指定する必要があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepAdminに関する説明を参照してください。

また、ttRepStartプロシージャおよびttRepDuplicateEx C関数を使用して、前述の処理とほぼ同様のコピー処理をCプログラムからも実行できます。詳細は、「レプリケーション・エージェントの起動および停止」および「障害が発生したデータベースのリカバリ」を参照してください。

レプリケート・データベースでのトランザクション・ログの管理

この項の内容は次のとおりです。

• ログ・バッファのサイズおよび永続性について

• マスター・データベースでのトランザクション・ログの増大について

• ロギングの接続属性の設定

ログ・バッファのサイズおよび永続性について

TimesTenユーザーに共通に見られる誤解として、ログ・バッファのサイズとトランザクションの消失に関係があるという誤解があります。ログ・バッファのサイズは、永続性には影響しません。

DSNがDurableCommits=0で構成されている場合、トランザクションは、次の場合にのみディスクに永続的に書き込まれます。

• ログ・バッファが一杯になった場合。

• ttDurableCommitプロシージャがコールされた場合、またはDurableCommits=1での接続でトランザクションがコミットまたはロールバックされた場合。

• レプリケーション・エージェントがサブスクライバにトランザクションのバッチを送信する際に、マスターがレプリケーションに対してTRANSMIT DURABLE属性（デフォルト）で構成されている場合。（「デフォルトのレプリケーション」を参照。）

• プライマリ・データベースがTRANSMIT DURABLEで構成されているかどうかに関係なく、レプリケーションが定期的に永続コミットを実行する場合。

• DSNがLogFlushMethod=2で構成されている場合は、アプリケーションに制御が返される前にディスクへの書込みが行われます。

前述の場合、ログ・バッファのサイズは、TimesTenによるディスクへのデータの書込みに影響しません。

マスター・データベースでのトランザクション・ログの増大について

レプリケーション、トランザクション・ログAPI（XLA）、キャッシュ・グループまたは増分バックアップを使用しないデータベースでは、自動バックグラウンド・チェックポイント・スレッドあるいはアプリケーションのttCkptまたはttCkptBlockingプロシージャのコールのいずれかによってチェックポイントが開始されるたびに、ログ・バッファ内の不要なレコードおよび不要なトランザクション・ログ・ファイルがパージされます。レプリケート・データベースでは、トランザクションがサブスクライバで完全に処理されたことをマスター・レプリケーション・エージェントが確認するまで、トランザクションはログ・バッファおよびトランザクション・ログ・ファイルに保持されます（「レプリケーション・エージェント」を参照）。マスターは、これを確認した時点でのみ、ログ・バッファおよびトランザクション・ログ・ファイルからのパージが必要であると認識します。

サブスクライバの状態が変わると、マスター・データベースのトランザクション・ログが、レプリケートされていないデータベースのログより大幅に大きくなる可能性があります。サブスクライバの状態については、「サブスクライバのレプリケーション状態の設定」を参照してください。サブスクライバがStart状態の場合、マスターはサブスクライバからの受信確認を受信した後、ログされているデータをパージできます。ただし、サブスクライバが使用不能またはPause状態になると、マスター・データベースのログはフラッシュできず、ログに使用する領域が使い果たされる可能性があります。ログ領域を使い果たすと、マスター・データベースでの後続の更新が強制終了されます。

ロギングの接続属性の設定

LogBufMBでは、メモリー内ログ・バッファの最大サイズを指定します（MB単位）。このバッファは、一杯になると、ディスク上のトランザクション・ログ・ファイルにフラッシュされます。LogBufMBの最小サイズは、LogBufParallelismの値の8倍です。

レプリケーション・ログ・ファイルのために十分なディスク領域を確保する必要があります。ログで使用されるディスク領域の量を管理する場合、次の2つの設定があります。

• DSNのLogFileSize設定では、トランザクション・ログ・ファイルの最大サイズを指定します。ロギング要件がこの値を超えると、同じ最大サイズを持つ追加のトランザクション・ログ・ファイルが作成されます。LogFileSizeをLogBufMBより小さい値に設定すると、TimesTenはLogBufMBに一致するようにLogFileSizeを自動的に大きくします。最適なパフォーマンスを実現するには、LogBufMBおよびLogFileSizeを最大値に設定します。

• ログの障害しきい値の設定では、マスターがサブスクライバで障害が発生したと想定するまでに累積できるトランザクション・ログ・ファイルの最大数を指定します。このしきい値は、最後に書き込まれたトランザクション・ログ・ファイルと、サブスクライバ用に最初に保存されたトランザクション・ログ・ファイルの間のトランザクション・ログ・ファイルの数です。たとえば、すべてのサブスクライバが受信に成功した最後のレコードがログ・ファイル1にあり、ディスクに書き込まれた最後のログ・レコードがログ・ファイル4の先頭にある場合は、2つ以上のトランザクション・ログ・ファイル（ログ・ファイル2および3の内容）がレプリケートされていません。しきい値が2の場合、マスターは、しきい値を超えたことを検出した後にサブスクライバをFailed状態に設定します。これには10秒かかる場合があります。詳細は、「ログ障害しきい値の設定」を参照してください。

トランザクションはディスクにロギングされるため、ブックマークを使用して、サブスクライバにレプリケートされた更新レコードおよびディスクに書き込まれた更新レコードのログ・レコード識別子を検出できます。masterDSNに関連付けられているサブスクライバのブックマークの位置を表示するには、CユーティリティまたはttBookmark組込みプロシージャを使用します。詳細は、「レプリケート・ログ・レコードの表示」を参照してください。

サブスクライバが停止して、しきい値に達する前に再起動した場合、ブックマークの後に続くトランザクション・ログ・ファイル内のコミット済トランザクションが自動的に送信されるため、レプリケーションは自動的にキャッチアップします。ただし、しきい値を超えると、マスターはサブスクライバをFailed状態に設定します。障害が発生したサブスクライバは、ttRepAdmin -duplicateを使用してマスター・データベースをコピーし、処理を最初から再実行します（第11章「データベースのフェイルオーバーおよびリカバリの管理」を参照）。

TimesTenの接続属性、組込みプロシージャおよびユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。

アクティブ・スタンバイ・ペアのレプリケーション・スループットの向上

アクティブ・データベースからスタンバイ・データベースへ変更を適用するスレッドの数を1から2に増やすには、ReceiverThreads初期接続属性を使用します。フェイルオーバーが発生した場合にスループットの向上を維持するためには、スタンバイ・データベースでReceiverThreadsを2に設定した場合、アクティブ・データベースでも2に設定する必要があります。

アクティブ・スタンバイ・ペアの1つ以上の読取り専用サブスクライバでReceiverThreadsを2に設定して、スタンバイ・データベースからのレプリケーション・スループットを向上させることもできます。

この属性を2に設定したことによる効果を得るには、データベースが双方向以上のシステムでホストされている必要があります。

他のレプリケーション・スキームのレプリケーション・スループットの向上

アプリケーションに予測可能なトランザクションの依存性が存在し、ターゲット・データベースとソース・データベースでコミット順序が同じである必要がない場合、パラレル・レプリケーションを構成することでレプリケーション・スループットを向上できます。

ユーザー指定のパラレル・レプリケーションでは、複数のスレッドを構成して、ソース・データベースからターゲット・データベースへの更新の送信と、ターゲット・データベースでの更新の適用を行います。トランザクションは、アプリケーションによってトラックに割り当てられるようにします。また、トランザクションが属するトラックは、ソース・データベースでトランザクションが開始されたときに指定します。各トラックのトランザクションは、ターゲット・データベースで受信された順に適用されます。ただし、異なるトラック間のトランザクションではコミット順序は保持されません。

外部キーで関連付けられている表に影響を与えるトランザクションをトラックに割り当てる場合は、注意する必要があります。関連付けられている表に対するトランザクションが別々のトラックに割り当てられた場合、トランザクションのコミット順序が変更され、いずれかのトランザクションが失われてしまう可能性があります。

通常、同じ表を変更するトランザクションは、同じレプリケーション・トラックに割り当てる必要があります。ただし、すべてのトランザクションが同じ表への挿入処理である場合、トランザクションを異なるトラックに割り当ててレプリケーション・スループットを向上できます。

ユーザー指定のパラレル・レプリケーションの構成

パラレル・レプリケーションを有効にするには、データベース作成時に、次のように接続属性を設定します。

• ReplicationParallelismを2から64の数値に設定します。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。デフォルトは1で、スレッドの数は1つです。

• ReplicationApplyOrderingを1に設定します。

『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationParallelismおよびReplicationApplyOrderingに関する説明を参照してください。

また、アプリケーションでは、次に示す4つのうちいずれかの方法で、トランザクションをトラックに割り当てる必要があります。

• ReplicationTrack一般接続属性を、ReplicationParallelismデータ・ストア属性によって指定された最大トラック数以下の数値（ただし、ゼロ以外）に設定します。

• ALTER SESSION SQL文を使用して、現在の接続のレプリケーション・トラック数を設定します。

• SQLSetConnectOption ODBC関数のTT_REPLICATION_TRACK ODBC接続オプションを使用します。

• TimesTenConnection JDBCクラスのsetReplicationTrack()メソッドを使用します。

ReplicationTrack一般接続属性を設定する方法の詳細は、次の説明を参照してください。

• 『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationTrackに関する説明

• 『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のALTER SESSIONに関する説明

• 『Oracle TimesTen In-Memory Database C開発者ガイド』のユーザー指定の並行レプリケーションの設定に関する説明

• 『Oracle TimesTen In-Memory Database Java開発者ガイド』のユーザー指定の並行レプリケーションの設定に関する説明

ttConfiguration組込みプロシージャを使用すると、現在の接続のレプリケーション・トラック数が返されます。ttLogHolds組込みプロシージャを使用すると、複数のトラックが使用されているかどうかを確認できます。

ユーザー指定のパラレル・レプリケーションの制限

• ユーザー指定のパラレル・レプリケーションにはアクティブ・スタンバイ・ペアを構成できません。

• エージング・ポリシーが定義されている表に対して、ユーザー指定のパラレル・レプリケーションを構成しないでください。

• ユーザー指定のパラレル・レプリケーションが構成されているデータベースには、キャッシュ・グループを含めることはできません。

• ユーザー指定のパラレル・レプリケーションを構成している場合、データベースをプロパゲータとして定義できません。

• ユーザー指定のパラレル・レプリケーションは、同期レプリケーション（RETURN RECEIPT属性およびRETURN TWOSAFE属性が構成されたデータベースを含む）ではサポートされていません。

• ReplicationParallelismおよびReplicationApplyOrderingはデータ・ストア属性であるため、データベース作成後に変更できません。

• ユーザー指定のパラレル・レプリケーションが構成されたデータベースでは、ADD句およびDROP句を指定したALTER TABLE SQL文は、サポートされていません。

多数のサブスクライバの構成

レプリケーション・スキームには最大128のサブスクライバを含めることができます。プロパゲータ・データベースを使用するレプリケーション・スキームには最大128のプロパゲータを含めることができます。また、各プロパゲータには最大128のサブスクライバを構成できます。アクティブ・スタンバイ・ペアのレプリケーション・スキームには、最大127の読取り専用サブスクライバを含めることができます。多数のサブスクライバが含まれるレプリケーション・スキームを計画する場合は、次のことを実行する必要があります。

• ログ・バッファのサイズは、SYS.MONITOR表のLOG_FS_READSの値が0（ゼロ）または0（ゼロ）に近い値になるようにすること。これによって、レプリケーション・エージェントでディスクからログ・レコードを読み取る必要がなくなります。LOG_FS_READSの値が増大する場合は、ログ・バッファのサイズを大きくします。

• CPUリソースが適切であること。マスター・データベースのレプリケーション・エージェントは、各サブスクライバ・データベースに対してスレッドを生成します。各スレッドでログの読取りおよび処理が個別に行われるため、処理を続行するには適切なCPUリソースが必要です。

異なるリリース間でのデータベースのレプリケート

異なるリリース間でのレプリケーションは、新しいバージョンのTimesTenのデータベースが古いバージョンのTimesTenのデータベースからttMigrateを使用してアップグレードされた場合にのみ機能します。より新しいバージョンのTimesTenで作成したデータベースでは、それより古いバージョンでの正常なレプリケートは保証されていません。

たとえば、TimesTenリリース5.1で作成されたデータベースとTimesTenリリース6.0で作成されたデータベース間のレプリケーションはサポートされていません。ただし、一方のデータベースがTimesTenリリース5.1で作成され、そのピア・データベースがTimesTenリリース5.1で作成された後でTimesTenリリース6.0にアップグレードされた場合、これらの間のレプリケーションはサポートされます。

『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のデータベースのアップグレードに関する説明を参照してください。

データベースへのレプリケーション・スキームの適用

第9章「レプリケーション・スキームの定義」の説明に従って、レプリケーション・スキームを定義します。CREATE REPLICATION文をSQLファイルに保存します。

SQLファイルにレプリケーション・スキームを記述した後、-fオプションを指定してttIsqlユーティリティ使用すると、データベースに対してSQLを実行できます。構文は次のとおりです。

ttIsql -f schemefile.sql - connstr "dsn=DSN"

例10-1 SQLファイルの実行によるレプリケーション・スキームの作成

レプリケーション・スキームをファイルrepscheme.sqlに記述した後、次のように入力して、masterDSNというDSNに対してファイルを実行できます。

> ttIsql -f repscheme.sql -connstr "dsn=masterDSN"

ほとんどの場合、すべてのレプリケート・データベースに対して同じスキームを適用する必要があります。ホストごとに個別のttIsqlコマンドを実行してレプリケーション・スキームを適用する必要があります。

例10-2 ホストごとのSQLファイルの実行

スキームにホストS1のデータベースmasterDSN、ホストS2のデータベースsubscriber1DSN、ホストS3のデータベースsubscriber2DSNが含まれている場合は、次のように実行します。

ホストS1では、次のように入力します。

> ttIsql -f repscheme.sql masterDSN

ホストS2では、次のように入力します。

> ttIsql -f repscheme.sql subscriber1DSN

ホストS3では、次のように入力します。

> ttIsql -f repscheme.sql subscriber2DSN

レプリケーション・スキームが含まれているSQLファイルは、ttIsqlコマンドラインからも実行できます。次に例を示します。

Command> run repscheme.sql;

レプリケーション・エージェントの起動および停止

レプリケーション・スキームを定義した後、レプリケーション・スキームに含まれている各データベースのレプリケーション・エージェントを起動できます。レプリケーション・エージェントを起動および停止するには、ADMIN権限が必要です。

レプリケーション・エージェントは、次の項で説明するように、コマンドラインまたはプログラムから起動および停止することができます。

• コマンドラインからのレプリケーション・エージェントの制御

• プログラムからのレプリケーション・エージェントの制御

注意: レプリケーション・スキームに関連していないデータベースのレプリケーション・エージェントを起動しようとしても失敗します。

コマンドラインからのレプリケーション・エージェントの制御

レプリケーション・エージェントをコマンドラインから起動および停止するには、-repStartまたは-repStopオプションを指定してttAdminユーティリティを使用します。

ttAdmin -repStart DSN
ttAdmin -repStop DSN

注意: レプリケーション・エージェントの実行時には使用できないレプリケーションDDLを、ttAdmin -repStartコマンドを発行してからレプリケーション・エージェントが実際に起動するまでの短い間に使用できる場合があります。たとえば、この期間中にレプリケーション・スキームを削除できる場合があります。

例10-3 ttAdminによるレプリケーション・エージェントの起動および停止

masterDSNおよびsubscriberDSNというDSNのレプリケーション・エージェントを起動するには、次のように入力します。

ttAdmin -repStart masterDSN
ttAdmin -repStart subscriberDSN

レプリケーション・エージェントを停止するには、次のように入力します。

ttAdmin -repStop masterDSN
ttAdmin -repStop subscriberDSN

また、ttRepStartおよびttRepStopプロシージャを使用して、ttIsqlコマンドラインからレプリケーション・エージェントを起動および停止することもできます。

例10-4 ttIsqlコマンドラインからのレプリケーション・エージェントの起動および停止

masterDSNというDSNのレプリケーション・エージェントを起動および停止するには、次のように入力します。

> ttIsql masterDSN
Command> call ttRepStart;
Command> call ttRepStop;

また、ttAdminユーティリティを使用してレプリケーション再起動ポリシーを設定することもできます。デフォルトでは、このポリシーはmanualです。これによって、前述のようにレプリケーション・エージェントを起動および停止できます。データベースのレプリケーション再起動ポリシーは、alwaysまたはnorestartに設定することもできます。

再起動ポリシー	TimesTenデーモンの起動時にレプリケーション・エージェントを起動	エラー発生時または無効化が行われた場合にレプリケーション・エージェントを再起動
always	する	する
manual	しない	する
norestart	しない	しない

注意: レプリケーション・エージェントはTimesTenデーモンによって管理されます。TimesTenデーモンは、レプリケーション・エージェントを起動する前に起動されている必要があります。

再起動ポリシーがalwaysの場合、データベースがメモリーにロードされるとレプリケーション・エージェントが自動的に起動されます。データベースがメモリーにロードされるタイミングを指定する方法については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。

例10-5 ttAdminを使用した再起動ポリシーの設定

ttAdminを使用して、レプリケーション再起動ポリシーをalwaysに設定するには、次のように入力します。

ttAdmin -repPolicy always DSN

ポリシーをmanualに再設定するには、次のように入力します。

ttAdmin -repPolicy manual DSN

エラー発生またはデータベースの無効化の後、manualおよびalwaysの両方のポリシーによってレプリケーション・エージェントが自動的に再起動されます。レプリケーション・エージェントが自動的に再起動されると、多くの場合、データベースへの初期接続になります。たとえば、これは、すべてのアプリケーションの接続を切断する必要がある致命的なエラーが発生した後に行われます。通常、データベースへの初期接続では、最新のチェックポイント・ファイルをロードする必要があり、また、多くの場合リカバリを実行する必要があります。非常に大容量のデータベースの場合、このプロセスに数分かかる場合があります。この間、新しい接続が行われず、古い接続の切断が終了されないように、データベースでのすべてのアクティビティがブロックされます。また、この結果、すべてのアプリケーションの接続が切断されるまで古いデータベースが存続するため、データベースの2つのコピーが同時に存在する場合もあります。初期接続時が重要な非常に大容量のデータベースの場合、新しいデータベースを起動する前にまず古いデータベースが非アクティブになるまで待機する必要がある場合があります。これは、再起動ポリシーnorestartに設定してレプリケーション・エージェントが自動的に再起動されないように指定することで実現できます。

プログラムからのレプリケーション・エージェントの制御

プログラムからデータベースのレプリケーション・エージェントを起動および停止するには、レプリケーション・データベースに接続し、ttRepStartおよびttRepStopプロシージャを使用します。

例10-6 プログラムからのレプリケーション・エージェントの起動および停止

hdbc接続ハンドルで識別されるデータベースのレプリケーション・エージェントを起動および停止するには、次のように入力します。

rc = SQLAllocStmt( hdbc, &hstmt );
rc = SQLExecDirect( hstmt, (SQLCHAR *)
    "CALL ttRepStart()", SQL_NTS );
rc = SQLExecDirect( hstmt, (SQLCHAR *)
    "CALL ttRepStop()", SQL_NTS );

例10-7 プログラムからの再起動ポリシーの設定

hdbc接続ハンドルで識別されるデータベースのレプリケーション・ポリシーをalwaysに設定するには、次のように入力します。

rc = SQLAllocStmt( hdbc, &hstmt );
rc = SQLExecDirect( hstmt, (SQLCHAR *)
     "CALL ttRepPolicy ('always')", SQL_NTS );

サブスクライバのレプリケーション状態の設定

サブスクライバ・レプリケーション・エージェントの状態は、そのマスター・データベースによって記述されます。障害が発生したサブスクライバ・データベースをリカバリする場合は、レプリケーション・スキームで通信するマスター・データベースに対するサブスクライバ・データベースのレプリケーション状態を再設定する必要があります。サブスクライバ・データベースの状態は、コマンドラインまたはプログラムから再設定できます。

• コマンドラインから、ttRepAdmin -stateを使用して、いずれかのサブスクライバ・データベースのレプリケーション状態を再設定するようにマスター・データベースに指示します。

• プログラムから、ttRepSubscriberStateSetプロシージャをコールして、いずれかまたはすべてのサブスクライバ・データベースのレプリケーション状態を再設定するようにマスター・データベースに指示します。

データベースの状態の問合せについては、「レプリケーションの監視」を参照してください。

マスター・データベースは、サブスクライバ・データベースをStart、PauseまたはStopのいずれかの状態に設定できます。データベースの状態は、次の表に示すとおり、TTREP.REPPEERS表のSTATE列に整数値として示されます。

状態	説明
Start 状態値: 0	レプリケーション更新が収集され、できるかぎり早くサブスクライバ・データベースに送信されます。サブスクライバ・データベースのレプリケーションが動作していない場合、更新は、送信可能になるまでトランザクション・ログ・ファイルに保存されます。
Pause 状態値: 1	レプリケーション更新は、送信を試行されずにログに保存されます。状態がStartに変更されると、送信が開始します。
Stop 状態値: 2	レプリケーション更新は、サブスクライバ・データベースに送信されずに破棄されます。サブスクライバ・データベースをStop状態にすると、マスターのトランザクション・ログに保留されている更新がすべて破棄されます。
Failed 状態値: 4	しきい値制限（ログ・データ）を超えているため、サブスクライバへのレプリケーションは失敗したとみなされます。この状態は、システムによって設定されます。システムが状態をStopに設定する前の遷移状態です。Failed状態のデータベースに接続するアプリケーションは警告を受信します。詳細は、「一般的なフェイルオーバーおよびリカバリの手順」を参照してください。

マスター・データベースがそのサブスクライバの1つをStart状態に設定すると、そのサブスクライバに対する更新がマスターのログに保存されます。サブスクライバがStop状態の場合、サブスクライバに対する更新は破棄されます。

サブスクライバがPause状態の場合、サブスクライバに対する更新はマスターのログに保存されますが、サブスクライバ・データベースには送信されません。マスターがサブスクライバをPauseからStartに変更すると、マスターのログに保存された更新のバックログがサブスクライバに送信されます。（これには例外があります。第11章「データベースのフェイルオーバーおよびリカバリの管理」を参照してください。）マスター・データベースは、状態が示されたサブスクライバに接続を確立できない場合、成功するまで接続の確立を定期的に試行します。

例10-8 ttRepAdminを使用したサブスクライバの状態の設定

コマンドラインからttRepAdminを使用して、subscriberdsサブスクライバ・データベースの状態をStopに設定するようにmasterdsマスター・データベースに指示するには、次のように入力します。

ttRepAdmin -dsn masterds -receiver -name subscriberds -state stop

注意: 異なるホストに同じ名前のサブスクライバが複数ある場合は、ttRepAdminユーティリティの-hostオプションでサブスクライバのホストを識別します。

例10-9 プログラムからサブスクライバの状態をStopに設定

レプリケーション・スキームがschemeであると想定した場合は、次のttRepSubscriberStateSetプロシージャで、サブスクライバ・データベース（system1のsubscriberds）の状態をStopに設定するようにマスター・データベースに指示します。

rc = SQLAllocStmt( hdbc, &hstmt );
rc = SQLExecDirect( hstmt, (SQLCHAR *)
    "CALL ttRepSubscriberStateSet('repscheme', 'repl',
          'subscriberds', 'system1', 2)", SQL_NTS );

例10-10 プログラムからサブスクライバの状態をPauseに設定

次のttRepSubscriberStateSetプロシージャで、すべてのサブスクライバ・データベースの状態をPauseに設定するようにマスター・データベースに指示します。

rc = SQLAllocStmt( hdbc, &hstmt );
rc = SQLExecDirect( hstmt, (SQLCHAR *)
    "CALL ttRepSubscriberStateSet( , , , , 1 )", SQL_NTS );

マスターのすべてのサブスクライバを特定の状態に設定する場合は、ttRepSubscriberStateSetのみを使用できます。ttRepAdminユーティリティに同等の機能はありません。