Chat now with support
Chat with Support

SharePlex 8.6.6 - 管理ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex の概要 SharePlex の実行 複数の SharePlex インスタンスの実行 sp_ctrl でのコマンドの実行 SharePlex パラメータ 複製のための Oracle 環境の準備 設定ファイルの作成 オープンターゲットのターゲットへの複製の設定 複製方法の設定 分割レプリケーションの設定 名前付きキューの設定 変更履歴ターゲットを維持するための SharePlex の設定 Oracle DDL の複製 エラー処理のセットアップ データの変換 SharePlex セキュリティ機能の設定 実稼動環境での複製のアクティベート SharePlex の監視 複製上の問題の防止および解決方法 非同期データの修復 Oracle の高可用性を維持するための手順 アクティブな複製環境の変更 Oracle アプリケーションのパッチまたはアップグレードの適用 ソースまたはターゲット上の Oracle データのバックアップ Capture プロセスのチューニング Post プロセスのチューニング 付録 A:ピアトゥピアの説明図 付録 B:SharePlex 環境変数

同期の問題の解決

このセクションでは、一般的な同期の問題の原因および解決方法を説明します。こうした解決方法を試しても問題が解決しない場合は、Quest サポートに連絡してください。

詳細については、次を参照: 同期の概念について

発生した問題がこのドキュメントに記載されていない場合は、以下のアドレスの SharePlex サポート技術情報を検索してください。

https://support.quest.com

サポート技術情報には、フィルタリングオプションと、SharePlex の使用およびトラブルシューティングに役立つ他のリソースへのリンクがあります。

SharePlex が非同期状態を報告するしくみ

SharePlex は、トランスフォーメーションに関与するものを除き、すべてのオブジェクトについて、複製されたデータをターゲットに post する前に、所定の操作でソースおよびターゲットのデータが同期されていることを確認します。トランスフォーメーションが使用中の場合、次の理由から、SharePlex は同期を検証しません。

  • トランスフォーメーションがターゲットデータを変更するために、変更前と変更後のイメージを比較できない。
  • SharePlex ではなく、トランスフォーメーションルーチンがデータを post する。

SharePlex は、ソースとターゲットのデータが異なると判断した場合は、エラー状態を生成しますが、post キューからの他のデータの post は継続します。非同期状態が検出されたときに Post で処理を停止するようにするには、SP_OPO_OUT_OF_SYNC_SUSPEND(Oracle)または SP_OPX_OUT_OF_SYNC_SUSPEND(オープンターゲット)パラメータを変更します。『 SharePlex リファレンスガイド』で Post パラメータの説明を参照してください。

非同期状態が発生すると、Post プロセスは Status Database およびイベントログにメッセージを記録します。これらのファイルを sp_ctrl で表示するには

  • Status Database:show statusdb または show sync コマンドを使用します。
  • イベントログ:show log コマンドを使用します。

非同期状態エラーを監視するために、これらのコマンドを頻繁に使用してください。

次は、SharePlex が非同期状態を報告する様子の例です。

sp_ctrl (irvspxu14:8567)> show sync

Out Of Sync Status Database irvspxu14

Count Details

----- --------------------

3 Table "SCOTT"."TG_TEST1" out of sync for queue irvspxu14 since 16-Jun-

08 17:06:33

3 Table "SCOTT"."TG_TEST2" out of sync for queue irvspxu14 since 17-Jun-

08 15:47:58

1 Table "SCOTT"."TG_TEST3" out of sync for queue irvspxu14 since 17-Jun-

08 15:52:03

データが非同期になった場合、SharePlex は、SharePlex 変数データディレクトリの data サブディレクトリにある database_ID_errlog.sql ファイルに失敗した SQL 文を記録します。

重要: Status Database およびイベントログで非同期メッセージが表示されたが、トランザクションの database_ID_errlog.sql ファイルにはレコードがない場合でも、これらのメッセージを無視しないでください。これらは、ROLLBACK. に関連付けられていることがあります。トランザクションがロールバックされるかどうかに関わらず、SharePlex はソースおよびターゲット行のプリイメージを依然として比較します。それらが異なる場合は、データが非同期になっていることを示します。トランザクションがソースでコミットされたが、ターゲットで失敗したときにのみ、SharePlex はそれを database_ID_errlog.sql ファイルに記録して、問題解決のツールとして、また必要に応じて文を手動で適用するために、適用されているべきであった文の記録を残します。ロールバックされた文は、取り消された操作なので、ターゲットには記録されません。

誤った非同期状態の検出

非同期メッセージが誤っており、実際にはデータが非同期状態ではないことがあります。compare コマンドを使用してソースデータとターゲットデータを比較したり、以下の比較を手動で実行したりすることができます。

compare コマンドで比較するには

『 SharePlex リファレンスガイド』で compare コマンドを参照してください。

データが非同期状態であることを確認するには

  1. ターゲットシステムの変数データディレクトリにある database_ID_errlog.sql ファイルから、影響を受ける行の rowid を取得します。
  2. WHERE 句で rowid を使用して、ソーステーブルで SELECT クエリを実行し、この rowid の行データを取得します。
  3. ソースのクエリから取得した行データを WHERE 句で使用して、ターゲットテーブルで SELECT クエリを実行します。
  4. クエリの結果を比較します。異なる場合は、行が非同期状態です。同じ場合は、行が同期されています。

