Usuário com melhor resposta
Sobre o backup e a restauração de bases, estes procedimentos estão corretos?

Pergunta
-
Olá pessoal,
Temos em nossa empresa, uma base oficial corpore e outra de teste corpore_contabilidade. Sempre que se precisa realizar testes fazemos o backup da base oficial e, em seguida, restauramos para a base de teste. Como estávamos só realizando o backup e a restauração percebemos que o espaço em disco estava aumentando ao ponto de não permitir mais o backup. Tenando resolver esse problema estamos adotando a seguinte estratégia abaixo e gostaríamos de saber com os mais experientes se esta estratégia está sendo executada corretamente.
Utilizamos o SQL Server 2008 R2.
USE master /* ENTRAMOS NA BASE MASTER */
GO-- REALIZA O BACKUP DA BASE OFICIAL
BACKUP DATABASE [corpore] TO DISK = N'E:\BACKUP_Contabil\corpore.bak' WITH NOFORMAT, INIT, NAME = N'corpore-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
-- COLOCAR A BASE DE TESTE COMO OFFLINE
ALTER DATABASE corpore_contabilidade SET OFFLINE WITH ROLLBACK IMMEDIATE
GO
-- RESTARUA O BACKUP NA BASE DE TESTE
RESTORE DATABASE corpore_contabilidade FROM DISK = N'E:\BACKUP_Contabil\corpore.bak' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10
GO
-- RETORNA A BASE DE TESTE PARA ONLINE
ALTER DATABASE corpore_contabilidade SET ONLINE WITH ROLLBACK IMMEDIATE
GO
-- ************************************************
-- PREPARANDO A MANUTENÇÃO NO BANCO APÓS A RESTAURAÇÃO
USE master /* ENTRA NA BASE MASTER */
GO
-- Alterar o modelo de recuperação para "simples"
ALTER DATABASE corpore_contabilidade SET RECOVERY SIMPLE WITH NO_WAIT
GO
USE corpore_contabilidade /* ENTRA NA BASE DE TESTE */
GO
-- Reduzir o tamanho do arquivo para 15360 MB (equivalente a 15 GB), reorganizando páginas (SHRINK) antes de liberar espaço
DBCC SHRINKFILE (N'corpore_Log' , 15360)
GO
USE master /* RETORNA PARA A BASE MASTER */
GO
-- Restringir o tamanho máximo do arquivo de log para 15360 MB (equivalente a 15 GB)
ALTER DATABASE corpore_contabilidade MODIFY FILE ( NAME = N'corpore_Log', MAXSIZE = 15728640KB )
GO
-- Retornar o modelo de recuperação para "Full"
ALTER DATABASE corpore_contabilidade SET RECOVERY FULL WITH NO_WAIT
GO
-- FINAL DA MANUTENÇÃO NO BANCO
-- ************************************************
-- RETORNA PARA A BASE DE TESTE PARA REMOVER OS USUÁRIOS DA TABELA GLOGIN
USE corpore_contabilidade
GO
DELETE FROM GLOGIN
GO
-- FIM DO PROCESSOGrato pela atenção de todos,
Ilano
- Editado ilanocf sexta-feira, 8 de fevereiro de 2013 14:59
Respostas
-
Acredito que sua estrategia esteja correta, só tome cuidado ao ficar fazendo shrink pois isto aumenta consideravelmente a fragmentação no disco que o arquivo fisico esta.
Alexandre Matayosi Conde Mauricio. Se esta sugestão for útil, por favor, classifique-a como útil. Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.
- Marcado como Resposta Ricardo Russo segunda-feira, 18 de fevereiro de 2013 12:47
Todas as Respostas
-
Acredito que sua estrategia esteja correta, só tome cuidado ao ficar fazendo shrink pois isto aumenta consideravelmente a fragmentação no disco que o arquivo fisico esta.
Alexandre Matayosi Conde Mauricio. Se esta sugestão for útil, por favor, classifique-a como útil. Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.
- Marcado como Resposta Ricardo Russo segunda-feira, 18 de fevereiro de 2013 12:47
-
Alexandre, desede já agradeço sua atenção. Então não seria prudente fazer o shirink sempre que formos fazer a restauração da base é isso? Então, como poderíamos melhorar estes procedimentos quando for executá-lo? Pois como muitas fezes por motivo das várias atividades que temos apenas deixamos esse script rodando e vamos continuando nossos outros trabalhos. Tem alguma forma de fazer uma verificação de um período, por exemplo e implementarmos no script? De quanto em quanto tempo podemos executar o shirink?
-
ilanocf,
Você está fazendo shrink no arquivo de log na base de teste para 15GB? Já que é base de teste, ao alterar ela para SIMPLE você pode fazer o shrink para um valor mais baixo, 50 MB por exemplo.
Veja qual o tamanho do seu arquivo de log na base de produção, caso este esteja em 15GB também, provavelmente você não está tirando backups de log. Caso esteja sendo realizado o backup de log com frequência na base de produção, seria interessante realizar o shrink do log uma vez para redução do tamanho do mesmo, assim ao restaurar o o banco na base de teste o arquivo de log não apresentaria o tamanho de 15GB e não sendo necessário o shrink do mesmo.
Abs.
-
Então, o grande problema do shrink é que ele causa um indice elevado de fragmentação no disco, de uma olhada no que o Andrei escreveu sobre o tamanho de log, pode ser util.
Vi que voce não faz na sua query, mas só para complementar o shrink do banco tambem causa a mesma fragmentação, sendo aconselhavei realizar somente em ultimo caso, e tambem seria uma solução para ganhar espaço por pouco tempo ja que o banco vai crescer novamente e reservar uma parte do espaço assim como estava antes do shrink do banco.
Alexandre Matayosi Conde Mauricio. Se esta sugestão for útil, por favor, classifique-a como útil. Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.