以下は、Oracle ALTER TABLE操作のレプリケーションに関するベストプラクティスです。
列を削除したり列を未使用に設定した直後にALTER TABLEを発行する予定がある場合は、VARRAY型の列やABSTRACTデータ型の列を追加しないでください。SharePlexは、このデータ型に関する情報を取得するためにデータベースにクエリを実行する必要があります。SharePlexが最初のDDLを処理できるようになる前に次のDDLが実行された場合、メタデータは既に変更されているため、クエリは失敗します。
データベースオブジェクトのストレージパラメーターなど、一部のメタデータがシステム固有のものである場合、そのメタデータに対するDDLがレプリケートされると、予期しない結果になることがあります。例えば、ALTER TABLEコマンドで変更されたのが一部のパラメーターだけであるにもかかわらず、SharePlexはソース側のOracleオブジェクトのすべてのストレージパラメーターをレプリケートします。ソースオブジェクトとターゲットオブジェクトが同じストレージパラメーターで作成されていない場合、ターゲット側のテーブルがソース側のテーブルのストレージを引き継ぐか、エラーが発生する可能性があります(ターゲットがDDLをサポートしていない場合)。
例: MAXEXTENTSが525、MINEXTENTSが20のソース側のテーブルと、MAXEXTENTSが505、MINEXTENTSが4のターゲット側のテーブルを考えます。ソースオブジェクトのMAXEXTENTSが無制限に変更された場合、SharePlexは、MAXEXTENTSの変更と、変更されていない20のMINEXTENTSの両方をレプリケートします。MINEXTENTSは現在割り当てられている範囲より大きくできないため、この結果、Oracleエラー01570が発生します。また、ソースでMINEXTENTSが1に変更され、MAXEXTENTSが変更されない場合、SharePlexは両方をレプリケートします。その結果、ターゲットパラメーターはMAXEXTENTS 525とMINEXTENTS 1になります。
現在レプリケーション中のソース側のテーブルに対してALTER TABLE RENAMEを発行すると、SharePlexは古い設定行をコメントアウトし、設定ファイルの末尾に新しい行を追加することで、アクティブな設定ファイルのテーブル名を変更します。ソース側とターゲット側のテーブル名が同じ場合は、いずれも新しい名前に変更されます。違う場合はソース側の名前だけが変更されます。以下はその例です。現在レプリケーション中のソーステーブルに対してALTER TABLE RENAMEを発行すると、SharePlexは古い設定行をコメントアウトし、設定ファイルの末尾に新しい行を追加することで、アクティブな設定ファイルのテーブル名を変更します。ソース側とターゲット側のテーブル名が同じ場合は、いずれも新しい名前に変更されます。違う場合はソース側の名前だけが変更されます。
次に示しているのはその一例です。
# Table scott.table1 renamed to scott.table2 August 5, 2003 10:14
scott.table2 scott.table2 sysA@o.ora555
RENAME操作時にPost処理が停止するかどうかは、SP_OPO_STOP_ON_DDL_ERRパラメーターの設定によって異なります。
システムが生成したインターバルパーティション/サブパーティションの名前はデータベースが生成するため、ソース上のこれらのパーティションの名前はターゲット上の対応するパーティションの名前と一致しません。システムが生成したインターバルパーティションをTRUNCATEする目的でALTER TABLEをレプリケートする場合、SharePlexが正しいパーティションを確実にトランケートできるようにするには、SP_OCT_TRUNC_PARTITION_BY_IDパラメーターを1に設定します。この設定により、SharePlexは元のALTER TABLEコマンドで指定されたパーティション名ではなく、パーティションIDを使用してパーティションを識別するようになります。Postは、ターゲット側のテーブルの正しいパーティション名にパーティションIDをマッピングします。詳細については、SP_OCT_TRUNC_PARTITION_BY_ID を参照してください。
システムで指定されたインターバルパーティション/サブパーティションのレプリケーションをサポートするには、ソースとターゲットの両方がSharePlexバージョン8.6.4以降でなければなりません。
サブパーティションが空の場合、SharePlexはシステムで生成されたサブパーティションのTRUNCATEをサポートしません。
テーブルの行IDを変更するALTER TABLE DDLコマンドは、レプリケーション対象のテーブルのプライマリキーまたは一意キーがログに記録されていない場合、後続のDML操作に影響を与える可能性があります。キーがログに記録されていない場合、SharePlexはrowidに基づいてその値を取得します。行IDを変更する操作(ALTER TABLE…MOVEなど)を行うと、その後のDML操作で間違ったキー値が使用される可能性があります。
CaptureとPostのいずれも、処理するDDLをログに記録します。SharePlexは、レプリケートされたDDLもSharePlexのイベントログに出力しますが、切り捨てられることがあります。PostのDDLログだけに完全なDDLステートメントが含まれます。SharePlexは、ソースおよびターゲットシステム上の変数データディレクトリにあるlogサブディレクトリにDDLログを保存します。
デフォルトでは、PostはDDLエラーの発生時に停止します。エラーは通常、ソースシステムでDDLが実行されたデータベースコンポーネントがターゲットデータベースにないことを示します。SP_OPO_STOP_ON_DDL_ERRパラメーターのデフォルト設定では、DDLエラー発生時にPostが停止し、そのオブジェクトに対する後続のDMLが失敗しないようにします。これにより問題を修正し、データベースの同期を保つことができます。このパラメーターの詳細については、『SharePlexリファレンスガイド』を参照してください。
表5: SharePlexDDLログの命名規則
DDLログのタイプ | 命名規則 | 例 |
---|---|---|
Capture | o.ORACLE_SID_ocap_ddl_log_number.log | o.ora12_ocap_ddl_01.log |
Oracleターゲット | o.ORACLE_SID_machine_name_opo_ddl_log_number.log | o.ora12_server2_opo_ddl_01.log |
Open Targetターゲット | r.database_name_machine_name_xpst_ddl_log_number.log | r.mssdb1_server3_xpst_ddl_01.log |
この章では、Post処理によって返されるエラーを処理するためにSharePlexが提供するツールの概要を説明します。
SharePlexには、DMLエラーが発生した後にPostの処理を停止するのではなく、続行する方法があります。
Oracleターゲットで有効
Oracleターゲット対してSharePlexがポストを実行しているときに、Oracleの特定のDMLエラーとSharePlexの特定のエラーメッセージを無視して処理を続行するようにPostを設定することができます。Postが無視するメッセージは、oramsglistファイルのリストに基づいて決まります。このファイルは、デフォルトで小規模なエラーリストと共にインストールされますが、必要に応じていずれかを削除することができます。
エラーを無視すると、PostはそのエラーをSharePlexのイベントログに書き込みます。またPostは、エラーとエラーの原因となったSQLステートメントもエラーログに記録します。このログはSID_errlog.sqlログファイルという名前で、SharePlexの変数データディレクトリ内のdataディレクトリに保存されます。詳細については、イベントとエラーの表示を参照してください。
注: Postが無視できない特定のエラーがあります。oramsglistファイルにこれらのエラーが含まれていても、そのメッセージではPostは停止します。
重要: この機能を使用する際は注意してください。使用した結果、隠れた非同期の状態が発生する可能性があります。このパラメーターは、ターゲットユーザがレプリケーションのタイムラグを許容できず、いくつかの非同期データがあっても構わない場合にのみ有効にしてください。また、SID_errlog.sqlログを頻繁にチェックし、レプリケーションの問題を引き起こす可能性のあるエラーがないかどうかを確認してください。
エラー発生時にPostを続行するように設定するには:
ターゲットシステムで、SharePlexの変数データディレクトリのdataサブディレクトリにディレクトリを変更します。
レプリケーションが有効でない場合は、テキストエディタでファイルを開きます。レプリケーションが有効な場合は、ファイルのコピーを作成し、エディタでそのコピーを開きます。
最初の行に含まれる数字を、追加するエラーの数だけ大きくします。この数字は、ファイル内のエラーの総数と等しくなければなりません。例えば、以下のファイルには10個のエラーが記載されています。
ora@sys1dad > vi oramsglist 10 604 900 902 908 909 910 911 932 960 1026
ファイルの末尾から始めて、OracleまたはSharePlexの各エラーの番号を、前の例に示すように1行に1つずつ追加します。メッセージは番号順にする必要はありません。
Postを停止します(実行中の場合)。
sp_ctrl> stop post
SP_OPO_CONT_ON_ERRパラメーターの値を1に変更します。または、oramsglistファイルに含まれるテーブルのエラーが発生してもポストを続行するように値を2に変更します。SP_OPO_CONT_ON_ERRパラメーターの説明は、『SharePlexリファレンスガイド』を参照してください。
sp_ctrl> set param SP_OPO_CONT_ON_ERR 1
Postを開始します。
sp_ctrl> start post
Open Targetで有効
Open Targetターゲットに対してSharePlexがポストを実行しているときに、ODBCエラーを無視して処理を続行するようにPostを設定することができます。PostはSharePlexのイベントログにエラーを書き込みます。またPostは、エラーとエラーの原因となったSQLステートメントもエラーログに記録します。このログの名前はID_errlog.sqlログファイルです。ここで、IDはデータベース識別子です。このファイルは、SharePlexの変数データディレクトリ内のdataディレクトリに保存されます。詳細については、イベントとエラーの表示を参照してください。
重要: この機能を使用する際は注意してください。使用した結果、隠れた非同期の状態が発生する可能性があります。このパラメーターは、ターゲットユーザがレプリケーションのタイムラグを許容できず、いくつかの非同期データがあっても構わない場合にのみ有効にしてください。また、SID_errlog.sqlログを頻繁にチェックし、レプリケーションの問題を引き起こす可能性のあるエラーがないかどうかを確認してください。
エラー発生時にPostを続行するように設定するには:
ターゲットシステムで、SharePlexの変数データディレクトリのdataサブディレクトリにディレクトリを変更します。
データベースに応じて、以下のファイルのいずれかを検索します。これらのファイルは空の状態でインストールされます。
ファイル名 | サポート対象データベース |
---|---|
postgresmsglist |
Postgres |
sqlservermsglist | Microsoft SQL Server |
mysqlmsglist | Oracle MySQL |
注: メッセージファイルに記載してもPostが停止するエラーがあります。
レプリケーションが有効でない場合は、テキストエディタでファイルを開きます。レプリケーションが有効な場合は、ファイルのコピーを作成し、エディタでそのコピーを開きます。
ファイルの末尾から始めて、各エラーの番号を、例に示すように1行に1つずつ追加します。メッセージは番号順にする必要はありません。
例:
sqlservermsglist:
8102
8180
544
2627
3621
Postを停止します(実行中の場合)。
sp_ctrl> stop post
SP_OPX_CONT_ON_ERRパラメーターの値を1に変更します。
sp_ctrl> set param SP_OPX_CONT_ON_ERR 1
Postを開始します。
sp_ctrl> start post
© ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center