一般的な非同期状態と解決方法

次に、データが非同期になる一般的な状態を説明します。ほとんどの場合で、SharePlex が非同期状態を検出し、エラーメッセージを戻しますが、非同期状態が隠れていて、SharePlex がエラーを戻さない状況もあります。

非同期状態 説明 解決策

不正確なクリーンアップ手順

いずれかの database_cleansp クリーンアップユーティリティが、(すべてではなく)一部のアクティブ設定に関係するシステムで実行されると、SharePlex は非同期状態と認識します。

イベントログを確認して、クリーンアップユーティリティがすべてのシステムで実行されたかどうかを判断します。ログから、各システムで実行されたかどうかと、その実行時期が分かります。また、設定がアクティベートされたかどうか、およびその時期も分かります。これらのイベントの時間を比較することで、何が起こったかを判断できます。

この設定のすべての複製システムでクリーンアップが完了していない場合は、クリーンアップユーティリティをすべてのシステムで実行します。クリーンアップでは、複製キューおよびプロセスを削除して、設定をディアクティベートするために、最初の同期を再び実行する必要があります。

DDL 変更

DDL に関連する非同期状態の原因には次のようなものがあります。

  • ソースオブジェクトに対して複製されていない DDL 変更が行われたが、設定が再アクティベートされておらず、オブジェクトを再分析できない。
  • SharePlex が複製する DDL が、ターゲットでも手動で実行されている。

サポートされる DDL のリストについては、『SharePlex リリースノート』を参照してください。

手動および SharePlex による重複した DDL 変更を取り消すには

  1. Post プロセスを停止します(すでに停止されていることがあります)。

    sp_ctrl(sysB)> stop post

  2. DDL 変更を取り消すために、ターゲットテーブルを変更します。
  3. Post を開始して、SharePlex に複製された DDL を post させます(これはまだ post キューにあります)。

    sp_ctrl(sysB)> start post

 

ターゲットに直接加えられた DML 変更 アプリケーションまたはユーザーがターゲットのテーブルに DML 変更を加えると、その変更の結果によって、Post が影響を受ける行に複製された変更を適用しようとするまで隠れた非同期状態が生じます。変更が適用されると、SharePlex は非同期エラーを返します。

複製中のターゲットテーブルに対するすべての DML アクセスを防止します。

compare および repair コマンドを使用し、テーブルで非同期行を比較し、該当する行を修復します。詳細については、『 SharePlex リファレンスガイド』でコマンドの説明を参照してください。

ターゲットオブジェクトのトリガ

トリガはターゲットオブジェクトで無効にする必要があります。トリガはソースシステムで起動され、SharePlex はその影響をターゲットに複製します。

トリガがターゲットシステムで起動された場合は、トリガで変更されたオブジェクトは非同期になるので、再同期する必要があります。「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。

Oracle ターゲットでトリガの効果を無効にするには

データを再同期した後でターゲット Oracle オブジェクト上のトリガの効果を無効にするには、次のいずれかを実行します。

  • SharePlex Oracle ユーザーを無視するようにトリガに指示する sp_add_trigger.sql スクリプトを実行します。トリガスクリプトの詳細については、『 SharePlex リファレンスガイド』でユーティリティの説明を参照してください。

  • 不要な場合はトリガを無効にします。
不要な制約

一方向の複製設定において、ターゲットテーブルで必要な制約は、プライマリキーおよび一意キー制約だけです。チェック制約はソースで満たされるため、ターゲットでは不要です。外部キーおよび ON DELETE CASCADE 制約もソースで満たされるため、SharePlex はターゲットの適切なテーブルに子操作を複製します。

Oracle ターゲットで ON DELETE CASCADE 制約を無視するように SharePlex を設定する場合は、この制約を有効にしておくことができます。

複製されるオブジェクトで制約を処理する方法については、 「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。

設定ファイルの重複エントリ 重複エントリ(ソース、ターゲット、およびルーティングマップが同一)によって、ターゲットでの post が重複します。

設定ファイルを新しいファイルにコピーします。

新しいファイルで重複を探し、削除します。

ソーステーブルとターゲットテーブルの再同期方法」の指示に従って、再同期および再アクティベートを実行します。

ディスク領域の不足

SharePlex にデータをキューに格納するために十分な場所がないときに、ユーザートランザクションが継続した場合は、データが非同期になります。この状態は次の場合に発生します。

  • ネットワークまたはターゲットシステムが使用不能になり、export キューに蓄積したデータが多すぎた場合。
  • ターゲットが使用不能になり、Post キューに蓄積したデータが多すぎた場合。
  • Capture がソーストランザクションのロギングのペースに追い付かなくなった場合。この場合、Capture キューにデータが蓄積されます。
  • SharePlex プロセスが停止されたが、再起動されていない場合。
  • flush コマンドが発行されたが、Post が再起動されなかった場合。
ディスクスペース不足の解決方法」を参照してください。

水平分割レプリケーションでのカラムコンディションの変更

