tabelas do SQL Server 2000

Question

Atualmente, temos um banco de dados do SQL Server 2000 com uma tabela contendo dados para vários usuários. Os dados são codificados por memberid, que é um campo inteiro. A tabela tem um índice clusterizado em memberid.

A tabela agora é de cerca de 200 milhões de linhas. Indexação e manutenção estão se tornando problemas. Estamos debatendo a divisão da tabela em uma tabela por modelo de usuário.

Isso implicaria que acabaríamos com um número muito grande de tabelas potencialmente até 2.147.483.647, considerando apenas valores positivos.

Minhas perguntas:

1. Alguém tem alguma experiência com uma instalação do SQL Server (2000/2005) com milhões de tabelas?

2. Quais são as implicações dessa arquitetura com relação à manutenção e ao acesso usando o Query Analyzer, o Enterprise Manager etc.

3. Quais são as implicações para ter um número tão grande de índices em uma instância de banco de dados?

Todos os comentários são bem-vindos.

Obrigado

Edit: Eu não concordei com esta questão sendo migrada para Serverfault. Esta é uma questão relacionada à programação.

    

Answer 1

Algumas reflexões aqui:

1) Não faça isso. A sério. Milhões de tabelas seriam um pesadelo e provavelmente causariam muito mais problemas do que soluções.

2) Se você realmente quer dividir a tabela em várias tabelas, você não precisa usar tantas. Dependendo do seu hardware, eu esperaria que 50 milhões de linhas não fossem problema, então você poderia dividir seus dados em 4 tabelas.

3) O que eu faria se fosse possível, seria atualizar para o SQL Server 2005 ou 2008 e usar o particionamento de tabela. Isso permitiria subdividir seus dados em uma tabela. Não é uma solução perfeita, mas muito melhor que milhões de tabelas.

Para responder às suas perguntas específicas, eu diria que é improvável que o SQL Server possa lidar com tantas tabelas em uma instância e se tiver uma tabela por registro faria com que o Query Analyzer, etc., fosse muito inútil.

Adição rápida: do site da Microsoft:

Os objetos de banco de dados incluem todas as tabelas, exibições, procedimentos armazenados, procedimentos armazenados estendidos, gatilhos, regras, padrões e restrições. A soma do número de todos esses objetos em um banco de dados não pode exceder 2.147.483.647.

link

É incrível que o número seja EXATAMENTE o que você especificou ... Hmmm ...

    

Answer 2

A manutenção do índice deve ser feita com base na fragmentação existente, não cegamente. Com uma coluna IDENTITY em cluster, você não deve ter muito com o que se preocupar. O script defrag do SQL Fool ajudará.

200 milhões de linhas não é muito e ainda não vale a pena particionar IMHO por causa da sobrecarga de consulta, muitos nomes de tabela que exigem SQL dinâmico etc. A menos que você tenha uma pequena janela de manutenção, talvez

Temos cerca de 6 milhões de linhas por dia INSERIDAS, FWIW em uma tabela.

A dor é pior do que o ganho com base na informação que você deu.

    

Answer 3

A divisão nessas várias tabelas é um pesadelo e não é recomendada. Entre outras complicações, pense na complexidade necessária para adicionar um novo usuário - você precisa criar dinamicamente uma nova tabela?

A resposta é simplesmente uma melhor indexação, projetada especificamente em torno das consultas que você está usando. Como você não detalhou essas consultas, não posso fornecer recomendações específicas.

Em geral, porém, suportamos muitos bancos de dados com tabelas tão grandes quanto isso, e sim, pode ser uma dor, mas é definitivamente possível.

Se você fizer decidir lá para implementar partições, use uma maneira diferente de dividir os dados (talvez dados atuais versus dados antigos) e um número razoavelmente pequeno de partições. Lembre-se de que, se você fizer isso "manualmente" (em vez de usar o recurso de particionamento do SQL 2005+), todas as consultas nessas tabelas particionadas provavelmente precisarão ser reprojetadas.

Editar: em uma resposta específica a uma parte da sua pergunta, sim, o Enterprise Manager / Query Analyzer pode começar a fazer coisas muito ruins quando você tiver um grande número de tabelas. Tivemos um dbs mal projetado com milhares de tabelas e você não pode nem mesmo expandir a pasta "Tabelas" na visualização em árvore sem esperar um longo tempo para listar todas elas.

    

Answer 4

Um por usuário parece um pouco exagerado e difícil na sua base de código. Você teria mais ou menos que usar SQL dinâmico em qualquer proc armazenado que usasse essas tabelas, o que definitivamente complica sua vida e futuros desenvolvimentos e testes. (Eu falo por experiência - nós costumávamos ter algumas tabelas muito complicadas que geramos diariamente; todas as interações com essas tabelas eram SQL dinâmicas.)

Não conhecendo os requisitos dos aplicativos que usam esses dados, você poderia avaliar os dados antigos em um arquivo ou tabela / tabela de histórico?

Para o SQL 2k5 / 2k8, você pode usar tabelas particionadas que podem ajudar também e abstrair o conteúdo de várias tabelas de suas consultas e aplicativos. Existem algumas armadilhas com tabelas particionadas, mas elas podem funcionar para você aqui.

Com esse tipo de volume, você terá que fazer alguns protótipos e benchmarking específicos, já que não há uma resposta única para todos.

    

Answer 5

Parece que o particionamento de tabelas é o caminho a percorrer. Você precisará de pelo menos o SQL Server 2005.

Aqui está um bom artigo sobre o assunto para você começar Kimberly Tripp MSDN Artigo

    

Answer 6

Gostaria de revisitar o design.

Você diz que ele está agrupado em memberid, mas isso pode causar divisões de página (e fragmentação) quando os dados são adicionados. É melhor agrupar em uma identidade substituta crescente (e ter um índice exclusivo, talvez até uma chave primária, em uma chave comercial que inclua o memberid).

Como alternativa, e mesmo se não estiver em cluster, você deve ter um índice exclusivo em memberid e a parte exclusiva das colunas restantes, já que parece que você tem várias linhas por membro. É improvável que um índice sobre apenas membros seja abrangido.