Partilhar via

Artigos transacionais - Regenerar procedimentos personalizados para refletir alterações de esquema

Aplica-se a:SQL ServerAzure SQL Managed Instance

Por padrão, a replicação transacional realiza todas as alterações de dados nos subscritores através de rotinas armazenadas, geradas por procedimentos internos, para cada artigo de tabela na publicação. Os três procedimentos (um para inserções, atualizações e exclusões) são copiados para o Assinante e executados quando uma inserção, atualização ou exclusão é replicada para o Assinante.

Quando uma alteração de esquema é feita em uma tabela em um Editor do SQL Server, a replicação regenera esses procedimentos automaticamente chamando o mesmo conjunto de procedimentos de script internos para que os novos procedimentos correspondam ao novo esquema (a replicação de alterações de esquema não é suportada para Editores Oracle).

Você também pode especificar procedimentos personalizados para substituir um ou mais dos procedimentos padrão. Os procedimentos personalizados devem ser alterados se a alteração de esquema afetar o procedimento. Por exemplo, se um procedimento fizer referência a uma coluna que é descartada em uma alteração de esquema, as referências à coluna devem ser removidas do procedimento.

Há duas maneiras de a replicação propagar um novo procedimento personalizado para Assinantes:

  • Usar um procedimento de script personalizado para substituir as predefinições usadas pela replicação
  • Usar um script que contenha uma nova definição de procedimento personalizado

Usar um procedimento de script personalizado para substituir as predefinições usadas pela replicação

Ao executar sp_addarticle, verifique se o bit @schema_option0x02 é .true

Observação

A definição de procedimento armazenado personalizado deve ser roteirizada usando Transact-SQL dinâmico, dentro de um procedimento armazenado de wrapper. Esse procedimento armazenado do wrapper também deve incluir um parâmetro @artid do tipo int, para garantir que ele seja criado no Assinante.

Execute sp_register_custom_scripting e especifique um valor de insert, updateou delete para o parâmetro @type e o nome do procedimento de script personalizado para o parâmetro @value .

Na próxima vez que uma alteração de esquema for feita, a replicação chamará esse procedimento armazenado para criar um script para a definição do novo procedimento armazenado personalizado definido pelo usuário e, em seguida, propagará o procedimento para cada Assinante.

Exemplo

Neste exemplo, suponha que o Publicador e o Assinante já estão configurados e você deseja criar um procedimento armazenado personalizado delete .

  1. No Assinante, crie uma tabela para mostrar o script de exclusão personalizado.

    USE [SubscriberDB];
GO

CREATE TABLE DeleteLogging (id INT PRIMARY KEY);
GO

  2. Adicione o artigo do Editor. Observe os valores dos parâmetros @schema_option, @ins_cmd, @upd_cmd, e @del_cmd.

    USE [PublisherDB];

EXECUTE sp_addarticle
    @publication = N'PubName1',
    @article = N'Purchases',
    @source_owner = N'dbo',
    @source_object = N'Purchases',
    @type = N'logbased',
    @description = NULL,
    @creation_script = NULL,
    @pre_creation_cmd = N'drop',
    @schema_option = 0x000000000803509F,
    @identityrangemanagementoption = N'manual',
    @destination_table = N'Purchases',
    @destination_owner = N'dbo',
    @vertical_partition = N'false',
    @ins_cmd = N'CALL sp_MSins_dboPurchases',  -- default
    @del_cmd = N'CALL custom_delete',          -- custom
    @upd_cmd = N'SCALL sp_MSupd_dboPurchases'; -- default
GO

  3. Crie um procedimento armazenado que gere o script do custom_delete procedimento armazenado que pretende usar no Subscritor. Este é o procedimento armazenado do invólucro, conforme indicado anteriormente.

    O retorno de valores diferentes de zero deste procedimento armazenado faz com que custom_delete não seja criado no Assinante. O SELECT deve retornar a definição completa CREATE do procedimento armazenado que será usado pelo subscritor.

    Observe o uso do parâmetro necessário @artid .

    USE [PublisherDB];
GO

CREATE OR ALTER PROCEDURE script_custom_delete (@artid INT)
AS
BEGIN
    SELECT 'CREATE OR ALTER PROCEDURE custom_delete
              @pkc1 INT
          AS
          BEGIN
              INSERT INTO DeleteLogging (id) VALUES (@pkc1)
          END';
    RETURN 0;
END
GO

  4. Registre o script personalizado no Publisher.

    USE [PublisherDB];
GO

EXECUTE sp_register_custom_scripting
    @type = 'delete',
    @value = 'script_custom_delete',
    @publication = 'PubName1',
    @article = 'Purchases';
GO

  5. Adicione uma subscrição. Neste exemplo, o @sync_type parâmetro é definido como replication support only, portanto, nenhum instantâneo é usado.

    USE [PublisherDB];
GO

EXECUTE sp_addsubscription
    @publication = N'PubName1',
    @subscriber = @@SERVERNAME,
    @destination_db = N'SubscriberDB',
    @subscription_type = N'Push',
    @sync_type = N'replication support only',
    @article = N'all',
    @update_mode = N'read only',
    @subscriber_type = 0;
GO

Usar um script que contenha uma nova definição de procedimento personalizado

Ao executar sp_addarticle, defina o parâmetro @schema_option0x02 como false para que a replicação não gere automaticamente procedimentos personalizados no Assinante.

Antes de cada alteração de esquema, crie um novo arquivo de script e registre o script com replicação executando sp_register_custom_scripting. Especifique um valor de custom_script para o parâmetro @type e o caminho para o script no Publisher para o parâmetro @value .

Na próxima vez que uma alteração de esquema relevante for feita, esse script será executado em cada Assinante dentro da mesma transação que o comando DDL. Depois de realizada a alteração do esquema, o script é desregistado. Você deve registrar novamente o script para que ele seja executado após uma alteração de esquema subsequente.

Conteúdo relacionado

  • Last updated on