Considerações sobre replicação transacional
Existe um número de considerações para replicação transacional:
Espaço de log de transação
Espaço em disco para o banco de dados de distribuição.
Chaves primárias para cada tabela publicada.
Gatilhos
Tipos de dados de objeto grande (LOB).
Assinaturas atualizáveis (se forem usadas). Para obter mais informações sobre considerações sobre assinaturas atualizáveis, consulte Assinaturas atualizáveis para replicação de transação.
Espaço de log de transação
Para cada banco de dados que será publicado usando a replicação transacional, certifique-se de que o log de transação tenha bastante espaço alocado. O log de transações de um banco de dados publicado pode exigir mais espaço do que o log de um banco de dados idêntico não publicado, porque os registros de log não ficam truncados até terem sido movidos para o banco de dados de distribuição.
Se o banco de dados de distribuição não estiver disponível ou se o Log Reader Agent não estiver sendo executado, o log de transação de um banco de dados de uma publicação continuará a crescer. O log não pode ser truncado após ter decorrido a transação publicada mais antiga que não foi distribuída no banco de dados de distribuição. Recomendamos que você configure o arquivo de log de transação para o crescimento automático de modo que o log possa acomodar estas circunstâncias. Para obter mais informações, consulte CREATE DATABASE (Transact-SQL) e ALTER DATABASE (Transact-SQL).
Recomendamos que você configure a opção sync with backup no banco de dados de distribuição, que retarda o truncamento no banco de dados de publicação até que as transações correspondentes no banco de dados de distribuição tenham o backup efetuado. Isto pode resultar em um log de transação maior no banco de dados de publicação. Para obter mais informações sobre essa opção, consulte Estratégias para fazer backup e restaurar o instantâneo e a replicação transacional.
Espaço em disco para o banco de dados de distribuição.
Certifique-se de que você possui bastante espaço em disco para armazenar transações replicadas no banco de dados de distribuição:
Se você não deixar arquivos de instantâneo imediatamente disponíveis para os Assinantes (que é o padrão): as transações serão armazenadas até serem replicadas a todos os Assinantes ou até que o período de retenção seja atingido, ou o que ocorrer em menor tempo.
Se criar uma publicação transacional e deixar arquivos de instantâneo disponíveis imediatamente para os Assinantes: as transações serão armazenadas até serem replicadas a todos os Assinantes ou até que o Snapshot Agent execute e crie um instantâneo, ou o que ocorrer em maior tempo. Se o tempo decorrido entre as execuções do Snapshot Agent for maior do que o período máximo de retenção de distribuição da publicação, cujo um padrão é de 72 horas, as transações mais antigas do que o período de retenção serão removidas do banco de dados de distribuição. Para obter mais informações, consulte Validade e desativação de assinatura.
Manter o instantâneo disponível imediatamente para os Assinantes melhora a velocidade com a qual os novos Assinantes têm acesso à publicação, mas a opção pode resultar no aumento de armazenamento em disco para o banco de dados de distribuição. Isto também significa que um instantâneo novo é gerado sempre que o Snapshot Agent for executado. Se a opção não for usada, um novo instantâneo só será gerado se for uma assinatura nova.
Chaves primárias para cada tabela publicada
Todas as tabelas publicadas em replicação transacional devem conter uma chave primária declarada. As tabelas existentes podem ser preparadas para publicação ao adicionar uma chave primária que usa a Transact-SQL instrução ALTER TABLE (Transact-SQL).
Gatilhos
Esteja ciente sobre os seguintes assuntos ao usar gatilhos em um banco de dados de assinatura:
Por padrão, os gatilhos executam com a configuração XACT_ABORT ON. Se uma instrução dentro de um gatilho causar um erro enquanto o Distribution Agent estiver aplicando as alterações no Assinante, todo o lote de alterações falhará, o que não ocorre com a instrução individual. Em replicação transacional, você pode usar o parâmetro - SkipErrors do Distribution Agent para omitir instruções que causam erros. Se -SkipErrors for usado com o XACT_ABORT ON, todo o lote de alterações será omitido se uma instrução causar um erro. A menos que você exija que o XACT_ABORT seja definido como ON nos gatilhos, recomendamos que você configure como OFF se estiver usando o parâmetro -SkipErrors. Para configurar a opção, especifique SET XACT_ABORT OFF na definição do gatilho. Para obter mais informações sobre o XACT_ABORT, consulte SET XACT_ABORT (Transact-SQL). Para obter mais informações sobre o parâmetro-SkipErrors, consulte Ignorando erros na replicação transacional.
Recomendamos não incluir transações explícitas em gatilhos no Assinante. A replicação transacional utiliza formação de lotes de transação para reduzir a ida e volta na rede, aumentando assim o desempenho. Se os gatilhos com instruções ROLLBACK forem adicionados ao Assinante, os lotes de transações poderão ser cancelados e o erro 266 no servidor poderá ser gerado (A contagem de transações após o EXECUTE indica que uma instrução COMMIT ou ROLLBACK TRANSACTION está faltando. Contagem anterior =% ld, contagem atual =% ld.). Um lote pode conter comandos de diversas transações ou fazer parte de uma grande transação no Publicador, então reverter as transações pode comprometer a integridade transacional.
Se você incluir transações explícitas, verifique se todas as instruções COMMIT em um gatilho terão as instruções BEGIN TRANSACTION correspondentes. Um COMMIT sem um BEGIN TRANSACTION correspondente faz o aplicativo não-transacional de alterações de linha mudar para o Assinante. Além disso, uma falha posterior poderá ocorrer se o Distribution Agent encontrar o erro 266 no servidor e tentar reverter uma transação ou fazer lote dos comandos de modo que possa aplicá-los novamente. Quando o agente tentar aplicar comandos que já foram aplicados, isto resultará em falhas de chave duplicadas.
Para obter mais informações sobre gatilhos, consulte Controlando restrições, identidades e gatilhos com NOT FOR REPLICATION.
Tipos de dados de objeto grande (LOB).
As replicações transacionais dão suporte à publicação de LOBs e efetuam atualizações parciais nas colunas LOB: se uma coluna LOB for atualizada, somente o fragmento dos dados alterados será replicado, e não todos os dados da coluna.
Se uma tabela publicada incluir qualquer LOBs, considere o uso dos seguintes parâmetros do Distribution Agent: - UseOledbStreaming, - OledbStreamThreshold e - PacketSize. A maneira mais objetiva de configurar estes parâmetros é usar o perfil do Distribution Agent com o nome Perfil de distribuição para fluxo contínuo OLEDB. Para obter mais informações, consulte Perfis do Replication Agent. Além deste perfil predefinido, você pode especificar o parâmetro em um perfil de agente ou na linha de comando criada ou modificada. Para obter mais informações, consulte:
Como trabalhar com perfis do Replication Agent (SQL Server Management Studio)
Como trabalhar com perfis do Replication Agent (Programação Transact-SQL de replicação)
Tipos de dados texto, ntext e imagem
O processo de replicação text, ntext e os tipos de dados image de uma publicação transacional está sujeito a um número de considerações. Recomendamos o uso dos tipos de dados varchar(max), nvarchar(max), varbinary(max) em vez de text, ntext e os tipos da dados image, respectivamente.
Ao usar text, ntext ou image, lembre-se de que:
As instruções WRITETEXT e UPDATETEXT deveriam ser embrulhadas em transações explícitas.
Operações de texto registradas podem ser reproduzidas usando WRITETEXT e UPDATETEXT com a opção de WITH LOG em tabelas publicadas. A opção de WITH LOG é requerida porque a replicação transacional rastreia as alterações no log de transação.
As operações de UPDATETEXT poderão ser usadas somente se todos os Assinantes estiverem executando o SQL Server. As operações WRITETEXT são reproduzidas como instruções UPDATE, assim elas também podem ser usadas com Assinantes não -SQL Server.
Um parâmetro configurável, max text repl size, controla o tamanho máximo (em bytes) do text, ntext, varchar(max), nvarchar(max), e os dados image que podem ser replicados. Isto permite dar suporte a: drivers ODBC e provedores OLE DB; as instâncias de Mecanismo de banco de dados do SQL Server que não conseguem controlar grandes valores para estes tipos de dados; e Distribuidores com restrições de recursos de sistema (memória virtual). Quando uma coluna com um destes tipos de dados for publicada e uma operação INSERT, UPDATE, WRITETEXT ou UPDATETEXT for executada e exceder o limite configurado, a operação falhará.
Use o procedimento armazenado de sistema sp_configure (Transact-SQL) para definir o parâmetro max text repl size.
Ao publicar as colunas text, ntext, e image, o ponteiro de texto deve ser recuperado dentro da mesma transação da operação UPDATETEXT ou WRITETEXT (e com repetição de leitura). Por exemplo, não recupere o ponteiro de texto em uma transação e em seguida use-o em outro. Ele pode ter sido movido e se tornado inválido.
Além disso, quando o ponteiro de texto for obtido, você não deverá efetuar qualquer operação que possa alterar os locais de texto apontados pelo ponteiro de texto (como atualização de chave primária), antes de executar a instrução UPDATETEXT ou WRITETEXT.
Este é o modo recomendado para usar as operações UPDATETEXT e WRITETEXT com dados a serem replicados:
Iniciar a transação.
Obter o ponteiro de texto usando a função TEXTPTR () com nível de isolamento REPEATABLE READ.
Usar o ponteiro de texto na operação UPDATETEXT ou WRITETEXT.
Confirmar a transação
.gif "Observação")
ObservaçãoSe você não obtiver o ponteiro de texto na mesma transação, as modificações serão permitidas no Publicador, mas a s alterações não serão publicadas para os Assinantes.
Por exemplo:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN DECLARE @mytextptr varbinary(16) SELECT @mytextptr = textptr(Notes) FROM Employees WHERE EmployeeID = '7' IF @mytextptr IS NOT NULL BEGIN UPDATETEXT Employees.Notes @mytextptr 0 NULL 'Terrific job this review period.' -- Dummy update to fire trigger that will update metadata and ensure the update gets propagated to other Subscribers. UPDATE Employees -- Set value equal to itself. SET Notes = Notes WHERE EmployeeID = '7' END COMMIT TRAN SET TRANSACTION ISOLATION LEVEL READ COMMITTED
| Observação |
|---|
Este exemplo é baseado no banco de dados Northwind que não está instalado por padrão. Para obter informações sobre como instalar este banco de dados, consulte Bancos de dados de exemplo Northwind e pubs no Centro de DownloadMicrosoft. |
Um item a considerar ao dimensionar os bancos de dados do Assinante é que o ponteiro de texto do text replicado, ntext, e as colunas image devem ser inicializados nas tabelas do Assinante, mesmo quando não forem inicializadas no Publicador. Conseqüentemente, cada text, ntext, e a coluna image adicionada à tabela do Assinante pela tarefa de distribuição consomem no mínimo 43 bytes de armazenamento de banco de dados mesmo que o conteúdo esteja vazio.