ヘッダーをスキップ
Oracle® TimesTen In-Memory Database開発者および管理者ガイド
11gリリース2 (11.2.2)
B66443-05
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

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

この章では、レプリケーションの設定方法および開始方法について説明します。この章のすべてのトピックは、クラシック・レプリケーション・スキームに適用されます。一部のトピックは、アクティブ・スタンバイ・ペアに適用されます。

アクティブ・スタンバイ・ペアを設定する場合は、次の項を参照してください。

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

ネットワークの構成

次の項のトピックは、アクティブ・スタンバイ・ペアとクラシック・レプリケーション・スキームの両方に適用されます。次の項は、ネットワーク上でTimesTenデータをレプリケートする場合に考慮する必要があるいくつかの問題について説明します。

ネットワーク帯域幅要件

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

表10-1は、レプリケート・レコードのサイズを計算するためのガイドラインを示しています。

表10-1 レプリケート・レコードのサイズ

レコード・タイプ サイズ

開始トランザクション

48バイト

更新

116バイト

+18バイト(更新された列ごとに)

+古い列値のサイズ

+新しい列値のサイズ

+主キーまたは一意キーのサイズ

削除

104バイト

+主キーまたは一意キーのサイズ

挿入

104バイト

+主キーまたは一意キーのサイズ

+挿入された行のサイズ


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

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

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

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

ホストIPアドレスの構成

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

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

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

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

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


注意:

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

詳細は、「クラシック・レプリケーション・スキームに対するネットワーク操作の構成」を参照してください。

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

データベース・ホストと、レプリケーションに使用するネットワーク・インタフェースを指定するには、可能な場合は、レプリケーション・スキームの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アドレスがあるHost1というサーバーを示します。

127.0.0.1        localhost
10.10.98.102     Host1
192.168.1.102    Host1

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

Host1     IN     A     10.10.98.102
          IN     A     192.168.1.102

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

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

127.0.0.1        localhost
10.10.98.102     Host1
192.168.1.102    Host1 RepHost1

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

Host1     IN     A     10.10.98.102
          IN     A     192.168.1.102
RepHost1  IN     A     192.168.1.102

レプリケーション接続をこのホストのIPアドレス192.168.1.102に制限する場合は、レプリケーション・スキームにホスト名としてRepHost1を指定できます。別の方法として、レプリケーション・スキームの構成に使用する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ユーティリティを使用して、マスター・データベースの内容全体をサブスクライバにコピーします。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。

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

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

パラレル・レプリケーションを構成する場合、ReplicationParallelismデータ・ストア属性およびReplicationApplyOrderingデータ・ストア属性の設定の詳細は、「パラレル・レプリケーションの構成」を参照してください。

レプリケーション・ログ・ファイルを管理するための推奨事項については、「ロギングの接続属性の設定」を参照してください。

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

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

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

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

パラレル・レプリケーションの構成

デフォルトでは、レプリケーションは、レプリケーション・スキーム内のノードに、1つのログ・リーダー(ソース・データベースでのトランスミッタ・スレッド)と1つのアプライヤ(ターゲット・データベースでのレシーバ・スレッド)が含まれるシングル・スレッドで実行されます。ソース・データベースからターゲット・データベースに更新を送信し、その更新をターゲット・データベースで適用するための複数のスレッドを構成するパラレル・レプリケーションを構成することによって、パフォーマンスを向上させることができます。


注意:

パラレル・レプリケーションを有効にした場合、同じトランザクション内でDDL文とDML文の両方を実行することはできません。

パラレル・レプリケーションには2つのタイプがあり、それぞれReplicationApplyOrderingデータ・ストア属性とReplicationParallelismデータ・ストア属性で構成されており、データベースの作成時に設定する必要があります。ReplicationParallelismReplicationApplyOrderingはどちらもデータ・ストア属性であるため、データベース作成後に変更することはできません。


注意:

