Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Se você tiver um ou mais procedimentos armazenados que são executados no Publicador e afetam tabelas publicadas, considere incluir esses procedimentos armazenados em sua publicação como artigos de execução de procedimento armazenado. A definição do procedimento (a instrução CREATE PROCEDURE) é replicada para o Assinante quando a assinatura é inicializada; quando o procedimento é executado no Publicador, a replicação executa o procedimento correspondente no Assinante. Isso pode fornecer um desempenho significativamente melhor para casos em que grandes operações em lotes são executadas, pois somente a execução do procedimento é replicada, ignorando a necessidade de replicar as alterações individuais para cada linha. Por exemplo, suponha que você crie o seguinte procedimento armazenado no banco de dados de publicação:
CREATE PROC give_raise AS
UPDATE EMPLOYEES SET salary = salary * 1.10
Este procedimento oferece a cada um dos 10.000 funcionários da sua empresa um aumento salarial de 10%. Quando você executa esse procedimento armazenado no Publicador, ele atualiza o salário de cada funcionário. Sem a replicação da execução de procedimento armazenado, a atualização seria enviada aos Assinantes como uma transação grande e de várias etapas:
BEGIN TRAN
UPDATE EMPLOYEES SET salary = salary * 1.10 WHERE PK = 'emp 1'
UPDATE EMPLOYEES SET salary = salary * 1.10 WHERE PK = 'emp 2'
E isso se repete para 10.000 atualizações.
Com a replicação da execução de procedimento armazenado, a replicação envia apenas o comando para executar o procedimento armazenado no Assinante, em vez de gravar todas as atualizações no banco de dados de distribuição e enviá-las pela rede para o Assinante:
EXEC give_raise
Importante
A replicação de procedimento armazenado não é apropriada para todos os aplicativos. Se um artigo for filtrado horizontalmente, para que haja diferentes conjuntos de linhas no Publicador do que no Assinante, executar o mesmo procedimento armazenado em ambos retornará resultados diferentes. Da mesma forma, se uma atualização for baseada em uma subconsulta de outra tabela não duplicada, executar o mesmo procedimento armazenado no Publicador e no Assinante retornará resultados diferentes.
Para publicar a execução de um procedimento armazenado
SQL Server Management Studio: publicar a execução de um procedimento armazenado em uma publicação transacional (SQL Server Management Studio)
Programação de Transact-SQL de replicação: execute sp_addarticle (Transact-SQL) e especifique um valor de "serializable proc exec" (recomendado) ou "proc exec" para o parâmetro @type. Para obter mais informações sobre como definir artigos, consulte Definir um artigo.
Modificando o procedimento no lado do assinante
Por padrão, a definição de procedimento armazenado no Publicador é propagada para cada Assinante. No entanto, você também pode modificar o procedimento armazenado no Assinante. Isso é útil se você quiser que uma lógica diferente seja executada no Publicador e no Assinante. Por exemplo, considere sp_big_delete, um procedimento armazenado no Publicador que tenha duas funções: ele exclui 1.000.000 linhas da tabela replicada big_table1 e atualiza a tabela não duplicada big_table2. Para reduzir a demanda por recursos de rede, você deve propagar a exclusão de 1 milhão de linhas como um procedimento armazenado publicando sp_big_delete. No Assinante, você pode modificar sp_big_delete para excluir apenas 1 milhão de linhas e não executar a atualização subsequente para big_table2.
Observação
Por padrão, todas as alterações feitas usando ALTER PROCEDURE no Publicador são propagadas para o Assinante. Para evitar isso, desabilite a propagação de alterações de esquema antes de executar ALTER PROCEDURE. Para obter informações sobre alterações de esquema, consulte Fazer Alterações de Esquema em Bancos de Dados de Publicação.
Tipos de artigos de execução de procedimento armazenado
Há duas maneiras diferentes de publicar a execução de um procedimento armazenado: artigo de execução de procedimento serializável e artigo de execução de procedimento.
A opção serializável é recomendada porque replica a execução do procedimento somente se o procedimento for executado dentro do contexto de uma transação serializável. Se o procedimento armazenado for executado de fora de uma transação serializável, as alterações nos dados nas tabelas publicadas serão replicadas como uma série de instruções DML. Esse comportamento contribui para tornar os dados no Assinante consistentes com os dados no Publicador. Isso é especialmente útil para operações em lotes, como operações de limpeza grandes.
Com a opção de execução do procedimento, é possível que a execução possa ser replicada para todos os Assinantes, independentemente de instruções individuais no procedimento armazenado terem sido bem-sucedidas. Além disso, como as alterações feitas nos dados pelo procedimento armazenado podem ocorrer em várias transações, os dados nos Assinantes podem não ser consistentes com os dados no Publicador. Para resolver esses problemas, é necessário que os Assinantes sejam somente leitura e que você use um nível de isolamento maior do que a leitura não-comitada. Se você usar leitura não confirmada, as alterações nos dados em tabelas publicadas serão replicadas como uma série de instruções DML.
O exemplo a seguir ilustra por que é recomendável que você configure a replicação de procedimentos como artigos de procedimento serializáveis.
BEGIN TRANSACTION T1
SELECT @var = max(col1) FROM tableA
UPDATE tableA SET col2 = <value>
WHERE col1 = @var
BEGIN TRANSACTION T2
INSERT tableA VALUES <values>
COMMIT TRANSACTION T2
No exemplo anterior, supõe-se que o SELECT na transação T1 ocorra antes do INSERT na transação T2.
Se o procedimento não for executado em uma transação serializável (com o nível de isolamento definido como SERIALIZABLE), a transação T2 terá permissão para inserir uma nova linha dentro do intervalo da instrução SELECT em T1 e será confirmada antes de T1. Isso também significa que ele será aplicado no Assinante antes de T1. Quando t1 é aplicado no Assinante, o SELECT pode potencialmente retornar um valor diferente do publicador e pode resultar em um resultado diferente do UPDATE.
Se o procedimento for executado em uma transação serializável, a transação T2 não poderá ser inserida dentro do intervalo coberto pela instrução SELECT em T2. Ele estará bloqueado até que T1 confirme a operação, assegurando os mesmos resultados no assinante.
Os bloqueios serão mantidos por mais tempo quando você executar o procedimento em uma transação serializável e poderá resultar em simultaneidade reduzida.
A configuração do XACT_ABORT
Ao replicar a execução do procedimento armazenado, a configuração da sessão que executa o procedimento armazenado deve especificar XACT_ABORT ON. Se XACT_ABORT estiver definido como OFF e ocorrer um erro durante a execução do procedimento no Publicador, o mesmo erro ocorrerá no Assinante, fazendo com que o Agente de Distribuição falhe. Especificar XACT_ABORT ON garante que todos os erros encontrados durante a execução no Publicador causem a reversão de toda a execução, evitando a falha do Agente de Distribuição. Para obter mais informações sobre como definir XACT_ABORT, consulte SET XACT_ABORT (Transact-SQL).
Se você precisar de uma configuração de XACT_ABORT OFF, especifique o parâmetro -SkipErrors para o Distribution Agent. Isso permite que o agente continue aplicando alterações no Assinante mesmo se um erro for encontrado.