Definição de problema

Nossos usuários precisam consultar um banco de dados atualizado. Os dados podem ficar obsoletos por até 24 horas e isso é aceitável. Qual seria a abordagem de menor custo para obter e manter um segundo banco de dados atualizado com uma cópia de produção? Existe uma abordagem em que não estou pensando?

Carga de trabalho

Temos um aplicativo de terceiros que usamos para monitorar a atividade de negociação de ações. Durante o dia, muitas pequenas mudanças ocorrem como parte de vários fluxos de trabalho (sim, esse comércio era válido. Não, isso é suspeito, etc.). À noite, realizamos grandes operações baseadas em conjuntos (carregamos as negociações do dia anterior).

A solução e o problema atuais

Utilizamos instantâneos de banco de dados . Às 22:00, descartamos e recriamos o instantâneo. O processamento ETL é iniciado. Obviamente, isso está sobrecarregando nosso disco, mas permite que nossos usuários consultem o banco de dados sem bloquear o banco de dados (eles usam um front end do Access). Eles o usam tarde da noite e de manhã cedo, para perceber o tempo de inatividade.

O problema com essa abordagem é duplo. A primeira é que, no caso de o processamento noturno falhar, e isso não é muito incomum, conseguimos restaurar o banco de dados, o que resulta na queda do instantâneo. O outro problema é que nossos tempos de processamento estão passando do nosso SLA. Estamos tentando resolver isso trabalhando com o fornecedor depois de identificarmos consultas mal escritas e falta de indexação. O instantâneo do banco de dados também é o culpado dessa desaceleração, como evidenciado pela diferença de velocidade quando está presente versus não --- chocante, eu sei.

Abordagens consideradas

Agrupamento

Tínhamos o clustering de bancos de dados ativado, mas isso não atendia às necessidades de disponibilização dos dados e geralmente complicava a vida do administrador. Desde então, foi desligado.

Replicação do SQL Server

Começamos a examinar a replicação na semana passada. Nossa teoria é que podemos colocar um segundo catálogo em pé e sincronizado com o banco de dados de produção. Antes do início do ETL, interromperemos a conexão e a reativaremos somente depois que o processo ETL for concluído.

O administrador começou com a Replicação de Snapshot, mas está preocupado com o fato de levar vários dias de alto uso da CPU para gerar a captura instantânea e o consumo de disco necessário. Ele indica que ele parece gravar todos os dados em arquivos físicos antes de ser enviado ao assinante, para que nosso banco de dados de .6TB custe 1,8TB em custos de armazenamento. Além disso, se levar vários dias para gerar um snap, não caberá no SLA desejado.

Depois de ler o artigo, parece que o Snapshot pode ser a maneira de inicializar os assinantes, mas gostaríamos de mudar para a Replicação Transacional para mantê-lo sincronizado depois disso. Presumo que ativar / desativar a replicação transacional não forçará uma reinicialização completa? Caso contrário, explodiremos nossa janela de tempo

Espelhamento de banco de dados

Nosso banco de dados está no modo de recuperação COMPLETA, portanto, o espelhamento de banco de dados é uma opção, mas eu sei ainda menos do que a replicação. Encontrei a resposta SO que indicava "O espelhamento de banco de dados impede que os dados sejam acessados ​​diretamente; os dados espelhados são acessíveis apenas através de um instantâneo de banco de dados".

Log Shipping

Parece que o envio de logs também pode ser uma opção, mas essa é outra daquelas coisas sobre as quais não sei nada. Seria uma solução de menor custo (implementação e manutenção) do que qualquer outra coisa? Baseado no comentário de Remus, "O envio de log permite acesso somente leitura à cópia da réplica, mas desconectará todos os usuários ao aplicar o próximo log de backup recebido (por exemplo, a cada 15 a 30 minutos)." Não sei quanto tempo esse tempo de inatividade se traduziria, o que pode causar angústia aos usuários.

MS Sync

Eu só ouvi falar sobre o uso do Sync no fim de semana passado e ainda não o investiguei. Eu odiaria introduzir uma nova tecnologia para algo com alta visibilidade como esse problema, mas se for a melhor abordagem, que seja.

