Existem etapas especiais necessárias para impedir a corrupção de dados ao reiniciar um servidor que hospeda uma instância do MS SQL Server?

Por exemplo, recentemente encontrei a recomendação de interromper o serviço SQL manualmente. Meu entendimento é que isso é tratado pelo shutdownprocesso do Windows .

Tenho certeza de que há um zilhão de etapas que cada pessoa pode recomendar, como acabei de mencionar, mas gostaria de evitar repetir práticas obsoletas ou supersticiosas . Existem recomendações da Microsoft ou padrões generalizados do setor?

Esta pergunta está relacionada ao procedimento de curto prazo de reinicialização de uma máquina. Há outra pergunta sobre o procedimento de longo prazo para garantir que uma máquina não seja usada antes de desativá-la permanentemente.

Você não precisa ser chique / preocupado ou assustado ao reiniciar o servidor sql.

Apenas certifique-se de que você não possui nenhuma transação de longa duração. O melhor é reiniciar o servidor sql usando o console ou o comando shutdown durante um período de atividade baixo / mínimo, também chamado de janela de manutenção para minimizar o impacto nos seus negócios.

Se você tiver alguma configuração de recuperação de desastres e não quiser ficar inativo, o melhor é fazer failover e reiniciar o nó passivo ou secundário.

O desligamento limpo do SQL Server ocorre nos cenários abaixo:

• Pare o servidor sql usando o console de serviços.
• Desligando o servidor
• executando o comando SHUTDOWN no ​​SSMS

Acima de todas as situações, o sql server encerra todos os seus bancos de dados de maneira limpa e finaliza o serviço que envolve confirmar ou reverter todas as transações, gravando todas as páginas sujas no disco e gravando uma entrada no log de transações.

Desligamento inadequado do servidor sql:

• desligamento com nowait
• puxando o cabo de alimentação do servidor (se você tiver acesso).
• matando sqlserver.exe do gerenciador de tarefas
• Falha direta no qual binários do servidor sql, exe, bancos de dados do sistema residem ou falha na unidade de sistema do Windows. Geralmente C: \ drive.
• superaquecimento do servidor causando seu desligamento (raramente deve acontecer !!)

O SQL Server sempre tentará fazer um desligamento limpo ... a menos que você faça algo impróprio, conforme indicado acima.

Alguns links de leitura muito bons sobre o que acontece nos bastidores durante a fase de recuperação:

• Noções básicas sobre log e recuperação no SQL Server
• Compreendendo como a restauração e a recuperação de backups funcionam no SQL Server
• Visão geral simples do processo de recuperação do SQL Server

Tudo isso é detalhado exaustivamente nesta página.

• Iniciar, Parar, Pausar, Continuar, Reiniciar os Serviços do SQL Server

Sendo sua pergunta especificamente "existe algum recomendado pela Microsoft ", estou inclinado a pensar que isso é contraproducente ter essa discussão aqui. O artigo detalha o processo através de

• Usando qualquer um
  • linha de comando
  • Powershell,
  • GUI (SQL Server Management Studio)
• Para 2008, 2012, 2014, 2016.
• Para o
  • Mecanismo de Banco de Dados
  • ou, agente

Se essas etapas são satisfatórias ou não, seria minha opinião, o que você não deseja. Portanto, a resposta correta estará sempre mais atualizada lá.

Parando o serviço antes de desligar

é necessário ou recomendado fazê-lo antes de desligar um servidor que esteja executando serviços SQL.

Não, não é necessário. Quando o Kernel do Windows envia o sinal para desligar o SQL Server, ele o faz de maneira segura e o sistema aguarda a conclusão. Falando em termos gerais, qualquer coisa construído com a capacidade de desligamento com segurança não tem que ser desligado manualmente, e é lógico todas as aplicações Microsoft seguem sua própria API e procedimentos amarrando nos PRESHUTDOWN, ou SHUTDOWNfases. A partir dos documentos PRESHUTDOWN, que eu assumo que eles estão usando,

Notifica um serviço que o sistema será desligado. Os serviços que precisam de tempo adicional para executar tarefas de limpeza além da restrição de tempo no desligamento do sistema podem usar esta notificação. O gerente de controle de serviço envia essa notificação aos aplicativos que se registraram para ele antes de enviar uma SERVICE_CONTROL_SHUTDOWNnotificação aos aplicativos que se registraram para essa notificação.

Um serviço que lida com essa notificação bloqueia o desligamento do sistema até que o serviço seja interrompido ou o tempo limite do pré-desligamento especificado até a SERVICE_PRESHUTDOWN_INFOexpiração. Como isso afeta a experiência do usuário, os serviços devem usar esse recurso apenas se for absolutamente necessário para evitar perda de dados ou tempo de recuperação significativo na próxima inicialização do sistema.

Conforme for necessário, presumo que é assim que o SQL Server funciona.

Não é exatamente quando se trata de desligar e impedir a corrupção do banco de dados. O MS SQL Server é um produto muito maduro e as chances de causar um problema de corrupção com um simples 'desligamento' seriam um cenário de ponta. É muito mais provável que você cause corrupção ao não executar o CHECK DB ou ter a validação de soma de verificação definida no seu DB.

Talvez o fato de ter ferramentas externas tocando diretamente nos arquivos MDF / NDF / LDF possa causar problemas, como tentar 'mover' os arquivos entre desligamentos ou ter algum software tentando bloquear os arquivos durante o desligamento. Vi o clustering do Windows estragar quando um disco que hospeda arquivos de banco de dados está cheio, mas não causa especificamente 'corrupção de banco de dados'.

Se você quiser ajudar a garantir um desligamento ou failover tranqüilo, execute um ponto de verificação, verifique se está executando o DBCC CHECKDB com frequência (pelo menos o tempo suficiente para recuperar dados corrompidos de um backup) e verifique se existem dependências externas. cuidada como espelhamento.

No entanto, se algum especialista tiver outras 'melhores práticas', eu adoraria ouvi-las, mas vasculhando os blogs e os recursos on-line nos últimos anos, não vi muita corrupção de dados e um simples 'desligamento / reinício'.

Do jeito que eu faço: 1) Desative todos os trabalhos. 2) Verifique se não há trabalhos em execução no momento. 3) Execute SP_Who3 frequentemente para verificar a atividade, também execute sp_whoisactive para obter mais informações. 4) Se não houver atividade e a única coisa que você vê é sua consulta sp_who3 atual. 5) Coloque os bancos de dados offline 6) Clique com o botão direito do mouse na parte superior do banco de dados e clique em Parar 7) Verifique se os serviços estão parados no services.msc 8 ) Feito

PS. Se você tiver um PAGEIOLATCH / IOCOMPLETION ou qualquer outra atividade no SP_Who3, não faça o acima, pois isso poderia colocar seus bancos de dados no modo de recuperação.