Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette rubrique définit les structures qui existent pendant une opération d’index en ligne et affiche les activités associées à ces structures.
Structures d’index en ligne
Pour permettre l'activité simultanée des utilisateurs pendant une opération DDL de définition de données d'index, les structures suivantes sont utilisées lors de l'opération d'indexation en ligne : les index sources et préexistants, la cible, et, pour reconstruire un tas ou supprimer un index en cluster en ligne, un index de mappage temporaire.
Index source et préexistants
La source est la table d’origine ou les données d’index cluster. Les index préexistants sont tous les index non cluster associés à la structure source. Par exemple, si l’opération d’index en ligne régénère un index cluster qui a quatre index non cluster associés, la source est l’index cluster existant et les index préexistants sont les index non cluster.
Les index préexistants sont disponibles pour les utilisateurs simultanés pour sélectionner, insérer, mettre à jour et supprimer des opérations. Cela inclut les insertions en bloc (prises en charge, mais non recommandées) et les mises à jour implicites par les déclencheurs et les contraintes d’intégrité référentielle. Tous les index préexistants sont disponibles pour les requêtes et les recherches. Cela signifie qu’ils peuvent être sélectionnés par l’optimiseur de requête et, si nécessaire, spécifiés dans les indicateurs d’index.
cible
La cible ou les cibles sont le nouvel index (ou tas) ou un ensemble d’index en cours de création ou de reconstruction. Les opérations d’insertion, de mise à jour et de suppression utilisateur sur la source sont appliquées par le moteur de base de données SQL Server à la cible pendant l’opération d’index. Par exemple, si l’opération d’index en ligne regénère un index cluster, la cible est l’index cluster reconstruit ; Le moteur de base de données ne régénère pas les index non cluster lorsqu’un index cluster est reconstruit.
L’index cible n’est pas recherché lors du traitement des instructions SELECT tant que l’opération d’index n’est pas validée. En interne, l’index est marqué comme étant à usage d’écriture seule (interdiction de lecture).
Index de mappage temporaire
Les opérations d’index en ligne qui créent, suppriment ou régénèrent un index cluster nécessitent également un index de mappage temporaire. Cet index temporaire est utilisé par des transactions simultanées pour déterminer les enregistrements à supprimer dans les nouveaux index générés lorsque les lignes de la table sous-jacente sont mises à jour ou supprimées. Cet index non cluster est créé à la même étape que le nouvel index cluster (ou tas) et ne nécessite pas d’opération de tri distincte. Les transactions simultanées gèrent également l’index de mappage temporaire dans toutes leurs opérations d’insertion, de mise à jour et de suppression.
Activités d’index en ligne
Pendant une opération simple d'index en ligne, comme la création d'un index clusterisé sur une table non indexée (tas), la source et la cible passent par trois phases : préparation, construction et finalisation.
L’illustration suivante montre le processus de création d’un index cluster initial en ligne. L’objet source (le tas) n’a aucun autre index. Les activités de structure source et cible sont affichées pour chaque phase ; Les opérations de sélection, d’insertion, de mise à jour et de suppression simultanées de l’utilisateur sont également affichées. Les phases de préparation, de build et finale sont indiquées avec les modes de verrouillage utilisés dans chaque phase.
Activités de structuration de la source
Le tableau suivant répertorie les activités impliquant les structures sources pendant chaque phase de l’opération d’index et la stratégie de verrouillage correspondante.
| Étape | Activité source | Verrouillage de source |
|---|---|---|
| Préparation Phase très courte |
Préparation des métadonnées système pour créer la nouvelle structure d’index vide. Un instantané de la table est défini. Autrement dit, le contrôle de version de ligne est utilisé pour assurer la cohérence de lecture pour chaque transaction. Les opérations d’écriture utilisateur simultanées sur la source sont bloquées pendant une période très courte. Aucune opération DDL simultanée n’est autorisée, sauf la création de plusieurs index non cluster. |
S (Partagé) sur la table* IS (intention partagée) INDEX_BUILD_INTERNAL_RESOURCE** |
| Construire Phase principale |
Les données sont analysées, triées, fusionnées et insérées dans la cible dans les opérations de chargement en bloc. Les opérations de sélection, d’insertion, de mise à jour et de suppression simultanées sont appliquées aux index préexistants et aux nouveaux index générés. |
EST INDEX_BUILD_INTERNAL_RESOURCE** |
| Finale Phase très courte |
Toutes les transactions de mise à jour non validées doivent être effectuées avant le démarrage de cette phase. Selon le verrou acquis, toutes les nouvelles transactions de lecture ou d’écriture utilisateur sont bloquées pendant une période très courte jusqu’à ce que cette phase soit terminée. Les métadonnées système sont mises à jour pour remplacer la source par la cible. La source est supprimée si nécessaire. Par exemple, après la reconstruction ou la suppression d’un index cluster. |
INDEX_BUILD_INTERNAL_RESOURCE** S sur la table si vous créez un index non cluster.* SCH-M (modification du schéma) si une structure source (index ou table) est supprimée.* |
* L'opération d'index attend la fin des transactions de mise à jour non validées avant d'acquérir le verrou de type S ou de type SCH-M sur la table.
** Le verrou de ressource INDEX_BUILD_INTERNAL_RESOURCE empêche l’exécution d’opérations DDL (Data Definition Language) simultanées sur la source et les structures préexistantes pendant que l’opération d’index est en cours. Par exemple, ce verrou empêche la reconstruction simultanée de deux index sur la même table. Bien que ce verrou de ressource soit associé au verrou Sch-M, il n’empêche pas les instructions de manipulation des données.
Le tableau précédent montre un seul verrou partagé (S) acquis pendant la phase de génération d’une opération d’index en ligne qui implique un seul index. Lorsque des index cluster et non cluster sont générés ou reconstruits, dans une seule opération d’index en ligne (par exemple, lors de la création initiale d’index cluster sur une table qui contient un ou plusieurs index non cluster), deux verrous S à court terme sont acquis pendant la phase de génération suivie des verrous partagés d’intention à long terme (IS). Un verrou S est d'abord acquis pour la création de l’index clusterisé et lorsque la création de l’index clusterisé est terminée, un deuxième verrou S à court terme est acquis pour créer les index non-clusterisés. Une fois les index non cluster créés, le verrou S est rétrogradé en verrou IS jusqu’à la phase finale de l’opération d’index en ligne.
Activités structurelles cibles
Le tableau suivant répertorie les activités qui impliquent la structure cible pendant chaque phase de l’opération d’index et la stratégie de verrouillage correspondante.
| Étape | Activité cible | Verrous cibles |
|---|---|---|
| Préparation | Un nouvel index est créé et défini sur écriture seule. | EST |
| Construire | Les données sont insérées à partir de la source. Les modifications utilisateur (insertions, mises à jour, suppressions) appliquées à la source sont appliquées. Cette activité est transparente pour l’utilisateur. |
EST |
| Finale | Les métadonnées d’index sont mises à jour. L’index est en mode lecture/écriture. |
S ou SCH-M |
La cible n’est pas accessible par les instructions SELECT émises par l’utilisateur tant que l’opération d’index n’est pas terminée.
Une fois la phase de préparation et finale terminée, les plans de requête et de mise à jour stockés dans le cache de procédure sont invalidés. Les requêtes suivantes utilisent le nouvel index.
La durée de vie d’un curseur déclaré sur une table impliquée dans une opération d’index en ligne est limitée par les phases d’index en ligne. Les curseurs de mise à jour sont invalidés à chaque phase. Les curseurs en lecture seule ne sont invalidés qu’après la phase finale.