ヘッダーをスキップ

Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド リリース6.0 B25769-01 |
| 目次 | 索引

前へ | 次へ |

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

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

- データ・ストアの設定
- レプリケート・データ・ストアのログの管理

## データ・ストアの設定

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

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

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

- データ・ストアに接続し、SQL文を使用して、マスターからレプリケートする表と一致する新しい表をサブスクライバ・データ・ストアに作成します。
- ttRepAdmin -duplicateユーティリティを使用して、マスター・データ・ストアの内容全体をサブスクライバにコピーします（「サブスクライバへのマスター・データ・ストアのコピー」を参照）。

### データ・ストア属性

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

- ExclAccess: マスターとサブスクライバの両方で共有モードを使用する必要があります（排他アクセスを無効にします）。
- Logging: 可能なかぎり、レプリケート・データ・ストアのDSNではディスク・ロギングを有効にする必要があります。詳細は、「レプリケート・データ・ストアのログの管理」を参照してください。
- LogBuffSizeおよびLogFileSize: 「レプリケート・データ・ストアのログの管理」を参照してください。
- SMPOptLevel: SMPOptLevelは、データ・ストアへの最初の接続によって設定されます。通常、レプリケーション・データ・ストアの場合は、レプリケーション・エージェントが設定します。設定したSMPOptLevelは、アプリケーションで使用されるDSNのSMPOptLevelの設定に関係なく、他の接続で変更することはできません。このため、レプリケーション・スキームを適用するDSNに、接続中のアプリケーションで許容可能なMPOptLevelが設定されていることを確認してください。レプリケーション・スキームをDSNに適用する方法については、「データ・ストアへのレプリケーション・スキームの適用」を参照してください。

### 表要件および制限

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

- レプリケーション・スキームに関連する表の名前、所有者、列定義は、マスターとサブスクライバの両方のデータ・ストアで一致している必要があります。
- レプリケートする表には、次の特性が必要です。

- 主キー
- NOT NULL列に定義された一意索引

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

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

- レプリケーション行の合計サイズは100,000バイトを超えることはできません。たとえば、60,000バイトのVARCHARが2つ含まれる行をレプリケートすることはできません。
- レプリケート表のVARCHAR列およびVARBINARY列のサイズは、256,000バイトまたは文字に制限する必要があります。NVARCHAR列のサイズは、128,000バイトまたは文字列に制限する必要があります。
- アクセス制御が有効になっている場合は、レプリケート対象の表に対してCREATE REPLICATION、DROP TABLE、INSERT、SELECT、UPDATE、DELETEを実行する権限が必要です。
- レプリケーション・スキームが定義されているデータ・ストアでは、一時表を定義および使用することができますが、一時表自体をレプリケートすることはできません。

CREATE SEQUENCE文を使用して生成される値は、各データ・ストアで異なるためレプリケートされません。詳細は、「SEQUENCE番号を持つデータ・ストアのリカバリ」を参照してください。

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

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

ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データ・ストアを複製できます。ただし、マスター・データ・ストアの内容をコピーしてサブスクライバ・データ・ストアに移入する前に、次の手順を実行する必要があります。

1. 新しいサブスクライバ・データ・ストアのDSNを作成します。
2. 「レプリケーション・スキームの定義」の説明に従って、レプリケーション・スキームを作成または変更して、新しいサブスクライバ・データ・ストアおよびそのホストを指定します。
3. 「データ・ストアへのレプリケーション・スキームの適用」の説明に従って、レプリケーション・スキームをマスター・データ・ストアに適用します。
4. 「レプリケーション・エージェントの起動および停止」の説明に従って、マスター・データ・ストアのレプリケーション・エージェントを起動します。

たとえば、ホストserver1にはmasterdsデータ・ストアについて記述するmasterDSNという名前のDSNがあり、ホストserver2にはnewstoreデータ・ストアについて記述するnewstoreDSNという名前のDSNがあります。

newstoreデータ・ストアにmasterdsの内容を移入するには、次の手順を実行します。

