none
Backup em database mirroring RRS feed

  • Pergunta

  • Boa tarde,

    Eu configurei o database mirroring para funcionar com meus bds. Está tudo funcionando perfeitamente.

    Mas, surgiu uma dúvida, quando eu faço o backup, por scripts antigos era feita uma manutenção através do DBCC conforme scripts abaixo:

    DUMP TRANSACTION SENIOR_VetorH WITH NO_LOG
    ALTER DATABASE SENIOR_VetorH SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    DBCC CHECKDB ('SENIOR_VetorH', REPAIR_REBUILD)
    ALTER DATABASE SENIOR_VetorH  SET MULTI_USER WITH ROLLBACK IMMEDIATE
    DBCC CHECKCATALOG

    Eles funcionavam no SQL 2005, mas agora rodando o SQL 2014, alguns erros ocorrem. Li algo a respeito onde informam que não se usa mais o DUMP TRANSACTION e sim o shrink no sql 2014, então eu usei estes em um servidor sem o mirroring e funcionou usando o comando acima sem o dump transaction e o shrink abaixo.

    ALTER DATABASE SGONET_Producao SET RECOVERY SIMPLE;
    GO
    CHECKPOINT;
    GO
    DBCC SHRINKFILE ('SGONet_Producao_log', 10);
    GO
    ALTER DATABASE SGONET_Producao SET RECOVERY FULL;
    GO

    Porém, agora configurado o database mirroring, ele não permite que seja feito o comando set recovery simple e full, e dá uma erro 1486. Pergunta: é extremamente necessário rodar o dbcc e o shrink no log para efetuar o backup database, ou posso manter somente o backup e caso dê o erro eu efetuar estes processos manualmente após quebrar o mirroring?

    Alguém pode me ajudar?

    Grato,

    Marcelo Varga


    marcelo_varga

    segunda-feira, 17 de agosto de 2015 19:38

Respostas

  • Marcelo boa tarde, 

    Sim você pode usar o backup dessa forma. Em questão dos dbcc checkdb é uma rotina a parte.

    o fato de você realizar um alter database base set single_user with rollback immediate você está cortando todas as conexões existentes e fazendo com que as elas façam rollback.

    Eu revisaria suas rotinas, e como mencionei anteriormente, DBCC CHECKDB no ambiente que adiministro eu executo ele em outro ambiente, um ambiente onde faço refresh semanalmente. Não quero levar esse custo para o ambiente de produção, muito menos alterar as bases fazendo com que eles executem o rollback forçado.

    abraço,


    Vinícius Kleber

    quinta-feira, 20 de agosto de 2015 20:18

Todas as Respostas

  • Marcelo boa noite, 

    Um dos pré-reqs para você montar um mirror é ter o recovery model como full, por isso seu script está dando erro.

    https://msdn.microsoft.com/en-us/library/ms189053.aspx#Recommendations

    Recomendações;

    The database must use the full recovery model.

    Outro ponto, não há necessidade de você realizar um shrink no log, para fazer backup. Você pode realizar os backups sem problemas.

    Vi que no seus comandos dbccs vocês colocam a base em single user, depois rodam o dbcc checkdb, depois voltam a base multi_user. Por que não realizar essa mesma rotina, em outro ambiente ?




    Vinícius Kleber


    segunda-feira, 17 de agosto de 2015 22:49
  • Bom dia, Vinicius.

    As minhas bases estão em modo recovery full. O erro se apresenta somente ao rodar o DBCC quando alterna-se para o single mode

    ALTER DATABASE SENIOR_VetorH SET SINGLE_USER WITH ROLLBACK IMMEDIATE

    Eu não preciso alterar para efetuar o DBCC?

    Posso rodar o DBCC sem alterar o database?


    marcelo_varga


    terça-feira, 18 de agosto de 2015 11:13
  • Marcelo,

    Vamos por partes, o comando DUMP foi mantido pela Microsoft até a versão 2005 por questões de compatilidade e desde então foi removido em versões posteriores conforme informa o link:

    https://technet.microsoft.com/en-us/library/ms187315(v=sql.90).aspx

    Outro ponto importante que você deve analisar de forma coerente é o uso do Database Mirroring, funcionalidade que não estará mais presente nas futuras versões do SQL Server, e possivelmente não estará mais presente na versão 2016.

    Desde a versão 2012 temos uma nova funcionalidade para Alta Disponibilidade que é o AlwaysOn Availabity Group, conceito que foi implementado no SQL Server para trabalhar em conjunto com o serviço de Cluster do Windows e desde então se tornou a principal ferramenta de Alta Disponibilidade relacionando ao SQL Server:

    https://msdn.microsoft.com/en-us/library/hh510230.aspx

    https://msdn.microsoft.com/en-us/library/ff877884.aspx


    Pedro Antonio Galvao Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quarta-feira, 19 de agosto de 2015 17:53
    Moderador
  • Bom dia, Junior Galvão.

    Então, eu habilitei me meus servidores o database mirroring, pois, eu desconhecia o AlwaysOn. E, acredito que deverá ficar para uma próxima. Mas, eu queira saber se eu posso fazer o comando de backup normalmente, sem rodar os DBCCs da vida.

    Fazendo o backup direto através de jobs.

    BACKUP DATABASE [BD_PRODUCAO] TO  DISK = 'F:\BACKUP\Backup_BD_PRODUCAO.bak' 
    WITH INIT,  NAME = 'BD_PRODUCAO', STATS = 10


    marcelo_varga

    quinta-feira, 20 de agosto de 2015 12:00
  • Marcelo boa tarde, 

    Sim você pode usar o backup dessa forma. Em questão dos dbcc checkdb é uma rotina a parte.

    o fato de você realizar um alter database base set single_user with rollback immediate você está cortando todas as conexões existentes e fazendo com que as elas façam rollback.

    Eu revisaria suas rotinas, e como mencionei anteriormente, DBCC CHECKDB no ambiente que adiministro eu executo ele em outro ambiente, um ambiente onde faço refresh semanalmente. Não quero levar esse custo para o ambiente de produção, muito menos alterar as bases fazendo com que eles executem o rollback forçado.

    abraço,


    Vinícius Kleber

    quinta-feira, 20 de agosto de 2015 20:18