Avec la virtualisation, on trouve de plus en plus d’opérations de redémarrages plus agressifs que les opérations de maintenances plus classiques. En effet, il y a parfois des opérations de bascules de VM entre hôtes, de la maintenance sur des SAN ou autre, et cela peut pousser à des redémarrages sans tenir compte de ce qui se passe sur le serveur. Et c’est souvent la nuit… pendant les phases de batchs !

Mais quel est l’impact ? Est-ce que SQL Server est résilient à ces actions ? Quels sont les risques ?

 

Pour répondre à cette question en version courte, utilisons en maquette un SQL Server 2019 sur une petite VM 2 vCPU /  4 Go de RAM (B2S dans Azure). Dessus, une base de données d’exemple de Stack Overflow de 50 Go.

Le protocole de test est le suivant :

• réalisation d’une instruction
• Arrêt de la VM par Azure / Kill du processus sqlserver.exe
• Observation des logs après redémarrage de SQL Server

Manipulation d’index :

Si on réalise une opération de type drop d’index / création d’index : le temps de récupération est négligeable. En effet, la structure nouvellement créée l’est en parallèle d’une existante. Par exemple le drop d’un clustered index créé un heap en parallèle et à la fin, le heap est dropé. Pour la création d’un clustered index, c’est la même chose. Pour l’ajout ou le drop d’un index classique, il s’agit d’une structure supplémentaire qui repose sur le heap ou le clustered index, donc encore moins d’inquiétude.

Le redémarrage lors de ce type d’opération est donc sans risque majeur au moment du redémarrage.

Manipulation de données :

Maintenant imaginons une opération qui réalise un update massif dans une table :

UPDATE Posts
SET AnswerCount = AnswerCount + 1 

Si on laisse tourner la requête pendant 30 secondes puis qu’on tue la machine ou le processus, puis que l’on redémarre, on verra dans les logs :

La reprise de la base a donc pris 43 secondes.

Réalisons la même opération mais en la laissant tourner la requête 5 minutes :

 

 

Le redémarrage a mis cette fois 1 019 secondes pour faire la récupération de cette base ! Par ailleurs, on voit dans les logs des avertissements sur les temps de réponse du disque (il s’agit d’une petite VM) : cela indique que la VM est vraiment très très sollicitée niveau IO. Si on avait un vrai serveur de production avec des bases de données en parallèle de celle occupant le gros recovery, les performances seraient très faibles (d’autant + avec un cache vide après redémarrage).

Et que se passe-t-il si on redémarre pendant cette phase de recovery ? Rien de particulier ! L’opération reprend comme elle avait eu lieu au démarrage précédent.

 

Et ça donne quoi le “Accelerated Database Recovery” ?

Depuis SQL Server 2019, une fonctionnalité a été rajoutée le “Accelerated Database Recovery” (c’est même encore amélioré dans la future version 2022 !). Cette technologie, qui doit être activée manuellement, permet d’améliorer les performances de la phase de recovery (mais pas que). Il permet également de :

• Faire un rollback instantané d’une transaction
• Réaliser de manière agressive un vidage de log transactionnel (même si une grosse transaction est en cours,  les vieilles transactions peuvent ainsi être purgées).

Il repose sur plusieurs choses :

• Un espace disque dédié à l’intérieur de la base sur laquelle l’ADR est activé, appelé Persisted Version Store (PVS). Il fait un peu penser au Version Store utilisé dans la TempDb pour le mode Read Commited Snapshot Isolation. Cela veut dire qu’il y aura des IO supplémentaires et de l’espace requis à partir du moment où l’ADR est activé.
• Une zone mémoire dédiée à connaitre l’état des opérations qui ne sont pas versionnées dans le PVS, appelé SLOG. Cette zone mémoire est censée garder une taille très modeste, et est consolidée sur disque à chaque checkpoint. Il sert à accélerer des opérations de rollbacks et troncation du log transactionnel
• Un processus qui sert à lire les données depuis le PVS pour faire les rollbacks instantanés : le Logical Revert
• Un processus qui sert à à nettoyer de manière asynchrone et régulière les pages du PVS : le Cleaner

 

On le voit donc, c’est clairement un outil qui devrait nous permettre d’améliorer la gestion des risques lors des redémarrages agressifs.

 

Pour l’activer, il faut juste réaliser un  :

ALTER DATABASE [DB] SET ACCELERATED_DATABASE_RECOVERY = {ON | OFF};

Une fois cette option activée sur notre base, si on réalise le même update, pour une durée de 6 minutes d’exécution, temps de recovery mesuré a été de … 41 secondes !

Par ailleurs, à partir de SQL Server 2022, le processus de recovery ne sera plus mono-threadé et par instance, mais par base. Du moment que les performances disques suivent, le recovery sera très très rapide.

 

Conclusion  :

Sur les versions récentes de SQL Server, la fiabilité en cas de reboot/crash/kill lors d’une transaction est réelle, même avec un reboot pendant la phase de recovery. Même si cela peut durer longtemps selon la taille des transactions ainsi que selon les performances disques, la base n’est pas corrompue facilement !

Par ailleurs, pour améliorer ces durées de phases de recovery, l’ADR apportée depuis la version 2019 apporte un gain immense. Par ailleurs, ce sont toutes les opérations de rollbacks qui en profitent également.

 

Continuez votre lecture sur le blog :

• Principes d’une sauvegarde à chaud (David Baffaleuf) [SQL ServerVintage]
• Stocker ses bases de données dans un Azure Blob Storage : l’impossible dilemme ? (Capdata team) [AzureSQL Server]
• Récupérer l’espace consommé par le versionning de lignes (David Baffaleuf) [SQL Server]
• PaaS PostgreSQL AWS vs Azure (Capdata team) [AWSAzureNon classéPostgreSQL]
• SQL Server Managed Instance dans Azure et le SQL Agent : pareil que du On-Prem ? (Capdata team) [AzureSQL Server]