Estou lendo sobre as soluções de alta disponibilidade e recuperação de desastres do SQL Server e dentre os recursos disponíveis o SQL Server possui recurso de snapshot. Em teoria, tudo parece bonito.
Eu também li que um instantâneo copiará um banco de dados em um ponto no tempo e você pode usar isso para restaurar um banco de dados.
Nesta resposta há um comentário (por Peter Schofield, 2013) sobre os instantâneos do SQL Server não terem suporte e é útil em um ambiente de desenvolvimento para reversões rápidas.
[...] Talvez o maior empecilho para a adoção seja que o Management Studio não oferecia suporte [...]
[...] Parece um uso ideal de instantâneos em um ambiente de desenvolvimento apenas para implantações rápidas de scripts e retrocessos rápidos.[...]
Gostaria de saber se os snapshots são realmente úteis em ambientes de produção. Quais são alguns exemplos de uso em produção e inclua exemplos pessoais sobre quando você usou instantâneos para fornecer uma solução em sistemas de produção.
O objetivo principal é fornecer alguns exemplos de uso real e através desses exemplos obter algumas ideias úteis para mim e para todos que lerão este post.
No meu caso utilizo o SQL Server 2017 Enterprise Edition em ambiente de produção.
Como uma pergunta e resposta baseada em opinião, suspeito que isso será encerrado, mas aqui estão meus dois centavos.
Eu usei e vi instantâneos de banco de dados em meus ambientes de produção, embora raramente.
Cenário A) Usamos instantâneos de banco de dados para fornecer uma imagem estática de um banco de dados para fins de relatório (ETL para um datawarehouse). Diariamente, um script seria executado no horário especificado e criaria um instantâneo para os relatórios usarem. Este banco de dados era transacionalmente consistente desde a data de criação, tão útil para isso.
Cenário B) Um trabalho de manutenção terrível que foi executado e fez algumas análises de uma tabela muito profunda e, em seguida, começaria a excluir as entradas apropriadas. Criamos um instantâneo no início deste processo para evitar qualquer bloqueio. Portanto, o trabalho de manutenção foi alterado para obter a lista de "o que precisava ser trabalhado" do instantâneo, depois descartar o instantâneo e "fazer o trabalho" no banco de dados ativo.
O caso de uso para instantâneos de banco de dados é um nicho para qualquer coisa, exceto CHECKDB. O SQL Server faz alguns truques de isolamento de bloqueio em segundo plano que o tornam uma boa opção se você precisar de uma correção rápida e suja para determinadas classes de operações.
Com isso ele quis dizer que você não tem recurso no SSMS para criar snapshot do banco de dados, você tem que confiar no comando TSQL para criar snapshot do banco de dados. Isso também é mencionado no documento oficial Create Database Snapshot
Concordo que o uso da palavra "suporte" não é totalmente claro. Deve ser que o SSMS não permita a criação de instantâneos de banco de dados.
O instantâneo do banco de dados "pode" ser usado em produção, tudo depende do que você deseja dele e de como ele atende às suas necessidades. Antes de prosseguir, leia Limitação do instantâneo do banco de dados. . Paul Randal tem mais alguns pontos sobre o que pode dar errado com instantâneos de banco de dados
Um instantâneo de produção de um banco de dados inativo é útil para preparar um banco de dados de Garantia de Sistemas ou "Suporte à Produção" de tamanho completo. Indiscutivelmente, estes não são produção, mas devem existir em um enclave semelhante à produção. Transações em andamento ou problemas de integridade referencial são evitados. problemas causados pelo descarregamento da Mesa A uma hora depois da Mesa B, digamos.
No extremo, eles podem fornecer uma posição de fallback para implementações ou atualizações. Os bancos de dados usados para pesquisa, métricas, análises, fornecendo um "cubo" de instantâneos, não precisam seguir as mesmas convenções dos exemplos da "web de negócios".