SharePlex は、オンラインおよびアーカイブの Oracle redo ログからキャプチャします。SharePlex は、ローデバイス、ファイルシステムデバイス、および ASM インスタンスに保存されている redo ログおよびデータファイルをサポートしています。
最低限のサプリメンタルロギングを設定してから、SharePlex の複製設定をアクティベートする必要があります。
さらに、SharePlex は、プライマリキーと一意キーの両方のサプリメンタルロギングを設定する、またはレプリケーション内の各テーブルに、一意の列のサプリメンタルロググループを定義することをお勧めします。行更新のキー列が redo ログにある場合は、SharePlex がその情報をデータベースからフェッチする必要はありません。ビジー状態のシステムでは、これで Read プロセスのパフォーマンスが大幅に向上します。一部の SharePlex 機能では、プライマリキーと一意キーのロギングを有効にする必要があります。
テーブルの rowid を変更する ALTER TABLE DDL コマンドは、複製中のテーブルのプライマリキーまたは一意キーがログに記録されていない場合、その後の DML 操作に影響する可能性があります。キーがログに記録されていない場合、SharePlex は rowid に基づいて値をフェッチします。ALTER TABLE...MOVE などの rowid を変更する操作により、その後の DML 操作で誤ったキー値が使用される可能性があります。
キー値を定義する場合の詳細については、「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。
プライマリキーと一意キーのサプリメンタルロギングを有効にしており、テーブルにプライマリキーがない場合、どのタイプの一意キーをログに記録するのかを Oracle が決定する必要があります。テーブルに複数の種類の一意キーがある場合、Oracle は使用する最適なキーを決定して、UPDATE ごとにこれらの列値をログに記録します。テーブルにどの種類のキーもない場合は、Oracle は LONG または LOB ではないすべての列をログに記録します。
SharePlex は、データの複製に使用するキーも識別する必要があります。Oracle と同様に、SharePlex は次の順序でキーを選択します。
SharePlex が複製しているテーブルにプライマリキーがなく、複数種類の一意キーが存在している場合、Oracle がログに記録したキー列が SharePlex が必要とするキー列ではない可能性があります。
キー値を定義する場合の詳細については、「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。
複製がアクティブであるときに、Capture プロセスが停止した（または SharePlex ユーザーによって停止された）場合、Capture はその場所を REDO ログに記録し、再開した時点でその場所から継続します。もし REDO ログが Capture が再開する前にラップした場合は、Capture は欠損したレコードを見つけるためにアーカイブログを読み込みます。
理想的には、SharePlex がアーカイブログを読み込まないで済むように、REDO ログを設定するべきです。ほとんどの場合、オンラインログの読み込みはアーカイブの読み込みよりも高速です。アーカイブログからの処理を最小化するために、オンライン REDO ログが十分に大きく多数であることを確認します。最小でも、ラップせずに数時間分を保持できる REDO ログの容量が必要です。
注：Exadata システムでは、ログを異なるシステムに多重化することで、Capture を高速化できる可能性があります。「Exadata での Capture のチューニング」を参照してください。
適切なオンラインログの設定をテストするには
実稼働前のテストでは、次の手順を実行することで、Capture がアーカイブログを読み込むかどうかを決定できます。
SHAREPLEX_ACTID テーブルをクエリすることで、SharePlex が処理しているログを判断します。
SQL> select seqno from splex.shareplex_actid
Oracle の V$LOG テーブルをクエリすることで、Oracle が書き込んでいるログを判断します。
SQL> select sequence# from v$log where status='CURRENT'
Capture が停止してから再開するまでの間に長い遅延が発生している場合、Capture が Oracle の処理に追いつかず、ソースデータとターゲットデータの間で遅延が生じる可能性があります。このような場合、必要なログがオンラインではなくなるので、Capture は通常、アーカイブを読み込む必要があります。Capture の問題を回避するには、次のようにアーカイブログを設定して、高速な連続複製をサポートします。
| 要件 | 説明 |
|---|---|
| ソースシステムでのアーカイブログの有効化 | アーカイブログをソースシステムで有効にする必要があります。この操作を実行しないと、Capture がオンラインログの処理を終了する前にラップが発生した場合に、ソースデータとターゲットデータの再同期が必要になります。 |
| 圧縮の適切なタイミング | SharePlex が処理を終了するまでアーカイブログを圧縮しないでください。これに反した場合、SharePlex はデータを処理できなくなるため、「Log wrap detected」というメッセージを返して停止します。SharePlex のカレントログを判断するには、ソースシステム上の sp_ctrl で、detail オプションをつけて show capture コマンドを発行します。カレントログの前に生成されたすべてのログを圧縮できます。 |
| デフォルト以外のアーカイブ先の指定 | Oracle のデフォルト以外の場所にアーカイブログを保存している場合は、アーカイブログがあるディレクトリのフルパス名に SP_OCT_ARCH_LOC パラメータを設定します。REDO ログがラップした場合は、SharePlex は Oracle のアーカイブログリストの中のアーカイブログを検索します。そこでアーカイブログが見つからなかった場合は、SP_OCT_ARCH_LOC パラメータで指定されたディレクトリを検索します。Capture で SP_OCT_ARCH_LOC の場所を直接対象にして、Oracle ログリストの読み込みをスキップするには、SP_OCT_CK_LOC_FIRST を 1 に設定します。 |
| ログ管理プロセスを待機するための Capture の設定 | SP_OCT_ARCH_LOC の使用時に、ログをその場所に自動的に移動する手法を使用している場合、移動完了までの一定時間は待機するように Capture を設定できます。これで、必要なログを使用できないという理由で Capture が停止することはなくなります。Capture は待機し、ログをチェックして、ログをまだ利用できない場合は停止します。ログを利用できるようになるまで、このチェックと停止を継続します。待機するように Capture を設定するには、SP_OCT_LOGWRAP_RESTART パラメータで Capture の待機秒数を設定します。これらのプロセスを定期的に監視して、複製の遅延を防ぎます。 |
| ターゲットでのアーカイブログの無効化 | ターゲットシステムのアーカイブログを無効にして、そのシステムで不要な Oracle の処理を削除できます。ただし、高可用性やピアトゥピアの方法は除きます。 |
| ログをルート ASM の場所に配置しないこと |
データベースが ASM を使用している場合、Oracle redo ログ（オンラインおよびアーカイブ）は ASM のルートディレクトリ下には配置できません。SharePlex は、この場所にある対象を読み込むことができません。 |
| Exadata 上のアーカイブログからの読み込み |
通常、オンライン redo ログからの読み込み時に、SharePlex は遅延を最小限に抑えることができます。ただし Exadata では、SharePlex が処理できるデータ量が増えるのは、Exadata ASM ファイルシステムの外部にある多重化されたアーカイブ先から読み込む場合です。詳細については、次を参照： Exadata での Capture のチューニング。 |
重要：Capture が Oracle による redo の生成量のペースに追いつけない場合、次に当てはまる可能性があります。
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy
