Introdução
A Replicação do SQL Server é um recurso do SQL Server que nos permite transferir dados de uma instância para outra para fins de consolidação de dados em um ambiente de relatórios ou migrações. Eu pessoalmente não consideraria a Replicação do SQL Server como uma tecnologia de alta disponibilidade, embora algumas pessoas a considerem.
A replicação do SQL Server usa termos semelhantes aos do setor editorial para descrever a maneira como os dados são tratados da origem ao destino. Os termos-chave são os seguintes:
- Publisher – uma instância do SQL Server que disponibiliza dados para serem replicados para outras instâncias (empacotados como publicações).
- Publicação – uma unidade pronta para ser passada para a instância receptora composta por uma coleção de artigos que na verdade são objetos de banco de dados.
- Distribuidor – uma instância do SQL Server responsável por armazenar dados associados a um ou mais editores em um banco de dados chamado banco de dados de distribuição . Um distribuidor local é armazenado na mesma instância que o Publicador enquanto um Distribuidor Remoto está localizado em outra instância.
- Assinante – uma instância que recebe um banco de dados replicado. Uma assinatura de assinante é uma solicitação de uma cópia de publicação que ele espera receber do editor.
- Instantâneo.
No artigo, compartilharei alguns pontos que aprendi ao configurar a replicação do SQL Server para dar suporte a um assinante heterogêneo. Criarei uma publicação e posteriormente uma assinatura Oracle que dependerá desta publicação. Também demonstrarei alguns pontos junto com o fluxo do processo que são muito importantes para solucionar problemas.
As etapas para configurar uma sessão de replicação de instantâneo são as seguintes:
- Configurar um distribuidor
- Configure um editor (junto com a publicação, incluindo os artigos que estão sendo publicados)
- Configurar um assinante
Farei uma breve explicação de cada etapa.
Configurando um Distribuidor
Um Distribuidor é uma instância responsável por armazenar as informações utilizadas durante a replicação. Ao tentar criar uma publicação na instância pela primeira vez, o SQL Server sugerirá que você configure um Distribuidor. Neste artigo, nosso Distribuidor é um Distribuidor Local .
Criando uma publicação
Vamos identificar o banco de dados que contém os objetos que gostaríamos de replicar. Este será um Banco de Dados de Publicação .
Para criar um banco de dados de publicação, siga as instruções nas capturas de tela abaixo.
Esta etapa permite selecionar um tipo de publicação que você deseja configurar. Cada tipo de publicação é descrito no painel inferior. Por motivos de simplicidade e compatibilidade, escolhemos uma publicação de instantâneo. Observe que pretendemos replicar objetos para uma instância Oracle. Nesse caso, Transacional e Publicações de instantâneo são suportados. Existem outros bons casos de uso para uma replicação ponto a ponto e de mesclagem.
Nesta etapa, escolhemos os artigos que queremos publicar. O SQL Server nos permite publicar quatro tipos de objetos-chave, como:
- Tabelas
- Procedimentos armazenados
- Visualizações
- Funções definidas pelo usuário
Como você pode ver, vamos publicar duas tabelas:Orders e OrderLines. Com o objetivo de demonstrar a flexibilidade da replicação do SQL Server, filtraremos os registros conforme mostrado abaixo.
Observação: Estamos interessados em que o número de OrderIDs seja maior que 1.000.
Para excluir linhas indesejadas de tabelas publicadas, clique em Adicionar… e entãoPróximo .
As capturas de tela abaixo mostram como filtrar colunas para a tabela OrderLines.
Em seguida, configure as propriedades do Snapshot Agent. Definimos um instantâneo inicial e o intervalo durante o qual um novo instantâneo é gerado. Os dados extraídos nesta etapa são armazenados em um diretório especificado ao configurar inicialmente o distribuidor.
Primeiro, configure um agendamento para o início de um agente de instantâneo. Clique em Avançar .
Para cada agente de instantâneo, especifique a conta na qual ele será executado.
Em seguida, defina as configurações de segurança do Snapshot Agent. A tabela Configurações de segurança abre outra janela onde definimos quem executa o processo do Snapshot Agent, bem como determinamos os detalhes de logon do SQL Server a serem conectados ao editor. Existem certas permissões exigidas por esses diretores que podem ser um pouco desonestas na produção. Usar a conta do SQL Server Agent Service é uma solução alternativa para evitar complicações, mas na verdade NÃO é recomendado pela Microsoft.
Perto do final, você precisará decidir se deseja salvar a configuração como um script para uso posterior ou criar a publicação imediatamente.
O próximo passo (Fig. 16) resume todas as opções que você selecionou. É recomendável fazer uma revisão rápida antes de clicar no botão Concluir botão.
O processo de Criação de Publicação é iniciado. Você pode clicar em Parar para interromper o processo.
Quando o processo for concluído, sua publicação ficará visível no painel Pesquisador de Objetos no SQL Server Management Studio.
Adicionando um assinante
Um assinante recebe publicações disponibilizadas pelo Editor . A cópia da publicação a ser entregue a um assinante é chamada de Assinatura . Um editor pode ter muitos assinantes. Cada
assinante recebe os artigos publicados por esta Editora como uma unidade denominada publicação para a Editora e considerada a assinatura do Assinante.
Ao criar uma assinatura, simplesmente informamos ao Editor:“Quero ter cópias desta publicação”. Por mais que um Editor possa ter muitas publicações, também pode haver muitos assinantes de uma
publicação. Assim, o relacionamento de Publicadores com Assinantes é um relacionamento de um para muitos.
O Assistente de Nova Assinatura nos permite decidir qual publicação gostaríamos de assinar. Podemos escolher em uma lista das publicações criadas anteriormente, conforme mostrado na Fig. 20.
Em seguida, decidimos se queremos executar uma assinatura push em vez de uma assinatura pull. Embora uma assinatura pull seja melhor para desempenho quando você prevê vários assinantes, ela não
funciona para uma replicação de banco de dados heterogênea. Assinantes que não são do SQL Server devem usar uma assinatura pull. Vale ressaltar que os artigos publicados neste cenário também se limitam a tabelas e visualizações indexadas.
Adicione um assinante Oracle usando um nome de fonte de dados (DSN). Este DSN já deve ter sido criado, testado e comprovado que está funcionando em termos de poder se conectar à instância Oracle via Oracle Net. Isso significa que você precisa de um cliente Oracle instalado no host do SQL Server com uma entrada para um arquivo chamado tnsnames.ora definindo o destino da conexão. Essa entrada TNS, por sua vez, é usada para configurar o nome da fonte de dados que o New Subscription Wizard está solicitando neste estágio.
A entrada que criei no meu arquivo tnsnames.ora se parece com isso:
ORCL10G = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = IGIRI-LP)(PORT = 1522)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl10g) ) )
A parte destacada é o alias enquanto os outros detalhes definem o destino da conexão. Podemos confirmar se esta entrada está funcionando corretamente e se minhas variáveis de ambiente Oracle estão configuradas corretamente usando o tnsping utilitário como mostrado abaixo.
Uma vez confirmada, esta entrada TNS é usada para configurar o DSN que pretendemos usar. Nosso nome de serviço TNS é chamado ORCL10G enquanto o DSN é chamado ORCLDC . É o DSN que usamos no Assistente de Nova Assinatura.
Observe que usamos a versão de 64 bits do ODBC para configurar o DSN e é um DSN do sistema, não um DSN do usuário. A configuração não depende de quem está conectado ao computador.
Selecione um tipo de assinante a ser adicionado e insira o nome da fonte de dados. Clique em OK .
Escolha um ou vários assinantes, bem como especifique um banco de dados para cada assinatura.
Uma vez que o DSN é adicionado, podemos prosseguir com a configuração da segurança do agente de distribuição. Descobrimos que isso é semelhante ao caso quando configuramos um Snapshot Agent Security no Assistente de Nova Publicação.
Aqui, no entanto, temos uma seção onde estabelecemos uma conexão com o Assinante em vez do Editor (lembre-se que esta é uma assinatura push). Essa conta de usuário deve ter sido criada na instância Oracle e deve ter privilégios para criar tabelas e cota em seu tablespace padrão (aqui você pode precisar de um DBA Oracle).
Adicione parâmetros à segurança do agente de distribuição e clique em OK .
Especifique as opções de conta e conexão para cada agente de distribuição e clique em Avançar .
Defina o agendamento de sincronização para cada agente. No nosso caso, optamos por sincronizar continuamente. Clique em Avançar .
Selecione a opção para inicializar a assinatura imediatamente, o que significa copiar TODOS os dados disponíveis na pasta Snapshot novamente. É aconselhável que os assinantes do NoSQL Server reinicializem a assinatura quando novos artigos forem adicionados à publicação. Clique em Avançar .
Selecione as opções a serem executadas após o processo ser concluído com sucesso. Clique em Avançar .
Verifique as informações que você adicionou e clique em Concluir .
O processo de criação de assinatura é executado.
A assinatura que acabamos de criar mostra uma entrada no Pesquisador de Objetos (no Publicador) mapeada para sua publicação pai. Observe que ele não aparece no nó Assinaturas Locais que fornece uma lista de assinaturas criadas na instância atual que não está neste caso.
Monitoramento e solução de problemas
O SQL Server fornece o Replication Monitor para revisar e monitorar detalhes de todas as sessões de replicação na instância. O Replication Monitor pode informar ao administrador quando o Snapshot Agent é executado e concluído. Também pode nos mostrar se as Assinaturas foram inicializadas e se o Agente de Distribuição está funcionando sem problemas.
Há oito trabalhos do SQL Server Agent associados à nossa configuração atual. A visualização do histórico desses trabalhos também fornece detalhes sobre se está tudo bem.
Erros reais do Oracle são listados no Replication Monitor e no log de erros do SQL Server quando são encontrados. Esse nível de detalhes torna a Replicação do SQL Server interessante para solucionar problemas. Ter um conhecimento de Oracle (para o SQL Server DBA) levará um longo caminho para entender os erros que podem surgir.
Dê uma olhada no exemplo do erro na Fig. 34. Este erro ocorreu antes que os ambientes Oracle Net e ODBC fossem configurados corretamente. Os erros dão uma indicação muito clara de onde está o problema.
A visualização Job Activity Monitor também nos informa quais trabalhos são bem-sucedidos e qual trabalho precisamos solucionar em detalhes examinando o histórico de trabalhos.
Depois que todos os erros anteriores forem resolvidos, abrir uma assinatura clicando duas vezes nos dá uma visão detalhada de todas as sessões, erros e resultados que esperamos ver quando tudo estiver bem. Observe que o Agent Bulk copia dados do Publicador para o Assinante em lotes. Também podemos consultar as tabelas que foram criadas na instância Oracle e comparar os registros. (Fig. 37).
Como você pode ver, o SQL Server prepara a tabela excluindo o esquema de origem (Sales) antes de criar a tabela no Oracle e copiar os dados.
A contagem de registros na instância Oracle corresponde à da tabela de origem e leva em consideração o fato de que filtramos a tabela OrderLines para OrderIDs maiores que 1000.
Conclusão
Passamos brevemente pelo processo de configuração da replicação de banco de dados heterogêneo com uma instância Oracle como Assinante. Embora essa opção esteja gradualmente sendo preterida pela Microsoft, há casos de uso que ainda podem se beneficiar dos recursos fornecidos por esse antigo recurso do SQL Server. A seção de Referências oferece uma leitura mais ampla sobre o assunto que acredito ser útil para aqueles que desejam praticar mais.
Referências
Configurar replicação para grupos de disponibilidade Always-On
Assinantes não Oracle
Replicação de banco de dados heterogêneo
Assinantes Oracle