none
Manutenção das bases de dados em ambiente com Mirror RRS feed

  • Pergunta

  • Pessoal, tenho a seguinte dúvida: qual seria a manutenção adequada pra as bases de dados das instâncias que participam da Mirronring?

    Essas manutenções se referem a: atualização de estatísticas, reorganização de índices, recriação de índices ,backup full/log e manutenção arquivo log.

     Agradeço desde já!

     
    segunda-feira, 18 de maio de 2015 18:46

Respostas

  • SELECT dbschemas.[name] as 'Schema',
    dbtables.[name] as 'Table',
    dbindexes.[name] as 'Index',
    indexstats.avg_fragmentation_in_percent,
    indexstats.page_count
    FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
    INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
    INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
    INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
    AND indexstats.index_id = dbindexes.index_id
    ORDER BY indexstats.avg_fragmentation_in_percent desc

    Essa query retorna a quantidade de pagina que um indice tem, eu armazeno essa quantidade em uma variavel, conforme ela vai sendo executada ele vai somando, quando ela chega a um valor determinado eu rodo um backup de log para limpar o log e não deixar o arquivo crescer...

    Agora é só voce desenvolver a lógica.


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    quinta-feira, 21 de maio de 2015 01:54
  • Jeferson o SQL Server faz o processo de checkpoint de tanto em tanto tempo, esse processo consiste em pegar os arquivos do log e gravar no arquivo de dados, depois disso se você executar um bkp de log ele vai limpar o seu arquivo de log.

    Então vc esta fazendo o rebuild de um índice que se exemplificando tenha 10 GB, o seu arquivo de log tem 50 GB, ao finalizar esse rebuild e você executar um backup de log, ele vai liberar os 10 GB no seu arquivo de log.

    Lembrando que o espaço do arquivo de log (.ldf) ele é reservado, então pode ser que ele esteja ocupando 50 Gb no disco, mas dentro dele tenha tenha apenas 5 GB em uso.


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    sexta-feira, 22 de maio de 2015 13:32
  • Pode ser.

    Acho que assim vc consegue minimizar os riscos de dar log full.

    Mas sugiro você sempre acompanhar os dados são dinâmicos e podem crescer. 


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    segunda-feira, 25 de maio de 2015 16:11