server1で:

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

    CREATE REPLICATION repl.repscheme
      ELEMENT e TABLE repl.tab
      MASTER masterds ON "server1"
      SUBSCRIBER newstore ON "server2";
    call ttRepStart;

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

    > ttIsql -f newrepscheme.sql masterds

server2で:

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

    > ttRepAdmin -dsn newstore -duplicate -from masterds
    -host "server1"

    これで、newstoreデータ・ストアにmasterdsデータ・ストアと同じ内容が含まれました。

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

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

#### 問題が発生した場合

最新のトラブルシューティング情報については、http://www.oracle.com/technology/documentation/timesten_doc.htmlにある『Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド』のレプリケーションのトラブルシューティングに関する章を参照してください。

## レプリケート・データ・ストアのログの管理

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

- ログ・バッファのサイズおよび永続性について
- マスター・データ・ストアでのログの増大について
- ログ障害しきい値の設定
- ディスクベース・ロギングの属性の設定
- ディスクレス・ロギングの属性の設定

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

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

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

- ログ・バッファが一杯になった場合。
- ttDurableCommitがコールされた場合、またはDurableCommits=1での接続でトランザクションがコミットまたはロールバックされた場合。
- レプリケーション・エージェントがサブスクライバにトランザクションのバッチを送信する際に、マスターがレプリケーションに対してTRANSMIT DURABLE属性（デフォルト）で設定されている場合（「デフォルトのレプリケーション」を参照）。
- プライマリ・ストアがTRANSMIT DURABLEで設定されているかどうかに関係なく、レプリケーションが定期的に永続コミットを実行する場合。
- DSNがLogFlushMethod=2で設定されている場合は、アプリケーションに制御が返される前にディスクへの書込みが行われます。

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

### マスター・データ・ストアでのログの増大について

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

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

### ログ障害しきい値の設定

しきい値を設定することができます。この値を超えると、使用可能なログ領域を使い果たす前に、使用不可能なサブスクライバをFailed状態に設定します。

ログしきい値を設定するには、CREATE REPLICATIONまたはALTER REPLICATION文でFAILTHRESHOLD値とともにSTOREパラメータを指定します（例3.19を参照）。
注意: ALTER REPLICATIONを使用して既存のレプリケーション・スキームのしきい値を再設定する場合は、まずレプリケーション・エージェントを停止し、ALTER REPLICATIONを使用して新しいしきい値を設定し、そしてレプリケーション・エージェントを再起動します。

デフォルトのしきい値は0（ゼロ）で、「制限なし」を意味します。これ以外のしきい値は、ディスクレス・ロギングを使用しているか、ディスクベース・ロギングを使用しているかによって異なります。詳細は、「ディスクレス・ロギングの属性の設定」および「ディスクベース・ロギングの属性の設定」を参照してください。

マスターは、サブスクライバ・データ・ストアをFailed状態に設定すると、障害が発生したサブスクライバのすべてのデータをログから削除し、そのサブスクライバ・データ・ストアにメッセージを送信します（マスター・レプリケーション・エージェントでサブスクライバ・レプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます）。サブスクライバは、双方向レプリケーションの場合または他のサブスクライバに更新を伝播するように設定されている場合、マスターからメッセージを受信すると、それ以上更新を送信しません。これは、レプリケーションの点からみて自身の状態が損なわれたためです。

障害が発生したサブスクライバに接続中のアプリケーションは、データ・ストアがレプリケーション・ピアによってFailedとマークされたことを示すtt_ErrReplicationInvalid (8025)警告を受信します。サブスクライバ・データ・ストアにその障害状態が通知されると、マスター・データ・ストアでのその状態はFailedからStopに変更されます。

アプリケーションでは、ODBCのSQLGetInfo関数を使用して、接続中のデータ・ストアがFailed状態に設定されているかどうかを確認できます「サブスクライバの障害」を参照）。

### ディスクベース・ロギングの属性の設定

最大の利便性と信頼性を得るには、すべてのレプリケーション・データ・ストアに対してディスクベースのロギングを有効（Logging = 1）にします。

