Como meu provedor de hospedagem deve lidar com os logs de transação do SQL Server?

Question

Recebi hoje um ticket de suporte do meu provedor de hospedagem (eles o criaram), informando que meu log de transação de SQL estava cheio e que ele estava truncado, reduzido e redefinido para o modelo de recuperação completa.

Estou confuso sobre o motivo pelo qual eles deixam os logs de transação se encherem até o ponto em que um site cai e precisa de intervenção manual. Eu perguntei se eles estavam fazendo o backup dos bancos de dados e eles responderam (em Inglês ligeiramente quebrado)

We back up every day and keep the backups for a week. The transaction log has to be kept because we don't know what transaction you make and it might contain important information. The backup itself has the log truncated.

Confuso pela última sentença. Parece implicar que eles não estão fazendo o backup dos logs, o que eu acho que está OK se eles estão executando um backup completo todos os dias, mas se esse for o caso, por que os logs de transação não são truncados todos os dias? p>

Eu tentei educadamente sugerir que eles provavelmente deveriam estar truncando os logs, mas não tenho certeza se eles entenderam corretamente como os logs funcionam. Eu posso manter o meu próprio com o SQL Server, mas eu não sou um especialista e não tenho certeza o suficiente de mim para chamá-los sobre isso. Também não sei qual software de backup está usando ou como está configurado.

Então, eles estão justificados em nunca truncar os logs? Existe algum cenário em que isso ajude? Eles parecem ter um sistema pelo qual recebem um alerta quando o log está cheio e entram e executam manualmente um script truncado. Ele funciona, mas é deselegante e significa que meu site cai a cada poucas semanas até que ele perceba o problema e conserte-o. Nesse ponto, ele apaga o log que eles me disseram antes que eu precisava manter. Arghghghgh!

O que você faria, oh especialista em SQL Server?

    

Answer 1

They seem to have a system whereby they get an alert when the log is full and they go in and manually run a truncate script. It works but it is inelegant, and means my web site falls over every few weeks until they notice the problem and fix it, at which point they delete the log which they told me earlier I needed to keep.

Sim, isso não é bom.

Supondo que seu banco de dados esteja em plena recuperação (porque, como Chris McKeown aponta, se fosse simples, ele truncaria automaticamente), eis o que acontece:

Quando você / eles executa um backup completo, inclui o estado atual do banco de dados naquele momento. Não não truncar o log .

Quando você executa um backup de log, ele faz o backup das transações e, supondo que um ponto de verificação tenha ocorrido, trunca (não encolhe) o log, abrindo espaço para mais transações. Portanto, o log de transações deve encontrar um tamanho mais ou menos estável e permanecer lá, exceto comportamento estranho ou não sendo feito backup de seus logs com frequência suficiente.

Eles disseram:

We back up every day and keep the backups for a week. The transaction log has to be kept because we don't know what transaction you make and it might contain important information. The backup itself has the log truncated.

Sim. Eu não estou cheio de confiança por isso.

Gostaria de pedir que eles esclarecessem o tipo de backup que estão executando diariamente: se estão executando backups completos, diferenciais ou de log. Se eles estão executando logs noturnos e nunca executando um full, bem, jogando fora na semana passada eles quebraram sua cadeia de restauração e nunca será capaz de restaurar em caso de falha. Eles também, como Chris McKeown aponta, quebraram sua cadeia de restauração truncando os logs.

Eu não posso dizer com certeza com base nas informações fornecidas, mas certamente parece que eles não estão executando backups de log. Se forem, os backups noturnos não estão sendo feitos para você e o log precisa ser submetido a backup com mais frequência.

Eu também não sei o que o Acordo de Nível de Serviço para SQL restaura com seu contrato de hospedagem, mas você pode querer revisitar isso com um olho para saber se eles estão ou não em conformidade com base nessas informações.

    

Answer 2

Se o banco de dados estiver usando o modelo de recuperação FULL e o log de transações estiver em constante crescimento, isso significa que, na verdade, eles não estão fazendo backups regulares de log de transação.

Isso é um problema? Isso depende da expectativa que o seu ISP está lhe dando sobre a recuperação em caso de desastre. Se eles disserem que podem restaurar a um ponto no tempo entre os backups completos, eles estão mentindo. Truncar manualmente os logs interromperá a cadeia de backup de log e impossibilitará a restauração de um ponto no tempo.

Se eles só estão garantindo a capacidade de recuperação para o último backup completo, basta alternar para o modo de recuperação SIMPLE e, em seguida, os logs serão truncados automaticamente.

    

Answer 3

Confused by the last sentence. It seems to imply that they are not backing up the logs,

Está tudo bem. É padrão truncar o log quando você faz um backup completo, como então você tem o backup dos dados naquele momento.

Basicamente, eles confiam nos backups diários completos e no log tx local - que, neste caso, simplesmente não é grande o suficiente. Eles devem então expandir o log (e você paga por ele) ou mover para fazer backup de backups em intervalos regulares (15 minutos, por hora).

Se eles não truncam o log após um backup completo, eles são "não inteligentes". Não há razão para manter o registro completo depois de fazer um backup completo. Mas esse não é o caso - como eles dizem: "O backup em si tem o log truncado".

O que aconteceu é que você usou mais espaço para um log de dia do que eles alocaram. Provavelmente você supera sua configuração de baixo uso.