Estamos mudando para o SQL Server 2014 Expensive Edition Q1 no próximo ano. No momento, estamos no SQL Server 2005 Standard Edition, portanto não temos acesso à MIRROR TOopção tão maravilhosa para nossos backups (usamos os scripts de Ola Hallengren).
No momento, estamos usando o robocopy para copiar arquivos para um compartilhamento de rede, caso nossos backups armazenados localmente sejam corrompidos, perdidos ou decidam tirar férias longas e agradáveis. Minha pergunta é, quando usamos a MIRROR TOopção, é mais/menos intensivo em recursos do que apenas usar robocopy, xcopy ou uma solução Powershell? O que exatamente acontece quando usamos MIRROR TOno SQL Server? Procurando um pouco de uma resposta 'porcas e parafusos', se possível.
Estou supondo aqui com base em como eu implementaria
MIRROR TO:Provavelmente, o SQL Server transmite os dados de backup para dois dispositivos de backup se você usar arquivos
MIRROR TO. Isso significa que cada bloco lido é escrito duas vezes. O fluxo de dados tem uma bifurcação.O que eles certamente não estão fazendo é gravar os dados uma vez e depois copiá-los. Isso a) incorreria em uma passagem de leitura adicional sobre os dados e b) também abriria uma janela para corrupção de dados enquanto existe apenas uma única cópia do backup. Do ponto de vista dos implementadores, é menos trabalhoso bifurcar o fluxo e tem um resultado melhor. É por isso que eu acho que eles estão fazendo dessa maneira.
Isso significa que
MIRROR TOconsome menos recursos do que copiar os arquivos de dados após o backup ter sido bem-sucedido. Ele também tem menos espaço para corrupção de dados. A corrupção de dados é rara, mas uma preocupação prática. Memória, disco e rede podem ter inversões de bits não detectadas. (Sim, o TCP não protege 100% disso.)Conselho dado o fato de que Enterprise Edition estará disponível para você: Use
MIRROR TO. Isso resulta em menos uso de recursos e menos potencial para corrupção de backup (não detectada). Ele também automatiza coisas que você pode errar ao fazer isso manualmente. O SQL Server certamente é testado melhor do que a maioria dos desenvolvimentos de script internos. A única razão para não usá-lo seria se o seu processo de backup não puder ser facilmente modificado para usá-lo.Um ponto adicional: se o espelho não puder ser gravado, o backup falhará. Isso pode ser uma desvantagem (você provavelmente excedeu seu objetivo de RPO). Pode ser uma vantagem porque os erros são mais prováveis de serem detectados.
Conforme mencionado por Paul White nos comentários: Se um dos destinos de backup for lento (ou todos os dados estiverem fluindo pelo mesmo link de rede saturado), o backup poderá demorar muito mais do que antes. No caso de um link de rede saturado, pode ser mais rápido duplicar localmente o arquivo de backup no servidor de destino.
Essa teoria pode ser testada: Faça backup do banco de dados em dois dispositivos IO que tenham características de desempenho idênticas usando MIRROR TO. Se eu estiver correto, você deve observar apenas uma pequena desaceleração porque as gravações são contínuas e paralelas.
Eu mesmo realizei esse benchmark. Fazendo backup de SSD (muito rápido) para duas unidades magnéticas (quase) idênticas. Usando compactação de dados (mas a CPU não foi maximizada).
Essa desaceleração (1:37 vs. 1:14) está bem dentro da tolerância da minha teoria. Parece haver algumas despesas gerais, mas certamente não há uma fase separada de espelhamento/cópia. Usando o Process Explorer, observei IO medido em MB/s. Foi bastante constante. Isso também indica que não há fase separada. As gravações parecem ser paralelas a ambas as unidades.