Sobre o backup e a restauração de bases, estes procedimentos estão corretos?

Question

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 PROCESSO

Grato pela atenção de todos,

Ilano

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.