Bonnes pratiques générales

Cette page présente les bonnes pratiques pour optimiser la performance, la durabilité et la disponibilité de Cloud SQL.

En cas de problème avec votre instance Cloud SQL, veuillez prendre connaissance des points suivants lors du dépannage :

Configurer et administrer une instance

Bonne pratique	En savoir plus
Lisez et suivez les consignes opérationnelles pour vous assurer que vos instances sont couvertes par le contrat de niveau de service Cloud SQL.
Configurez un intervalle de maintenance permettant à votre instance principale de contrôler à quel moment des mises à jour perturbatrices peuvent se produire.	Consultez la page Intervalle de maintenance.
Si vous supprimez et recréez régulièrement des instances, utilisez un horodatage dans l'ID d'instance pour augmenter les chances d'utilisation des nouveaux ID d'instances.
Ne démarrez pas une opération administrative avant la fin de l'opération précédente.	Les instances Cloud SQL n'acceptent pas de nouvelle requête d'opération avant d'avoir terminé l'opération précédente. Si vous essayez de démarrer prématurément une nouvelle opération, la requête d'opération échoue. Cela inclut les redémarrages d'instances. L'état de l'instance dans Google Cloud Console ne permet pas de savoir si une opération est en cours d'exécution. La coche verte indique uniquement que l'instance est à l'état `RUNNABLE`. Pour savoir si une opération est en cours d'exécution, accédez à l'onglet Opérations et vérifiez l'état de la dernière opération.
Configurez l'espace de stockage pour tenir compte de la maintenance critique des bases de données.	Si le paramètre d'activation de l'augmentation automatique de l'espace de stockage est désactivé ou si la limite d'augmentation automatique de l'espace de stockage est activée, assurez-vous de disposer d'au moins 20 % d'espace disponible pour prendre en charge toutes les opérations de maintenance de base de données critiques que Cloud SQL peut effectuer. Pour recevoir des alertes lorsque l'espace disque disponible est inférieur à 20 %, créez une règle d'alerte basée sur les métriques pour l'utilisation du disque avec une position au-dessus du seuil et une valeur de 0,8. Pour en savoir plus, consultez la page Créer des règles d'alerte basées sur des métriques.
Évitez de trop solliciter votre processeur.	Vous pouvez afficher le pourcentage de processeur disponible utilisé par votre instance sur la page "Informations sur l'instance" de la console Google Cloud. Pour en savoir plus, consultez l'article Métriques. Vous pouvez également surveiller votre utilisation du processeur et recevoir des alertes à un seuil spécifié à l'aide de la procédure décrite dans Créer des règles d'alerte basées sur un seuil de métrique. Pour éviter toute surutilisation, vous pouvez augmenter le nombre de processeurs de votre instance. La modification du nombre de processeurs nécessite un redémarrage de l'instance. Si l'instance est déjà au nombre maximal de processeurs, segmentez la base de données sur plusieurs instances.
Évitez l'épuisement de la mémoire.	Lorsque vous recherchez des signes d'épuisement de la mémoire, vous devez principalement utiliser la métrique usage. Pour éviter les erreurs liées à une mémoire insuffisante, nous vous recommandons de maintenir cette métrique à un niveau inférieur à 90 %. Vous pouvez également utiliser la métrique total_usage pour observer le pourcentage de mémoire disponible utilisé par votre instance Cloud SQL, y compris la mémoire utilisée par le conteneur de base de données et la mémoire allouée par le cache du système d'exploitation. En observant la différence entre les deux métriques, vous pouvez identifier la quantité de mémoire utilisée par les processus par rapport à la quantité utilisée par le cache du système d'exploitation. Vous pouvez réutiliser la mémoire dans ce cache. Pour prédire les problèmes de mémoire insuffisante, vérifiez les deux métriques et interprétez-les ensemble. Si les métriques semblent élevées, l'instance peut être à court de mémoire. Cela peut être dû à une configuration personnalisée, au sous-dimensionnement de l'instance pour la charge de travail ou à une combinaison de ces facteurs. Mettez à l'échelle votre instance Cloud SQL pour augmenter la taille de sa mémoire. La modification de la taille de la mémoire de l'instance nécessite un redémarrage de l'instance. Si l'instance est déjà à la taille maximale de la mémoire, vous devez segmenter votre base de données sur plusieurs instances. Pour en savoir plus sur la surveillance des deux métriques dans la console Google Cloud, consultez la page Métriques.
Définissez les paramètres SQL Server de sorte qu'ils fonctionnent de manière optimale pour Cloud SQL.	Consultez la page Paramètres SQL Server.
Optimisez le fonctionnement de l'instance pour les tests.	Le tableau suivant regroupe les valeurs de configuration adaptées aux tests. CPU virtuel : `40` Mémoire : `262144 MB` MAXDOP : `8` Seuil de coût pour le parallélisme : `120` Fichiers tempdb : `8`. Taille présélectionnée pour empêcher l'augmentation automatique. Fichiers de base de données utilisateur : augmentation automatique définie dans `64-128` Mo. Taille présélectionnée pour empêcher l'augmentation automatique. Stockage : `>= 4TB` pour les meilleures IOPS
Déterminez la capacité du sous-système des opérations d'E/S avant de déployer SQL Server.	Testez différents types et tailles d'E/S. La taille des E/S attribuées au stockage sur disque persistant provenant de SQL Server affecte les IOPS et le débit. La charge de travail SQL Server est limitée lorsqu'elle atteint la limite d'IOPS ou le débit maximal. Le type de stockage utilisé dans Cloud SQL est le disque persistant SSD, qui est adapté aux charges de travail hautes performances de l'entreprise. Personnalisez la VM pour optimiser les performances en procédant comme suit : Une taille de disque de 4 To ou plus fournit davantage de débit et d'IOPS. Plus le nombre de processeurs virtuels est élevé, plus le nombre d'IOPS et le débit sont élevés. Lorsque vous utilisez un nombre de processeurs virtuels plus élevé, surveillez les temps d'attente de la base de données pour le parallélisme, qui peuvent également augmenter. Pour des performances optimales, émettez des E/S en parallèle afin d'augmenter la profondeur de la file d'attente d'E/S.
Empêchez la fragmentation des index et les index manquants.	Réorganisez votre index ou configurez une planification pour recréer votre index en fonction de la fréquence de modification de vos données. Définissez également un facteur de remplissage approprié pour réduire la fragmentation. Surveillez SQL Server pour détecter les index manquants susceptibles d'améliorer les performances.
Mettez à jour les statistiques régulièrement.	Si les statistiques sont obsolètes, l'optimiseur de requête SQL peut générer des plans de requête non optimaux. Mettez à jour les statistiques, en particulier après la modification de grandes quantités de données. Utilisez le magasin de requêtes pour surveiller le serveur SQL dont les plans de requêtes ne sont pas optimaux et résoudre les problèmes associés.
Empêchez les fichiers de base de données d'être excessivement volumineux.	Définissez `autogrow` en Mo plutôt que sous forme de pourcentage, en utilisant des incréments adaptés à l'exigence. Gérez également la croissance de manière proactive avant le démarrage de la croissance automatique. Assurez-vous également que la fonctionnalité Cloud SQL Activer l'augmentation automatique de l'espace de stockage est activée, afin que Cloud SQL puisse ajouter de l'espace de stockage si celui de la base de données et de l'instance est insuffisant.
Détectez les problèmes d'intégrité de la base de données en exécutant `DBCC CHECKDB` au moins une fois par semaine.	`DBCC CHECKDB` vérifie l'intégrité de tous les objets d'une base de données. En exécutant `DBCC CHECKDB` chaque semaine, vous pouvez vous assurer que vos bases de données ne sont pas corrompues. `DBCC CHECKDB` est une opération nécessitant beaucoup de ressources qui peut affecter les performances de votre instance. N'exécutez pas `DBCC CHECKDB` sur un serveur de production. Nous vous recommandons d'utiliser l'une des options suivantes au lieu d'exécuter `DBCC CHECKDB` sur un serveur de production : Clonez une base de données et exécutez `DBCC CHECKDB` sur cette base de données clonée. Restaurez une sauvegarde sur une autre instance, puis exécutez `DBCC CHECKDB` sur les bases de données de l'instance restaurée. Pour en savoir plus sur la restauration d'une instance, consultez la section Restaurer une instance. Utilisez les extraits de code suivants pour exécuter `DBCC CHECKDB` sur une base de données : (Recommandé) Exécutez `DBCC CHECKDB` avec `EXTENDED_LOGICAL_CHECKS`. Il s'agit d'un contrôle complet, mais plus gourmand en ressources. USE `DATABASE_NAME` DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS Exécutez `DBCC CHECKDB` avec `PHYSICAL_ONLY` : USE `DATABASE_NAME` DBCC CHECKDB WITH PHYSICAL_ONLY, NO_INFOMSGS, ALL_ERRORMSGS

Architecture de données

Bonne pratique	En savoir plus
Dans la mesure du possible, scindez vos instances volumineuses en instances plus petites.	Lorsque cela est possible, l'utilisation de nombreuses instances Cloud SQL plus petites est préférable à une instance de grande taille. La gestion d'une instance monolithique de grande taille présente des défis que ne pose pas un groupe d'instances plus petites.
N'utilisez pas trop de tables de base de données.	Le nombre de tables de votre instance doit être inférieur à 10 000. Un trop grand nombre de tables de base de données peut influer sur le temps de mise à niveau de la base de données.
Classement des bases de données	Que vous procédiez à l'installation d'une nouvelle instance SQL Server, la restauration d'une sauvegarde de base de données ou la connexion d'un serveur à des bases de données clientes, il est important de comprendre les exigences locales, l'ordre de tri, ainsi que la sensibilité à la casse et aux accents des données sur lesquelles vous travaillez. Lorsque vous sélectionnez un classement pour votre serveur, base de données, colonne ou expression, vous attribuez certaines caractéristiques à vos données. Ces caractéristiques affectent les résultats de nombreuses opérations dans la base de données. Par exemple, lorsque vous créez une requête en utilisant`ORDER BY`, l'ordre de tri de votre ensemble de résultats peut dépendre du classement appliqué à la base de données ou dicté dans une clause `COLLATE` au niveau de l'expression de la requête. En savoir plus sur le classement des bases de données et la compatibilité avec Unicode
Conception de requêtes	Pour optimiser les performances des bases de données ou des requêtes, veillez à ne pas utiliser un grand nombre de tables dans la même requête (seize ou plus).
Surveillance des requêtes	Les requêtes peuvent se dégrader dans le temps. Il est important de surveiller les performances de vos applications et de vos requêtes au fil du temps. Les interruptions de hachage peuvent être l'une des raisons de cette dégradation. Les jointures de hachage récursives ou les interruptions de hachage entraînent une baisse des performances sur un serveur. Si vous rencontrez de nombreux événements de type hash warning dans une trace, mettez à jour les statistiques des colonnes en cours de jointure. En savoir plus sur les interruptions de hachage.

Mise en œuvre de l'application

Bonne pratique	En savoir plus
Utilisez de bonnes pratiques de gestion des connexions, telles que le regroupement de connexions et l'intervalle exponentiel entre les tentatives.	Ces techniques améliorent l'utilisation des ressources de votre application et vous aident à respecter les limites de connexion de Cloud SQL. Pour en savoir plus et pour obtenir des exemples de code, consultez la page Gérer les connexions à la base de données.
Testez la réponse de votre application aux mises à jour de maintenance qui peuvent se produire à tout moment pendant l'intervalle de maintenance.	Essayez la maintenance en libre-service pour simuler une mise à jour de maintenance. Pendant la maintenance, votre instance devient indisponible pendant une courte période et les connexions existantes sont supprimées. Tester les déploiements de maintenance permet de mieux comprendre comment votre application gère la maintenance planifiée et à quel rythme le système peut récupérer.
Testez la réponse de votre application aux basculements qui peuvent se produire à tout moment.	Vous pouvez déclencher un basculement manuellement à l'aide de la console Google Cloud, de gcloud CLI ou de l'API. Consultez la page Déclencher un basculement.
Évitez les transactions volumineuses.	Effectuez de petites transactions. Si une base de données volumineuse doit être mise à jour, faites-le en plusieurs petites transactions plutôt qu'en une seule grosse transaction.
Si vous utilisez le proxy d'authentification Cloud SQL, assurez-vous de bien utiliser la version la plus récente.	Consultez la section Maintenir le proxy d'authentification Cloud SQL à jour.

Importer et exporter des données

Bonne pratique	En savoir plus
Accélérez les importations pour les petites instances.	Pour les petites instances, vous pouvez temporairement augmenter le nombre de processeurs et la quantité de mémoire RAM d'une instance afin d'améliorer la performance en cas d'importation de grands ensembles de données.
Si vous exportez des données à importer dans Cloud SQL, veillez à suivre la procédure appropriée.	Consultez la page Exporter des données à partir d'un serveur de base de données géré en externe.

Sauvegarde et récupération

Bonne pratique	En savoir plus
Protégez vos données à l'aide de la fonctionnalité Cloud SQL appropriée.	Les sauvegardes et les exportations sont deux façons d'assurer la redondance et la protection des données. Ces approches permettent l'une et l'autre d'éviter différents scénarios indésirables et se complètent dans le cadre d'une stratégie efficace de protection des données. Les sauvegardes sont légères. Elles permettent de restaurer les données de votre instance dans l'état où elles se trouvaient au moment de la sauvegarde. Cependant, les sauvegardes ont certaines limites. Si vous supprimez l'instance, les sauvegardes sont également supprimées. Vous ne pouvez pas sauvegarder une seule base de données ou une seule table. De plus, si la région dans laquelle se trouve l'instance n'est pas disponible, vous ne pouvez pas restaurer l'instance à partir de cette sauvegarde, même dans une région disponible. Les exportations prennent plus de temps, car un fichier externe est créé dans Cloud Storage pour recréer vos données. Les exportations ne sont pas affectées si vous supprimez l'instance. En outre, vous ne pouvez exporter qu'une seule base de données, voire une seule table, en fonction du format d'exportation choisi. Lorsque vous utilisez la fonctionnalité d'exportation de sauvegarde sur une instance SQL Server Enterprise ou Standard, évitez de créer un fichier d'archive GZ, car il tentera de compresser une sauvegarde déjà compressée de manière native par SQL Server.
Protégez votre instance et vos sauvegardes contre toute suppression accidentelle.	Une instance Cloud SQL que vous créez dans la console Google Cloud ou via Terraform active par défaut la protection contre la suppression accidentelle. Utilisez la fonctionnalité d'exportation de Cloud SQL pour exporter vos données afin de bénéficier d'une protection supplémentaire. Utilisez Cloud Scheduler avec l'API REST pour automatiser la gestion des exportations. Pour les scénarios plus avancés, utilisez Cloud Scheduler avec les fonctions Cloud Run pour l'automatisation.

Bonne pratique

Protégez vos données à l'aide de la fonctionnalité Cloud SQL appropriée.

Les sauvegardes et les exportations sont deux façons d'assurer la redondance et la protection des données. Ces approches permettent l'une et l'autre d'éviter différents scénarios indésirables et se complètent dans le cadre d'une stratégie efficace de protection des données.

Les sauvegardes sont légères. Elles permettent de restaurer les données de votre instance dans l'état où elles se trouvaient au moment de la sauvegarde. Cependant, les sauvegardes ont certaines limites. Si vous supprimez l'instance, les sauvegardes sont également supprimées. Vous ne pouvez pas sauvegarder une seule base de données ou une seule table. De plus, si la région dans laquelle se trouve l'instance n'est pas disponible, vous ne pouvez pas restaurer l'instance à partir de cette sauvegarde, même dans une région disponible.

Les exportations prennent plus de temps, car un fichier externe est créé dans Cloud Storage pour recréer vos données. Les exportations ne sont pas affectées si vous supprimez l'instance. En outre, vous ne pouvez exporter qu'une seule base de données, voire une seule table, en fonction du format d'exportation choisi.