非同期状態は、次の場合に水平分割レプリケーションを使用すると発生する可能性があります。

  • カラムコンディション値が更新され、新しい値が行選択条件を満たさなくなった。
  • カラムコンディションを満たしていなかった行が、更新されて条件を満たすようになった。

パーティションシフトが発生しないようにカラムコンディションを作成する方法の詳細については、該当の資料を参照してください。

設定変更後に再アクティベートされていない。

テーブルが設定に追加されたが、設定を再アクティベートしなかった場合は、そのテーブルの操作は複製されません。

:Oracle ソーステーブルの場合、自動追加機能はデフォルトで有効であり、設定ファイルで名前がワイルドカードを満たす新しいテーブルは、複製に自動で追加されます。詳細については、次を参照: Oracle DDL 複製の制御

SharePlex がそのオブジェクトキャッシュをアップデートできるように、影響を受けたテーブルを再同期してから、設定を再アクティベートします。テーブルを再同期するには、「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。

キューの破損

システム障害時など、SharePlex キューが破損している場合は、その中のデータが消失することがあります。この場合は、再同期が必要です。

テーブルを再同期するには、「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。

(Oracle)システム障害によるキューの破損を防ぐには、SP_QUE_SYNC パラメータを使用できます。『 SharePlex リファレンスガイド』で Queue パラメータの説明を参照してください。

Oracle 関連の非同期状態と解決方法

次に、特に Oracle データベース間の複製に関連する、一般的な同期の問題を示します。ほとんどの場合で、SharePlex が非同期状態を検出し、エラーメッセージを戻しますが、非同期状態が隠れていて、SharePlex がエラーを戻さない状況もあります。

非同期状態 説明 解決策
DDL 変更

DDL に関連する非同期状態の原因には次のようなものがあります。

  • ソースオブジェクトに対して複製されていない DDL 変更が行われたが、設定が再アクティベートされておらず、オブジェクトを再分析できない。
  • SharePlex が複製する DDL が、ターゲットでも手動で実行されている。

サポートされる DDL のリストについては、『SharePlex リリースノート』を参照してください。

手動および SharePlex による重複した DDL 変更を取り消すには

  1. Post プロセスを停止します(すでに停止されていることがあります)。

    sp_ctrl(sysB)> stop post

  2. DDL 変更を取り消すために、ターゲットテーブルを変更します。
  3. Post を開始して、SharePlex に複製された DDL を post させます(これはまだ post キューにあります)。

    sp_ctrl(sysB)> start post

 

不適切または存在しない競合解決ルーチン

ピアトゥピア(active-active)設定では、競合解決手順が必要です。SharePlex は、同じデータ変更を異なるシステムから受信したときに、どの操作を post するかを判断するために、競合解決手順を使用します。

競合解決手順を修正およびテストしてから、「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。
ログラップ

Capture が必要なデータを処理できる前に REDO ログがラップした場合は、アーカイブログが有効になっていない場合、または Capture が必要とするアーカイブログが削除されている場合に、データが非同期になることがあります(通常、Capture はアーカイブログにアクセスして、複製を継続します)。

問題を先に解決する」を参照してください。

  • アーカイブが有効になっていない場合は、SharePlex が読み取るアーカイブログはありません。ログラップの後で消失したデータは、回復できません。アーカイブログを有効にして、データを再同期してください。「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。
  • SharePlex が多数のログで Oracle より遅れている場合は、ログをリストアする代わりにデータを再同期することを検討してください。Capture がアーカイブログから消失したレコードを処理するためにかかる時間よりも、この方が短いことがあります。さらに、こうすることで、アーカイブログを処理中に capture キューが空きディスク領域を超過する可能性がなくなります。REDO ログのサイズおよび複製するテーブルの数に基づいて判断することができます。両方が Capture が処理する必要がある情報の量を決定します。また、ターゲットデータのユーザーが許容できる遅延も考慮してください。
  • アーカイブログが利用可能な場合は、適切なログをソースシステムのアーカイブログディレクトリにコピーして戻すか、SP_OCT_ARCH_LOC パラメータを使用して、SharePlex にその場所を示します。
LONG 列

テーブルに主キーまたは一意キーがない場合は、SharePlex は「LONG および LOB 列を除いて」すべての列にシミュレーションされたキーを構築します。ターゲット行の LONG 列が一意の値を含む唯一の列である場合、シミュレーションされたキーの条件を複数の行が満たすことがあります。SharePlex は、エラーを検出せずに、違う行に UPDATE または DELETE を適用することがあり、これにより、エラーメッセージを表示せずにテーブルが非同期になります。

ターゲットテーブルの一意性を確保する列からキーを作成できる場合は、この種類の非同期状態を防止できます。キーを作成した後で、これらのオブジェクトを再同期して再アクティベートすると、SharePlex はそのオブジェクトキャッシュをアップデートできます。

主キーまたは一意キーを追加できない場合は(パッケージアプリケーションを使用している場合など)、ターゲットシステム上の行の一意性は保証できません。

キーの変更

