Mise en pause automatique et reprise automatique dans le niveau de calcul serverless pour Azure SQL Database

S’applique à :Azure SQL Database

Cet article explique le comportement d’auto-pause et de reprise automatique pour la couche de calcul serverless dans Azure SQL Database, et comment elle interagit avec diverses fonctionnalités d’Azure SQL Database.

Actuellement, le niveau service à usage général est le seul qui supporte la pause et la reprise automatiques sans serveur.

Pour surveiller l’état d’une base de données serverless, voir Surveiller pause et reprendre l’état.

Mise en pause automatique

L’auto-pause commence si toutes les conditions suivantes sont vraies pendant le délai d’auto-pause :

  • Nombre de sessions = 0
  • Processeur = 0 pour la charge de travail utilisateur exécutée dans le pool de ressources utilisateur

Par défaut, il y a un délai d’une heure pour la pause automatique.

Fonctionnalités qui empêchent l’auto-pause

Si vous utilisez l’une des fonctionnalités suivantes, désactivez la mise en pause automatique. La base de données reste en ligne peu importe la durée de son inactivité. Les fonctionnalités suivantes empêchent la mise en pause automatique, mais elles prennent en charge la mise à l’échelle automatique :

Les scénarios de fonctionnalités suivants empêchent également la pause automatique :

  • Base de données de synchronisation utilisée dans SQL Synchronisation des données. Contrairement aux bases de données de synchronisation, les bases de données hub et membres prennent en charge la suspension automatique.
  • Avec les jobs élastiques, une base de données sans serveur avec la mise en pause automatique activée n’est pas prise en charge en tant que base de données des travaux. Les bases de données serverless ciblées par des jobs élastiques supportent bien la mise en pause automatique. Les connexions de travaux relancent une base de données.
  • La mise en pause automatique est temporairement indisponible durant le déploiement de certaines mises à jour de service pour lesquelles la base de données doit être en ligne. Dans ce cas, la mise en pause automatique est réactivée dès que la mise à jour du service est terminée.

Reprise automatique

La reprise automatique se déclenche si l’une des conditions suivantes est remplie à tout moment :

Fonctionnalité Déclencheur de reprise automatique
Authentification et autorisation Tentative de connexion
Détection de menaces Activation ou désactivation des paramètres de détection des menaces au niveau de la base de données ou du serveur.
Modification des paramètres de détection des menaces au niveau de la base de données ou du serveur.
Découverte et classification des données Ajout, modification, suppression ou affichage des étiquettes de sensibilité
Auditing Affichage des enregistrements d’audit.
Mise à jour ou affichage de la politique d’audit.
Masquage de données Ajout, modification, suppression ou affichage des règles de masquage des données
Chiffrement transparent des données Visualisation de l'état ou du statut du chiffrement transparent des données
Évaluation des vulnérabilités Analyses initiées manuellement et analyses périodiques si activées
Magasin de données sur les requêtes et les performances Modification ou affichage des paramètres de Magasin des requêtes
Recommandations en matière de performances Affichage ou application des recommandations en matière de performances
Réglage automatique Application et vérification des recommandations d’auto-tuning telles que l’autoindexation
Copie de base de données Création d’une base de données comme copie.
Exportation vers un fichier BACPAC.
Synchronisation des données SQL Synchronisation entre les bases de données hub et membre qui s’exécutent selon une planification configurable ou qui sont exécutées manuellement
Modification de certaines métadonnées de base de données Ajout ou modification des balises Azure dans la base de données.
Changement du nombre maximal de vCores, du nombre minimal de vCores ou du délai de mise en pause automatique.
SQL Server Management Studio (SSMS) Dans les versions SSMS antérieures à la 18.1 et en ouvrant une nouvelle fenêtre de requête pour toute base de données du serveur, toute base de données en pause automatique dans le même serveur est reprise. Ce comportement ne se produit pas si vous utilisez SSMS version 18.1 ou ultérieure.

