14 レプリケーション・パフォーマンスの向上

レプリケーション・パフォーマンスを向上させる方法を次に説明します。

• パラレル・レプリケーションを構成します。「パラレル・レプリケーションの構成」を参照してください。

• デフォルトの非同期のレプリケーションを使用します。詳細は、「パフォーマンスとリカバリのトレードオフについての判断」を参照してください。ただし、アクティブ・スタンバイ・ペアを使用している場合、RETURN RECEIPT(半同期レプリケーション)よりもRETURN TWOSAFE(同期レプリケーション)のパフォーマンスの方が優れています。

• LogFileSizeおよびLogBufMB初期接続属性を最大値に設定します。詳細は、「ロギングの接続属性の設定」を参照してください。

• ワークロードが高く、レプリケーションが遅延することがある場合、インメモリー・ログ・バッファからではなく、ディスク上のトランザクション・ログからレプリケート対象の変更を取得する必要があります。できるだけ高速の記憶域をTimesTenトランザクション・ログ用に使用することで、トランザクション・ログのフラッシュとレプリケーションの取得によるI/Oの競合が緩和し、ワークロードが少ない時間帯にレプリケーションが遅れをすばやく取り戻せるようになります。複数の高速ディスクまたはソリッド・ステート・ストレージにRAID 0ストライプを構成した高性能のキャッシュ・ディスク・アレイを使用することを検討してください。

• 更新が適用されるデータベースへの様々な接続数を試してみてください。同時接続数が65以上必要な場合、Connections初期接続属性の設定値を高くします。『Oracle TimesTen In-Memory Databaseリファレンス』のConnectionsに関する説明を参照してください。

• トランザクション・ログ・バッファ・サイズ、CPU性能およびリソースを調整します。「トランザクション・ログ・バッファ・サイズおよびCPU」を参照してください。

• 複数のパーティションと余分な領域のある表を変更した後、パフォーマンスの問題が発生する可能性があります。詳細は、「レプリケートされる表を変更するときのパフォーマンスの考慮事項」を参照してください。

• RecoveryThreadsという最初の接続属性を変更して、アクティブ・マスター・データベースからスタンバイ・マスター・データベースに変更を適用するスレッドの数を増やします。詳細は、「アクティブ・スタンバイ・ペアのレプリケーション・スループットの向上」を参照してください。

• レプリケーションおよびXLA操作では、トランザクション・ロギングで大量のオーバーヘッドが発生します。レプリケーションのスケーラビリティは、トランスミッタまたはレシーバの数が制限されている場合に最も高くなります。詳細は、「レプリケーションのトランスミッタとレシーバおよびXLAリーダーの制限」を参照してください。

注意: 追加の推奨事項については、『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』のレプリケーションまたはXLAのパフォーマンスの低下に関する説明を参照してください。

トランザクション・ログ・バッファ・サイズおよびCPUの調整

レプリケーション・スキームを計画する場合は、次の項目を確認してください。

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

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

• レプリケーション・スキームの送信側と受信側でCPUの能力が一致していない場合は、レプリケーションの受信側を高速な方のシステムに配置すること。

レプリケートされる表を変更するときのパフォーマンスの考慮事項

列を追加または削除するために表を変更すると、パフォーマンスや領域使用率が低下する場合があります。

• 1つ以上の列を追加するために表を変更すると、その列用に新しいパーティションが割り当てられます。パーティションの追加によって、データの取得時に追加の処理が発生するため、パフォーマンスが低下します。ALTER TABLEを使用したときにどのようにパーティションが追加されるかを理解するには、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER TABLE」を参照してください。

• 列を削除するために表を変更しても、領域が解放されるわけではないため、領域使用率が低下します。

TABLE DEFINITION CHECKING EXACT属性で定義されたレプリケーション・スキームでは、両方のマスター・データベース間で操作をレプリケートできるようにするために、それらのマスター・データベース上に同じ物理構造の表が必要です。EXACT表定義チェック属性を使用している場合、列の削除によって発生した余分な領域を解放したり、列の追加によって発生した余分なパーティションを排除するための唯一の方法は、表を削除して再作成した後、その表にデータをリロードすることです。

ただし、TABLE DEFINITION CHECKING RELAXED属性で表を作成した場合は、(表のキー定義、列数、列のデータ型は同じですが、)両方のマスター・データベースで物理構造が同じである必要はありません。TABLE DEFINITION CHECKING RELAXED属性によってパフォーマンスはわずかに低下しますが、これは両方のマスター上の表が同じでない場合です。パフォーマンスの変化は、ワークロードおよび表のパーティションおよび列の数に応じて異なります。

RELAXEDが設定されたデータベースのパフォーマンスを向上させるには、ttMigrate -r -relaxedUpgradeを使用して表を結合し、列の削除によって発生した余分な領域または列の追加によって作成された複数のパーティションを排除します。これを行うことができるのは1つのデータベースのみであり、その間、もう一方のデータベースは稼働を続け、アプリケーションにかわってリクエストを受け付けています。レプリケーションに含まれる両方のデータベースを同時に停止する必要はなく、1つずつ順番にttMigrate -r -relaxedUpgradeを実行できます。これは、表が頻繁に変更されるデータベースの場合、およびデータベースがオンライン・アップグレードのみを行う場合に最適です。

表定義チェックがRELAXEDの場合、レプリケートされた表に対するttMigrate -r -relaxedUpgradeでできるのは、パーティションを結合し、余分な領域を排除することのみです。ただし、表でEXACT属性が使用されている場合は、表定義チェックを一時的にRELAXEDに設定し、表のパーティションと領域を連結した後、EXACTにリセットできます。

TABLE DEFINITION CHECKING RELAXED属性の詳細は、「レプリケート表の列定義オプション」を参照してください。

注意: 表に複数のパーティションがあるかどうかを確認できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER TABLE」のALTER TABLE使用時のパーティションに関する説明、および『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』の表のパーティション数の確認に関する説明を参照してください。

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

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

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

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

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

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

レプリケーションのトランスミッタとレシーバおよびXLAリーダーの制限

レプリケーションおよびXLA操作では、トランザクション・ロギングで大量のオーバーヘッドが発生します。レプリケーションのスケーラビリティは、トランスミッタまたはレシーバの数が制限されている場合に最も高くなります。レプリケーションのトポロジを調べ、簡略化できるかどうか確認します。通常、XLAのスケーラビリティは、リーダーの数が制限されている場合に最も高くなります。アプリケーションのリーダー数が多い場合は、その数を削減できるかどうかを確認します。

XLAおよびレプリケーションを監視して、読取りがディスクからではなく、トランザクション・ログ・バッファから行われていることを確認してください。同時実行される更新が多いと、レプリケーションが処理されない場合があります。サブスクライバでは、更新はシングルスレッドです。確認の頻度が減少すると、XLAのスループットを向上できます。

SYS.MONITOR表のLOG_FS_READS列およびLOG_BUFFER_WAITS列の値を確認して、必要なリーダーおよびトランスミッタの数を見積もります。この情報は、接続が確立または解放されるたび、およびトランザクションがコミットまたはロールバックされるたびにシステムによって更新されます。

LogFlushMethod=2を設定すると、RETURN TWOSAFEレプリケーション処理、およびDURABLE TRANSMITが指定されたRETURN RECEIPT処理のパフォーマンスを向上できます。