Lorsque vous utilisez la fonctionnalité d'exportation de sauvegarde sur une instance SQL Server Enterprise ou Standard, évitez de créer un fichier d'archive GZ, car il tentera de compresser une sauvegarde déjà compressée de manière native par SQL Server.

Protégez votre instance et vos sauvegardes contre toute suppression accidentelle.

Une instance Cloud SQL que vous créez dans la console Google Cloud ou via Terraform active par défaut la protection contre la suppression accidentelle.

Utilisez la fonctionnalité d'exportation de Cloud SQL pour exporter vos données afin de bénéficier d'une protection supplémentaire. Utilisez Cloud Scheduler avec l'API REST pour automatiser la gestion des exportations. Pour les scénarios plus avancés, utilisez Cloud Scheduler avec les fonctions Cloud Run pour l'automatisation.

Paramètres SQL Server

Certains paramètres SQL Server sont recommandés pour Cloud SQL. Les rubriques suivantes décrivent certaines recommandations.

Paramètres de configuration généraux

Paramètre Recommandation

max worker threads Conservez la valeur par défaut de 0. Ce paramètre définit le nombre de threads disponibles pour SQL Server en fonction du nombre de processeurs. La valeur est calculée automatiquement par le moteur SQL Server au démarrage.

max server memory (MB)

Si vous ne spécifiez pas de valeur pour ce paramètre, SQL Server consomme autant de mémoire que possible jusqu'à atteindre 100 %. Si l'utilisation de la mémoire d'une instance Cloud SQL pour SQL Server est trop élevée, vous pouvez rencontrer des problèmes de performances. Pour en savoir plus sur l'utilisation de la mémoire pour SQL Server, consultez Surveiller l'utilisation de la mémoire.

Nous vous recommandons d'utiliser la formule suivante pour définir l'option de base de données
max server memory :

Réservez 1,4 Go de mémoire pour le système d'exploitation et les agents.
Si la RAM du serveur est inférieure ou égale à 16 Go, réservez 1 Go de mémoire pour chaque RAM de 4 Go.
Si la RAM sur le serveur est supérieure à 16 Go, laissez 4 Go de mémoire et réservez 1 Go de mémoire pour chaque RAM de 8 Go au-delà de 16 Go.

Par exemple, si la RAM de votre instance est de 104 Go
(106 496 Mo), réservez :

1,4 Go de mémoire pour le système d'exploitation et les agents.
4 Go de mémoire, car 104 Go est supérieur à 16 Go.
11 Go de mémoire, car il y a 88 Go de RAM, ce qui est supérieur à 16 Go (104 - 16 = 88), et 88 divisé par 8 est égal à 11.

Dans cet exemple, vous devez réserver 16,4 Go de mémoire. Par conséquent, pour la valeur de cette option, spécifiez 89702 Mo
[(104 - 16,4) * 1 024 = 89 702].

Le tableau suivant présente les valeurs et les pourcentages de RAM totale recommandés pour certains niveaux de machine virtuelle (VM) courants :

Niveau d'instance (Mo)	Mémoire maximale du serveur (Mo)	% (total)
3 840	1440	37
4 096	1632	39
5792	2912	50
8 192	4704	57
11584	7248	62
16 384	10848	66
23168	16800	72
32 768	25200	76
46336	37072	80
65568	53888	82
92704	77648	83
131136	111248	84
185440	158784	85
262272	226000	86
370880	321056	86
524544	455488	86
741792	645600	87

Pour surveiller l'utilisation de la mémoire de votre instance, utilisez les métriques suivantes :

database/memory/usage
database/sqlserver/memory/buffer_cache_hit_ratio
database/sqlserver/memory/memory_grants_pending
database/sqlserver/memory/page_life_expectancy

Pour en savoir plus, consultez la page Surveiller des instances Cloud SQL.

Paramètres de base de données à modifier

Pour des performances optimales de la base de données SQL Server, définissez les paramètres SQL Server comme indiqué ci-dessous.

Paramètre	Recommandation
`cost threshold for parallelism`	Il s'agit du seuil auquel l'optimiseur SQL exécute une requête à l'aide du parallélisme. La valeur par défaut de `5` peut entraîner l'exécution d'un nombre trop élevé de requêtes en parallèle, ce qui augmente le temps d'attente de la base de données sur les threads parallèles. Pour réduire ce type de conflit, augmentez la valeur. La valeur est ignorée lorsque la valeur de `maxdop` est définie sur `1`.
`max degree of parallelism (MAXDOP)`	Pour réduire les temps d'attente de la base de données en raison du parallélisme, ajustez cette valeur en fonction de recommandations spécifiques concernant le nombre de processeurs logiques disponibles. Mesurez attentivement les performances si vous définissez cette option sur 1.
`optimize for ad hoc workloads`	Évitez de disposer d'un grand nombre de plans à usage unique dans le cache de plans. Pour améliorer l'efficacité du cache de plans pour les charges de travail contenant de nombreux lots ad hoc à usage unique, définissez cette option sur `1`.
`tempdb`	Présélectionnez la taille `tempdb` pour qu'elle n'ait pas besoin d'augmenter automatiquement. Tous les fichiers de `tempdb` doivent être de taille égale et avoir la même croissance de fichier. Le type d'attente de la base de données pour les conflits de `tempdb` apparaît sous la forme `PAGELATCH_UP`. Pour réduire les conflits, ajoutez d'autres fichiers. Si le nombre de processeurs est inférieur ou égal à 8, utilisez le même nombre de fichiers que de processeurs logiques. Si le nombre de processeurs est supérieur à 8, utilisez 8 fichiers de données. Si les conflits se poursuivent, augmentez le nombre de fichiers par des multiples de 4 jusqu'à ce qu'il n'y ait plus de conflit.

En fonction de votre charge de travail, vous pouvez également modifier les paramètres suivants.

Paramètre	Recommandation
`Close Cursor on Commit Enabled`	La valeur par défaut est `off`, ce qui signifie que les curseurs ne sont pas fermés automatiquement lorsque vous effectuez le commit d'une transaction.
`Default Cursor`	Cette option contrôle le champ d'application d'un curseur utilisé dans le code T-SQL. Si vous modifiez ce paramètre, évaluez les effets indésirables au niveau du code de l'application.
`Page Verify`	Cette option permet à SQL Server de calculer une somme de contrôle pour une page de base de données avant l'écriture sur le disque et de la stocker dans l'en-tête de la page. Lorsqu'une page est lue à nouveau, la somme de contrôle est recalculée pour vérifier l'intégrité de la page. La valeur recommandée est `checksum`.
`Parameterization`	La valeur par défaut est `simple`. Le paramétrage simple permet à SQL Server de remplacer les valeurs littérales d'une requête par des paramètres. Microsoft fournit des instructions pour modifier cette valeurs et l'utiliser avec les guides de plan.

Paramètres de base de données à conserver

Pour des performances optimales de la base de données SQL Server, conservez les valeurs par défaut des paramètres SQL Server suivants.