パラレル・レプリケーションを使用したレプリケーション・スキーム内のすべてのデータベースは、同じタイプのパラレル・レプリケーションおよび同じ数のスレッドまたはトラックを使用して同一に構成する必要があります。

パラレル・レプリケーションの属性に異なる値を設定できるのは、アップグレード中のみです。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のパラレル・レプリケーション使用時のアップグレードに関する説明を参照してください。


次の項では、パラレル・レプリケーションの2つのオプションについて説明します。

自動パラレル・レプリケーションの構成

自動パラレル・レプリケーションを使用すると、レプリケーションと、レプリケーション・スキーム内のノードへのトランザクションの変更の適用を並行して行う複数のスレッドを構成できます。自動パラレル・レプリケーションでは、トランザクションの依存性が強制され、変更がコミット順に適用されます。

自動パラレル・レプリケーションは、ReplicationApplyOrdering=0の設定でデフォルトで有効になっています。パラレル・レプリケーションを構成するには、ReplicationParallelismを2から32の数値に設定します。この数値は、LogBufParallelismの半分の値を超えることはできません。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。ただし、シングル・スレッド・レプリケーションを使用している場合、ReplicationParallelismを1 (デフォルト)に設定します。


注意:

ReplicationParallelismが1より大きい場合は、LogBufParallelism初期接続属性はReplicationParallelismの整数倍である必要があります。

レプリケーション・スキームがAWTキャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアである場合は、データ・ストア属性ReplicationApplyOrderingReplicationParallelismおよびCacheAWTParallelismの設定によって、TimesTenキャッシュ表の変更を対応するOracle Database表に適用するのに使用されるスレッド数が決定されます。詳細は、『Oracle In-Memory Database Cacheユーザーズ・ガイド』のOracle Database表へのパラレル伝播の構成に関する説明を参照してください。

これらのデータ・ストア属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationParallelism、ReplicationApplyOrderingおよびLogBufParallelismに関する説明を参照してください。

クラシック・レプリケーション・スキームに対するユーザー定義のパラレル・レプリケーションの構成

アプリケーションに予測可能なトランザクションの依存性が存在し、ターゲット・データベースとソース・データベースでコミット順序が同じである必要がない場合、ユーザーが異なるトラック間の処理を手動で割り当てることができるユーザー定義のパラレル・レプリケーションを使用することで、レプリケーション・スループットを向上できます。

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


注意:

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

通常、同じ表を変更するトランザクションは、同じレプリケーション・トラックに割り当てる必要があります。また、受信側で順番に適用される必要のある更新は、同じトラックを使用する必要があります。ただし、すべてのトランザクションが同じ表への挿入処理である場合、トランザクションを異なるトラックに割り当ててレプリケーション・スループットを向上できます。行を同じトラックに関連付けるキーを使用して、複数のトラック間で表のワークロードを分割できます。

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

  • ReplicationApplyOrderingを1に設定します。

  • ReplicationParallelismを1から64の数値に設定します。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。シングル・スレッド・レプリケーションでは、1 (デフォルト)に設定します。パラレル・レプリケーションを使用するためには、2から64の数値に設定します。

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

  • ReplicationTrack一般接続属性をゼロ以外の数値に設定します。接続によって発行されたすべてのトランザクションは、このトラックに割り当てられます。値は任意の数値です。TimesTenは、この接続のReplicationTrack数をパラレル・レプリケーションの使用可能なスレッドのいずれかにマップします。これにより、アプリケーションで任意の数を使用して、順番に適用する必要のあるトランザクションをグループ化できます。『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationTrackに関する説明を参照してください。

  • ALTER SESSION SQL文を使用して、現在の接続のレプリケーション・トラック数を設定します。『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER SESSION」を参照してください。

  • SQLSetConnectOption ODBC関数のTT_REPLICATION_TRACK ODBC接続オプションを使用します。『Oracle TimesTen In-Memory Database C開発者ガイド』のレプリケーションで使用するための機能に関する説明を参照してください。

  • TimesTenConnection JDBCクラスのsetReplicationTrack()メソッドを使用します。『Oracle TimesTen In-Memory Database Java開発者ガイド』のレプリケーションで使用するための機能に関する説明を参照してください。

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

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

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

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

  • ユーザー定義のパラレル・レプリケーションをアクティブ・スタンバイ・ペアのレプリケーション・スキーム内で使用することはサポートされていません。

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

  • ユーザー定義のパラレル・レプリケーションが有効でないデータベースからユーザー定義のパラレル・レプリケーションが有効なデータベースへの、リリース間のレプリケーションおよび移行は、リリース11.2.1.6.0から11.2.1.8.0まではサポートされません。11.2.1.6.0より前と、11.2.1.8.0以降のリリースではサポートされています。11.2.1.6.0から11.2.1.8.0のユーザーは、まず11.2.1.8.0のインプレース・パッチ・リリース・アップグレードを適用してから、アップグレードを実行できます。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のパラレル・レプリケーション使用時のアップグレードに関する説明を参照してください。

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

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