La surveillance, la gestion ou d’autres solutions effectuant l’une de ces opérations déclenchent la reprise automatique. La reprise automatique commence également lors du déploiement de certaines mises à jour de service nécessitant que la base de données soit en ligne.

Identification du déclencheur de reprise automatique

Le journal d’activité Azure Monitor affiche les déclencheurs de reprise automatique pour les opérations Resume Databases dans la propriété Caller du JSON des événements Started et Succeeded. Pour plus d’informations, voir Surveiller la couche de calcul serverless.

Latency

La latence est généralement de l’ordre d’une minute pour reprendre automatiquement et de 1 à 10 minutes pour mettre en pause automatique. La latence de l’une ou l’autre opération peut être aussi faible que l’ordre d’une seconde.

Chiffrement transparent des données géré par le client

Suppression ou révocation d'une clé

Si vous utilisez un chiffrement transparent des données géré par le client (apportez votre propre clé ou BYOK) et que la base de données sans serveur est automatiquement mise en pause lors de la suppression ou de la révocation de la clé, la base de données reste en état de mise en pause automatique. Dans ce cas, après la reprise de la base de données, la base de données devient inaccessible pendant 10 minutes environ. Une fois que la base de données devient inaccessible, le processus de récupération est le même que pour les bases de données de calcul provisionnées. Si la base de données serverless est en ligne lors de la suppression ou de la révocation de clé, la base de données devient également inaccessible en environ 10 minutes, de la même manière que pour les bases de données de calcul provisionnées.

Rotation des clés

Si vous utilisez un chiffrement transparent des données géré par le client (BYOK) et activez la pause automatique sans serveur, la base de données reprend automatiquement chaque fois que les clés sont tournées. La base de données se met alors automatiquement en pause lorsque les conditions de mise en pause automatique sont remplies.

Résolution des problèmes de mise en pause automatique

Dépannage de la connectivité de reprise automatique

Si une base de données serverless est mise en pause, la première tentative de connexion reprend la base de données et retourne une erreur indiquant que la base de données n’est pas disponible (code d’erreur 40613). Une fois la base de données reprise, réessayez la connexion. Les bases de données reprennent généralement en moins d’une minute.

Toutes les applications connectées au cloud devraient utiliser des recommandations logiques de réessayage de connexion. Les applications nécessitent une logique de retentative pour réussir après des erreurs de connectivité transitoire. La logique de réessayage est particulièrement importante pour les bases de données serverless, où les erreurs de connectivité temporaires dues à la reprise automatique sont prévisibles.

Pour les options et les recommandations relatives à la logique de réessai de connexion, voir :

Résolution de problèmes d’auto-pause

Si vous activez la mise en pause automatique et n’utilisez pas les fonctionnalités qui bloquent la pause automatique, mais que la base de données ne met pas en pause après la période de délai, les sessions d’application ou d’utilisateur pourraient empêcher la mise en pause automatique.

Pour vérifier si des applications ou des sessions utilisateur sont actuellement connectées à la base de données, lancez la requête suivante :

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
          (
          wg.name like 'UserPrimaryGroup.DB%'
          AND
          TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
          )
      OR
      wg.name = 'DACGroup'
      );

Tip

Après avoir exécuté la requête, veillez à vous déconnecter de la base de données. Sinon, la session ouverte utilisée par la requête empêche la suspension automatique.

  • Si le jeu de résultats n’est pas vide, cela indique que des sessions empêchent actuellement la mise en pause automatique.
  • Si l’ensemble de résultats est vide, il est toujours possible que les sessions aient été ouvertes, possiblement pendant une courte période, à un moment donné plus tôt pendant la période de délai d’auto-pause. Pour vérifier l’activité pendant la période de retard, utilisez Auditing for Azure SQL Database et Azure Synapse Analytics et examinez les données d’audit pour la période concernée.

Important

La présence de sessions ouvertes, avec ou sans utilisation simultanée du processeur dans le pool de ressources utilisateur, est la raison la plus courante pour laquelle une base de données serverless n’est pas mise en pause automatique comme prévu.

Contenu connexe

  • Last updated on