Paramètre	Valeur par défaut à conserver
`Auto Close`	`False` : ce paramètre, lorsqu'il est activé, ouvre et ferme les connexions et purge la procédure après chaque connexion. Cela peut entraîner la dégradation des performances des bases de données fréquemment consultées.
`Auto Shrink`	`False` : l'activation de cette fonctionnalité peut entraîner une fragmentation de la base de données et des index, ainsi que d'autres problèmes de performances. Certains d'entre eux sont abordés dans le blog SQL Server.
`Date Correlation Optimization Enabled`	`False` : son activation peut permettre à l'optimiseur de rechercher et d'optimiser les relations entre les dates de deux tables associées. Le suivi de ces opérations dans SQL Server peut altérer les performances.
`Legacy Cardinality Estimation`	`False` : dans certains cas, SQL Server ne peut pas calculer avec précision les cardinalités lorsque ce paramètre est activé.
`Parameter Sniffing`	`ON` L'extraction de paramètres à partir de tables de base de données peut aider à créer des plans d'exécution à réutiliser. Si les données sont réparties de manière inégale, les plans d'exécution qui en résultent peuvent entraîner des problèmes de performances. Avec ces données, utilisez d'autres options du Query Store plutôt que de modifier ce paramètre.
`Query Optimizer Fixes`	`False` : lorsque cette option est activée, elle peut affecter l'outil d'estimation de la cardinalité SQL Server. Si vous choisissez de l'activer, assurez-vous qu'il n'y a pas de régression de la requête.
`Auto Create Statistics`	`True` : cette option permet à SQL Server de créer des statistiques à une colonne qui peuvent améliorer les estimations de cardinalité pour les plans de requête.
`Auto Update Statistics`	`True` : cette option permet à SQL Server de mettre à jour les statistiques obsolètes à l'aide d'un seuil de recompilation basé sur la cardinalité des tables.
`Auto Update Statistics Asynchronously`	`False` : cette option, lorsqu'elle est activée, indique à l'optimiseur de requêtes SQL d'utiliser les statistiques obsolètes pour l'exécution de la requête en cours, tout en mettant à jour les statistiques de manière asynchrone pour bénéficier de charges de travail futures. Toutefois, si vous prévoyez un temps de réponse prévisible pour une requête fréquemment exécutée ou si votre application rencontre fréquemment des délais avant expiration pour les requêtes client dans l'attente des mises à jour des statistiques, envisagez d'activer cette option et de désactiver `Auto Update Statistics`.
`Target Recovery Time (Seconds)`	`60` : ce paramètre définit une limite supérieure pour le temps de récupération d'une base de données en vidant les pages modifiées plus ou moins fréquemment sur le disque à partir du pool de mémoire tampon. Pour les charges de travail hautement transactionnelles, une valeur inférieure pour ce paramètre, associée à une valeur IOPS de stockage proche de la valeur maximale, peut contribuer à un goulot d'étranglement des performances.

Paramètres des indicateurs de trace

Les indicateurs de trace dans SQL Server permettent de définir certaines caractéristiques, de modifier le comportement des bases de données SQL Server ou de résoudre les problèmes liés à SQL Server.

Certains indicateurs de trace SQL Server sont compatibles avec Cloud SQL et peuvent être définis à l'aide d'options de base de données. Les paramètres recommandés sont les suivants :

Indicateur de trace	Recommandé
`1204`	`Yes`, sauf pour les serveurs exigeants en charge de travail qui génèrent de nombreux interblocages. Renvoie les ressources et les types de verrous participant à un interblocage, ainsi que la commande actuellement affectée.
`1222`	`Yes`, sauf pour les serveurs exigeants en charge de travail qui génèrent de nombreux interblocages.
`1224`	`No` : cela peut entraîner une utilisation plus importante de la mémoire et provoquer une pression de mémoire sur la base de données.
`2528`	`No` La vérification parallèle des objets est recommandée par défaut. Elle est recommandée. Le degré de parallélisme est automatiquement calculé par le moteur de base de données.
`3205`	`No` : les lecteurs de bandes pour les sauvegardes sont une fonctionnalité de Cloud SQL pour SQL Server.
`3226`	`No`, sauf si vous avez besoin d'effectuer des sauvegardes fréquentes, telles que des sauvegardes TLOG.
`3625`	`No` : étant donné que le compte racine ne dispose pas d'accès administrateur système, il se peut qu'il ne puisse pas voir tous les messages d'erreur.
`4199`	`No` : cela affecte l'outil d'estimation de la cardinalité et peut entraîner une régression de la requête.
`4616`	`No` Cette restriction réduit la sécurité des rôles d'application. Elle doit être validée en fonction des exigences de l'application.
`7806`	`Yes` : si le serveur de base de données ne répond plus, la connexion d'administration dédiée peut être le seul moyen d'établir une connexion pour les diagnostics.

Étapes suivantes

Pour en savoir plus sur les bonnes pratiques par moteur de base de données, consultez les pages suivantes :