トランザクション アーティクル - 再生成によるスキーマ変更の反映
適用対象:SQL ServerAzure SQL Managed Instance
既定では、トランザクション レプリケーションがサブスクライバー上のデータを変更する際、パブリケーション内の各テーブル アーティクルに対して内部プロシージャが生成したストアド プロシージャが必ず使われます。 3 つのプロシージャ (挿入、更新、削除用に 1 つずつ) はサブスクライバーにコピーされ、挿入、更新、削除がサブスクライバーにレプリケートされた時点で実行されます。 SQL Server パブリッシャー上のテーブルでスキーマが変更されると、レプリケーションがスクリプト作成内部プロシージャの同じセットを呼び出すことで、これらのプロシージャが自動的に再生成され、新しいプロシージャと新しいスキーマが一致します (スキーマ変更のレプリケーションは、Oracle パブリッシャーではサポートされていません)。
カスタム プロシージャを指定して、1 つ以上の既定のプロシージャを置き換えることもできます。 スキーマ変更によってカスタム プロシージャが影響を受ける場合は、そのプロシージャを変更する必要があります。 たとえば、スキーマ変更によって削除される列をプロシージャが参照している場合には、その列への参照をプロシージャから削除する必要があります。 レプリケーションで新しいカスタム プロシージャをサブスクライバーに反映するには、2 つの方法があります。
1 つ目のオプションは、カスタム スクリプト作成プロシージャを使用して、レプリケーションで使用する既定のプロシージャを置き換える方法です。
sp_addarticle (Transact-SQL) を実行するときは、0x02 ビットが true であることを確認
@schema_option
します。sp_register_custom_scripting (Transact-SQL) を実行し、パラメーターに 'insert'、'update'、または 'delete' の値を指定し、 パラメーター
@type
のカスタム スクリプト プロシージャの名前を指定します@value
。
次回にスキーマが変更されると、レプリケーションによってこのストアド プロシージャが呼び出され、新しくユーザーが定義したカスタム ストアド プロシージャの定義がスクリプト化されて、プロシージャが各サブスクライバーに反映されます。
2 つ目のオプションは、新しいカスタム プロシージャの定義を含むスクリプトを使用する方法です。
sp_addarticle (Transact-SQL) を実行する場合は、レプリケーションによってサブスクライバーでカスタム プロシージャが自動的に生成されないように、0x02 ビットを false に設定
@schema_option
します。スキーマを変更する前に、新しいスクリプト ファイルを作成し、 sp_register_custom_scripting (Transact-SQL) を実行してスクリプトをレプリケーションに登録します。
@type
パラメーターの値として "custom_script" を指定し、@value
パラメーターにパブリッシャー上のスクリプトのパスを指定します。
次回に関連スキーマが変更されると、各サブスクライバーでは、DDL コマンドと同じトランザクション内でこのスクリプトが実行されます。 スキーマ変更が完了すると、スクリプトの登録が解除されます。 以降のスキーマ変更でこのスクリプトを実行するには、スクリプトを再登録する必要があります。
参照
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示