テーブルがキーとして自動生成された数値シーケンスを使用しており、キーの値が変更される場合は、結果的にターゲットシステムで重複が生じる可能性があります。新しい値が、ターゲットシステムの他の行にキーとしてすでに存在している場合は、SharePlex が一意キー制約違反および非同期エラーを戻します。これは、x +n 式を使用して値をアップデートしたときに発生することがあります。ここで n は増分です。x +n の値の 1 つが既存の値に等しい可能性があります。

ターゲットシステムで更新によるキーの重複が発生しないように、シーケンスを作成します。詳細については、「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。
ソースシステムやターゲットシステムで実行中の DBMS_SCHEDULER 手順 これらの手順の影響(オブジェクトの作成、複製外での操作や削除など)は、複製で認識されなかったりサポートされなかったりします。そのため、非同期状態の原因となるデータ変更が発生します。 ジョブからソースオブジェクトとターゲットオブジェクトを除外します。
仮想プライベートデータベース 仮想プライベートデータベースとして設定されたデータを複製する場合、SharePlex データベースユーザーにデータをキャプチャするアクセス権限がないことがあります。そのデータの変更は、ターゲットに反映されません。

そのデータがターゲットに複製される必要がない場合は、分割レプリケーションによって SharePlex 設定からフィルタで除外できます。

データを複製する場合は、SharePlex ユーザーに適切なアクセス権限を割り当てます。

PK/UK ロギングが有効でない キーの値をログに記録することで、特定の複製の問題を防止できます。SharePlex は、rowid に基づいてキーの値を取得します。ALTER TABLE...MOVE など、rowid を変更するあらゆる操作が、その後の DML 操作で間違ったキーの値が使用される原因となる可能性があります。 SharePlex は、プライマリキーと一意のキーの両方のサプリメンタルロギングを設定するか、複製内のすべてのテーブルで一意の列にサプリメンタルロググループを定義することをお勧めします。

問題を先に解決する

データが非同期になっている場合は、データを再同期する前に以下の手順を実行します。

  1. 非同期が発生した原因を特定してから、データを再同期してください。そうしない場合は、問題自体が繰り返され、より多くのデータが非同期になります。
  2. Post プロセスを停止して、エラーがこれ以上発生しないようにします。Post キューにメッセージが蓄積されるために、ディスクスペースの問題が発生しそうな場合、およびソースシステムに十分なディスクスペースがある場合は、Post が他のトランザクションによる操作の一部をクリアできるようになるまで、Import を停止できます。この手順については、「ディスクスペース不足の解決方法」を参照してください。
  3. Status Database とイベントログを表示して、問題の原因を特定します。
  4. 問題を解決します。

データの再同期

ソーステーブルとターゲットテーブルの再同期方法」を参照して、データを再同期します。

compare コマンドエラーの解決

複製上の問題の防止および解決方法 > compare コマンドエラーの解決

compare または repair コマンドに関する問題がある場合は、次の説明を参照してください。

発生した問題がこのドキュメントに記載されていない場合は、以下のアドレスの SharePlex サポート技術情報を検索してください。

https://support.quest.com

サポート技術情報には、フィルタリングオプションと、SharePlex の使用およびトラブルシューティングに役立つ他のリソースへのリンクがあります。

問題 説明 解決策
Oracle エラー 904

「Error 904 calling oexec in de_select_prepare_to_fetch.」

比較対象のソーステーブルとターゲットテーブルの構造が異なるため、比較が失敗しました。compare および repair コマンドは、非同期の DDL 操作または構造的に同一でないテーブルによって生じた非同期状態を検出して修復しません。

両方のテーブルに DESCRIBE を実行します。おそらくテーブルで、列の数が同じでないか、データ型が異なることが表示されます。DDL の問題を解決した後で、repair を実行し、行の中の値を再同期できます。

「ユーザー数が多すぎる」エラー

「Can not add DataEquator queue reader que_TOOMANYUSERS:User table is full.」

SharePlex キューに対して読み書きするプロセスの最大数を超過しています。複製プロセスと compare および repair プロセスを含めて、同時に post キューから読み取り、および書き込みできるプロセスは 20 以下です。修復は修復のない比較よりもずっと長い時間キューにアクセスするために、エラーは、修復オプションを使用しているときに、よく起こります。

回避策やこの制限を調整する方法はなく、制限を超過せずに同時に実行できる compare プロセスの数を判断する方法もありません。

ヒント: プロセスの限度に制限されずに同時に複数のテーブルを比較するには、compare using コマンドを使用します。比較するテーブルを制限するには、比較したいものだけがある新しい設定を作成して、それを比較に使用します(その設定はアクティベートしません)。すべてのテーブルが、1 つの compare using プロセスで比較されます。

クライアントプロセスが終了しません

sp_desvr サーバプロセスが終了すると、関連する sp_declt クライアントプロセスユーティリティも終了します。プロセスが終了しない場合は、kill できます。

compare プロセスの kill」を参照してください。
サーバープロセスが終了しません sp_declt クライアントプロセスを kill するとき、またはそれが勝手に終了したとき、または sp_desvr サーバープロセスがクライアントと通信していない場合は、sp_desvr サーバープロセスは、通常 SP_DEQ_TIMEOUT パラメータで制御する一定の時間後に終了します。 compare プロセスの kill」を参照してください。
     

compare プロセスの kill

