このトピックは、何かがレプリケーションを妨げた場合に発生する可能性のあるディスク容量の問題解決に役立ちます。考えられる原因については、「レプリケーションの問題の解決 ページを参照してください。
SharePlexは、データをキャプチャして処理する速度が、SQLステートメントを使用してターゲットシステムにポストする速度よりも大幅に速いため、ネットワークが稼働しており、ソースからデータが送信されていると仮定した場合、ほとんどのディスクの問題が発生する可能性が高いのはターゲットです。postキューがディスク容量を超える可能性があると思われる場合、postキューがクリアされるまでデータを一時的に保存するための十分な空き容量がソースシステムにある可能性があります。
ターゲットのディスク容量を節約するには:
この方法を実施する場合は、ソースシステム上のレプリケーションサービスとディスク使用量を監視します。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)
キュー用ディスクの空き容量がほとんどない場合、データを再同期することなくディスク容量を追加できる可能性があります。
ディスク容量を復元するには:
イベントログを表示し、メッセージ「queue recovery started(キューのリカバリが開始されました)」および「queue recovery complete(キューのリカバリが完了しました)」を探します。
Oracleデータベースで動作するようにSharePlexをセットアップする場合、ORACLE_SIDを指定すると、SharePlexはoratabファイル(Unix/Linux)からORACLE_HOMEを取得します。両方の値はSharePlexの環境に保存されます。SharePlexは、ORACLE_HOMEで指定された場所にあるOracleライブラリを使用します。
SharePlexで使用されているORACLE_SIDとORACLE_HOMEを特定するには:
sp_ctrlでorainfoコマンドを実行します。
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 です。
この章ではSharePlexのcompareおよびrepair機能の概要を説明します。SharePlexは、Oracleテーブルの内蔵サポートとしてこの機能を提供し、ソースシステムとターゲットシステム間で同期されたデータの維持を支援します。
レプリケーションの正常性とパフォーマンスを定期的に監視するだけでなく、ソースとターゲットのデータを定期的にcompareし、すべてのデータが同期されていることを確認することをお勧めします。Postは処理中の行の非同期状態を検出しますが、非同期状態が隠れている場合があります。このような例としては、ターゲットに適用されたDMLや不完全なバックアップのリストアがあります。このような状態は、非同期の行に影響を与える操作をPostが適用するまで検出されない可能性があります。SharePlexのcompareとrepair機能により隠れた非同期状態を検出し、修復することができます。
注意: どのように非同期の状態(非表示)になるかを理解するには、「同期の概念の理解ページを参照してください。
SharePlexには、非同期のデータをcompare・repairするための以下のコマンドが用意されています。
OracleからOracleへ、PostgreSQLからPostgreSQLへ
compareコマンドとrepairコマンドは常にソースシステムで発行されます。このコマンドはソースシステムでサーバプロセスを生成し、SharePlexのキューを通じてメッセージを送り、ターゲットシステムでクライアントプロセスを生成します。
その後、サーバプロセスとクライアントプロセスは互いに通信を開始します。コマンドに含まれる構文オプションによっては、プロセスがターゲット上でマルチスレッド化されることがあります。2つのプロセスはソーステーブルとターゲットテーブルをcompareし、その結果をログファイルに書き出します。
。
compareの間、SharePlexは行選択のための読み取りの一貫性を得る目的で、ソースおよびターゲットテーブルで短時間の排他ロックを取得します。これにより、SharePlexがデータを処理している間、行データの一貫性が保証されます。ロックの解除後、行は、読み取り一貫性ビューを使用してソースとターゲットの両方で同一の方法で読み込まれ、ソートされます。次に行のバッチが読み込まれ、チェックサムが実行されます。チェックの合計が一致すると、別の行のバッチが同じように処理されます。チェックサムが一致しない場合、プロセスはどの行が同期していないかを判断し、それらをrepairするSQLステートメントを作成します。repairプロセス実行時にターゲットテーブルはロックされ、他のプロセスによってデータが変更されないようにします。
WHERE句、targetWHERE、またはsourceWHEREオプションが指定された場合、条件に一致する行のセットのみがロックされます(これはPostgreSQLデータベースにのみ適用される)。
© ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center