mesa maciça no SQL 2005 banco de dados precisa de desempenho melhor!

Question

Eu estou trabalhando em uma aplicação web orientados a dados que utiliza um banco de dados SQL 2005 (edição standard).

Uma das tabelas é bastante grande (8 milhões + linhas grande, com cerca de 30 colunas). O tamanho da tabela, obviamente, afeta o desempenho do site, que é a seleção de itens da tabela através de procedimentos armazenados. A tabela é indexada mas ainda assim o desempenho é fraco devido à enorme quantidade de linhas na tabela - isto é parte do problema - a tabela é como ler igualmente actualizado, por isso não podemos adicionar índices / remover sem fazer um dos as operações pior.

O objetivo que eu tenho aqui é aumentar o desempenho ao selecionar itens da tabela. A tabela tem dados de correntes 'e / dados mal tocou antigos. A solução mais podemos pensar nesta fase é separar a tabela em 2, ou seja, um para itens antigos (antes de uma determinada data, digamos 1 Jan 2005) e um para itens mais recentes (igual a ou antes de 01 de janeiro de 2005) .

Sabemos de coisas como distribuídas particionados Views - mas todas essas funções exigem Enterprise Edition, que o cliente não vai comprar (e não, jogando hardware para isso não vai acontecer, quer)

.

Answer 1

Você sempre pode rolar o seu próprio "particionamento pobre homem / DPV", mesmo se ele não cheira como o caminho certo para fazê-lo. Esta é apenas uma ampla abordagem conceitual:

1. Criar uma nova tabela para os dados do ano corrente - mesma estrutura, os mesmos índices. Ajuste o procedimento armazenado que escreve para o principal, grande mesa de escrever para ambas as tabelas (apenas temporariamente). Eu recomendo fazer a lógica no procedimento de exemplo armazenado se CURRENT_TIMESTAMP> = '[alguma data inteiro sem tempo]' - isto irá tornar mais fácil para aterrar os dados nesta tabela, que é anterior à mudança para o procedimento que começa registrando lá.

2. Criar uma nova tabela para cada ano em sua história usando SELECT INTO da tabela principal. Você pode fazer isso em um banco de dados diferente no mesmo exemplo, para evitar a sobrecarga no banco de dados atual. Os dados históricos não vai mudar Presumo, portanto, neste outro banco de dados você pode até mesmo torná-lo somente leitura quando é feito (o que irá melhorar dramaticamente o desempenho de leitura).

3. Uma vez que você tem uma cópia de toda a tabela, você pode criar visualizações que fazem referência apenas o ano em curso, uma outra visão que as referências 2005 para o ano em curso (usando UNION ALL entre a tabela atual e os do outro banco de dados que são> = 2005), e outro que referências todos os três conjuntos de mesas (aqueles mencionados, e as tabelas que pré-data de 2005). Claro que você pode quebrar este ainda mais, mas eu só queria manter o conceito mínimo.

4. Mude seus procedimentos armazenados que lêem os dados sejam "mais inteligentes" - se o período solicitado quedas dentro do ano civil em curso, use a menor ideia de que só é local; se o período for> = 2005, em seguida, usar o segundo ponto de vista, então usar a terceira visão. Você pode seguir a lógica semelhante com procedimentos armazenados que escreve, se você está fazendo mais do que apenas a inserção de novos dados que é relevante apenas para o ano em curso.

5. Neste ponto, você deve ser capaz de parar a inserção na tabela maciça e, uma vez que tudo está provado que estar trabalhando, soltá-lo e recuperar algum espaço em disco (e com isso quero dizer liberando espaço no arquivo de dados (s) para reutilização, não realizando uma db psiquiatra -. já que você vai usar esse espaço de novo)

Eu não tenho todos os detalhes da sua situação, mas siga até se você tiver dúvidas ou preocupações. Eu tenho usado essa abordagem em vários projetos de migração, incluindo um que está acontecendo agora.

Answer 2

desempenho é fraco devido à enorme quantidade de linhas na tabela

8 milhões de linhas não soa tudo o que louco. Será que você verifique seus planos de consulta?

a tabela é como igualmente lido como atualizadas

Você realmente atualizar uma coluna indexada ou é igualmente ler e Inserida para?

(e não, jogando hardware para isso não vai acontecer, quer)

Isso é uma pena, porque a RAM é sujeira barato.

Answer 3

Reconstruir todos os seus índices. Isto irá aumentar o desempenho das consultas. Como fazê-lo é este e mais em efeito na reconstrução do cluster e não índice -clustered nofollow aqui

Em segundo lugar executar de-fragmentação em sua unidade em que o DB é armazenado.