クライアントプロセスを kill するには

sp_declt クライアントプロセスを kill する必要があり、複数の compare が実行中の場合は、次の方法のいずれかで kill するものを判断できます。

  • sp_declt ログファイルを表示 - このファイルで、sp_declt プロセスの Session ID を探して、終了した sp_desvr プロセスの PID に一致するものを見つけます。これが、kill する sp_declt プロセスです。sp_declt の Session ID は、関連付けられた sp_desvr プロセスの PID と同じです。
  • Event Log を表示 -Event Log は、各 sp_declt クライアントプロセスの起動とその PID を記録します。ログの中のその後のエントリは、プロセスが待機している compare ログファイルを記録します。そのエントリの compare ログファイルの名前の中に、サーバープロセスの PID があります。たとえば、次のサンプルエントリで sp_declt プロセスの PID は 2450 です。このプロセスはログ ../o734v32a_declt- 1228-01.log に書き込みます。1228 は、サーバープロセスの PID です。

    05/04/01 17:01 Process launched: sp_declt (for o.o734v32a-o.o734v32a- 87056 queue all) [pid = 2450]

    05/04/01 17:01 Notice: sp_declt(deq) (for o.o734v32a-o.o734v32a-87056 queue all) Opened DataEquator session log file /u10/julia30014/var7/ log/o734v32a_declt-1228-01.log

    終了したサーバープロセスでログファイル名を検索して、そのログファイルに関連付けられたクライアントプロセスを探すことで、終了する正しい PID を判断できます。

Windows システムでは、ログは、関連付けられた sp_cop プロセスの起動も記録します。

サーバプロセスを kill するには

sp_declt クライアントプロセスが終了したときに、sp_desvr サーバープロセスを kill する必要がある場合は、Event Log を調べて、どのログに sp_declt クライアントプロセスが書き込んでいたかを見つけます。イベントログは、各クライアントプロセスの起動およびその PID を記録します。ログの中のその後のエントリは、プロセスが待機している compare ログファイルを記録します。そのエントリの compare ログファイルの名前の中に、サーバープロセスの PID があります。たとえば、次のサンプルエントリで sp_declt プロセスの PID は 2450 です。このプロセスはログ ../o734v32a_declt-1228-01.log に書き込みます。1228 はサーバープロセスの PID であり、これが kill するプロセスです。

05/04/01 17:01 Process launched: sp_declt (for o.o734v32a-o.o734v32a- 87056 queue all) [pid = 2450]

05/04/01 17:01 Notice: sp_declt(deq) (for o.o734v32a-o.o734v32a-87056 queue all) Opened DataEquator session log file /u10/julia30014/var7/ log/o734v32a_declt-1228-01.log

Windows システムでは、ログは、関連付けられた sp_cop プロセスの起動も記録します。

その他の問題の解決

このセクションでは、他の複製問題の解決方法を説明します。

発生した問題がこのドキュメントに記載されていない場合は、以下のアドレスの SharePlex サポート技術情報を検索してください。

https://support.quest.com

サポート技術情報には、フィルタリングオプションと、SharePlex の使用およびトラブルシューティングに役立つ他のリソースへのリンクがあります。

SharePlex が Windows システムで実行できません

SharePlex は Windows システムで動作するために、Parametric Technology Corporation(PTC)の MKS Toolkit®(NuTCRACKER とも呼ばれます)運用環境を使用します。NuTCRACKER サービスが停止または無効にされている場合、または NuTCRACKER ファイルが削除または移動されている場合は、SharePlex を実行しようとしたときにエラーが発生します。

解決策

  1. Windows タスクマネージャを実行して、[プロセス]タブをクリックします。
  2. NuTCRACKER サービスが実行されているか調べます。プロセス名は、nutsrvx です。ここで x は、NuTCRACKER ソフトウェアのバージョンです。
  3. このプロセスが実行中でない場合、管理ツール コントロールパネルの サービス パネルを使用して、NuTCRACKER サービスを起動します。

    • NuTCRACKER サービスが表示されない場合は、SharePlex を再インストールします。
    • NuTCRACKER サービスを起動できても、まだ SharePlex がエラーを返す場合は、NuTCRACKER ファイルの場所を調べてください。正しいインストール先を特定するには、Windows レジストリの次の項目を探します。

      HKEY_LOCAL_MACHINE\SOFTWARE\Data Focus\Runtime

    • Runtime ノードの右ペインにある InstallDir 文字列に、そのファイルの正しいロケーションが示されます。MKS Toolkit フォルダを検索し、InstallDir エントリで指定されている場所にファイルを復元します。

ファイルが見つからない場合、または正しい場所に復元できない場合は、以下の操作を実行します。

  1. SharePlex および NuTCRACKER サービスが実行中の場合は、それらを停止します。

  2. regedit を実行して、レジストリエディタを開きます。

  3. HKEY_LOCAL_MACHINE\SOFTWARE\ の下にある Data Focus および Mortice Kern Systems レジストリフォルダを削除します。
  4. レジストリエディタを閉じます。
  5. システムを再起動します。
  6. SharePlex を再インストールします。必ず同じロケーションに SharePlex を再インストールして、プロンプトが表示されたときに NuTCRACKER コンポーネントをインストールします。
  7. 新しい NuTCRACKER 環境を有効にするために、システムを再起動します。