SSIS

Fazemos bastante SSIS aqui, portanto, gerar algumas centenas de pacotes SSIS para manter o secundário sincronizado é uma opção para nós, embora seja feia . Eu não sou fã disso, pois há muita sobrecarga de manutenção que prefiro que minha equipe não assuma.

Instantâneo "mágico" da SAN

No passado, ouvi falar de nossos administradores usando alguma tecnologia SAN para fazer backups instantâneos de discos inteiros. Talvez exista alguma mágica da EMC que possa ser usada para fazer cópias rápidas do mdf / ldf e, em seguida, podemos desanexar / anexar o banco de dados de destino.

Backup e restauração

Acho que fazemos backups completos uma vez por semana, diferenciais todas as noites e tlog a cada 15 minutos. Se os usuários pudessem conviver com a interrupção de 3 a 4 horas da restauração completa, suponho que essa seja uma abordagem.

Restrições

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, armazenamento EMC SAN com unidades mapeadas para arquivos vmdk, backups de manipulação de commvault e .6TB de dados no catálogo de origem. Este é um aplicativo de terceiros que hospedamos internamente. Modificar sua estrutura é geralmente desaprovado. Os usuários não podem ficar sem consultar o banco de dados e se recusam a ser restringidos identificando proativamente as tabelas que monitoram para realizar seu trabalho.

Nossos DBAs são puramente contratados no momento. Os temporizadores partiram e ainda não os substituímos. Os administradores de aplicativos não são bem versados ​​nos assuntos do SQL Server e temos uma equipe de administradores de armazenamento / VM que pode ajudar / impedir esse esforço. As equipes de desenvolvimento não estão envolvidas no momento, mas podem ser recrutadas com base na abordagem. Portanto, uma solução mais simples de implementar e manter seria preferível.

Eu, eu estou do lado do desenvolvimento do hosue, então só posso propor abordagens e não tive que lidar com o lado administrativo das coisas. Portanto, sem tempo na sela do administrador, hesito em dizer que uma abordagem seria superior a outra - tudo parece ótimo de acordo com os documentos. Estou totalmente disposto a seguir qualquer direção que vocês sugerem, porque, a meu ver, isso só me tornará mais valioso como profissional de DB. Eu tenho um carrinho de mão, mas nenhuma capa do holocausto está disponível .

Perguntas relacionadas

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Edições

Para responder às perguntas de @ onpnt

Aceitação de latência de dados

Os usuários atualmente visualizam dados com até 24 horas de atraso. Os dados são atuais apenas a partir de 2200

A quantidade de dados é alterada em um determinado minuto, hora e dia. Não sabe como quantificá-lo. Horário comercial, talvez centenas de alterações por hora. Processamento noturno, milhões de linhas por dia útil

Conectividade com o secundário

Rede interna, host virtual separado e armazenamento dedicado

Leia os requisitos na instância secundária

O grupo do Windows terá acesso de leitura ao secundário, todas as tabelas

Tempo de atividade da instância secundária

Não há uma definição forte de um requisito de tempo de atividade. Os usuários querem que ele esteja sempre disponível, mas estão dispostos a pagar por isso, provavelmente nem tanto. Realisticamente, eu diria que 23 horas por dia seriam suficientes.

Alterações no esquema existente e em todos os objetos

Modificações pouco frequentes, talvez uma vez por trimestre para objetos de tabela. Talvez uma vez por mês para objetos de código.

Segurança

Nenhuma necessidade especial de segurança. As permissões de produção corresponderiam às permissões da cópia. Embora, enquanto eu penso sobre isso, possamos revogar o acesso de leitura dos usuários ao prod e permitir que eles leiam a cópia ... Mas não é um requisito.

@darin strait

A reversão para o instantâneo pode ser uma opção, mas acho que houve alguma razão para eles não terem buscado. Vou verificar com o administrador

@cfradenburg

Minha suposição era de que usaríamos apenas uma dessas abordagens, mas esse é um bom ponto que as restaurações quebrariam as "outras" tecnologias de sincronização. Eles estão investigando o uso da mágica de instantâneo da EMC. Como o administrador descreveu, eles tiravam um instantâneo em 1900 e migravam a imagem para a zona do secundário. Isso deve ser concluído em 2200 e, em seguida, eles executam uma desanexação e recolocação do banco de dados secundário.

Embrulhar

2012-10-29 Avaliamos a mágica do instantâneo da EMC e algumas outras opções de replicação, mas os DBAs decidiram que poderiam descobrir melhor o espelhamento. Votou as respostas porque todas elas ajudaram e me deram muitas opções, além de "trabalhos de casa" para investigar.

Modificar sua estrutura é geralmente desaprovado

A replicação é mais do que provável e eu descartaria o Sync antes disso. (dos testes transacitonais altos da vida real no Sync Framework)

Se a exceção de latência de dados for de 3 a 4 horas, o envio de logs provavelmente será sua melhor aposta aqui em uma cópia somente leitura. Mas quanta mudança está acontecendo no log? descubra isso monitorando-o para ver com que rapidez e quanto você precisa transmitir.

Se você não pode ir para o espelhamento ou atualizar para a empresa de 2012, isso está fora, embora isso seja uma estratégia sólida se você puder usar a empresa, se não estiver nela.

O SSIS não se destina apenas a despejar dados, mas pode fazê-lo. Você está olhando demais nos termos das transformações de pesquisa e a tarefa seria cara em tempo e recursos. Embora, como eu disse, possa fazê-lo.

Realmente, haverá um estreitamento distinto de opções com base em respostas a algumas perguntas

• Aceitação de latência de dados
• Quantidade de dados alterados em um determinado minuto, hora e dia Conectividade com o secundário
• Leia os requisitos na instância secundária
• Tempo de atividade da instância secundária
• Alterações no esquema existente e em todos os objetos
• Segurança

Essa será uma dessas coisas que você precisa tentar para descobrir o que funciona melhor. A replicação pode ser complicada, portanto, embora possa não haver um custo monetário direto, haverá uma sobrecarga administrativa para mantê-la.

Para expandir o envio de logs, não é necessário restaurar os logs a cada 15 a 30 minutos. Se você escolher, poderá fazê-lo a cada quatro horas ou uma vez por dia. Uma solução semelhante à que eu implementei é fazer um backup completo semanal e restaurar um banco de dados de relatórios (que pode demorar um pouco e acontece no fim de semana). Durante a semana, são realizados backups diferenciais e esses são restaurados no banco de dados de relatórios todas as noites. Os usuários precisam ser inicializados antes da restauração, mas como o banco de dados de relatórios é um aplicativo de horário comercial, não há problema nisso. Os dados têm um dia de idade, o que não deve ser um problema com base em seus requisitos.

Para usar o espelhamento de banco de dados, é necessário adquirir o Enterprise para poder usar instantâneos se você ainda não estiver executando o Enterprise. Também não manteria os dados 100% atualizados, pois o instantâneo precisa ser eliminado (o que significa que todos os usuários precisam estar fora) e, em seguida, recriado para obter os novos dados. No entanto, isso levaria menos tempo do que as restaurações de log ou o método que expliquei acima.

Se a atualização para o SQL 2012 for uma opção, é possível configurar um secundário somente leitura que será mantido atualizado com o banco de dados primário. Só mencionei isso porque é provável que seja a solução mais suave.

Por mais que as pessoas se preocupem com a replicação transacional, isso parece ser um bom ajuste para a sua situação. Algumas notas:

1. Você não precisa inicializar o assinante com um instantâneo. Você pode fazer um backup do editor e inicializar com isso.
2. Você pode pausar a entrega de comandos para o assinante apenas interrompendo o trabalho de distribuição (é apenas um trabalho normal do SQL Agent no distribuidor ou no assinante, dependendo se você o configurou como assinatura push ou pull, respectivamente). Lembre-se de sua retenção no distribuidor para manter um histórico suficiente para recuperar o atraso.
3. Você pode alterar a indexação no assinante para acomodar as cargas de trabalho que serão feitas lá (tipo de relatório presumivelmente) em vez de precisar aceitar a indexação do seu editor (provavelmente do tipo OLTP), se desejar.