Devo particionar minha tabela principal com 2 milhões de linhas?

Question

Eu sou um desenvolvedor e precisaria de alguns conselhos sobre DBA.
Estamos começando a ter problemas de desempenho com um banco de dados MSSQL2005. Os efeitos visíveis dos incidentes ocorrem principalmente no servidor, mas as operações informaram que também estavam drenando recursos da SAN (nem sempre). A principal fonte de problemas é certa em alguns aplicativos, mas eu estou querendo saber se devemos particionar algumas das tabelas principais de qualquer maneira, a fim de relaxar a pressão de I / O.
A base é de cerca de 60GB em um arquivo.
A tabela principal (ordem) tem 2,1 milhões de linhas com 215 colones (mas nenhuma é enorme). Nós temos um inteiro como PK, então deve ser OK definir uma função de partição.

Será que vamos ganhar algo com o particionamento? vai dividir os índices nos comprar alguma coisa?
Aqui estão mais alguns fatos sobre o DB e a tabela

database_name  database_size    unallocated space
My_base         57173.06 MB     79.74 MB
reserved        data            index_size      unused
29 444 808 KB   26 577 320 KB   2 845 232 KB    22 256 KB

name        rows            reserved    data        index_size      unused
Order   2 097 626       4 403 832 KB    2 756 064 KB    1 646 080 KB    1688 KB

Obrigado por qualquer conselho

Dom

    

Answer 1

Ah - por quê? Há 15 anos, 1 milhão de linhas era considerado pequeno. Hoje, 100 milhões de linhas são consideradas pequenas.

Se você tem um CPU-porco, eu começaria a procurar o problema - isso se parece muito mais com um problema de índice e / ou um design de campo ruim do que qualquer outra coisa.

Agora, a SAN hogging - isso é totalmente normal para qualquer SQL Server. Normalmente, as pessoas da SAN são extremamente ignorantes em relação ao fato de que os servidores de banco de dados são IO pesados. Os bancos de dados normalmente exigem uma configuração de SAN específica que é otimizada para eles e pode ser totalmente utilizada por eles. Não é "monopolizá-lo", ele tenta usar todos os recursos da melhor forma possível.

Seu banco de dados é SMALL - sério. Eu realmente não vejo nenhum problema aqui. A tabela de pedidos tem apenas 4GB de memória, o que - interessante o suficiente - é um tamanho que deve ser respondido da memória.

O particionamento é útil para exclusões em massa (uma tabela por ano, descartando um ano de pedidos é uma tabela truncada, não uma exclusão), mas com seu tamanho isso não é um problema (Eu tenho uma tabela de preços que tem cerca de 1,5 BILHÕES de entradas, e isso é pequeno). Ele não acelera muito as consultas - a consulta pode ser selecionada para apenas uma partição (e não, o inteiro PK não ajuda, a menos que você selecione por intervalo PK como filtro) - ou não pode. Mas, mesmo que seja possível, um índice é quase tão rápido.

Que tipo de consulta é ruim? Como está o plano de execução? Talvez você:

• Tem pouca memória (8GB ou mais?)

• Tem um layout de índice suboptimal / não correspondente, de modo que a consulta basicamente se transforma em uma varredura de tabela? Neste caso, eu começaria a corrigir esse lado.

• Você carrega mais dados do que precisa?

Sem o seu plano de execução de consultas, isso não pode ser respondido.

BTW, 60 GB em um arquivo é negligência grosseira. QUALQUER banco de dados considerável deve ter tantos arquivos quanto possíveis operações paralelas (ou seja, núcleos de servidor disponíveis para SQL Server);) E tenho certeza que sua E / S está mal organizada - partição não alinhada, formatação incorreta, atrasando você ( possivelmente muito - configuração de disco ruim pode custar até 40% de desempenho).

Para relaxar a pressão de E / S:

• Verifique se o seu servidor de banco de dados está instalado corretamente (raramente vejo um - os administradores parecem gostar de ignorar a documentação aqui)

• Certifique-se de ter recursos adequados em primeiro lugar. Qual é o valor do seu orçamento de IOPS no subsistema de disco? Você o mediu ou?

• Verifique se os bancos de dados estão configurados corretamente (novamente, a maioria dos administradores adora ser ignorante nesse caso)

• Verifique se você tem uma boa estrutura de tabela e uma boa chave primária (praticamente a única coisa que você tem certo).

Depois, entre no profiler, descubra o aplicativo e verifique se as consultas estão otimizadas.