「Can’t unlink file」エラーが Windows システム上で発生します

下のもののような厄介なエラーが、時折 Windows システムで発生します。結果として、ファイルはリンク解除します。

Text file busy Unlinking file:'r:\splex2102/rim/o.SERV+C+0.0000000

または

System call error: sp_ordr.exe(osp) (for o.SERV queue o.SERV) Text file busy 17003 - Can't unlink file R:\Splex2100/state/o.SERVlog_ sp_ordr.30

一般的な接続エラー

sp_ctrl の起動、または sp_ctrlhostport、または [on host] コマンドによる接続で発生する一般的なエラーの解決策は次のとおりです。

接続エラーメッセージの説明
エラー 原因 解決策
Host unknown: cannot form connection host コマンドまたは [on host] オプションを発行したときに、表示されます。 接続先のシステムが実行中であること、および正しいシステム名を使用していることを確認してください。
Network unreachable ネットワークがダウンしています。 この状態の継続時間について、ネットワーク管理者に確認します。ダウンタイムのために、SharePlex キューがディスク領域を超過する可能性がある場合は、データを再同期しなくて済むように手段を講じてください「ディスクスペース不足の解決方法」を参照してください。
User is not authorized as a SharePlex user -- check /etc/group 操作を実行するためのユーザー許可がありません。 SharePlex ユーザーは、/etc/group ファイル(Unix および Linux)またはユーザーリスト(Windows)で SharePlex Admin グループ、spoper、spview という SharePlex ユーザーグループの 1 つにリストされる必要があります。
unauthorized connection attempt from host hostname. net リモートマシンの名前が auth_hosts ファイルにリストされていないため、そのマシンからの接続が拒否されました。 システム名については、エラーメッセージを参照してください。そのシステムがローカルシステム上の sp_cop に接続できるようにするために、その名前を auth_hosts ファイルに追加します。

一般的なコマンドエラー

エラー 原因 解決策
Deactivate/flush a nonactive datasource アクティブでない設定をフラッシュしようと試みています。 何も必要ありません。
Bad routing specification ルーティングマップの構文が正しくありません。 設定ファイルでのルーティング指定」を参照してください。
Status db file is corrupt. Status Database が破壊されています。 SharePlex をシャットダウンし、statusdb ファイルを削除します。このファイルは SharePlex 変数データディレクトリの data サブディレクトリにあります。sp_cop を再起動すると、SharePlex が新しいファイルを作成します。
Parameter does not exist in database.

パラメータを設定しようとしましたが、間違った名前を入力したか、パラメータがお使いの SharePlex バージョンで廃止されています。

list param コマンドを使用して、使用中のバージョン用の SharePlex パラメータを表示し、綴りを確認します。

Parameter type checking failed - look in param - defaults file. パラメータに入力したデータ型が誤っている可能性があります。 list param コマンドを使用して、有効なデータ型を特定します。

Unknown service specified.

または

No such module.

または

Service may be only one of: post, read, import, export, capture, all.

有効なサービス(プロセス)の名前は、capture、read、exportimportpost です。 正しい名前でコマンドをもう一度発行します。

Command was called with an invalid argument.

または...

Unknown keyword used in command.

コマンドに無効な入力が含まれています。 help コマンドを発行して、コマンドの有効な入力を表示します。
Permission denied for command - check your authorization level. このコマンドを発行できるユーザーグループのメンバではありません。 authlevel コマンドを発行して権限レベルを表示します。
Default host is not defined: use the ‘host’ command or [on host] option. SharePlex が、コマンドの対象システムを特定できません。 host コマンドでデフォルトホストを確立するか、発行するコマンドに [on host] オプションを使用します(使用可能な場合)。

ソースおよびターゲットオブジェクトの再同期方法

複製上の問題の防止および解決方法 > ソースおよびターゲットオブジェクトの再同期方法

次の手順は、非同期テーブルの再同期方法の決定に役立ちます。

非同期テーブルの手動パッチ

対象:すべてのデータベースタイプ 

同期エラーの数が少ない場合は、手動による非同期テーブルの修復を試行できます。Post プロセスは非同期状態を検出しても、そのエラーを無視して、post キュー内の次の操作の適用を続行します。ただし、Post は非同期エラーを引き起こしたソースの SQL 文を、エラーファイル calleID_errlog.sql にログとして記録します(ID は、ORACLE_SID やデータベース名など、SharePlexターゲットインスタンスに対して使用する識別子です)。データベースのネイティブ SQL インターフェイスを介して、これらの SQL 文をターゲットテーブルに適用できます。この手順では、Post による比較を省略しているので、ターゲットテーブルの構造が変わらなければ操作が成功します。

SharePlexID_errlog.sql をターゲットシステム上の変数データディレクトリの data サブディレクトリに保存します。ファイル内のエントリは、次の例とほぼ同じです。

-- Host (irvlabua) Sid (al920u64)

-- session 2, 1 error --

--

-- [1] Tue Dec 11 13:31:32 2007

-- redolog seq#/offset 26622/26980368

