Basta saber que tipos de processos vocês têm para transferir dados de produção para fins de análise?
Li algumas publicações, mas não tenho certeza das despesas gerais envolvidas e dos processos de configuração.
FYI, estou usando o SQL Server 2008 com o Windows Server 2008 R2. MY DB tem cerca de 36 shows. Estou interessado apenas nos dados.
Outros métodos são bem vindos!
* EDITAR Informação adicional: Eu não me importo de o banco de dados ser lido apenas e estou procurando executar este processo uma vez por semana.
Você pode ver o envio de logs, muito semelhante à sua abordagem "manual", mas usa componentes SQL internos para fazer o trabalho e funciona com backups de log de transações.
Uma ótima explicação e comparação para o espelhamento de banco de dados pode ser vista em link
Como uma mera sugestão, você diz que seu db é de 36 shows. Dependendo da compressão + velocidade de transferência, você pode achar mais fácil despejá-lo em uma unidade USB e enviá-lo pelo correio. Além disso, alguns ftp nunca permitirão arquivos de > 4GB. Push incrementais podem ser o seu caminho, mas, novamente, considere o pior caso: o que acontece se seus dados mudarem mais rápido do que o seu banco de dados pode empurrá-los para o replicador?
Eu tenho um cliente que precisava dessa coisa exata. Eles não podiam aceitar que o banco de dados ficasse inacessível quando os logs eram restaurados para que o envio de logs estivesse fora. A replicação não era possível porque seu esquema seria muito de um hastle. O espelhamento não funcionaria porque é somente leitura, e eles precisavam de um banco de dados gravável ... mas essas gravações não tiveram que voltar para o servidor principal.
Acabei de escrever um plano de manutenção e alguns scripts que fazem um backup completo do banco de dados em questão (120 GB) e, em seguida, usam xp_cmdshell para copiar o arquivo para um compartilhamento de rede no outro servidor SQL e, por último, executa um trabalho remotamente (você pode definir qual servidor executar na etapa do plano) para fazer uma restauração do banco de dados.
Você pode querer verificar o script isp_Restore de Tara Kizer, que pode ajudá-lo com isso. link Acabei escrevendo meu próprio roteiro porque o dela não fez exatamente o que Eu precisava, mas deveria pelo menos começar.
O envio de logs é ótimo para análise, mas esteja preparado para alta sobrecarga com o backup inicial e a transferência dos dados para outro servidor / instância. Além disso, o envio de log implica um atraso entre os dados ao vivo e os dados de análise. Depois disso, você está apenas movendo backups de log de transações, que são teoricamente menores.
Em nosso ambiente, registramos a remessa à noite, porque o gerenciamento executa relatórios quando eles chegam ao escritório pela manhã, e esses relatórios normalmente exigem uma quantidade significativa de pivôs.
Tivemos um banco de dados de 4 GB, onde raramente é necessário um backup para analisar os problemas. O banco de dados era muito grande para fazer um backup durante o dia enquanto a produção estava sendo executada. Portanto, nossa solução foi executar um backup à noite, quando nosso sistema de produção estava inativo e manter os backups mais recentes (acho que ficamos uma semana).
Um dos nossos requisitos era que o banco de dados precisava ser enviado para departamentos diferentes, dependendo do problema. Outro motivo foi que poderíamos disponibilizar os arquivos de backup para os gerentes de projeto, que não tinham acesso direto a nenhum servidor SQL e que eles estavam encarregados de enviar os backups para os destinatários apropriados. Eles não precisaram envolver os administradores para obter os backups.
Os backups diários foram agendados usando as ferramentas padrão do servidor SQL.
Supondo que seu banco de dados analítico de destino é a mesma plataforma que seu banco de dados de produção, a solução mais fácil é fazer um backup incremental semanal e depois aplicá-lo ao seu banco de dados analítico. Se o seu banco de dados não está crescendo muito rapidamente, um arquivo incremental deve ser transmissível em um período de tempo razoável.
Se você está transmitindo para algum outro tipo de banco de dados do que o que você está executando atualmente na produção, uma ferramenta de ETL como Pentaho Data Integration pode ser um melhor ajuste. Uma ferramenta ETL é uma solução ainda melhor se você se importa apenas com algumas das tabelas e não com todas elas.
Tags sql-server