Como impedir que o log de transações fique cheio durante a reorganização do índice?

Temos várias máquinas nas quais alocamos previamente o tamanho do log de transações para 50 GB. O tamanho da tabela que estou tentando reorganizar é de 55 a 60 gb, mas aumentará continuamente. A principal razão pela qual eu quero reorganizar é recuperar espaço e qualquer benefício de desempenho por causa disso é um bônus adicional.

O nível de fragmentação da tabela é de 30 a 35%. Em algumas dessas máquinas, recebo o erro "log de transações cheio" e a reorganização falha. O tamanho do log de transações atinge até 48gb. Qual é uma boa maneira de combater isso? Não temos o incremento automático ativado e reluto em fazê-lo.

Posso aumentar o tamanho do log para um valor maior, mas como o tamanho da tabela aumenta no futuro, o valor pode não ser suficiente. Também anula o propósito de reorganizar para recuperar espaço, se eu quiser aumentar o tamanho do log igualmente. Alguma idéia de como eu posso efetivamente combater isso? Usar o modo em massa não é uma opção, pois a perda de dados não é aceitável.

A melhor prática é REORGANIZEabaixo de cerca de 30% de fragmentação e REBUILDacima disso. Simplesmente, REBUILDfaz uma cópia limpa, REORGANIZEfaz no local.

Verifique o que você está realmente fazendo: você não tem um plano de manutenção fazendo as duas coisas?

Em tabelas maiores (a tabela de 50 GB está chegando lá), vi REORGANIZEconsumir todo o espaço do log de transações se você seguir esta regra. Frequentemente: apenas um sistema com um determinado padrão de carga. A REORGANIZEexecução acabou até o log expandir e consumir todo o espaço em disco.

Em REBUILDvez disso, mudamos para sem mais problemas, mas ignoramos a fragmentação abaixo de 25%. Isso funcionou melhor para nós: você terá que ver se funciona para você.

REBUILDpode afetar o desempenho mais do que REORGANIZEna produção, mas às vezes isso pode ser mitigado com a ONLINEopção (é necessário o Enterprise Edition).

REORGANIZE (como em ALTER INDEX ... REORGANIZE) é uma operação muito rápida (bem, principalmente ...), que requer pequena quantidade de log, pode ser interrompida a qualquer momento e retomada mais tarde e funciona internamente em transações em lotes pequenos :

a desfragmentação é executada como uma série de transações curtas; portanto, um log grande é desnecessário se os backups de log forem realizados com freqüência ou se a configuração do modelo de recuperação for SIMPLES.

Tem certeza de que não está falando sobre uma reconstrução ? Um índice REBUILD é lento, caro, consome uma quantidade enorme de logs (se não estiver offline e não puder ser minimamente registrado , a reconstrução online não pode ser minimamente registrada), é uma única transação gigante e não pode ser interrompida sem perder todo o trabalho.

Parece-me que você está reconstruindo, o que é uma operação realmente excepcional que você não deve fazer, a menos que tenha uma razão extremamente bem pensada. Que tipo de recuperação de espaço você espera? Algo que DBCC CLEANTABLEnão vai aguentar? Você verificou a estrutura física da tabela, desviou-se da estrutura lógica (consulte as colunas da tabela do SQL Server sob o capô para obter detalhes)?

Se você realmente precisa reconstruir a tabela, receio que você não tenha outra escolha a não ser morder o marcador e alocar o log necessário. Não o deixe crescer automaticamente, apenas retardará o processo. Faça um pré-crescimento para 2,5 vezes o tamanho da tabela.

Se a tabela estiver particionada, você poderá reconstruir offline (e reorganizar) uma partição por vez. A reconstrução online só pode ser feita em todo o nível da tabela.

Eu já tive esse problema antes.

• Você tem um grande banco de dados e uma pequena unidade de log. Você deseja reorganizar (por vários motivos).
• Quando você tenta fazer isso em uma tabela fragmentada grande, o log é preenchido até que a unidade de log esteja cheia e o comando é interrompido.
• Se estiver no modo simples, outras transações poderão falhar até que o log seja limpo no próximo ponto de verificação e, se estiver no modo completo, outras transações poderão falhar até o próximo backup de log. Outage!
• Se você estiver no modo completo, você aumenta sua frequência de backup de log, mas isso não ajuda a evitar o problema, porque a reorganização é feita em uma transação implícita, o log não é limpo até que a transação seja concluída, interrompida ou interrompida.
• E você REALMENTE deseja que essa reorganização seja executada até a conclusão.

Isso é um pouco contra-intuitivo, porque você sabe que, se você interromper a reorganização, ela pode continuar de onde parou, é apenas que um cancelamento confirma a transação em vez de reverter.

Aqui está o que você faz. É um pouco longo, mas direto.

• Faça um pré-crescimento do seu arquivo de log para um tamanho relativamente grande, mas não o máximo. Basicamente, você deseja deixar espaço suficiente para realizar um trabalho útil, além de alguns pequenos crescimentos, se ocorrerem, para que as operações normais não parem.
• Crie um trabalho para executar a reorganização do seu índice ('Reorganizar').

• Crie um alerta WMI do agente ('Reorganize Relief Valve') em uma condição de desempenho.

  • Objeto: SQLServer: bancos de dados
  • Contador: log de porcentagem usado
  • Instância: (seu grande nome de banco de dados)
  • Alerta se o contador ultrapassar: 80
  • Resposta: Executar trabalho ('Reorganizar verificação')

• Criar um trabalho ('Reorganizar verificação')

  • No trabalho, verifique msdb.dbo.sysjobactivity para ver se o trabalho 'Reorganizar' está em execução. E se for ...
  • Pare o trabalho e faça uma sondagem até que ele pare. Isso pode levar alguns segundos.
  • (Se você estiver no modo completo) Acione sua tarefa de backup de log e confirme quando ela terminar.
  • Verifique novamente os sys.dm_os_performance_counters que seu contador de espaço livre de log reduziu abaixo do seu limite.
  • Inicie o trabalho 'Reorganizar'.

• Teste tudo isso em algum lugar, até mesmo uma sandbox de desenvolvimento, para garantir que ele funcione corretamente antes de colocá-lo no servidor de produção.

O que você verá é que o trabalho 'Reorganizar' é iniciado e começa a preencher o log. Quando o log atinge uma porcentagem cheia, ele dispara o alerta WMI (em cerca de 30s), que executa seu outro trabalho, o que indica que o trabalho 'Reorganizar' está em execução e provavelmente com falha. Em seguida, para 'Reorganizar', faz um backup, confirma que o espaço livre do log voltou a um valor razoável e inicia o trabalho 'Reorganizar' novamente, que continuará de onde parou.

Portanto, o motivo pelo qual você pré-dimensiona seu log para um valor razoável nesse cenário é reduzir o número de crescimento / acionador / trabalho / parada / reinicialização, para que ele possa ser mais eficiente e também mantenha espaço suficiente para o crescimentos ocasionais que não são capturados a tempo.

Este é um tipo de cenário estranho. Eu tenho certeza que eu teria enganado isso há alguns anos atrás e, obviamente, há questões subjacentes fundamentais em mãos aqui. Mas se você lida com centenas de servidores, surgirão alguns casos extremos que não podem ser tratados de forma alguma, por qualquer motivo comercial, exceto pelo MacGyvering, uma solução temporária que faz o trabalho.

Desde que seja seguro, lógico, testado e bem documentado, não deve haver problema.

Isso é o que eu normalmente fazia (também tenho algumas tabelas com 80 GB de tamanho cada) para o reorg do índice (porque o reorg do índice pode ser interrompido a qualquer momento sem perder o trabalho anterior do reorg).

1. Durante o reorg do índice, aumentarei o backup do tlog da minha frequência normal de 30 minutos para cada 10 minutos de frequência
2. Tenho outra sessão realizando verificação de espaço livre do tlog a cada 1 minuto e, se o espaço livre do tlog estiver abaixo de um limite, pararei a sessão de reorganização do índice e iniciar (ou aguardar) o backup do tlog. Em seguida, reinicie o índice reorganizar.

Na minha estrutura de manutenção de índice, categorizo ​​os índices em dois grupos, um para reconstrução de índice e outro para reorganização de índice. Para a reconstrução do índice, usarei uma abordagem um pouco diferente, porque não quero interromper uma sessão de reconstrução do índice (o que causará uma reversão e perderá todo o trabalho anterior). Durante a reconstrução do índice, se minha sessão de monitoramento perceber um cenário de espaço livre no arquivo tlog, a sessão de monitoramento aumentará automaticamente o arquivo tlog e, no pior cenário (ou seja, o disco está cheio), minha sessão de monitoramento criará outro arquivo de log ( mas depois eu vou largar) em outra unidade (a unidade de backup)

Eu tive o mesmo problema que o autor da pergunta e, olhando os comentários dele, posso dizer que tive a mesma configuração. Enquanto eu tentava fazer um REORGANIZE, o log fica cheio, independentemente do tamanho, até várias vezes o tamanho da tabela inteira.

O problema foi causado pela replicação transacional . Aparentemente, não é possível fazer backup do log até que a REORGANIZEoperação seja concluída. Li em algum lugar que era um problema conhecido pela Microsoft, mas não sei onde.

Depois que desabilitei a replicação transacional, os backups de log funcionaram normalmente novamente, e fazer backups de log a cada 30 segundos durante a reorganização funcionou bem para mim.

Suponho que você esteja executando algo como:

ALTER INDEX ON REORGANIZE

Infelizmente, não há como executar uma organização parcial (da maneira que você pode reduzir parcialmente um arquivo de log, por exemplo). As maneiras pelas quais posso pensar em relação a esses problemas são:

1) defina o banco de dados para o modo de recuperação simples enquanto executa a reorganização, mas você disse que não é aceitável

2) particione o índice - se você puder pensar em uma maneira de particionar o índice para obter partições de tamanho aproximadamente igual, você poderá reorganizar (ou reconstruir com a opção online) cada partição independentemente e, assim, limitar o crescimento do arquivo de log

Estou certo de que você está fazendo isso, mas, se não estiver, convém iniciar um backup do arquivo de log antes e depois de fazer qualquer otimização do índice, o que permitirá recuperar o espaço usado.