A resiliência a falhas do SQL Server pode ser melhorada?

Temos computadores executando o SQL Server (2008 SP4 e 2016 SP1) que perdem energia regularmente. Obviamente, isso às vezes leva à corrupção (índice) do banco de dados do SQL Server, que precisamos restaurar posteriormente.

Estou ciente de que o SQL Server não foi projetado para esses cenários e a solução correta é corrigir a causa da perda de energia (mais sobre isso abaixo, se você estiver curioso). No entanto, existem opções de ajuste no SQL Server que posso definir para reduzir o risco de corrupção do banco de dados devido à perda de energia ?

Antecedentes: O "PC" é um tablet Windows montado em uma empilhadeira. Quando o usuário desliga a empilhadeira, o tablet perde energia. Tentamos ensinar os usuários a desligar o Windows corretamente antes de desligar a empilhadeira, mas falharam (provavelmente porque apenas desligá-lo "funciona" na maioria das vezes). No momento, também estamos investigando outras opções, como adicionar um no-break que sinaliza o tablet para desligar com a perda de energia.

Estou ciente de que o SQL Server não foi projetado para esses cenários e a solução correta é corrigir a causa da perda de energia […]

Na verdade, ele foi projetado para lidar com a perda de energia, é por isso que existem coisas como WNA (gravação antecipada) e recuperação de falhas na inicialização (ou o que você quiser chamar). Uma das maneiras de fazer isso é optar por não armazenar em cache as gravações, o que parece ser o que o tablet está fazendo, daí a corrupção.

No entanto, existem opções de ajuste no SQL Server que posso definir para reduzir o risco de corrupção do banco de dados devido à perda de energia?

Não, o SQL Server está fazendo o que deveria. Você deve procurar fora do SQL Server (configurações do Windows para armazenamento em cache da unidade [que o SQL deseja desativar, mas não podemos forçá-lo], atualizações de hardware / firmware etc.) ou, como Eric disse, comprar uma fonte de alimentação externa por relativamente barato, o que poderia resolver os sintomas (o problema real é provavelmente algum tipo de cache ou gravação com bateria que não é realmente suportada).

Se o tablet tiver uma bateria funcionando , você poderá configurar o Windows para desligar quando a bateria estiver fraca .

Se o tablet tiver uma bateria que não está funcionando , considere substituí-la. (Eu já tive laptops assim - você ficaria surpreso com o quão barata as baterias de reposição podem ser no eBay. Elas não funcionam tão bem quanto as OEM, mas, ei, tudo é melhor que nada nessa situação.)

Se o tablet não possuir recursos de bateria , considere adicionar uma pequena fonte de alimentação ininterrupta (UPS) com saídas USB que podem se comunicar com o Windows para avisá-lo quando estiver funcionando com bateria. (Por exemplo, eu tenho minha própria área de trabalho configurada para desligar quando o no-break estiver com pouca carga da bateria - dessa forma, ele será desligado por falta de energia, mesmo que eu não esteja em casa.)

Se nada disso for uma opção, você estará sem sorte. É um white paper antigo, mas os Fundamentos de E / S do SQL Server 2000 da Microsoft basicamente explicam que você precisa de um subsistema de E / S que possa lidar com falhas de energia normalmente.

Existem opções que você pode usar para aumentar o risco - como Durabilidade atrasada ou tabelas com apenas memória (não durável) - mas, por padrão, o SQL Server já está fazendo o possível para maximizar a confiabilidade a cada gravação no log de transações. Se mesmo as gravações no log de transações não puderem ser garantidas devido a falta de energia aleatória, gaste US $ 100 em uma bateria do no-break.

Supondo que você tenha um banco de dados local na empilhadeira e não um servidor por causa de conexões sem fio irregulares? Obviamente, tirar o SQL da empilhadeira seria a solução preferível.

De qualquer forma, como sugeriu Brent, defina o tablet para desligar sozinho após x minutos de bateria ou alguns critérios semelhantes.

Caso contrário, um pequeno no-break que possa iniciar um desligamento normal provavelmente será sua melhor aposta nesse caso. Confiar nos usuários para coisas assim está pedindo para falhar.

O sistema operacional subjacente deve garantir que uma gravação bem-sucedida ou um erro seja retornado. O sistema operacional, por sua vez, depende de drivers que, por sua vez, dependem de firmware que depende do hardware. Se os drivers, o firmware e o hardware estão, não há nada que o Windows ou o servidor sql possa fazer sobre isso.

É por isso que você precisa verificar com o fabricante do driver / firmware / hardware.

Também é necessário garantir a ordem de gravação em todas as camadas, para que também seja necessário verificar.

Até os caches com bateria podem falhar, por exemplo, durante tempestades em Nova York, alguns data centers não estavam acessíveis por dias e as baterias acabariam, potencialmente perdendo gravações comutadas

https://www.postgresql.org/docs/devel/static/wal-reliability.html

https://brad.livejournal.com/2116715.html

http://rhaas.blogspot.com/2010/10/wal-reliability.html?m=1

Para expandir as outras respostas:

Primeiro, tente tirar o SQL da empilhadeira, se possível. Pense que a recuperação de uma perda de energia é ruim, tente fazer isso depois que o laptop foi atropelado por mais de 7.000 libras. Com horas de atividade de armazém, sem backup ...

Segundo, um mecanismo para o laptop desligar automaticamente após o tempo x da bateria deve estar instalado de qualquer maneira.

Terceiro, conectar o laptop a uma alimentação não comutada na empilhadeira seria uma opção? Certifique-se de considerar as normas de segurança (o ambiente pode exigir tudo da chave da empilhadeira) e por quanto tempo a empilhadeira fica entre os usos (principalmente nos fins de semana e feriados) para evitar o esgotamento da bateria da máquina.