ログ・バッファのフラッシュについて

専用のサブデーモン・スレッドはログ・バッファの内容を定期的にディスクに書き込みます。これらの書込みは同期化またはバッファリングできます。サブデーモン・スレッドは、ログ・バッファに同期化することなく、システムI/OバッファがLogFileSize初期接続属性の値を超えるトランザクション・ログ・データで一杯にならないようにします。

データベースがLogFlushMethod=2で構成されている場合は、ディスクへの書込みはすべて同期書込みで、書込みコールが返される前にデータはディスクに永続的に書き込まれます。データベースがLogFlushMethod=1で構成されている場合には、アプリケーションから同期書込みの特定のリクエストがないかぎり、書込みはバッファリングされます。

定期的な書込みに加えて、アプリケーションはサブデーモン・スレッドをトリガーして、バッファの内容をディスクに書き込むこともできます。次に、アプリケーションがディスクへの同期書込みをトリガーする場合を示します。

  • 永続コミットをリクエストしたトランザクションがコミットされた場合。ttDurableCommit組込みプロシージャをコールするか、DurableCommits接続属性を1に設定することによって、トランザクションは永続コミットをリクエストできます。

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

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

また、永続コミットが戻りサービス失敗ポリシーの一部として構成されており、障害が発生した場合にも、トランザクションは永続的にディスクに書き込まれます。

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

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

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

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


注意:

トランザクション・ログの増大の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの蓄積の監視に関する説明を参照してください。ttLogHolds組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttLogHoldsに関する説明を参照してください。

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

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

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

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

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

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

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

TimesTenの接続属性、組込みプロシージャおよびユーティリティの詳細は、『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 -connstr "dsn=masterDSN"

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

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

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

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

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

Command> run repscheme.sql;

サブスクライバへのマスター・データベースの複製

サブスクライバ・データベースに内容を移入する最も簡単な方法は、マスター・データベースの内容を複製する方法です。また、障害が発生したデータベースのリカバリ時にも、この方法でデータベースを複製する必要があります(第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照)。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。

データベースを複製する場合は、次の条件を満たす必要があります。

  • インスタンス管理者が複製操作を実行します。

  • インスタンス管理者のユーザー名は、複製に含まれる両方のインスタンスで同じである必要があります。

  • ソース・データベースで、ADMIN権限があるユーザーのユーザー名とパスワードを入力する必要があります。

  • ターゲットDSNにクライアント属性およびサーバー属性を含めることはできません。

