Notes
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.
S’applique à :
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceBase de données SQL dans Microsoft Fabric Preview
Cet article 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 de l'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 pendant une opération d’index en ligne) 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. 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.
Target
La ou les cibles est le nouvel index (ou segment de mémoire), ou bien un jeu des nouveaux index en cours de création ou de régénération. 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 à 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 utilisé tant que l’opération d’index n’est pas validée. En interne, l'index est marqué en écriture seule.
Index de mappage temporaire
Les opérations d'index en ligne qui créent, suppriment ou régénèrent un index cluster exigent é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 source 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 conservent 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 d’index en ligne, telle que la création d’un index clusterisé sur une table non indexée (heap), la source et la cible passent par trois phases : préparation, génération et phase finale.
Vous pouvez utiliser l’événement progress_report_online_index_operation étendu pour surveiller la progression d’une opération d’index en ligne.
L'illustration suivante représente le processus de création d'un index cluster initial en ligne. L'objet source (le segment) ne possède aucun autre index. Les activités de structure source et cible sont affichées pour chaque phase ; les opérations utilisateur concurrentes SELECT, INSERT, UPDATE, et DELETE sont également affichées. Les phases de préparation, de génération et finale sont affichées avec les modes de verrouillage utilisés dans chacune d'elles.
Activités liées à la structure source
Le tableau suivant répertorie les activités impliquant les structures sources lors de chaque phase de l'opération d'index ainsi que la stratégie de verrouillage correspondante.
| Phase | Source activity | Source locks |
|---|---|---|
|
Preparation Short phase |
Préparation des métadonnées système afin de créer la nouvelle structure d'index vide. Un instantané de la table est défini. Cela signifie que le contrôle de version de ligne est utilisé pour fournir une cohérence de lecture au niveau de la transaction. Les opérations d’écriture d’utilisateurs simultanés sur la source sont bloquées pendant une période courte. Aucune opération DDL simultanée n'est autorisée, à l'exception de la création de plusieurs index non-cluster. |
Partagé (S) dans le tableau1Intention partagée ( IS)Verrou d’objet de modification de schéma ( Sch-M) avec le sous-type de ressource INDEX_OPERATION2 |
|
Build Main phase |
Les données sont analysées, triées, fusionnées et insérées dans la cible à l’aide d’opérations de chargement en bloc. Les opérations des utilisateurs concurrents INSERT, UPDATE, DELETE, et MERGE sont appliquées aux index existants ainsi qu’aux nouveaux index en cours de création. |
Intention partagée (IS)Sch-Mverrou d’objet avec le sous-type INDEX_OPERATION de ressource 2 |
|
Final Short phase |
Toutes les transactions d'écriture non validées doivent être terminées avant le début de cette phase. Selon le verrou acquis, toutes les nouvelles transactions de lecture ou d’écriture utilisateur sont bloquées pendant une courte période jusqu’à ce que cette phase se termine. 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. |
Sch-Mverrou d’objet avec le sous-type de ressource INDEX_OPERATION2Partagé ( S) sur la table si vous créez un index non-clusterisé.1Sch-M si une structure source (index ou table) est supprimée. 1 |
1 L’opération d’index attend la fin des transactions d’écriture non validées avant d’acquérir le S verrou ou le Sch-M verrou sur la table. Si une requête longue est en cours d’exécution, l’opération d’index en ligne attend la fin de la requête. Sauf si des verrous de faible priorité sont utilisés, cela peut former une chaîne bloquante.
2 Un Sch-M verrou d’objet avec le sous-type INDEX_OPERATION de ressource 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 régénération simultanée de deux index sur la même table. Bien qu’il s’agit d’un Sch-M verrou, 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 clusterisés et non clusterisés sont générés ou reconstruits dans une seule opération d’index en ligne (par exemple, lors de la création initiale de l’index clusterisé sur une table qui contient un ou plusieurs index non clusterisés), deux verrous à court terme S sont acquis pendant la phase de génération, suivis de verrous partagés à long terme IS. Un S verrou est d'abord acquis pour la création d'index clusterisé. Lorsque l'index clustérisé est créé, un deuxième verrou à court terme S est acquis pour créer les index non clustérisés. Une fois les index non-cluster créés, le S verrou est rétrogradé à un IS verrou jusqu’à la phase finale de l’opération d’indexation en ligne.
Pour plus d’informations sur l’utilisation des verrous et comment les gérer, consultez WAIT_AT_LOW_PRIORITY avec les opérations d’index en ligne.
Activités de la structure ciblée
Le tableau suivant répertorie les activités impliquant la structure cible lors de chaque phase de l'opération d'index ainsi que la stratégie de verrouillage correspondante.
| Phase | Target activity | Target locks |
|---|---|---|
| Preparation | Un nouvel index est créé et défini en écriture seule. | Intention partagée (IS) |
| Build | Les données sont insérées à partir de la source. Les modifications utilisateur (insertions, mises à jour, suppressions) appliquées à la source sont également appliquées à la cible. Cette activité est transparente pour l'utilisateur. |
Intention partagée (IS) |
| Final | Les métadonnées de l'index sont mises à jour. L’index est défini sur l’état de lecture/écriture. |
Modification partagée (S) ou de schéma (Sch-M) |
La cible n’est pas accessible par les requêtes utilisateur tant que l’opération d’index n’est pas terminée.
Une fois la phase de préparation ou finale terminée, les plans de requête stockés dans le cache du plan peuvent être invalidés.
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 de l'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.