Pourquoi la désactivation d'un index cluster rend la table inaccessible?

Lorsqu'un index est désactivé, la définition reste dans le catalogue système mais n'est plus utilisée. SQL Server ne gère pas l'index (car les données de la table changent) et l'index ne peut pas être utilisé pour satisfaire les requêtes. Si un index cluster est désactivé, la table entière devient inaccessible.

Pourquoi n'est-il pas possible d'accéder aux données directement à partir de la table en supprimant l'arbre B? (très probablement en balayant le tableau ligne par ligne) Ne serait-ce pas plus approprié que de rendre les données complètement inaccessibles?

C'est une question purement théorique - je ne ferais jamais ça. Ce n'est pas un scénario, ni une chose à faire, je veux juste savoir pourquoi ça va comme ça, considérez-le comme une question interne.

pourquoi n'est-il pas possible d'accéder aux données directement à partir de la table en supprimant l'arbre B? (très probablement en analysant le tableau ligne par ligne) ne serait-ce pas plus approprié que des données inaccessibles?

Pour répondre à votre question, les bases de l'indexation sont plus pratiques - Un index est composé d'un ensemble de pages (nœuds d'index) qui sont organisés dans une structure en arborescence B. Cette structure est de nature hiérarchique, avec le nœud racine en haut de la hiérarchie et les nœuds feuilles en bas. Pour plus de détails, reportez-vous ici .

En outre, comme de nombreuses personnes l'ont décrit, les index clusterisés == les tables d'origine qui sont physiquement ordonnées avec une ou plusieurs clés ou colonnes. Ainsi, lorsqu'un index cluster est désactivé, ses lignes de données ne sont pas accessibles. Vous ne pourrez pas insérer de données (pour un index non clusterisé, l'insertion réussira - mais ce n'est pas entièrement lié à ce message - car ici, la discussion porte sur un index clusterisé), ou aucune des opérations de réorganisation ne fonctionnera.

Ci-dessous vous expliquera en détail:

nous utiliserons la base de données Adventureworks pour voir l'effet de la désactivation de l' index CLUSTERED .

Vérifiez maintenant le nombre de lignes dans le tableau:

Désactivez maintenant l'index clusterisé

Sélectionnez maintenant le nombre de lignes dans le tableau. Cette fois, il affichera une erreur avec le message ci-dessous:

Même l'opération de réorganisation ne fonctionne pas !!

Reconstruisez maintenant l'index clusterisé et cela devrait fonctionner correctement.

Sélectionnez le tableau pour voir si nous pouvons accéder aux données

Donc, en fin de compte, si nous désactivons l'index clusterisé, les données du tableau existent toujours, mais ne seront accessibles pour rien d'autre que les opérations Drop ou REBUILD. Tous les index et vues non groupés associés ne seront pas disponibles, de même que les clés étrangères référençant la table seront désactivées et là, en amenant l'échec pour toutes les requêtes qui référencent la table.

Remarque: Il n'y a aucune option pour ACTIVER l'index. Vous devez le RECONSTRUIRE.

Le niveau de feuille de l'arbre B + est la table. Qu'espérez-vous réaliser en désactivant le CI? Ne faites pas cela si vous ne voulez pas que les données soient inaccessibles.

Je ne sais pas vraiment pourquoi SQL Server vous permet même de le faire.

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

ALTER INDEX PK ON T DISABLE;

... désactive également le NCI donc même les SELECTrequêtes qui seraient couvertes par celui-ci sont désactivées. Je ne peux penser à aucun cas d'utilisation pour cela. - martin-smith

La seule utilisation à laquelle je peux penser de ma tête est exactement ce dont on discute. Désactiver une table. Si vous avez une table que vous ne voulez pas que quiconque touche, même dboou sysadmin, vous pouvez désactiver l'index cluster. La table existe avec les données, mais est complètement inaccessible jusqu'à ce que vous réactiviez l'index cluster. - kenneth-fisher