Estou um pouco embaraçado ao admitir que esse comportamento foi causado por um procedimento armazenado chamado como parte de um aplicativo interno. No entanto, mesmo tendo corrigido o bug, ainda não sei por que foi acionado por um backup!
Este foi o código ofensivo:
SELECT DISTINCT T.*, TL.RunDate
FROM TaskLog TL
INNER JOIN Task T ON TL.TaskID = T.ID
WHERE TL.RerunFlag = 1
UPDATE TaskLog SET RerunFlag = 0
Última linha alterada para:
UPDATE TaskLog SET RerunFlag = 0 WHERE RerunFlag = 1
Eu fiz um backup completo do banco de dados e isso fez com que o arquivo de log começasse a crescer de forma incontrolável. Portanto, não é o processo de envio de logs em si, mas simplesmente o primeiro passo - ou seja, fazer o backup do banco de dados que causa o problema. Eu verifiquei o número de VLF e foi mais de 400 ontem, atualmente quase 200, então isso é definitivamente um problema.
O arquivo de log de um banco de dados normalmente em torno de 80mb se expande continuamente para 10 gigabytes sem nenhum sinal de interrupção se eu tentar iniciar o envio de logs no banco de dados no SQL Server 2005. DBCC SHRINKFILE não tem efeito.
Eu tenho implementado log shipping em vários bancos de dados, mas tendo um comportamento estranho em um banco de dados específico no SQL Server 2005. Normalmente este banco de dados é de cerca de 80mb com 80mb para um tamanho total de cerca de 160mb. Geralmente não varia muito em tamanho durante o dia. Os problemas começam quando tento iniciar o envio de logs nesse banco de dados usando o assistente de envio de logs.
O assistente chega ao primeiro passo que é o backup do banco de dados e chega a 100% completo. Em seguida, ele pára / pausa aqui e nunca chega ao próximo passo. Nenhuma mensagem de erro é gerada e o próprio SSMS é responsivo. Parece simplesmente que o mago está literalmente tomando para sempre. Eu paro e mato o processo, mas o dano já começou. A partir deste momento até o momento em que o arquivo de log é submetido a backup e reduzido, o arquivo de log continua expandindo a uma taxa de cerca de 100mb a cada 5 minutos.
Os usuários não são aparentemente afetados (graças a Deus).
Alguma idéia de causas e soluções?
Você já tentou fazer o backup e a restauração de origem no servidor de destino usando as opções NORECOVERY STANDBY e depois fazer a instalação do envio de logs? Eu usei isso para ignorar a necessidade de o "assistente" fazer um backup completo e restaurá-lo no servidor de destino.
Parece que há algo acontecendo com o Log de transações.
Você examinou o Log Relatório de status de envio? Isso pode lhe dar uma ideia do que está acontecendo com esse banco de dados quando ele desliga. Especificamente, você vai querer descobrir o que acontece quando ele tenta copiar o log.
Você faz backup regularmente do arquivo de log de transações? (Você deveria)
Parece que você tem a fragmentação do arquivo de log virtual (VLF). Sugiro a leitura: 8 passos para uma melhor taxa de transferência do log de transações
Devido a seus sintomas, acho que o crescimento do arquivo de log está correto. O banco de dados é normalmente um modelo de recuperação simples? Execute o gerenciador de perfil por um curto período de tempo para esse banco de dados e você provavelmente encontrará muitas atualizações (ou exclusões ou inserções) acontecendo.
Meu pensamento é este,
Normalmente, o SQL Server está reutilizando o espaço de log. Depois de iniciar o processo de envio de logs, o SQL Server não poderá mais liberar o log até que ele seja enviado (ou pelo menos com backup pronto para ser enviado). Os processos de envio de logs são iniciados assim que você usa o backup completo para inicializar o banco de dados de parceiros, e é por isso que os sintomas aparecem assim que o backup acontece. O backup não está causando o problema, o problema é que as atualizações estão sendo executadas com tanta frequência.
Tags windows log-files sql-server