ディスクベースのロギングを使用する場合は、データ・ストアをパーマネントとして（Temporary = 0）設定します。一時データ・ストア（Temporary = 1）上で、ディスクベース・ロギング（Logging = 1）は設定できません。

LogBuffSizeでは、インメモリー・ログ・バッファの最大サイズを指定します。このバッファは、一杯になると、ディスク上のログ・ファイルにフラッシュされます。LogBuffSize値を小さくすると、パフォーマンスに影響はありますが、信頼性には影響しません。

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

- DSNのLogFileSize設定では、ログ・ファイルの最大サイズを指定します。ロギング要件がこの値を超えると、同じ最大サイズを持つ追加のログ・ファイルが作成されます（LogFileSizeをLogBuffSizeより小さい値に設定すると、TimesTenはLogBuffSizeに一致するようにLogFileSizeを自動的に大きくします）。
- ログのしきい値の設定では、マスターがサブスクライバで障害が発生したと想定する前に累積可能なログ・ファイルの最大数を指定します。このしきい値は、最後に書き込まれたログ・ファイルと、サブスクライバ用に最初に保存されたログ・ファイルの間のログ・ファイルの数です。たとえば、すべてのサブスクライバが受信に成功した最後のレコードがログ・ファイル1にあり、ディスクに書き込まれた最後のログ・レコードがログ・ファイル4の先頭にある場合は、2つ以上のログ・ファイル（ログ・ファイル2および3の内容）がレプリケートされていません。しきい値が2の場合、マスターは、しきい値を超えたことを検出した後にサブスクライバをFailed状態に設定します。これには10秒かかる場合があります。詳細は、「ログ障害しきい値の設定」を参照してください。

トランザクションがディスクにロギングされた場合は、ブックマークを使用してサブスクライバにレプリケートされた更新レコードおよびディスクに書き込まれた更新レコードのLSN（ログ順序番号）を検出できます。masterDSNに関連付けられているサブスクライバのブックマークの位置を表示するには、ttRepAdminユーティリティまたはttBookmarkプロシージャを使用します。「レプリケート・ログ・レコードの表示」を参照してください。

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

### ディスクレス・ロギングの属性の設定

使用可能なディスクがないシステムでTimesTenを実行している場合は、ディスクレス・ロギング（Logging = 2）を使用できます。ただし、次のデメリットを考慮する必要があります。

- データ・ストアは一時データ・ストアである必要があります（Temporary = 1）。
- データ・ストアのインメモリー・ログ・バッファが一杯にならないように、そのサイズを十分大きく設定する必要があります。
- データ・ストア障害が発生した場合、障害発生時にレプリケートされていなかったすべての更新が失われます。

ディスクレス・ロギング使用時のトランザクション・ログ・バッファのサイズに関する設定には、次の2つの設定があります。

- DSNのLogBuffSize設定では、インメモリー・ログ・バッファの最大サイズを指定します。ログ・バッファの設定方法は、使用可能なメモリー、トランザクションの最大存続時間および同時トランザクションの予測最大数によって異なります。
- ログのしきい値の設定では、ログ・バッファの割合を指定します。この値を超えると、使用不可能なサブスクライバ・データ・ストアの状態はFailedに設定されます。たとえば、しきい値が80の場合、ログ・バッファが80%を超えて使用されると、サブスクライバ・データ・ストアはFailed状態に設定されます。詳細は、「ログ障害しきい値の設定」を参照してください。

## 多数のサブスクライバの設定

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

- ログ・バッファのサイズは、SYS.MONITOR表のLOG_FS_READSの値が0（ゼロ）または0（ゼロ）に近い値になるようにすること。これによって、レプリケーション・エージェントでディスクからログ・レコードを読み取る必要がなくなります。LOG_FS_READSの値が増大する場合は、ログ・バッファのサイズを大きくします。
- CPUリソースが適切であること。マスター・データ・ストアのレプリケーション・エージェントは、各サブスクライバ・データ・ストアに対してスレッドを生成します。各スレッドでログの読取りおよび処理が個別に行われるため、処理を続行するには適切なCPUリソースが必要です。