マスター・データベースの内容をサブスクライバ・データベースに複製するには、次のタスクを実行します。

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

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

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

  4. ソース(マスター)・データベースで、次のように入力してユーザーを作成し、そのユーザーにADMIN権限を付与します。

    CREATE USER ttuser IDENTIFIED BY ttuser;
    User created.
    
    GRANT admin TO ttuser;
    
  5. インスタンス管理者のユーザー名がtimestenであるとします。ターゲット・ホスト(サブスクライバ)でtimestenとしてログインし、次のようにhost1のデータベースmasterDSNsubscriber1DSNに複製します。

    ttRepAdmin -duplicate -from masterDSN -host host1 subscriber1DSN
    
    Enter internal UID at the remote datastore with ADMIN privileges: ttuser 
    Enter password of the internal Uid at the remote datastore:
    

    リモート・データベースの内部ユーザーのパスワードを入力するよう要求されたら、ttuserと入力します。


    注意:

    ホスト・エントリは、リモート・ホストの名前またはTCP/IPアドレスのいずれかで指定できます。TCP/IPアドレスを使用してホストを指定する場合は、-localhostオプションを使用してローカル・ホスト(この例ではhost1)のアドレスを指定する必要があります。

    ソース・ホストとターゲット・ホストのローカルおよびリモートのネットワーク・インタフェースを指定するには、ttRepAdmin -duplicate-localIPオプションと-remoteIPオプションを使用します。一方または両方のネットワーク・インタフェースが指定されていない場合は、TimesTenによって選択されます。

    詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepAdminに関する説明を参照してください。


  6. サブスクライバ・データベースでレプリケーション・エージェントを起動します。

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

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

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

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

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

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

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

『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の「TimesTenのアップグレード」を参照してください。

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

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

レプリケーション・エージェントは、ttAdminユーティリティに-repStartまたは-repStopオプションを指定して、起動および停止できます。また、ttRepStartおよびttRepStop組込みプロシージャを使用して、ttIsqlコマンドラインからレプリケーション・エージェントを起動および停止することもできます。

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

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

ttAdmin -repStart masterDSN
ttAdmin -repStart subscriberDSN

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

ttAdmin -repStop masterDSN
ttAdmin -repStop subscriberDSN

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

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

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

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

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


注意:

レプリケーション・エージェントは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に設定してレプリケーション・エージェントが自動的に再起動されないように指定することで実現できます。データベースがメモリーにロードされるタイミングを判断するために、データベースがリロードされないようにする設定ポリシーについて、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。

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

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

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

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

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

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

表10-2 データベースの状態

状態 説明

start

状態値: 0

レプリケーション更新が収集され、できるかぎり早くサブスクライバ・データベースに送信されます。サブスクライバ・データベースのレプリケーションが動作していない場合、更新は、送信可能になるまでトランザクション・ログ・ファイルに保存されます。

pause

状態値: 1

レプリケーション更新は、送信を試行されずにログに保存されます。状態がstartに変更されると、送信が開始します。

stop

状態値: 2

レプリケーション更新は、サブスクライバ・データベースに送信されずに破棄されます。サブスクライバ・データベースをstop状態にすると、マスターのトランザクション・ログに保留されている更新がすべて破棄されます。

警告: このサブスクライバの再起動を計画している場合、停止と再起動の間、更新は格納されません。このため、サブスクライバを再起動すると、サブスクライバには、マスターからの更新はすべて含まれません。再起動を計画している場合、サブスクライバを停止するかわりに、一時停止します。

failed

状態値: 4

しきい値(ログ・データ)を超えているため、サブスクライバへのレプリケーションは失敗したとみなされます。この状態は、システムによって設定され、システムが状態をstopに設定する前の遷移状態です。failed状態のデータベースに接続するアプリケーションは警告を受信します。詳細は、「一般的なフェイルオーバーおよびリカバリの手順」を参照してください。


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

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

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

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

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

注意:

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

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

マスター・データベースで、ttRepSubscriberStateSet組込みプロシージャをコールして、repschemeレプリケーション・スキームのサブスクライバ・データベース(subscriberds ON system1)の状態をstopに設定します。

Command> CALL ttRepSubscriberStateSet('repscheme', 'repl',
          'subscriberds', 'system1', 2);

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