-- redolog timestamp 641050290 (12/11/15 13:31:30)

-- original rowid AAE0m8AAWAAAAFEAAA

-- -- NOT FOUND

delete from “SP_5”.”QA_LOB_DISABLE_INROW” t where rownum = 1 and “KEY”='01';

SQL を手動で適用するには

  1. 影響を受けたソーステーブルへのユーザーアクセスを停止します。
  2. ターゲットシステムで ID_errlog.sql ファイルを開きます。
  3. SQL 文をターゲットテーブルに適用します。
  4. 設定に変更を加える必要があった場合は、その設定を再アクティベートします。

    sp_ctrl> activate config filename

  5. ソーステーブルへのユーザーアクセスを許可します。

ソーステーブルのコピーによる再同期

対象:すべてのデータベースタイプ 

この手順で、ソーステーブルのコピーを適用することで、非同期ターゲットテーブルの同期がリストアされます。非同期のテーブルの再同期だけが必要なので、ユーザーは他のすべてのテーブルへのアクセスを継続できます。

重要! 開始する前にこの手順を確認してください。使用するコマンドの詳細については『 SharePlex リファレンスガイド』を参照してください。

  1. ソースおよびターゲットシステムで、sp_cop が実行中であることを確認します。
  2. ターゲットシステムで、sp_ctrl を実行します。
  3. [必要に応じて]ターゲットシステムで、show sync コマンドを発行して、非同期になっているテーブルを特定します。

    sp_ctrl> show sync

  4. 「ソース」システムで、非同期テーブルの活動を停止します。
  5. ソースシステムで、sp_ctrl を実行します。
  6. ソースシステムで、flush コマンドを発行します。: このコマンドには、名前付きキューまたは複数のターゲットで使用するための追加のオプションがあります。このコマンドの詳細については、『 SharePlex リファレンスガイド』を参照してください。

    sp_ctrl> flush datasource

  7. 「ソース」システムで、テーブルをコピーします。
  8. ソースシステムで、何らかの変更を加える必要があった場合は、設定ファイルを再アクティベートします。

    sp_ctrl> activate config filename

  9. ソース」システムで、ユーザーの「ソース」テーブルへのアクセスを許可します。
  10. ターゲットシステムで、Post が停止したことが示されるまで、status コマンドを発行します。

    sp_ctrl> status

  11. ターゲットシステムで、テーブルをリストアします。

  12. ターゲットシステムで、複製方法の要件に従って、トリガ、参照整合性制約、チェック制約を無効化または変更します。
  13. ターゲットシステムで、Status Database を表示して、各メッセージのステータス ID を特定します。

    sp_ctrl> show statusdb detail

  14. ターゲットシステムで、次のコマンドで各メッセージをクリアします。

    sp_ctrl> clear status statusID

  15. ターゲットシステムで、Post プロセスを再開します。

    sp_ctrl> start post

Oracle トランスポータブル表領域による再同期

対象:Oracle データベース

トランスポータブル表領域機能を使用すると、最小のダウンタイムで多数の非同期テーブルをすばやく再同期できます。トランスポータブル表領域機能を使用するには、Oracle マニュアルの中の指示に従って、表領域セットを作成し、表領域セットをターゲットデータベースに移動し、セットをデータベースにプラグします。次の指示は、データを再同期するためだけにこの機能を使用するステップです。トランスポータブル表領域機能の使用に習熟していることを前提としています。

重要! 開始する前にこの手順を確認してください。使用するコマンドの詳細については『 SharePlex リファレンスガイド』を参照してください。

  1. ソースシステムで、ソース表領域を READ ONLY に設定します。

    SQL> ALTER TABLESPACE name READ ONLY;

  2. ソースシステムで、sp_ctrl を実行します。
  3. ソースシステムの sp_ctrl の中で flush コマンドを発行します。: このコマンドには、名前付きキューまたは複数のターゲットで使用するための追加のオプションがあります。詳細については、『 SharePlex リファレンスガイド』を参照してください。

    sp_ctrl> flush datasource

  4. Oracle のドキュメントに従って、メタデータをエクスポートファイルにエクスポートします。
  5. export が完了したら、データファイルを「ソース」システム上の二次ロケーションにコピーします。こうすることで、ファイルをターゲットシステムにコピーするソースデータベースへの影響を最小にできます。
  6. ソースシステムで、ソース表領域を READ WRITE モードに設定します。

    SQL> ALTER TABLESPACE name READ WRITE;

  7. ターゲット」システムで、ターゲットデータベースから既存のデータファイルおよび表領域をドロップして、コピーされたファイルを適用できるようにします。
  8. ファイルを「ソース」システム上の二次ロケーションから、「ターゲット」システムにコピーします。
  9. 「ターゲット」システムで、Oracle のインポートユーティリティを使用して、メタデータおよび表領域定義をインポートします。
  10. ターゲットシステムで、表領域を READ WRITE モードに設定します。

    SQL> ALTER TABLESPACE name READ WRITE;

    注: SharePlex は、ピアトゥピアレプリケーションを使用しているのでない限り、ターゲットテーブルへの書き込みアクセスを許可された唯一のユーザーである必要があります。

  11. ソースシステムで、設定ファイルに何らかの変更を加える必要があった場合は、その設定ファイルを再アクティベートします。

    sp_ctrl> activate config filename

  12. ターゲットシステムで、sp_ctrl を実行します。
  13. ターゲットシステムで、Post プロセスを再開します。

    sp_ctrl> start post

