Indices clustered y non clustered

On Fri, 16 Feb 2007 10:18:16 -0300, "Mauro SB."
wrote:

Alfred
lo que dice el articulo, es que no se garantiza que sean contiguos por que no se puede garantizar que los bloques del disco esten fisicamente contiguos,

No, leelo mejor.

Pero logicamente en el indice los datos estan contiguos.a nivel del SQL

No. Aun suponiendo bloques de disco continuos SQL Server puede
desordenar las páginas.


Saludos

jb,

La principal diferencia consiste en los nodos hojas de cada tipo de indice.
En el clustered, los nodos hojas son la data fisica o paginas de dato. En el
indice nonclustered los nodos hojas son los valores de la llave (en 2005 la
cosa cambia porque puedes incluir columnas que no son parte de la clave) y
ademas punteros o valores que apuntan a la data, que en el caso de que la
tabla tenga indice clustered, pues sera el valor de la clave del indice
clustered asociada y si la tabla es heap (no tiene indice clustered) entonces
el puntero es una combinacion de fileid-pageid-offset. Como los nodos hoja
del indice clustered son la data, entonces una tabla solo puede tener un
unico indice clustered.

La idea tras un indice clustered es que la data este agrupada/organizada por
la clave del indice, pero con el tiempo, debido a las sentencias de
manipulacion de data, a las columnas que conformen la clave, al factor de
relleno de la pagina, y tambien de acuerdo al espacio en disco, las paginas
de data (su orden) pueden no estar en el orden que esta la clave, que es lo
que se conoce como fragmentacion. Si desfragmentamos el indice clustered y
hay espacio suficiente pues toda la data se pondra en paginas que cumplen una
secuencia (lo optimo seria paginas contiguas), lo cual ayuda a la lectura de
grupos de filas.

Ahora, esto no garantiza que cuando leemos desde una tabla, el resultado
estara ordenado porque esta tenga un indice clustered. Lo unico que garantiza
que el resultado de una sentencia "select" este ordenado es que usemos la
clausula "order by" en esa sentencia. Ese es el tema principal del los
articulos que adjunto Alfredo Novoa.


AMB


"jb" wrote:

Cual es la diferencia?


Saludos,

Xus

Hola Mauro,

On Fri, 16 Feb 2007 10:31:49 -0300, "Mauro SB."
wrote:

Alfred,
sea como sealas ventajas se ven :D
por lo que no te preocupes que pasa abajo, sino en los resultados.

Si no te preocupas de lo que pasa por debajo eso puede afectar a los
resultados. Por ejemplo si el índice se fragmenta mucho.


Saludos

Alfredo, tus apreciaciones son interesante pero no son totalmente correctas.

Dentro de una pagina los registros se acceden mediante punteros y no estan
ordenados.

La hipotesis del articulo es:

I'll demonstrate that the pages at the leaf level of the clustered index
are not necessarily organized within the file in the same order as the
logical index key order (maintained by the index leaf level's linked
list). To do so, I'll create a table called T1 with a clustered index on
col1; I'll populate the table with a loop that inserts a row in each
iteration, with a random value in col1:

Fijate que no se refiere al desorden de los datos sino a ´las paginas.
Por otro lado apunta a analizar las alternativas de realizar un SCAN de la
tabla.

Yo queria simplificar y recalcar el concepto de la diferencia de indices,
mas que expresar la realidad exacta de las cosas, porque la pregunta era
conceptual mas que de detalle..

Eso que expresa el articulo, importa muy especialmente en los Range Scan o
en los Full Scan Ordenados, cuando se produce bajo condiciones de
fragmentacion por causa de desorden de paginas y las mismas no tienen
suficiente localidad de referencia como para estar en el cache. Sin embargo
una vez que el SQL Server tiene las paginas en memoria la cosa tiene un
modelo de acceso independiente de la fragmentacion en disco. Por lo tanto,
el resultado final no es tan directo porque la cosa es mucho mas compleja,
porque ademas de depender del working set depende tambien de la
planificacion de la controladora de discos, de la cache que tenga, del
tamaño del bloque de transferencia de los discos, de la eficiencia en
realizar los Scatter gather I/O y lecturas/escrituras asincronicas, entre
otros varios detalles mas.

Igualmente puedes reorganizar periodicamente la base de datos para corregir
estos fenomenos.




Saludos
Ing. Jose Mariano Alvarez


(Cambia los ceros por O y saca lo que sobra)




"Alfredo Novoa" wrote in message
news:

Hola Mauro,

On Fri, 16 Feb 2007 10:31:49 -0300, "Mauro SB."
wrote:

Alfred,
sea como sealas ventajas se ven :D
por lo que no te preocupes que pasa abajo, sino en los resultados.

Si no te preocupas de lo que pasa por debajo eso puede afectar a los
resultados. Por ejemplo si el índice se fragmenta mucho.


Saludos

On Mon, 19 Feb 2007 11:40:22 -0300, "Jose Mariano Alvarez"
wrote:

I'll demonstrate that the pages at the leaf level of the clustered index
are not necessarily organized within the file in the same order as the
logical index key order (maintained by the index leaf level's linked
list). To do so, I'll create a table called T1 with a clustered index on
col1; I'll populate the table with a loop that inserts a row in each
iteration, with a random value in col1:

Fijate que no se refiere al desorden de los datos sino a Žlas paginas.
Por otro lado apunta a analizar las alternativas de realizar un SCAN de la
tabla.

Páginas desordenadas implica datos desordenados. En otra parte del
artículo dice que incluso puede haber datos desordenados en una misma
página.

"Note that even the records within a page are not necessarily sorted
physically. "

Yo queria simplificar y recalcar el concepto de la diferencia de indices,
mas que expresar la realidad exacta de las cosas, porque la pregunta era
conceptual mas que de detalle..

Yo solo contestaba a Pepe que dijo que SQL Server "fuerza" el orden en
los datos físicos y eso no es totalmente cierto.


Saludos