Heap X Clustered, na pratica….

Galera, hoje, irei falar sobre um assunto muito legal!, algo que gosto muito de verdade, que é a ordenação fisica das pagina de uma tabela, bem, todos sabemos que o SQL Server trabalha com uma estrutura de paginas, contendo cada uma 8KB.

Bem, este tema abre varias raizes para varias explicações, neste, quero falar especificamente, ou melhor, mostrar, as diferenças entre uma tabela HEAP e uma tabela Clusterizada.

Do ponto de vista teorico temos a seguinte explicação:

Uma tabela HEAP é aquela que não contem uma indice cluster, portanto, suas paginas são ordenadas e localizadas a partir de uma tabela especial chamada IAM (Index Allocation Map, ou, como ultimamente tem sido chamada, Allocation Unit [AU]). Ja uma tabela Clusterizada possui um indice Cluster e toda sua estrutura sera feita a partir desta caracterisca, ou seja, sua paginas são ligadas diretamente uma na outra, mantendo uma ordem, segundo os dados especificados no indice Cluster.

Vamos ver na pratica como que funciona?…

Primeiro uma criação de tabela simples, algumas inserções de dados e um select apenas para confirmação de inserção:

--Criação de tabela
CREATE TABLE Teste
(
	Id UNIQUEIDENTIFIER
)

--Inserção de dados
INSERT INTO Teste VALUES (NEWID())
GO 3000

--Select de teste de inserção de dados
SELECT *
FROM Teste

Depois, o comando para verificarmos as paginas desta tabela:

DBCC IND('Master', Teste, -1)

O que é legal de observar:
Temos, pela PageType = 10, nosso IAM (ou AU), e PageType = 1, paginas de dados, alem de podermos ver que os campos NextPagePID e PrevPagePID estão todos zerados, ou seja, não ha uma ordernação das paginas.

Criação de um indice não clusterizado

CREATE INDEX IX_01 ON Teste(Id)

Nova verificação das paginas:

DBCC IND('Master', Teste, -1)

Podemos agora observar que as paginas de dados, ou seja, com PageType = 1 continuam ser ordenação entre si, porem, um novo PageType foi introduzido, o PageType 2, que quer dizer que estamos falando de uma pagina de indice, se observar os campos NextPagePID e PrevPagePID, podemos observar que os mesmo estão preenchidos, mantendo uma ordenação conforme se espera de um indice, ou seja, ainda estamos falando de uma tabela HEAP.

Agora, vamos dropar este indice não clusterizado, e criar um indice cluster nesta tabela.

DROP INDEX IX_01 ON Teste

CREATE CLUSTERED INDEX IX_01 ON Teste(Id)

Reexecução do comando de verificação das paginas:

DBCC IND('Master', Teste, -1)

Agora, podemos observar que voltamos a não ter o PageType = 2, porem, agora nossas paginas de dados estão ordenadas pelo campo Id.

Aonde isso pode me ajudar:
Deixo aqui como “lição arrumada” de um projeto de software que pegamos la na empresa, no caso, temos uma tabela de discagem de utiliza um campo NEWID, ou seja, UNIQUEIDENTIFIER como Primary Key (Assim como o campo ID no titulo), ou seja, todas as vezes de alguma inserção era feita na tabela, um novo UNIQUEIDENTIFIER era criado, como o mesmo não segue uma ordem obrigatoria de crescente ou decrescente, toda nova inserção fazia com que o SQL Server se arrumasse inteiro, realocando todas as paginas de sua tabela, com a simples remoção do indice Primary Key deste campo, fizemos qualquer operação reduzir de 45 segundos em media, para no maximo 3 segundos.

Anúncios
Post a comment or leave a trackback: Trackback URL.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: