Chat now with support
Chat with Support

SharePlex 11.4 - 管理者ガイド

このガイドについて このガイドで使用される表記規則 SharePlexの概要 SharePlexの実行 SharePlexの複数のインスタンスの実行 sp_ctrlでのコマンドの実行 SharePlexパラメータの設定 データレプリケーションの設定 コンテナデータベースとの間のレプリケーションの設定 名前付きキューの設定 分割レプリケーションの設定 変更履歴ターゲットへのレプリケーションの設定 レプリケーション戦略の設定 DDLレプリケーションの設定 エラー処理の設定 データトランスフォーメーションの設定 セキュリティ機能の設定 SharePlexユーザのセキュリティグループへの割り当て 本番システムでのレプリケーションの開始 SharePlexの監視 レプリケーションの問題の防止と解決 非同期データのrepair Captureプロセスの調整 Postプロセスの調整 Oracleフェールオーバー後のレプリケーションのリカバリ アクティブなレプリケーション環境に対する変更 Oracleアプリケーションのパッチまたはアップグレードの適用 ソースまたはターゲットのOracleデータのバックアップ トラブルシューティングのヒント 付録A: ピアツーピア図 付録B: SharePlex環境変数

ディスク容量不足を解消する方法

このトピックは、何かがレプリケーションを妨げた場合に発生する可能性のあるディスク容量の問題解決に役立ちます。考えられる原因については、「レプリケーションの問題の解決 ページを参照してください。

ターゲットのディスク容量を節約する方法

SharePlexは、データをキャプチャして処理する速度が、SQLステートメントを使用してターゲットシステムにポストする速度よりも大幅に速いため、ネットワークが稼働しており、ソースからデータが送信されていると仮定した場合、ほとんどのディスクの問題が発生する可能性が高いのはターゲットです。postキューがディスク容量を超える可能性があると思われる場合、postキューがクリアされるまでデータを一時的に保存するための十分な空き容量がソースシステムにある可能性があります。

ターゲットのディスク容量を節約するには:

  1. Importプロセスを停止します。
  2. Postがpostキューをクリアするのに十分なメッセージを処理するまで、データをソースシステムに蓄積させます。
  3. Importを開始します。
  4. postキューに蓄積されるデータ量が平準化されるまで、Importの停止と開始を続けます。

この方法を実施する場合は、ソースシステム上のレプリケーションサービスとディスク使用量を監視します。UnixおよびLinuxシステムでは、sp_psスクリプトを使用してプロセスを監視し、sp_qstatmonモニタリングスクリプトを使用してキューを監視することができます。

ディスク容量の復元の方法

キュー用ディスクのディスク容量が不足すると、イベントログにこのようなメッセージが表示されることがあります:

11/22/07 14:14 System call error: No space left on device bu_wt.write [sp_mport(que)/1937472]

11/22/07 14:14 System call error: No space left on device bu_rls.bu_wt [sp_mport(que)/1937472]

11/22/07 14:14 Error: que_BUFWRTERR: Error writing buffer to file que_writecommit(irvspxuz+P+o.a920a64z-o.a102a64z) [sp_mport(rim)/1937472] 11/22/07 14:14 Error: sp_mport: rim_writecommit failed 30 - exiting [sp_mport/ 1937472]

11/22/07 14:14 Process exited sp_mport (from irvspxuz.domain.com queue irvspxuz) [pid = 1937472] - exit(1)

キュー用ディスクの空き容量がほとんどない場合、データを再同期することなくディスク容量を追加できる可能性があります。

ディスク容量を復元するには:

  1. 影響を受けるシステムでSharePlexを停止します。
  2. ディスク容量を増やします。
  3. SharePlexを起動します。
  4. イベントログを表示し、メッセージ「queue recovery startedキューのリカバリが開始されました」および「queue recovery completeキューのリカバリが完了しました」を探します。

    • 両方のメッセージがあれば、SharePlexは中断したところから処理を再開し、リカバリは成功しています。アプリケーションによって大量のトランザクションが生成された場合、キューに多数の滞留メッセージが存在する可能性があります。トランザクションの特性、ターゲットデータベースとPostプロセスの調整の程度、レイテンシに対する許容度によっては、レプリケーションがトランザクションのアクティビティと同等になるのを待つのではなく、データを再同期する方が現実的な場合もあります。
    • 1つまたは複数のキューが破損している場合、イベントログには以下のようなメッセージが記録されます。「Bad header magic...」または「peekahead failure」またはメッセージ「queue recovery startedキューのリカバリが開始されました」が表示されますが、キューのリカバリに成功したことを示すメッセージ「queue recovery completeキューのリカバリが完了しました」は表示されません。この場合、レプリケーションを初期状態に復元する必要があります。

