none
Dividir fisicamente um banco de 290 GB em varios bancos menores RRS feed

  • Pergunta

  • Olá galera!!!

    Gostaria de algumas opiniões...

    Seguinte...

    Tenho uma base de dados de 290 GB.

    Hoje, a base possui 7 filegroup e está em MIRROR.

    Não podemos fazer um processo de fechamento da base (deletar dados antigos), pois segundo a regra de negocio a base precisa ter os dados dos ultimos 6 anos...

    A Situação seria o seguinte...

    A empresa solicitou um estudo para dividir a base fisicamente em pequenos bancos... Talvez uma base por ano, ou seja, 6 bases.

    Alguem já passou por uma situação assim ou teria alguma dica para este tipo de situação??

    Abraços a todos!!!
    terça-feira, 2 de fevereiro de 2010 12:27

Respostas

  • Leonardo,

    Certo, você utilizou a sp_spaceused e obter o valor total do seu banco de dados!!!!

    Se você analisar o tamanho dos seus arquivos de dados esta chegando a 90 GBs e o Log em 102.

    Você possui alguma rotina de backup neste banco de dados? A valor de espaço não alocado é pequeno, a configuração da taxa de crescimento do seu banco de dados esta definida de que forma?

    Talvez deveríamos pensar em analisar as taxas de fragmentação de dados, pois acredito que esta base esta mal distribuída em relação a sua alocação.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:14
    terça-feira, 2 de fevereiro de 2010 16:04
    Moderador
  • Oi Anderson.

    O particionamento das tabelas NÃO vai te trazer nenhum ganho em termos de tamanho do banco, pois os dados são os mesmos. Caso exista fragmentação internas nas páginas você poderá diminuir um pouco o tamanho, mas normalmente nada muito drástico.

    Você deverá escolher como é a sua função de particionamento de acordo com o seu negócio, mas supondo que você consiga particionar por data, poderá colocar os dados mais antigos em filegroups específicos e, quando for necessário fazer um restore, você pode trazer primeiramente o FG primário e o FG dos dados atuais, colocando o sistema online e continuando a recuperação dos outros filegroups (com dados antigos e não vitais) aos poucos.

    Como estamos falando do SQL Server 2008 e seu banco está crescendo, eu também pensaria em utilizar o recurso de compressão de dados, mas isso não excluí o particionamento. Não se esqueça de manter dados e índices alinhados também. Se você estiver indexando demais seu banco, também pode diminuí-lo vendo quais índices são realmente úteis e removendo aqueles desnecessários.

    Aconselho os artigos:
    http://msdn.microsoft.com/en-us/library/ms345146(SQL.90).aspx
    http://msdn.microsoft.com/en-us/library/dd578580.aspx

    Sobre o mirroring, me parece estranho o failover estar demorando, pois seu banco de dados de espelho deveria estar praticamente pronto do outro lado, recebendo apenas logs do primário. Têm certeza que o problema está no tamanho do banco?

    Espero ter ajudado.

    Abraços,
    Luti


    luti
    • Sugerido como Resposta Fausto.Branco terça-feira, 9 de fevereiro de 2010 13:05
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:14
    terça-feira, 2 de fevereiro de 2010 21:06
  • Leonardo,

    Em relação de dados destacada pelo Luciano é uma das novidades do SQL Server 2008, se você quiser saber mais sobre esta funcionalidade, a Revista SQL Magazine na Edição 68 publicou um artigo meu sobre este assunto.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:14
    quarta-feira, 3 de fevereiro de 2010 10:33
    Moderador
  • Leonardo,
    minhas considerações sobre sua situação

    1 - como já falaram, partição é uma boa para dividir as tabelas maiores em vários filegroups, mas o banco continuará do mesmo tamanho.

    2 - como seu log está grande, mas pouco usado eu rodaria o shrink para diminui-lo. Se ele ficar com os arquivos menores, seu tempo de backup diminuirá

    3 - separar uma única base em várias pequenas provavelmente vai adicionar complexidade ao código que acessa essa base. Isto porque hoje ela aponta para uma única base e depois que a base grande for dividida em várias bases pequenas, o código terá que sempre referenciar à base específica do ano que o usuário está precisando.

    Espero ter ajudado.


    Se a resposta resolveu sua questão ouproblema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 11:52
  • Leonardo,


    Se a implementação do Mirroring não for muito custosa para a empresa... eu acredito que executar um procedimento para diminuir o tamanho do arquivo de log seja interessante, como o Alex falou. Após isso, seria refeito o mirroring, já com o log menor.


    Certa vez eu tive problemas com mirroring exatamente por causa do grande tamanho de log. Ao fazer isso, meu problema se resolveu.


    Outra coisa, em relação aos backups, não seria interessante rodar um FULL diariamente em um horário "fora do expediente"? Isso ajudaria na hora de um possível restore, já que o único FULL roda uma vez por semana aos domingos.




    Att,
    De Lima - MCITP SQL Server 2005/2008
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 12:02
  • Com relação ao Shirink eu acredito (me corrijam se estiver errado) que não irá resolver o problema dele, uma vez que o logfile voltará a crescer, causando mais split e consequentemente uma perda de performance.

    Com relação aos backups, acho importante saber se ocorre lentidão durante o processo, caso contrário se já é uma política que dá certo em seu ambiente talves não seja necessário mudar.
    O processo de restore citado pelo Luciano Moreira:

    "Você deverá escolher como é a sua função de particionamento de acordo com o seu negócio, mas supondo que você consiga particionar por data, poderá colocar os dados mais antigos em filegroups específicos e, quando for necessário fazer um restore, você pode trazer primeiramente o FG primário e o FG dos dados atuais, colocando o sistema online e continuando a recuperação dos outros filegroups (com dados antigos e não vitais) aos poucos."


    Ótima alternativa para disponibilizar od dados aos usuários.

    E quanto a dividir os dados em Bases diferentes concordo com o falado mais acima pelo Alex M. Bastos, somente iria gerar mais custo de administração e desenvolvimento/codificações.

    Uma vantagem poderia ocorrer ao migrar parte dos dados (dados antigos) para outro servidor e deixálos somente para leitura com Recovery Simple, etc, etc. Esta é uma solução que já apliquei e deu muito certo. Aí você pode fazer as consultas (antigas) via View com Linked Servers e a aplicação nem saberia que os dados estão em outro servidor.

    http://ricardomura.spaces.live.com
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 19:28
  • Concordo com o Ricardo!
    Todo log de transação tende a estabilizar seu tamanho de acordo com a frequência dos backups de log e perfil da aplicação. Encolhimentos e crescimento frequentes é ruim e leva a fragmentação física (e também dos VLFs).

    Outro comentário, o tempo de backup não está relacionado com o tamanho total do log, mas sim com as informações ativas do log. Basta usar o DBCC LOGINFO() para verificar quais são os VLFs ativos e seu tamanho. Um impacto que podemos ter na duração do backup de log é quando trabalhamos com recovery model bulk logged e operações minimamente logadas, mas esse é papo para outra hora.

    []s
    Luciano [Luti] Caixeta Moreira
    http://luticm.blogspot.com



    luti
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 23:35