アクティブデータベースでの Oracle ホットバックアップによる再同期

対象:Oracle データベース

ターゲットインスタンスを再同期するために、Oracle ホットバックアップ、reconcile コマンドを使用するときは、バックアップを実行し適用している間も、ユーザーは実稼動データにアクセスを継続できます。

重要:
  • データウェアハウスなどの「集中レポーティング」を再同期するには、すべてのソースシステムからホットバックアップは使用できません。1 つのバックアップが以前のものからのデータを上書きするためです。ソースインスタンスの 1 つのホットバックアップを使用してターゲットインスタンスを確立してから、export/import やトランスポータブル表領域などの他の方法を使用して、他のインスタンスからテーブルをコピーできます。
  • ピアトゥピア」レプリケーションを再同期するには、この手順の間「すべての」二次ソースシステムを沈静化する必要があります。すべてのユーザーを一時システムに移動してから、手順に従います。「すべての」二次システムで手順を実行した後で、ユーザーはそれらのシステムでの活動を再開できます。
  • 開始する前にこの手順を確認してください。使用するコマンドの詳細については『 SharePlex リファレンスガイド』を参照してください。

ホットバックアップで再同期するには

  1. ソースおよびターゲットシステムで、sp_ctrl を実行します。
  2. ターゲットシステムで、Post プロセスを停止します。こうすることで、ターゲットインスタンスが回復し調和されるまで、複製されたデータが post キューに蓄積します。

    sp_ctrl> stop post

  3. ソースシステムで Oracle ホットバックアップを実行します。
  4. ソースおよびターゲットシステムで、sp_copsp_ctrl、およびすべての SharePlex プロセス(Capture、Read、Export、Import、Post)が実行中であることを確認します。

    sp_ctrl> status

  5. ソースシステムのログファイルを切り替えます。

    • データベースをシーケンス番号に回復するには、最高のアーカイブログのシーケンス番号を記録します。

    • データベースを Oracle System Change Number(SCN)に回復するには、回復する SCN をターゲットデータベースで選びます。
  6. 次のように、ホットバックアップから「ターゲット」データベースを回復します。

    • シーケンス番号に回復する場合は、RECOVER 句の UNTIL CANCEL オプションを使用してホットバックアップからデータベースを回復し、前のステップのログが Oracle で完全に適用された後、回復をキャンセルします。
    • SCN に回復する場合は、RECOVER 句の UNTIL CHANGE SCN オプションを使用してホットバックアップからデータベースを回復し、前のステップから SCN に一致するログが Oracle で適用された後、回復をキャンセルします。
  7. RESETLOGS オプションでデータベースを開きます。

  8. ターゲットシステムで、reconcile コマンドを発行します。named post queues を使用している場合は、各キューに対してコマンドを発行します。キューの名前が分からない場合は、qstatus コマンドを発行してください。

    • シーケンス番号に回復する場合は、ステップ 5 で記録したログのシーケンス番号に置き換えます。

      sp_ctrl> reconcile queue queuename for datasource-datadest seq sequence_number

      例:reconcile queue SysA for o.oraA-o.oraA seq 1234

    • SCN に回復する場合は、ステップ 5 で記録した SCN に置き換えます。

      sp_ctrl> reconcile queue queuename for datasource-datadest scn scn_number

      例:reconcile queue SysA for o.oraA-o.oraA scn 0123456789

    sp_ctrl は reconcile プロセスが完了するまでプロセスによって制御され、完了すると sp_ctrl のプロンプトが戻ります。

  9. ターゲットシステムで、SharePlex の Oracle ユーザーとして SQL*Plus にログオンし、SharePlex 製品ディレクトリの bin サブディレクトリの中にある cleanup.sql スクリプトを実行します。このスクリプトは、SharePlex ユーザーが所有している SharePlex テーブルを切り詰めてアップデートします。複数の変数データディレクトリで複数の sp_cop のインスタンスを実行している場合は、それぞれのために SharePlex Oracle ユーザーが存在します。必ずリストアするテーブルを所有する SharePlex ユーザーとしてこのスクリプトを実行してください。スクリプトから、SharePlex ユーザー名およびパスワードを入力するように促すプロンプトが表示されます。

    SQL> @/productdir/bin/cleanup.sql

  10. ターゲットシステムで、複製方法に従って、次の項目を無効化または変更します。

    • トリガ
    • 外部キー制約
    • カスケード削除の制約(または、これらを無視するように SharePlex を設定)
    • チェック制約
    • DML を実行するスケージュールされたジョブ
  11. ソースシステムで、設定ファイルに何らかの変更を加える必要があった場合は、その設定ファイルを再アクティベートします。

    sp_ctrl> activate config filename

  12. ターゲットシステムで、Post プロセスを再開します。これで 2 つのインスタンスは同期され、SharePlex が複製を継続します。

    sp_ctrl> start post

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating