Bonnes pratiques générales

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.

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.

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.

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.

• 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

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.

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.

• 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
        

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.

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.

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.

Cet indicateur limite la quantité de mémoire que Cloud SQL peut allouer à ses pools internes.

Si vous ne définissez pas de valeur pour cet indicateur, Cloud SQL la gère automatiquement en fonction de la taille de la RAM de votre instance. De plus, si vous redimensionnez votre instance, Cloud SQL ajuste automatiquement la valeur de l'indicateur pour respecter nos recommandations concernant la nouvelle taille de l'instance.

Nous vous recommandons vivement de ne pas spécifier de valeur pour cet indicateur pour vos instances. Si vous définissez cette valeur sur une valeur supérieure à 80%, vous risquez de rencontrer de l'instabilité, une dégradation des performances et des plantages de la base de données en raison de problèmes de mémoire insuffisante.

Si vous préférez gérer la valeur de cette option, définissez-la manuellement. Par conséquent, Cloud SQL désactive la gestion automatique. Si vous redimensionnez votre instance, envisagez de modifier la valeur pour qu'elle corresponde aux valeurs recommandées pour une nouvelle taille.

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 :

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.

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.

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.

É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.

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.

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.