Todas as Respostas

  • Bom dia Leonardo

    Não sei a versão do SQL Server que você está utilizando, mas se estiver utilizando a Enterprise acredito que o particionamento seja uma boa solução.



    Espero ter ajudado
    Anderson - DBA/MCP/MCTS/MCITP/MCT - Sua pergunta foi respondida ? Marque-a como tal! www.myspace.com/andersondpa
    terça-feira, 2 de fevereiro de 2010 12:29
  • Leonardo,

    O particionamento aplicado a filegroups.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    terça-feira, 2 de fevereiro de 2010 12:44
    Moderador
  • Bom dia Anderson,

    Ambiente SQL 2008 Enterprise.

    Uma pergunta... O particionamento de tabela dividi as tabelas fisicamente, mas não diminui o tamanho do banco. né?

    Com um banco de 290 GB sofremos com lentidão no momento de fazer um failover do principal para o mirror e outros processos como backup e restore.

    Não há problema com o espaço em disco... Há mais de 500 GB livre.

    terça-feira, 2 de fevereiro de 2010 12:54
  • Leonardo,

    O particionamento de tables é uma técnica para melhora de performance, organização e administração de dados, ela não se preocupa com o tamanho dos dados, muito menos com o tamanho do backup de dados.

    Quando filegroups o seu banco de dados possui?
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    terça-feira, 2 de fevereiro de 2010 13:01
    Moderador
  • Junior,

    Hoje tenho 6 filegroups:

    FG1 - 60 GB (Arquivo.mdf)
    FG2 - 8 GB (Arquivo.ndf)
    FG3 - 1 GB (Arquivo.ndf)
    FG4 - 7 GB (Arquivo.ndf)
    FG5 - 10 GB (Arquivo.ndf)
    FG6 - 4 GB (Arquivo.ndf)

    Em outra unidade eu tenho o Ldf com 102 GB.

    Acabei de rodar o sp_spaceused



    database_name                                                                                                                    database_size      unallocated space
    -------------------------------------------------------------------------------------------------------------------------------- ------------------ ------------------
    Banco                                                                                                                                   289224.13 MB       39056.66 MB

    reserved                        data               index_size         unused
    ------------------ ------------------ ------------------ ------------------
    154667480 KB       123908592 KB       30482064 KB        276824 KB

     

    terça-feira, 2 de fevereiro de 2010 13:34
  • Leonardo,

    Certo, você utilizou a sp_spaceused e obter o valor total do seu banco de dados!!!!

    Se você analisar o tamanho dos seus arquivos de dados esta chegando a 90 GBs e o Log em 102.

    Você possui alguma rotina de backup neste banco de dados? A valor de espaço não alocado é pequeno, a configuração da taxa de crescimento do seu banco de dados esta definida de que forma?

    Talvez deveríamos pensar em analisar as taxas de fragmentação de dados, pois acredito que esta base esta mal distribuída em relação a sua alocação.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:14
    terça-feira, 2 de fevereiro de 2010 16:04
    Moderador
  • Oi Anderson.

    O particionamento das tabelas NÃO vai te trazer nenhum ganho em termos de tamanho do banco, pois os dados são os mesmos. Caso exista fragmentação internas nas páginas você poderá diminuir um pouco o tamanho, mas normalmente nada muito drástico.

    Você deverá escolher como é a sua função de particionamento de acordo com o seu negócio, mas supondo que você consiga particionar por data, poderá colocar os dados mais antigos em filegroups específicos e, quando for necessário fazer um restore, você pode trazer primeiramente o FG primário e o FG dos dados atuais, colocando o sistema online e continuando a recuperação dos outros filegroups (com dados antigos e não vitais) aos poucos.

    Como estamos falando do SQL Server 2008 e seu banco está crescendo, eu também pensaria em utilizar o recurso de compressão de dados, mas isso não excluí o particionamento. Não se esqueça de manter dados e índices alinhados também. Se você estiver indexando demais seu banco, também pode diminuí-lo vendo quais índices são realmente úteis e removendo aqueles desnecessários.

    Aconselho os artigos:
    http://msdn.microsoft.com/en-us/library/ms345146(SQL.90).aspx
    http://msdn.microsoft.com/en-us/library/dd578580.aspx

    Sobre o mirroring, me parece estranho o failover estar demorando, pois seu banco de dados de espelho deveria estar praticamente pronto do outro lado, recebendo apenas logs do primário. Têm certeza que o problema está no tamanho do banco?

    Espero ter ajudado.

    Abraços,
    Luti


    luti
    • Sugerido como Resposta Fausto.Branco terça-feira, 9 de fevereiro de 2010 13:05
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:14
    terça-feira, 2 de fevereiro de 2010 21:06
  • Leonardo,

    Em relação de dados destacada pelo Luciano é uma das novidades do SQL Server 2008, se você quiser saber mais sobre esta funcionalidade, a Revista SQL Magazine na Edição 68 publicou um artigo meu sobre este assunto.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:14
    quarta-feira, 3 de fevereiro de 2010 10:33
    Moderador
  • Junior,

    Desculpe a demora, fiquei ausente nos ultimos dias.

    Hoje, há o seguinte processo de backup:

    Todo Domingo 23h - FULL
    Todos os dias 4h - DIFERENCIAL
    Todos os dias a cada 30 minutos - LOG

    Obs: Todos os backups utilizam a opção Compress Backup


    Taxa de crescimento

    FG1 - 60 GB (Arquivo.mdf) - crescimento de 300 mb
    FG2 - 8 GB (Arquivo.ndf) - crescimento de 300 mb
    FG3 - 1 GB (Arquivo.ndf) - crescimento de 300 mb
    FG4 - 7 GB (Arquivo.ndf) - crescimento de 300 mb
    FG5 - 10 GB (Arquivo.ndf) - crescimento de 300 mb
    FG6 - 4 GB (Arquivo.ndf) - crescimento de 1000 mb
    Ldf com 102 GB - Ldf com 30 porcent

    Acabei de gerar um relatorio de espaço usado e percebi que o meu log de 102 GB, possui 2% de uso e 98% de não usado.

    Vou analisar as taxas de fragmentação de daodos.



    terça-feira, 9 de fevereiro de 2010 11:37
  • Leonardo,
    minhas considerações sobre sua situação

    1 - como já falaram, partição é uma boa para dividir as tabelas maiores em vários filegroups, mas o banco continuará do mesmo tamanho.

    2 - como seu log está grande, mas pouco usado eu rodaria o shrink para diminui-lo. Se ele ficar com os arquivos menores, seu tempo de backup diminuirá

    3 - separar uma única base em várias pequenas provavelmente vai adicionar complexidade ao código que acessa essa base. Isto porque hoje ela aponta para uma única base e depois que a base grande for dividida em várias bases pequenas, o código terá que sempre referenciar à base específica do ano que o usuário está precisando.

    Espero ter ajudado.


    Se a resposta resolveu sua questão ouproblema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 11:52
  • Leonardo,


    Se a implementação do Mirroring não for muito custosa para a empresa... eu acredito que executar um procedimento para diminuir o tamanho do arquivo de log seja interessante, como o Alex falou. Após isso, seria refeito o mirroring, já com o log menor.


    Certa vez eu tive problemas com mirroring exatamente por causa do grande tamanho de log. Ao fazer isso, meu problema se resolveu.


    Outra coisa, em relação aos backups, não seria interessante rodar um FULL diariamente em um horário "fora do expediente"? Isso ajudaria na hora de um possível restore, já que o único FULL roda uma vez por semana aos domingos.




    Att,
    De Lima - MCITP SQL Server 2005/2008
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 12:02
  • Com relação ao Shirink eu acredito (me corrijam se estiver errado) que não irá resolver o problema dele, uma vez que o logfile voltará a crescer, causando mais split e consequentemente uma perda de performance.

    Com relação aos backups, acho importante saber se ocorre lentidão durante o processo, caso contrário se já é uma política que dá certo em seu ambiente talves não seja necessário mudar.
    O processo de restore citado pelo Luciano Moreira:

    "Você deverá escolher como é a sua função de particionamento de acordo com o seu negócio, mas supondo que você consiga particionar por data, poderá colocar os dados mais antigos em filegroups específicos e, quando for necessário fazer um restore, você pode trazer primeiramente o FG primário e o FG dos dados atuais, colocando o sistema online e continuando a recuperação dos outros filegroups (com dados antigos e não vitais) aos poucos."


    Ótima alternativa para disponibilizar od dados aos usuários.

    E quanto a dividir os dados em Bases diferentes concordo com o falado mais acima pelo Alex M. Bastos, somente iria gerar mais custo de administração e desenvolvimento/codificações.

    Uma vantagem poderia ocorrer ao migrar parte dos dados (dados antigos) para outro servidor e deixálos somente para leitura com Recovery Simple, etc, etc. Esta é uma solução que já apliquei e deu muito certo. Aí você pode fazer as consultas (antigas) via View com Linked Servers e a aplicação nem saberia que os dados estão em outro servidor.

    http://ricardomura.spaces.live.com
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 19:28
  • Concordo com o Ricardo!
    Todo log de transação tende a estabilizar seu tamanho de acordo com a frequência dos backups de log e perfil da aplicação. Encolhimentos e crescimento frequentes é ruim e leva a fragmentação física (e também dos VLFs).

    Outro comentário, o tempo de backup não está relacionado com o tamanho total do log, mas sim com as informações ativas do log. Basta usar o DBCC LOGINFO() para verificar quais são os VLFs ativos e seu tamanho. Um impacto que podemos ter na duração do backup de log é quando trabalhamos com recovery model bulk logged e operações minimamente logadas, mas esse é papo para outra hora.

    []s
    Luciano [Luti] Caixeta Moreira
    http://luticm.blogspot.com



    luti
    • Marcado como Resposta leonardo candido sexta-feira, 19 de fevereiro de 2010 11:13
    terça-feira, 9 de fevereiro de 2010 23:35