Júlio Battisti Livros e Cursosa sua sala de aula na internet

Neste tipo de replicação somente as alterações efetuadas no Publisher é que são replicadas para um ou mais Subscribers. Qualquer alteração feita, em um ou mais artigos de uma publicação, é imediatamente capturada a partir do Log de transações e replicada para o Distributor. Dependendo das configurações e da velocidade de conexão entre os servidores, podemos manter as diversas réplicas sincronizadas quase que instantaneamente.

A principal vantagem é que podemos manter as diversas réplicas praticamente idênticas, diminuindo bastante a latência (questão de segundos) de atualização entre as diversas réplicas. A grande desvantagem é que este monitoramento contínuo em busca das alterações, implica em uma maior exigência de memória e processamento no servidor SQL Server.

Um detalhe importante a ser observado é a autonomia das réplicas. Para manter-se atualizada, a réplica precisa estar em contato com os demais servidores que participam da replicação, mais especificamente, com o Subscriber e o Distributor. Este fator pode ser um problema para o caso de servidores em localidades remotas, ligados à rede da empresa por links de WAN de baixa velocidade (links de 128 KB ainda são bastante comuns em cidades do interior).

Apenas transações concluídas (committed transactions) serão replicadas para os Subscribers, e serão aplicadas nas réplicas, na mesma ordem em que foram aplicadas no Banco de Dados original.

Este é o tipo de replicação que mantém os dados o mais atualizados possíveis, com o menor nível de latência em relação aos demais tipos de replicação do SQL Server 2005.

Tanto a Snapshot replication quanto Transactional replication somente permitem que alterações sejam feitas no Publisher, isto é, os dados não podem ser alterados no Subscriber. Existe, porém, um mecanismo que combina dois itens: a opção “Immediate Update Subscribers Option” e “Two-phase commit protocol”. Com estas duas opções, os dados podem ser alterados nos Subscribers e as alterações serão aplicadas no Publisher ao mesmo tempo, através da utilização do protocolo Two-phase commit protocol.

A seguir descrevo as situações, onde é indicado o uso da replicação do tipo Transactional Replication:

• Para fazer com que as alterações sejam repassadas para os Subscribers, com a menor latência possível.
• Os dados replicados serão utilizados por aplicações que precisam de um tempo de latência muito baixo, o menor possível.
• Em situações onde existe um grande número de operações de inserção, atualização e exclusão no Publisher.
• Quando o Publisher ou o Subscriber não for um banco de dados do SQL Server, tal como o ORACLE ou o DB2 da IBM.