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

  • 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 PROCESSO

    Grato pela atenção de todos,

    Ilano


    • Editado ilanocf sexta-feira, 8 de fevereiro de 2013 14:59
    sexta-feira, 8 de fevereiro de 2013 14:56

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
    sexta-feira, 8 de fevereiro de 2013 15:11

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
    sexta-feira, 8 de fevereiro de 2013 15:11
  • 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?
    sexta-feira, 8 de fevereiro de 2013 15:52
  • 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.

    sexta-feira, 8 de fevereiro de 2013 17:01
  • 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.

    sexta-feira, 8 de fevereiro de 2013 18:52