Não sou DBA, mas sendo as coisas como são, tenho que usar o chapéu de DBA e configurar planos de manutenção na minha instância do SQL Server.
Então, por um tempo, tenho feito meu processo noturno do SSIS executar uma tarefa Executar SQL para executar os backups - basicamente executando master.dbo.xp_create_subdir
para garantir que as pastas de destino existam e, em seguida, BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT
.
Sempre que essa tarefa falhava, o resto do processo era abortado e eu recebia uma notificação, e chegava na manhã seguinte para perceber que a unidade para logs de transações estava cheia, então eu os truncava manualmente e seguia em frente. .. até que a história se repetisse e os logs de transações superassem o espaço em disco disponível novamente.
O script "truncate manual" se parece com isso:
use Staging; alter database Staging set recovery simple alter database Staging set recovery full dbcc shrinkfile ('Staging_log', 0, truncateonly); go
Então, estou ficando cansado disso e decidi tentar fazer as coisas corretamente , seguir as etapas aqui e criar um plano de manutenção real :
O problema é que nunca fiz isso antes, então tenho algumas perguntas:
- Fazer backup dos logs de transações como esse os truncará automaticamente ou há outra coisa que preciso fazer?
- Posso executar backups de dados e logs de transações simultaneamente? Se não, então qual é a maneira correta de fazer isso?
- Os arquivos de backup estão sendo coletados durante a noite por outro processo que pega todos os arquivos no servidor e os armazena em outro lugar - seria uma boa ideia expirar o conjunto de backup após 2 dias? Eu preciso fazê-los expirar em tudo?
- As tarefas de limpeza removem, respectivamente, os arquivos .bak e .trn "antigos" nas subpastas de
G:\Backups
. Isso faz sentido? - Seria melhor fazer isso no SSIS, para que eu possa falhar no meu ETL se/quando os backups falharem? Ou meu processo de ETL deveria se importar?
Desculpe se são muitas perguntas para um post, se necessário, editarei e farei várias perguntas - acho que todas estão intimamente relacionadas.
Você deve escolher seu modelo de recuperação com base em suas necessidades de negócios:
Com base na resposta acima, você deve escolher cuidadosamente seu modelo de recuperação de banco de dados .
Em termos simples (não discutindo o modelo de recuperação de log em massa) ,
Lembre-se de que o truncamento de log NÃO é uma redução física no tamanho do arquivo de log de transações. Isso significa que a parte inativa do arquivo de log de transações é marcada como reutilizável .
Portanto, você deve pré-dimensionar corretamente seu arquivo de log de transações (e arquivos de dados). Aumentar o arquivo de log acionará eventos de crescimento automático (se seu banco de dados estiver configurado para crescimento automático como último recurso). Confira minha resposta - Autogrowth - Porcentagem de uso?
Eu sugiro que você abandone os planos de manutenção e implemente [uma solução de manutenção inteligente - que seja fácil, flexível e siga as melhores práticas] - 5 . - Solução de backup da Ola (e solução de manutenção Index também).
vamos responder suas perguntas:
Por favor, não anexe backups ou defina-os para expirar. Eles criam uma grande confusão. Use
INIT
e faça backups de log separados com carimbo de data e hora. De fácil manutenção. Use a solução de backup da Ola para isso. A solução é flexível para excluir backups antigos também.Um backup completo não tem efeito em um backup T-log. Um backup completo contém apenas o log de transações necessário para que, no caso de uma restauração, o banco de dados possa ser transacionalmente consistente com o momento em que a parte de leitura de dados do backup completo foi concluída. Check- quanto log de transações um backup completo inclui?
Além disso, um backup de log durante um backup completo não truncará o log de transações. Um (alguns) backups de log após a conclusão do backup completo truncará o log.
Para ambos acima, use a solução de manutenção de backup da Ola. Ele cuidará da exclusão de arquivos antigos.