none
Dividir tabelas grandes

    Question

  • A um tempo eu postei a mensagem abaixo:

    Este paricionamento de tabelas para o SQL2005 é o que eu procuro?

    Ele já particiona as tabelas? Qual critério usa?

    SQL Server 2005
    Partition
    ed Tables and Indexes (segue o link)

    http://www.sqlskills.com/resources/Whitepapers/Partitioning%20in%20SQL%20Server%202005%20Beta%20II.htm#_Toc79339947

     

     

     

     

     

     

     

    ------------------------------------------- mensagem antiga >>

    Pessoal;

    Tenho tabelas no meu banco que estão cada vez ficando maiores, e esta dificil trabalhar (esta demorando muito). Qeuro dividir sem mudar nos sistemas ou nas procuderes de forma que fique transparente para todos.

    Como havia até falado antes, pensei em dividi-las, dentro do mesmo banco, onde tenho: clientes

    teria: clientes2004, clientes2005 e clientes2006

    Assim eu trabalharia apenas com os dados do ano atual.

    Porém caso eu precisasse buscar dados em outra tabela, uma view clientes seria criada (com mesmo nome da tabela original, para que não possa ter impacto nos sistemas)

    select * from clientes2004 union all select *from clientes2005.

     

    Agora como eu farei com os insert, update (teria que ser na view chamada clietnes, mas em qual tabela ela vai guardar)?  e como ficariam os relacionamentos?

     

    Alguem tem algum exemplo para me passar?

    Thursday, May 25, 2006 8:12 PM

All replies

  • quantas linhas tem essa tabela? ....  o SQL Server suporta grandes quantidades de registros em tabelas.. vc deve incluir indices. e analisar o plano de execução....  vc pode adicionar um arquivo no filegroup para que ele possa melhorar a performance.....

     

    se for o SQL Server 2005 vc pode particionar sua tabela em varios filegroups....

     

    Thursday, May 25, 2006 8:16 PM
  • Igo o particionamento usando uma view so teria logica se vc. estivesse em servidores diferentes, o que vc. pode fazer e deixar os itens mais acessados em outra tabela e controlar o acesso dela por meio de uma procedure, mais nao vai conpensar juntar em uma view nao....

     

    Abs.;

    Friday, May 26, 2006 10:07 AM
  • Em um mesmo servidor tb rola... vc pode particionar uma tabela horizontalmente colocar as tabelas em filegroups diferentes...  e depois criar uma view para retornar a a partir de um Select UNION  mas mesmo assim é valido fazer uma análise devido ao custo do union...como vc disse não compensa juntar
    Friday, May 26, 2006 11:55 AM
  • bom em filegroups separados parece bom, para aproveitar o I/O, mais o que ele nao podera e usar a view para ser um source unico para as tabelas fragmentas.

    bom tema e passivel de analise ...

    Friday, May 26, 2006 12:14 PM
  • Pessoal;

     

    Um exemplo duas dessas tabelas possuem:

    14.142.734 registros e outra 19.775.189 registros , são usadas em diversos sistemas.

    e inclusive são replicadas (por meio transacional) para outro servidor, para ser usado em mais sistemas

    Friday, May 26, 2006 12:42 PM
  • Ygorabelo ,

    Boa analise mesmo, esse problema é comum para caramba, uma boa tecnica como pessoal ja falou seria particionar se for 2005 e colocar em filegroups diferentes para contraolar o I/O , usar um disco com raid seria boa tecnica , separar em anos(2006,2005,2004) seria uma forma de particinamento mas ai teria os problemas com atualização como disse, meu conselho e tentar usar a tecnica de se forem dados novos eles são mais usados e mais importantes no banco pois é usado com mais frequencia separe tabela 2006 "Atual"  e o restante do outros em outra tabela "historico" se tiver atualização faça com que o pessoal de desenvolvimento na tela de atualização de cadastros de clientes coloque um flag se for < 2006 então ele vai na tabela "historico" se for maior "atual" e assim o mesmo para consulta, não e mais elegante e refinada das soluções mas resolve o problema, até ter uma mais robusta.

    Espero ter ajudado.

     

      

    Friday, May 26, 2006 12:43 PM
  • Certo, so que queria fazer sem ter impacto para os desenvolvedores.

    obs.:

    Uso RAID 5, e SQL 2000

    Friday, May 26, 2006 1:16 PM
  • Cara se vc. tem um RAID 5 e todos os discos estao no RAID nao adianta colocar em file groups diferentes...., eu deixaria tudo em uma tabela so, ou ate analisaria os dados de historico ( que nao seriam alterados e nem deletados ) em uma segunda tabela, ai usando uma procedure com union all para juntar o antigo + novo. uma rotina ( job ) que moveria os dados do novo para o antigo segundo alguns criterios.

     

    veja ai qualquer coisa retorne.

    Friday, May 26, 2006 1:41 PM
  • Isso mesmo Marcelo, essa seria a ideia.

    Agora queria fazer uma view "inteligente" onde ela so usasse o unionall quando for procurar clientes por exemplo que nao estao na tabela de 2006 (que é a atual).

     

    e colcoando o nome: clientes na view, todas as procedures e sistemas não precisariam ser mudados...

     

    agora como faria todo resto? update:? insert? os relacionamentos (acho que isso so deve ser criado para as tabelas antigas ne)

     

    ahh tenho tabelinha com:

    86.863.191  também

    Friday, May 26, 2006 2:05 PM
  • Vc pode fazer um UPDATE.. INSERT... DELETE na view utilizando uma view do tipo INSTEAD OF... a ação que dispara a trigger não ocorre...

    Mas mesmo assim acho que vc deve avaliar os seus discos.... porque como eu disse o SQL Server suporta grandes quantidades de registros.... pode ser que seus discos estão com muita utilização e estão em concorrencia com outros processos.... tente colocar essas tabelas em uma FILEGROUP separado das outras tabelas do SQL Server... porque eu acho que criar um view para resolver seu problema vc vai ter muito impacto no aplicativo....

    Friday, May 26, 2006 2:20 PM
  • André;

    Eu entendo pouco, mas como eu disse estou usando RAID5, então logo ele usa todo o meu array de risco não é? então ele grava um pouco em cada (seria +/- assim). Se eu colocar um tabela dessas em outro filegroup vai resolver? e se devo, qual critério que devo adotar? outra partição para receber esses filegroups?

    Friday, May 26, 2006 5:12 PM
  • Ygo  se vc colocar a tabela em outro filegroup pode ser feito sim... mas os arquivos do filegroup não devem estar no mesmo RAID5...  porque se não esta em concorrencia de novo...

     

    Friday, May 26, 2006 5:48 PM
  • Pessoal;

    Este paricionamento de tabelas para o SQL2005 é o que eu procuro?

    Ele já particiona as tabelas? Qual critério usa?

    SQL Server 2005
    Partition
    ed Tables and Indexes (segue o link)

    http://www.sqlskills.com/resources/Whitepapers/Partitioning%20in%20SQL%20Server%202005%20Beta%20II.htm#_Toc79339947

     

    Thursday, June 29, 2006 2:06 PM