Início / dba / Perguntas / 12913
Accepted
JNK
Asked: 2011-03-30 04:42:59 +0800 CST

SQL Server 2008 - Particionamento e Índices Clusterizados

  • 772

Portanto, deixe-me começar dizendo que não tenho controle total sobre o design do meu banco de dados; portanto, muitos aspectos do sistema atual não podem ser alterados para os propósitos deste cenário.

Comentários sobre como devemos repensar os aspectos do design provavelmente estão corretos, mas inúteis :)

Eu tenho uma tabela muito grande, com aproximadamente 150 campos de largura e cerca de 600m de linhas, que conduz um grande número de processos. Isso está em uma situação de data warehouse, portanto, não temos NENHUMA atualização/inserção fora do processo de carregamento agendado, portanto, é altamente indexado.

Foi tomada a decisão de tentar particionar esta tabela e tenho algumas preocupações sobre a indexação de uma tabela particionada. Não tenho nenhuma experiência com particionamento, portanto, qualquer entrada ou link é bem-vindo. Não consegui localizar especificamente o que estou procurando no BOL ou msdn.

Atualmente, agrupamos em um campo que chamaremos IncidentKeyde a varchar(50)e não exclusivo - poderíamos ter entre 1 a 100 registros com o mesmo IK(sem comentários, por favor). Muitas vezes, obtemos novos dados em IncidentKeyregistros antigos, portanto, também não são sequenciais.

Entendo que preciso incluir meu campo de partição, IncidentDate, em minha chave de índice clusterizado para que a partição funcione corretamente. Estou pensando que seria IncidentKey, IncidentDate.

A questão é: como a mecânica de um índice clusterizado funcionará em uma chave de 2 partes em uma tabela particionada, se um registro em uma partição "nova" estiver antes de um registro em uma partição "antiga" no índice clusterizado?

Por exemplo, tenho 5 registros:

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

Se eu obtiver um novo registro ABC123, 2/1/2011, ele precisará estar no índice clusterizado ANTES XYZ999, 1/1/2010 . Como é que isso funciona?

Estou assumindo fragmentação e ponteiros, mas não consigo encontrar nenhuma informação sobre o armazenamento físico e a configuração de índices clusterizados não particionados em tabelas particionadas com chaves de duas partes.

sql-server index

2 respostas

  1. Best Answer

    Uma tabela particionada é realmente mais como uma coleção de tabelas individuais unidas. Portanto, seu exemplo de agrupamento por IncidentKeye partição por IncidentDate, diga que a função de particionamento divide as tabelas em duas partições para que 01/01/2010 esteja na partição 1 e 01/07/2010 seja a partição dois. Os dados serão dispostos no disco como:

    Partition 1:
IncidentKey    Date
ABC123        1/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010

Partition 2:
IncidentKey    Date
ABC123        7/1/2010
XYZ999        7/1/2010

    Em um nível baixo, existem realmente dois conjuntos de linhas distintos. É o processador de consultas que dá a ilusão de uma única tabela criando planos que buscam, examinam e atualizam todos os conjuntos de linhas juntos, como um só.

    Qualquer linha em qualquer índice não clusterizado terá a chave de índice clusterizado à qual corresponde, digamos ABC123,7/1/2010. Como a chave do índice clusterizado sempre contém a coluna da chave de particionamento, o mecanismo sempre saberá em qual partição (conjunto de linhas) do índice clusterizado procurar esse valor (neste caso, na partição 2).

    Agora, sempre que estiver lidando com particionamento, você deve considerar se seus índices NC serão alinhados (o índice NC é particionado exatamente da mesma forma que o índice clusterizado) ou não alinhado (o índice NC não é particionado ou particionado de forma diferente do índice clusterizado) . Índices não alinhados são mais flexíveis, mas apresentam algumas desvantagens:

    O uso de índices alinhados resolve esses problemas, mas traz seu próprio conjunto de problemas, porque essa opção de design de armazenamento físico se reflete no modelo de dados:

    • índices alinhados significam que restrições exclusivas não podem mais ser criadas/aplicadas (exceto para a coluna de particionamento)
    • todas as chaves estrangeiras que fazem referência à tabela particionada devem incluir a chave de particionamento na relação (já que a chave de particionamento está, devido ao alinhamento, em todos os índices) e isso, por sua vez, exige que todas as tabelas que fazem referência à tabela particionada contenham o valor da coluna da chave de particionamento. Pense em Orders->OrderDetails, se Orders tiver OrderID, mas for particionado por OrderDate, OrderDetails deverá conter não apenas OrderID, mas também OrderDate, para declarar corretamente a restrição de chave estrangeira.

    Esses efeitos raramente são mencionados no início de um projeto que implanta o particionamento, mas eles existem e têm sérias consequências.

    Se você acha que os índices alinhados são um caso raro ou extremo, considere o seguinte: em muitos casos, a base do ETL e das soluções de particionamento é a troca rápida de tabelas de preparação. As operações de comutação requerem índices alinhados.

    Ah, mais uma coisa: todo o meu argumento sobre chaves estrangeiras e o efeito cascata de adicionar o valor da coluna de particionamento a outras tabelas se aplica igualmente a junções .

    • 19

  2. Quando um índice clusterizado tem várias partições, cada partição tem uma estrutura de árvore B que contém os dados dessa partição específica. Por exemplo, se um índice clusterizado tiver quatro partições, haverá quatro estruturas de árvore B; um em cada partição. Ref. Estruturas de índices agrupados

    Diretrizes especiais para índices particionados

    Você pode reconstruir partições específicas de um índice particionado.

    por exemplo

    ALTER INDEX IX_TransactionHistory_TransactionDate
ON Production.TransactionHistory
REBUILD Partition = 5;
GO
    • 9

relate perguntas