Estamos executando nosso software ERP em um servidor SQL Server 2016 como uma VM no VMware ESXi. Atualmente temos a VM configurada com 2 drives, com os dados indo para 1 e os logs para o outro. Tivemos um problema quando a VM foi corrompida e revertemos para um backup VEEAM. A restauração demorou um pouco, mas foi bem sucedida. Infelizmente, isso resultou na perda de cerca de 4 horas de dados. E como os logs de transações foram prejudicados com o servidor, não foi possível restaurar a partir dos logs de transações.
Então pensamos em gravar os logs de transações em outro compartilhamento de rede. Mas ao tentar configurá-lo em um banco de dados de teste, parece que o SQL Server não permite isso.
Existe uma maneira de fazer isso? Existe um impacto significativo no desempenho? Existe uma abordagem melhor?
Responder1
Existe uma maneira de fazer isso?
Sim, mas você provavelmente não quer fazer isso. Você pode ativarBandeira de rastreamento 1807para fazer com que o SQL Server use um caminho UNC para seus dados e arquivos de log. No entanto, a partir dessa documentação:
A Microsoft geralmente recomenda que você use uma rede de área de armazenamento (SAN) ou um disco conectado localmente para o armazenamento dos arquivos de banco de dados do Microsoft SQL Server porque essa configuração otimiza o desempenho e a confiabilidade do SQL Server.
(Embora a documentação vinculada indique que o SQL 2016 deve permitir isso por padrão, você precisará elaborar "parece que o SQL Server não permite".)
Existe um impacto significativo no desempenho?
Dependeem seu hardware. Depende de onde está o armazenamento "local" - discos giratórios dentro do host ESXi, ou em uma SAN, ou em outro lugar. E isso depende do armazenamento subjacente ao compartilhamento de rede que você está pensando em usar. Eles podem acabar iniciando o mesmo hardware e, nesse caso, as diferenças de desempenho podem se resumir a um pouco de sobrecarga do VMware. A Microsoft entra em detalhes sobre as considerações de desempenho no documento vinculado acima.
Existe uma abordagem melhor?
Sim
Os próprios arquivos de log de transações (normalmente *.ldf) não são o que você deseja usar para restaurar após um desastre. Tê-los locais no servidor é apropriado. E colocá-los em uma unidade separada dos arquivos de dados (normalmente *.mdf), como você fez, é uma coisa boa.
Quando ocorre um desastre e precisa restaurar a partir de um backup, você restaura a partir de um backup completo, depois, possivelmente, de alguns backups diferenciais e, possivelmente, de alguns backups do log de transações. Portanto, você deve escrever seucópias de segurançapara um local longe do seu servidor. Ou, no mínimo, se você precisar escrevê-los localmente, tenha um processo que os copie imediatamente em outro lugar. Como você descobriu, muitos tipos de falhas fazem com que todos os dados locais fiquem inutilizáveis.
Existem muitos tutoriais sobre como estabelecer um mecanismo de backup adequado.Brent Ozar Ilimitadotem vários bons.