¿Por qué deshabilitar un índice agrupado hace que la tabla sea inaccesible?


11

Cuando se deshabilita un índice, la definición permanece en el catálogo del sistema pero ya no se usa. SQL Server no mantiene el índice (ya que los datos en la tabla cambian), y el índice no puede usarse para satisfacer consultas. Si un índice agrupado está deshabilitado, toda la tabla queda inaccesible.

¿Por qué no es posible acceder a los datos directamente desde la tabla descartando el árbol B? (muy probablemente escaneando la tabla fila por fila) ¿No sería más apropiado que hacer que los datos sean completamente inaccesibles?

Es una pregunta puramente teórica: en realidad nunca haría eso. No es un escenario ni una tarea pendiente, solo quiero saber por qué las cosas van así, considérelo una pregunta interna.

Respuestas:


10

¿Por qué no es posible acceder a los datos directamente desde la tabla descartando el árbol B? (muy probablemente escaneando la tabla fila por fila) ¿no sería eso más apropiado que datos inaccesibles?

Para responder a su pregunta, los conceptos básicos de indexación son más útiles: un índice se compone de un conjunto de páginas (nodos de índice) que se organizan en una estructura de árbol B. Esta estructura es de naturaleza jerárquica, con el nodo raíz en la parte superior de la jerarquía y los nodos hoja en la parte inferior. Para más detalles consulte aquí .

Además, como muchas personas han descrito, Índices agrupados == Tablas originales que están físicamente ordenadas con una o más claves o columnas. Entonces, cuando un índice agrupado está deshabilitado, no se puede acceder a sus filas de datos. No podrá insertar ningún dato (para el índice no agrupado, la inserción tendrá éxito, pero eso no está completamente relacionado con esta publicación, ya que aquí la discusión es sobre el índice agrupado) o tampoco funcionará la operación Reorganizar.

A continuación le explicaremos en detalle:

utilizaremos la base de datos Adventureworks para ver el efecto de deshabilitar el índice CLUSTERADO .

ingrese la descripción de la imagen aquí

Ahora verifique el recuento de filas en la tabla:

ingrese la descripción de la imagen aquí

Ahora deshabilite el índice agrupado

ingrese la descripción de la imagen aquí

Ahora seleccione el recuento de filas de la tabla. Esta vez se producirá un error con el siguiente mensaje:

ingrese la descripción de la imagen aquí

¡Incluso la operación de reorganización no funciona!

ingrese la descripción de la imagen aquí

Ahora reconstruya el índice agrupado y debería funcionar bien.

ingrese la descripción de la imagen aquí

Seleccione la tabla para ver si podemos acceder a los datos.

ingrese la descripción de la imagen aquí

Entonces, la conclusión es que, si deshabilitamos el índice agrupado, los datos en la tabla aún existen, pero no serán accesibles para nada más que las operaciones Drop o REBUILD. Todos los índices y vistas no agrupados relacionados no estarán disponibles, así como las claves foráneas que hagan referencia a la tabla se deshabilitarán y allí se mostrará el FALLO para todas las consultas que hacen referencia a la tabla.

Nota: No hay opción para HABILITAR el índice. Tienes que RECONSTRUIRLO.


2

El nivel de la hoja del árbol B + es la tabla. ¿Qué espera lograr al deshabilitar el CI? Simplemente no haga esto si no desea que los datos sean inaccesibles.

No estoy realmente seguro de por qué SQL Server incluso te permite hacer esto.

CREATE TABLE T
(
    X INT CONSTRAINT PK PRIMARY KEY CLUSTERED, 
    Y INT CONSTRAINT UQ UNIQUE NONCLUSTERED
);

ALTER INDEX PK ON T DISABLE;

... también deshabilita el NCI, por lo que incluso las SELECTconsultas que estarían cubiertas se deshabilitan. No puedo pensar en ningún caso de uso para esto. - martin-smith

El único uso que se me ocurre es exactamente lo que se está discutiendo. Deshabilitar una mesa. Si tiene una tabla que no desea que nadie toque, dboni siquiera sysadmin, puede deshabilitar el índice agrupado. La tabla existe junto con los datos, pero es completamente inaccesible hasta que vuelva a habilitar el índice agrupado. - Kenneth-Fisher

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.