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. Vous devez attendre quelques jours avant de pouvoir réutiliser l'ID d'une instance supprimée.
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 une 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 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.

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 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 vCPU (processeur virtuel) plus élevé, surveillez la base de données à l'attente du parallélisme, qui peut é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. Réorganisez votre index ou configurez une planification pour recréer votre index en fonction de la fréquence à laquelle vos données changent.
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.
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 que la croissance automatique ne s'active.

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.

Architecture de données

Bonne pratique En savoir plus
Partitionnez vos instances si possible. 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 posent pas des instances plus nombreuses et plus petites.
N'utilisez pas trop de tables de base de données.

Un trop grand nombre de tables de base de données peuvent influer sur le temps de réponse d'une instance. Par exemple, un nombre de tables supérieur à 10 000 aura une incidence sur la couverture de votre contrat de niveau de service. Pour en savoir plus, consultez la page Consignes opérationnelles.

Bien qu'il n'existe pas encore de consignes opérationnelles spécifiques concernant les instances SQL Server, les mêmes principes généraux s'appliquent.

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. 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. La modification du type de machine d'une instance est l'approche la plus semblable à une mise à jour de maintenance. Assurez-vous que l'application tente de se reconnecter à la base de données, en utilisant de préférence un intervalle exponentiel, pendant au moins 10 minutes, afin de s’assurer de redémarrer l'opération après un événement de maintenance. Pour en savoir plus, consultez la page Gérer les connexions à la base de données.
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 Cloud Console, de l'outil de ligne de commande gcloud 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 page 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.

Paramètres SQL Server

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

Paramètre de configuration globale

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.

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 de trop 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 maxdop est défini 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.

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 validez 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 négatifs du code d'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 vide la procédure après chaque connexion. Cela peut entraîner une 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 : l'activation de cette fonctionnalité 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 entraîne des frais de 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 résultants 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 les performances de 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 requêtes.
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 options 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.
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 le paramètre par défaut. Il est recommandé. 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 de 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.