Chat now with support
Chat with Support

Please note, you may experience access issues between 6am - 7am Eastern time on Saturday, May 28 2022 due to planned maintenance

SharePlex 8.6.6 - リファレンス・ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex コマンド SharePlex パラメータ SharePlex ユーティリティ 付録 B:SharePlex 環境変数

SharePlex をサポートするための Oracle redo ロギングのセットアップ

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 がアーカイブログを読み込むかどうかを決定できます。

  1. SHAREPLEX_ACTID テーブルをクエリすることで、SharePlex が処理しているログを判断します。

    SQL> select seqno from splex.shareplex_actid

  2. Oracle の V$LOG テーブルをクエリすることで、Oracle が書き込んでいるログを判断します。

    SQL> select sequence# from v$log where status='CURRENT'

  3. sequence# の値から、seqno の値を引き算します。こうすることで、Capture がいくつのログで Oracle から遅れをとっているかが分かります。
  4. オンライン REDO ログをその値から引き算します。この数が負である場合は、SharePlex はアーカイブログを処理しています。たとえば、10 個の REDO ログがあり、SharePlex が 11 ログ分遅れている場合は、アーカイブログを処理しています。さらに、この結果を使用して、オンラインロギングの設定を調整できます。

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 の生成量のペースに追いつけない場合、次に当てはまる可能性があります。

  • アーカイブログからのキャプチャによる SharePlex でのパリティの復元を待機する代わりに、データを再同期する方が実際的である可能性があります。
  • 失われた操作を Capture が処理およびキューイングしている間に、ソースシステムのディスクスペースが不足する可能性があります。
  • 特に、必要なアーカイブログを利用できなくなった場合に、Post が SQL 文を作成するために必要な情報を SharePlex が失う可能性があります。SharePlex の実行中は常に、ディスクスペースと遅延を監視します。
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating