SQL 2017 a introduit la possibilité de suspendre et de reprendre les opérations de reconstruction d'index pendant la maintenance de la base de données. Cette fonctionnalité offre plus de flexibilité aux administrateurs de base de données car elle leur permet de choisir entre la réindexation hors ligne et en ligne, ainsi que de suspendre et de reprendre la reconstruction de l'index chaque fois que nécessaire.
Avant la publication de l'index réactivable, les administrateurs de base de données pouvaient exécuter la reconstruction de l'index hors ligne et en ligne .
Hors ligne offre une exécution plus rapide, car la table est verrouillée pour toute lecture ou écrire opération, et le nouvel index est construit à partir de l'ancien index. Au cours de ce processus, aucune opération de lecture ou d'écriture n'est autorisée. Lorsque l'opération est terminée, le verrou de la table est libéré et les opérations de lecture et d'écriture sont à nouveau autorisées. Le Hors ligne option est naturellement plus rapide.
En ligne garde la table ouverte pour lecture et écrivez opérations. Une autre copie de l'index est créée et toutes les opérations de reconstruction d'index se trouvent dans cette copie. Toutes les opérations sur les nouvelles lignes sont écrites dans les deux index. Lorsque la reconstruction est terminée, le changement est effectué et la nouvelle copie d'index est utilisée. Le en ligne reconstruction permet d'effectuer des opérations de reconstruction pendant que la base de données est en ligne. Le temps d'arrêt est minime.
Notez que la fonctionnalité d'index récapitulatif n'est disponible que dans l'édition SQL Server Enterprise et l'édition Developer gratuite. Si vous avez cette option sur la table, vous pouvez jouer avec, faire un test simple et voir si cette fonctionnalité est utile dans votre cas.
La documentation Microsoft indique les aspects suivants pour vos considérations :
- Vous pouvez gérer, planifier et étendre les fenêtres de maintenance des index. Vous pouvez mettre en pause et redémarrer les opérations de création ou de reconstruction d'index lorsque vous avez besoin de respecter vos fenêtres de maintenance.
- Vous pouvez récupérer des échecs de création ou de reconstruction d'index (tels que les basculements de base de données ou le manque d'espace disque).
- Faites attention au fait que lorsqu'une opération d'indexation est interrompue, l'index d'origine et celui qui vient d'être créé nécessiteront de l'espace disque. Vous devrez les mettre à jour lors des opérations DML.
- Vous pouvez activer la troncature des journaux de transactions lors des opérations de création ou de reconstruction d'index.
- Notez que l'option SORT_IN_TEMPDB=ON n'est pas prise en charge
Testons la reconstruction de l'index avec reprise. J'utiliserai une image de conteneur exécutant l'édition SQL 2019 Server Developer. De plus, je vais créer une petite table avec seulement quelques colonnes et insérer environ un million de lignes dans cette table. Vous pouvez agrandir le tableau avec plus de lignes.
Comme j'utilise une machine Linux et que je ne peux pas installer SQL Server Management Studio, j'utiliserai le client Azure Data Studio pour me connecter à mon SQL Server. Jetez un oeil à la capture d'écran de mes propriétés SQL Server :
Nous allons créer un exemple de base de données, une table et un index avec les scripts T-SQL ci-dessous. Vous pouvez les exécuter sans problème avec SSMS ou dbForge Studio for SQL Server :
-- Create a new database called 'DatabaseName'
-- Connect to the 'master' database to run this snippet
USE master
GO
-- Create the new database if it does not exist already
IF NOT EXISTS (
SELECT [name]
FROM sys.databases
WHERE [name] = N'dbatools'
)
CREATE DATABASE dbatools
GO
Use dbatools
-- Create a new table called '[TableName]' in schema '[dbo]'
-- Drop the table if it already exists
IF OBJECT_ID('[dbo].[TabletoIndex]', 'U') IS NOT NULL
DROP TABLE [dbo].[TabletoIndex]
GO
-- Create the table in the specified schema
CREATE TABLE [dbo].[TabletoIndex]
(
[Id] INT NOT NULL PRIMARY KEY, -- Primary Key column
[ColumnName1] NVARCHAR(50) NOT NULL
-- Specify more columns here
);
GO
Pour remplir le tableau avec des données aléatoires, exécutez le script ci-dessous :
--populate the table
SET NOCOUNT ON
Declare @Id int
Set @Id = 1
While @Id <= 1000000
Begin
Insert Into TabletoIndex values (@Id, 'Name - ' + CAST(@Id as nvarchar(10))) Set @Id = @Id + 1
End
SELECT count(*) from TabletoIndex
Avec une table remplie prête, nous pouvons passer à l'index récapitulatif. Commençons par créer cet index :
-- Create a nonclustered index with or without a unique constraint -- Or create a clustered index on table '[TableName]' in schema '[dbo]' in database '[DatabaseName]'
CREATE UNIQUE INDEX IX_ID_Name ON [dbo].[TabletoIndex] (ID desc, [ColumnName1] DESC) WITH (SORT_IN_TEMPDB = OFF, RESUMABLE=ON, ONLINE = ON, MAX_DURATION=1) GO
Notez les nouvelles options/paramètres dans la commande ci-dessus. RESUMABLE=ON signifie que nous voulons avoir une opération d'index pouvant être reprise. Max_Duration est la valeur en minutes définissant la durée d'exécution de l'indexation.
Pendant que la commande ci-dessus est en cours d'exécution, ouvrez une autre session et exécutez la commande T-SQL ci-dessous pour PAUSE l'activité de reconstruction en cours :
--Rebuild WITH RESUMABLE functionality
ALTER INDEX IX_ID_Name ON [dbo].[TabletoIndex] PAUSE
GO
Si la PAUSE est réussie, nous mettons en pause l'opération d'indexation en cours commencée il y a environ une minute. Cependant, lorsque vous revenez à la session précédente pour la commande de reconstruction avec resumable=ON , il renvoie une vilaine erreur. Pouah. Mais oui, c'est le comportement attendu.
Avec cette reconstruction d'index avec reprise, SQL Server a également introduit un nouveau DMV sys.index_resumable_operations pour vérifier les opérations en pause. Essayons de regarder dans ce DMV :
La requête de résultat DMV renvoie ma commande de reconstruction d'index, le pourcentage achevé est une bonne chose, et plus encore. Lorsque toutes vos opérations de reconstruction d'index sont terminées, DMV renvoie vide :
Plutôt chouette, hein ?
Et si vous changiez d'avis sur la table ? Et s'il y avait un changement dans les exigences et que vous deviez apporter des modifications à la conception de la base de données ? Essayons de supprimer la table :
Cela donnera un autre message d'erreur long et laid :
Msg 10637, niveau 16, état 1, ligne 1
Impossible d'effectuer cette opération sur "l'objet" avec l'ID 581577110 car un ou plusieurs index sont actuellement en état de reconstruction d'index avec reprise. Veuillez vous référer à sys.index_resumable_operations pour plus de détails.
Durée totale d'exécution :00:00:00.018
À partir de là, vous vous rendrez compte que vous n'avez pas d'autre choix que d'ANNULER complètement l'opération ou de la REPRENDRE et de laisser la reconstruction se terminer.
Voir la commande T-SQL pour reprendre ou abandonner l'opération. Ensuite, vous pouvez supprimer le tableau avec succès :
ALTER INDEX IX_ID_Name ON [dbo].[TabletoIndex] RESUME
ALTER INDEX IX_ID_Name ON [dbo].[TabletoIndex] ABORT
La même erreur se produira également si vous devez effectuer d'autres opérations comme supprimer totalement l'index ou tuer la session en cours.
Mais vous vous demandez, est l'option de reprise en premier lieu ? La réponse est non. Pour SQL 2019, toutes les créations d'index se font avec RESUMABLE=ON par défaut. C'est à cause de ces 2 déclarations de portée :
ALTER DATABASE SCOPED CONFIGURATION SET ELEVATE_ONLINE=WHEN_SUPPORTED ALTER DATABASE SCOPED CONFIGURATION SET ELEVATE_RESUMABLE=WHEN_SUPPORTED Résumé
L'impact de l'utilisation de l'option de reprise sur les performances n'est pas différent de l'utilisation de l'opération de réindexation normale. SQL Server vous donne simplement plus de contrôle sur vos opérations de maintenance de base de données.
En ce qui concerne les exigences de reconstruction de votre index de tableau périodique, la meilleure pratique consiste toujours à exécuter les opérations d'index hors ligne, ou au moins pendant les heures creuses pour garantir un impact commercial minimal.
