Tabela Particionada e Paralelismo do SQL Server 2008

Question

Minha empresa está migrando para o SQL Server 2008 R2. Nós temos uma tabela com muitos dados de arquivo. A maioria das consultas que usa essa tabela emprega o valor DateTime na instrução where. Por exemplo:

Consulta 1

SELECT COUNT(*) 
FROM TableA 
WHERE 
     CreatedDate > '1/5/2010' 
     and CreatedDate < '6/20/2010'  

Estou supondo que as partições são criadas em CreatedDate e cada partição está distribuída em várias unidades, temos 8 CPUs e há 500 milhões de registros no banco de dados que estão espalhados uniformemente entre as datas de 1 / 1/2008 a 2/24/2011 (38 partições). Esses dados também podem ser divididos em parcelas de um ano ou outras durações, mas vamos manter as suposições em meses.

Nesse caso, eu acreditaria que as 8 CPUs seriam utilizadas e somente as 6 partições seriam consultadas para datas entre 1/5/2010 e 20/6/2010.

Agora, se eu fiz a seguinte consulta e minhas suposições são as mesmas que as acima.

Consulta 2

SELECT COUNT(*) 
FROM TableA 
WHERE State = 'Colorado'

Perguntas?
    1. Todas as partições serão consultadas? Sim
    2. Todas as 8 CPUs serão usadas para executar a consulta? Sim
    3. O desempenho será melhor do que consultar uma tabela que não seja particionada? Sim
    4. Há mais alguma coisa que me falta?
    5. Como o Índice de Partição ajudaria?

Eu respondo as 3 primeiras perguntas acima, com base no meu conhecimento limitado do SQL Server 2008 Partitioned Table & Paralelismo. Mas se as minhas respostas estiverem incorretas, você pode fornecer feedback por que estou incorreto.

Recurso:

• Vídeo: Demonstração Paralelismo de Tabelas Particionadas do SQL Server 2008 (5 minutos de duração)
• MSDN: Tabelas e índices particionados

Atualização     Nós temos um índice de cluster no banco de dados e cobrindo índices em colunas

BarDev

    

Answer 1

1. Sim
2. Possivelmente, dependendo de qual índice é consultado e de como esse índice é particionado.
3. Possivelmente, novamente, dependendo de qual índice é consultado e de como esse índice é particionado.
4. Um índice não agrupado poderia ser criado na tabela e esse índice poderia ser particionado na coluna Estado, o que seria muito rápido. Se houver um índice em outra coluna e a coluna Estado for incluída, esse índice poderá ser mais barato para o SQL Server verificar.
5. Provavelmente.