レプリケーションを初期状態に復元するには:

  1. db_cleanspを実行し、変数データディレクトリとSharePlexテーブルを復元します。これは、影響を受けるレプリケーション設定内のすべてのシステムで実行しなければなりません。『SharePlexリファレンスガイド』のユーティリティに関する文書を参照してください。
  2. 希望する方法でデータを同期させ、設定を再度アクティベーションします。詳細については、本番システムでのレプリケーションの開始を参照してください。
  3. この問題の再発を防止するには、SharePlexの監視ユーティリティを使用して、キューの容量に関するアラートを含む主要なレプリケーションイベントの無人での監視を開始します。詳細については、SharePlexの監視を参照してください。

ORACLE_SIDおよびORACLE_HOMEの見つけ方

Oracleデータベースで動作するようにSharePlexをセットアップする場合、ORACLE_SIDを指定すると、SharePlexoratabファイルUnix/LinuxからORACLE_HOMEを取得します。両方の値はSharePlexの環境に保存されます。SharePlexは、ORACLE_HOMEで指定された場所にあるOracleライブラリを使用します。

SharePlexで使用されているORACLE_SIDとORACLE_HOMEを特定するには:

sp_ctrlorainfoコマンドを実行します。

sp_ctrl (mysysl11:2101)> orainfo

Oracle instance #1:

Oracle SID ora12

Oracle HOME /oracle/products/12

Oracle Version 12

Oracle instance #2:

Oracle SID ora12

Oracle HOME /oracle/products/12

Oracle Version 12

UNIXとLinuxでデフォルトのORACLE_SIDとORACLE_HOMEを特定するには:

ほとんどのUnixおよびLinuxシステムでは、oratabファイルは/etc/oratabの下にあります。Oracle Solarisシステムでは/var/opt/oracleの下にありますが、場合によってはoratabファイルは/etcディレクトリにもあります。

ファイル内のエントリは以下の例のようになります。

qa12:/qa/oracle/ora12/app/oracle/product/12.0

この例では、qa12はORACLE_SID、/qa/oracle/ora12/app/oracle/product/12.0はORACLE_HOME です。

非同期データのrepair

この章ではSharePlexのcompareおよびrepair機能の概要を説明します。SharePlexは、Oracleテーブルの内蔵サポートとしてこの機能を提供し、ソースシステムとターゲットシステム間で同期されたデータの維持を支援します。

内容

compareとrepairの概要

レプリケーションの正常性とパフォーマンスを定期的に監視するだけでなく、ソースとターゲットのデータを定期的にcompareし、すべてのデータが同期されていることを確認することをお勧めします。Postは処理中の行の非同期状態を検出しますが、非同期状態が隠れている場合があります。このような例としては、ターゲットに適用されたDMLや不完全なバックアップのリストアがあります。このような状態は、非同期の行に影響を与える操作をPostが適用するまで検出されない可能性があります。SharePlexのcompareとrepair機能により隠れた非同期状態を検出し、修復することができます。

注意: どのように非同期の状態非表示になるかを理解するには、「同期の概念の理解ページを参照してください。

SharePlexには、非同期のデータをcompare・repairするための以下のコマンドが用意されています。

  • compare: 個のソーステーブルとそのターゲットテーブルをcompareするか、同じスキーマ内のワイルドカードで指定されたテーブルセットをcompareします。
  • compare using: ファイルから入力を受け取り、アクティブなレプリケーション設定の一部またはすべてのテーブルをcompareします。
  • repair: 同じスキーマ内の個のターゲットテーブルまたはワイルドカードで指定されたテーブルのセットをrepairします。
  • repair using: ファイルから入力を受け取り、アクティブなレプリケーション設定の一部またはすべてのテーブルをrepairします。

サポート対象のソースとターゲット

OracleからOracleへ、PostgreSQLからPostgreSQLへ

サーバおよびクライアントプロセスの概要

compareコマンドとrepairコマンドは常にソースシステムで発行されます。このコマンドはソースシステムでサーバプロセスを生成し、SharePlexのキューを通じてメッセージを送り、ターゲットシステムでクライアントプロセスを生成します。

その後、サーバプロセスとクライアントプロセスは互いに通信を開始します。コマンドに含まれる構文オプションによっては、プロセスがターゲット上でマルチスレッド化されることがあります。2つのプロセスはソーステーブルとターゲットテーブルをcompareし、その結果をログファイルに書き出します。

ロックの管理方法

compareの間、SharePlexは行選択のための読み取りの一貫性を得る目的で、ソースおよびターゲットテーブルで短時間の排他ロックを取得します。これにより、SharePlexがデータを処理している間、行データの一貫性が保証されます。ロックの解除後、行は、読み取り一貫性ビューを使用してソースとターゲットの両方で同一の方法で読み込まれ、ソートされます。次に行のバッチが読み込まれ、チェックサムが実行されます。チェックの合計が一致すると、別の行のバッチが同じように処理されます。チェックサムが一致しない場合、プロセスはどの行が同期していないかを判断し、それらをrepairするSQLステートメントを作成します。repairプロセス実行時にターゲットテーブルはロックされ、他のプロセスによってデータが変更されないようにします。

WHERE句、targetWHERE、またはsourceWHEREオプションが指定された場合、条件に一致する行のセットのみがロックされますこれはPostgreSQLデータベースにのみ適用される

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating