Isenção de responsabilidade padrão: sou um "DBA involuntário" (uma bela frase que vi neste artigo ) e fiz muitas e muitas e muitas e muitas e muitas leituras sobre esse assunto, mas ainda estou confuso/preocupado...
Preciso alterar o modelo de recuperação de vários bancos de dados de produção do SQL Server 2014 de Completo para Simples.
Os bancos de dados estão atualmente configurados para Full Recovery e estavam sendo copiados usando SqlBackupAndFTP , que faria um backup completo diário, com 3 backups diferenciais e 20 backups de transação por dia. Isso estava funcionando bem até que tivemos grandes problemas com a empresa que fornece armazenamento baseado em FTP.
Cerca de 3 meses atrás, mudei para o Attix5, que está funcionando bem - no entanto, descobri agora que, devido à maneira como o software funciona, os logs de transação são tão grandes quanto os arquivos de dados (em um caso, mais de 14 Gb contra um arquivo de dados de 13 Gb ).
Fui recomendado para mudar o modelo de recuperação para Simples, para que o log de transações não cresça.
Sei que ter o Simple Recovery não fornecerá restauração pontual - isso é absolutamente bom, pois backups completos estão ocorrendo a cada hora e estamos "felizes em perder" qualquer coisa que possa ter acontecido nos 1 a 59 minutos anteriores.
Meu entendimento é que devo definir o modelo de recuperação como Simples e deixar o backup ocorrer, o que definirá um ponto de verificação no log de transações permitindo que o espaço seja reutilizado.
No entanto, eu realmente preciso reduzir o log de transações para um tamanho razoável (para que não ocupe muito espaço de backup), mas continuo lendo que reduzir é uma má ideia. Ou estou entendendo o lado errado da vara?
Se eu reduzir o log de transações para cerca de 25 MB (o que deve ser grande o suficiente para um único conjunto de transações por hora) usando o seguinte comando, isso é suficiente?
DBCC SHRINKFILE('log file name',25)
(Sinto muito por estar perguntando algo que parece ter sido perguntado um zilhão de vezes antes, mas não é algo que eu possa errar.)
Em primeiro lugar, gostaria de salientar novamente que, na maioria dos casos, a recuperação SIMPLES não é recomendada para um banco de dados de produção. No entanto, se isso é algo que você deseja alterar, a melhor maneira que encontrei para reduzir o arquivo LOG, depois de colocar o banco de dados no modelo de recuperação SIMPLE, é a seguinte. Isso não apenas liberará espaço livre do log, mas também reduzirá o arquivo ao seu menor tamanho possível.
Como você afirmou, encolher também não é normalmente uma boa prática, mas há momentos em que é justificado. Existem muitos artigos pró / contra sobre isso, e eu concordo com aqueles que dizem para você nunca usar,
DBCC SHRINKDATABASE;sempre useDBCC SHRINKFILEse precisar absolutamente de um psiquiatra.No entanto, o arquivo de log realmente precisa ter um tamanho razoável, mesmo no modelo de recuperação SIMPLE, pois é onde as informações são mantidas durante as transações e os SPIDs de execução longa precisam de mais de um arquivo de log. Entre muitos motivos, um deles é a reversão em caso de problema. Como afirmei acima, esses scripts reduzirão seu arquivo de log ao menor tamanho absoluto possível, mas como você precisa de pelo menos algum espaço de log, você deve aumentá-lo manualmente e também certificar-se de que seu "crescimento automático" esteja definido para um valor razoável número; indiscutivelmente, uma porcentagem deve sempre ser evitada. Encolher o log para seu menor tamanho e reaumentá-lo manualmente realiza um processo muito importante - o de manter sua fragmentação/contagens VLF regressivas. Esse é outro tópico que não vou abordar aqui, e muitos sites, incluindo Brent Ozar, podem entrar nas estatísticas reais e testar o motivo, mas sempre aumente seu arquivo de log em 8 GB por crescimento, se precisar ser tão grande ou maior. Você mencionou acima de 25 MB e não consigo imaginar que seja grande o suficiente. Eu pessoalmente gerencio mais de cem bancos de dados no momento, e menos de uma dúzia está configurado para 64 MB - todos os outros são muito maiores, variando até 64 GB. Sua atividade e consultas SQL reais determinarão qual deve ser o tamanho ideal. No mínimo, eu iria de 512 MB para 2 GB e definiria seu crescimento para o mesmo até que você saiba onde seu arquivo de log deve ficar. Eu pessoalmente gerencio mais de cem bancos de dados no momento, e menos de uma dúzia está configurado para 64 MB - todos os outros são muito maiores, variando até 64 GB. Sua atividade e consultas SQL reais determinarão qual deve ser o tamanho ideal. No mínimo, eu iria de 512 MB para 2 GB e definiria seu crescimento para o mesmo até que você saiba onde seu arquivo de log deve ficar. Eu pessoalmente gerencio mais de cem bancos de dados no momento, e menos de uma dúzia está configurado para 64 MB - todos os outros são muito maiores, variando até 64 GB. Sua atividade e consultas SQL reais determinarão qual deve ser o tamanho ideal. No mínimo, eu iria de 512 MB para 2 GB e definiria seu crescimento para o mesmo até que você saiba onde seu arquivo de log deve ficar.
Acho que executar cada linha separadamente funciona melhor, garantindo o sucesso antes de ir para a próxima etapa. A linha final do curso é o que aumenta seu log para o tamanho que você definiu. Eu tenho 8 GB, mas você pode alterar isso para atender às suas necessidades. Se você não quiser encolher totalmente e depois crescer novamente, remova a última linha e altere o "1" na linha acima para sua escolha de tamanho.
Uma última coisa antes de sair e reduzir seu arquivo de log.
IMPORTANTE: Sempre que um arquivo de log aumenta, manualmente ou automaticamente por SQL, basicamente todo o seu banco de dados é bloqueado até que o crescimento seja concluído. Escolha um bom momento quando isso não afetará as transações ativas - se você tiver "fora do expediente" ou janelas de manutenção. Um tamanho tão pequeno de 1 GB ou menos deve ser bastante rápido e invisível para o usuário final, mas isso será realmente determinado por sua infraestrutura.
Então você sabe que está jogando com uma espada de dois gumes e está ciente dos riscos - qualquer fio que você tocar, você vai se cortar.
Verifique com o fornecedor se eles estão anexando os arquivos de backup do log de transações ou não e use a compactação de backup .
Eu vejo um problema nisso. Se bem entendi, você está lutando contra o espaço de armazenamento em disco. Um backup completo sempre ocupará mais espaço em comparação com um backup de log de transação (ou um backup de log diferencial).
Você deve consultar o fornecedor da ferramenta de backup e solicitar que ele corrija o problema. Como alternativa, por que você não usa uma solução T-SQL - que tem mais transparência e controle sobre o que você está fazendo, em vez de usar uma ferramenta que você sabe que está causando problemas.
Você deve ler mais uma resposta incrível - Por que o log de transações continua crescendo ou fica sem espaço?
Você deve descobrir com que frequência o crescimento automático entra em ação e começar com um valor médio e depois ajustar. O dimensionamento adequado do log de transações é muito importante e, por favor, não use 25 MB. O som é muito baixo e o valor será muito baixo, o que iniciará os eventos de autocrescimento com mais frequência.
Se o seu log de transações for grande, então (passe o mouse abaixo)
Não deixe que a ferramenta de buggy do seu fornecedor afete sua decisão sã :-)