Todas as Respostas

  • Jerfeson,

    Sinceramente este tipo de manutenção deve ser muito bem analisada e pensada, pois poderá impactar totalmente na maneira que o SQL Server vai trabalhar!!!

    Você deseja aplicar este tipo de manutenção em qual banco de dados? No Source ou nos Mirrors?


    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]

    terça-feira, 19 de maio de 2015 15:40
    Moderador
  • Junior,

    É possivel fazer manutenção em bases que estão no mirror? 

    Eu acredito que não pois as bases ficam com status restoring, então todo o plano de manutenção deve ser aplicado nas bases que está ativa.

    Com o AlwaysOn é possivel fazer o plano de manutenção nas bases que estão nó passivo.

    Se eu estiver errado por favor me corrija. 


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    terça-feira, 19 de maio de 2015 17:07
  • Tiago,

    Você esta certo, por isso eu questionei Jerfeson, eu gostaria de entender o que ele esta querendo fazer.

    No caso do AlwaysOn é possível sim aplicar, já no Mirror somente no banco de dados que esta fornecendo os dados.


    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]

    terça-feira, 19 de maio de 2015 17:50
    Moderador
  • Agradeço a atenção caros colegas.

    Na verdade minha dúvida seria de aplicar a manutenção de rotina nas bases, sendo que na base ativa seria atualização de estatísticas, reorganização de índices, recriação de índices ,backup full/log e manutenção arquivo log e na base passiva a manutenção do crescimento do arquivo de log. Lembrando que a base passiva estará recebendo da base ativa as transações e com isso haverá crescimento de arquivo de log, principalmente nos momentos de manutenção de atualização das estatísticas, recriação e reorganização de índices.

    Costumo executar o comando abaixo após a conclusão da rotina de recriação/reorganização de índices e atualização de estatísticas, no qual na base ativa nem na passiva do mirror não é possível.

    USE master
    GO
    ALTER DATABASE nome_do_banco SET RECOVERY SIMPLE 
    GO
    USE nome_do_banco
    GO
    CHECKPOINT
    GO
    DBCC SHRINKFILE (nome_lógico_do_log,0) 
    GO
    ALTER DATABASE nome_do_banco SET RECOVERY FULL 
    GO


    terça-feira, 19 de maio de 2015 19:02
  • Entao Jeferson tudo vc faz na base ativa, primeiro para vc configurar o mirror obrigatoriamente a sua base tem que estar com o recovery model full, a manutenção do log vc tb não consegue diminuir pois ele o log do mirror é o mesma da sua base de produção.

    Quanto a crescimento do log na base de mirror ela nao cresce tanto pois os dados são comitados no arquivo de de dados do banco.

    Não sei se fui claro.


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    terça-feira, 19 de maio de 2015 19:06
  • Foi claro sim grande Tiago.

    O meu problema é mesmo com a questão do crescimento do arquivo log, pois já avaliei a questões de realizações de backups full e log intercalados. Sabemos que a execução da manutenção de atualização de estatísticas, recriação/reorganização dos índices o arquivo de log cresce consideravelmente e por conta disso necessito executar a manutenção para o tamanho inicial configurado. O crescimento do arquivo de log de meu ambiente normalmente configuro com tamanho inicial de 10% do arquivo de data do banco de dados.

    Só lembrando que a versão do meu SQL Server é o 2008, no qual não tem ainda a técnica de alta disponibilidade Alwayson implementada, sendo um features da versão 2012.

     

    terça-feira, 19 de maio de 2015 19:56
  • Entao, no meu caso fiz uma rotina que ao final de cada índice que é realizado o rebuild ele soma a quantidade de pagina, quando essa quantidade de pagina chega a 2000000 de páginas ele roda um bkp de log, assim eu consigo garantir que o o arquivo de log vá crescer muito.

    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    terça-feira, 19 de maio de 2015 20:09
  • Desculpa Tiago, mas não entendi. Como seria isso??
    quarta-feira, 20 de maio de 2015 23:01
  • SELECT dbschemas.[name] as 'Schema',
    dbtables.[name] as 'Table',
    dbindexes.[name] as 'Index',
    indexstats.avg_fragmentation_in_percent,
    indexstats.page_count
    FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
    INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
    INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
    INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
    AND indexstats.index_id = dbindexes.index_id
    ORDER BY indexstats.avg_fragmentation_in_percent desc

    Essa query retorna a quantidade de pagina que um indice tem, eu armazeno essa quantidade em uma variavel, conforme ela vai sendo executada ele vai somando, quando ela chega a um valor determinado eu rodo um backup de log para limpar o log e não deixar o arquivo crescer...

    Agora é só voce desenvolver a lógica.


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    quinta-feira, 21 de maio de 2015 01:54
  • E se faz necessário, sendo que tenho uma rotina de backup de log com intervalo de 10 em 10 minutos?

    O lance do crescimento do log está relacionado apenas na execução das rotinas de manutenção do banco de dados. A definição que fiz pra o crescimento do log em horário de expediente produtivo tem sido suficiente. Em horário de produção ainda não estourou o limite do size atual, no qual roda com o mesmo valor fixo já algum tempo. O tamanho inicial definido só se estoura quando é executado as rotinas de atualização de estatísticas, recriação e reorganização de índices.

    Implementando o mirroring no ambiente e o mesmo não me permitindo realizar a manutenção no arquivo de log usando a instrução sugerir acima o arquivo ldf, o mesmo crescerá até concluir a execução das rotinas e pode comprometer o espaço disponibilizado em disco.


    sexta-feira, 22 de maio de 2015 13:21
  • Jeferson o SQL Server faz o processo de checkpoint de tanto em tanto tempo, esse processo consiste em pegar os arquivos do log e gravar no arquivo de dados, depois disso se você executar um bkp de log ele vai limpar o seu arquivo de log.

    Então vc esta fazendo o rebuild de um índice que se exemplificando tenha 10 GB, o seu arquivo de log tem 50 GB, ao finalizar esse rebuild e você executar um backup de log, ele vai liberar os 10 GB no seu arquivo de log.

    Lembrando que o espaço do arquivo de log (.ldf) ele é reservado, então pode ser que ele esteja ocupando 50 Gb no disco, mas dentro dele tenha tenha apenas 5 GB em uso.


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    sexta-feira, 22 de maio de 2015 13:32
  • Justamente esse o conceito.

    Está me dizendo pra colocar em meu planejamento de manutenção do arquivo de log uma rotina de backup de log imediato pra esvaziar o que foi consumo no arquivo .ldf pelas execuções de atualização das estatísticas, recriação e reorganização dos índices?

    Bem, pensei então que seria necessário evidenciar quantos GB é preciso aumentar o arquivo de log para que possa suportar a execução das operações sem superar seu limite, ou seja, se tenho atualmente 50 GB de tamanho no arquivo log e com a execução das rotinas o mesmo cresce pra 80 GB penso em ajustar o tamanho do arquivo para 80 GB + 5 ou 10% desse valor, no qual seria talvez o suficiente para condicionar as transações do dia do app e mais os da rotinas de manutenção, se esvaziando posteriormente os 80 GB do arquivo de log no backup de log.

    Assim também evitaria ficar recebendo alerta de ocupação acima de 80% de meu arquivo de log, além de manter o crescimento de meu arquivo controlado.

    Correto caro colega Tiago? Confere?

    Agradeço a atenção. 


    domingo, 24 de maio de 2015 13:41
  • Pode ser.

    Acho que assim vc consegue minimizar os riscos de dar log full.

    Mas sugiro você sempre acompanhar os dados são dinâmicos e podem crescer. 


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    segunda-feira, 25 de maio de 2015 16:11
  • Beleza caro Tiago. 

    Ainda estou com algumas dúvidas, porém se for explaná-las pode fugir do assunto principal do titulo da thread. Respeitando as normas do fórum vou abrir uma nova thread pra discutir com a galera.

    Obrigado à todos.

    terça-feira, 2 de junho de 2015 20:29