Comment puis-je optimiser la consommation de stockage dans mon instance de base de données Amazon RDS for SQL Server ?

Lecture de 9 minute(s)

Mon instance de base de données SQL Server Amazon Relational Database Service (Amazon RDS) pour Microsoft SQL Server utilise plus de mémoire que prévu. Je souhaite optimiser l’espace de stockage de mon disque.

Brève description

Pour optimiser l’utilisation du stockage, commencez par résoudre les problèmes de stockage immédiats. Identifiez ensuite les composants qui consomment de l'espace. Si votre instance est à l’état Stockage plein, mettez à l’échelle votre stockage ou migrez vers une nouvelle instance de base de données RDS dotée d'une capacité de stockage suffisante. Si votre instance de base de données dispose d'un espace de stockage disponible, identifiez les composants qui consomment de l'espace et appliquez des techniques d'optimisation pour chaque composant.

Vous pouvez surveiller l'espace de stockage disponible d’une instance de base de données à l'aide de la métrique FreeStorageSpace dans Amazon CloudWatch. La métrique FreeStorageSpace ne décrit pas la manière dont le moteur SQL Server utilise le stockage disponible. Surveillez fréquemment cette métrique et activez l’autoscaling du stockage pour ne pas manquer d’espace de stockage.

Résolution

Résoudre les problèmes de stockage d'une instance Amazon RDS pour SQL Server à l'état Stockage plein

Vous ne pouvez pas effectuer des opérations de base lorsque votre instance de base de données est bloquée à l'état Stockage plein. Pour plus d’informations, consultez la section Comment puis-je résoudre les problèmes qui surviennent lorsque les instances de base de données Amazon RDS manquent d'espace de stockage ?

Certaines instances de base de données RDS for SQL Server présentent des limites quant à la manière dont vous pouvez modifier le stockage. Si votre instance de base de données n'est pas éligible à la modification, l'option Stockage alloué de la console RDS est désactivée.

Remarque : Le stockage à grande échelle et l’autoscaling du stockage ne sont pas pris en charge dans les instances RDS for SQL Server qui utilisent un stockage magnétique.

Pour mettre à l’échelle le stockage sur une instance lorsque l'option de modification n'est pas disponible, utilisez la sauvegarde et la restauration natives pour migrer vos données vers une nouvelle instance de base de données. Puis, vérifiez que la nouvelle instance de base de données dispose d'entrées/sorties par seconde (IOPS) provisionnées ou utilise le type de stockage à usage général (SSD). Vous pouvez également utiliser AWS Database Migration Service (AWS DMS) pour migrer vos données vers la nouvelle instance de base de données. Pour plus d'informations, consultez la section Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS.

Pour voir les options de stockage valides pour votre instance de base de données, exécutez la commande describe-valid-db-instance-modifications suivante :

describe-valid-db-instance-modifications

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'AWS CLI.

Pour les instances de base de données pour lesquelles l’autoscaling de stockage est activé, l'extension automatique du stockage ne se produit que lorsque des conditions spécifiques existent. Si l’autoscaling n'étend pas votre espace de stockage comme prévu, vous pouvez l'étendre manuellement. Cependant, notez que l'extension de stockage automatique et manuelle comporte des limites. Pour plus d'informations sur les conditions et les limites de l’autoscaling, consultez la section Gestion automatique de la capacité avec l’autoscaling du stockage Amazon RDS.

Analyser l’utilisation du stockage par base de données

Pour obtenir des informations sur l'utilisation de l'espace disque physique pour votre instance de base de données RDS for SQL Server, exécutez une requête similaire à l'exemple suivant :

SELECT D.name AS [database_name]    
    , F.name AS [file_name]
    , F.type_desc AS [file_type]
    , CONVERT(decimal(10,2), F.size * 0.0078125) AS [size_on_disk_mb]
    , CONVERT(decimal(10,2), F.max_size * 0.0078125) AS [max_size_mb]
FROM sys.master_files AS F
INNER JOIN sys.databases AS D
    ON F.database_id = D.database_id;

Les fichiers de type ROWS contiennent les données de votre base de données, tandis que les fichiers de type LOGS contiennent des journaux de transactions pour les transactions en cours.

Pour plus d'informations, consultez la page sys.master_files (Transact-SQL) sur le site Web de Microsoft.

Remarque : La vue système sys.master_files indique la taille de démarrage de tempdb. Cela ne reflète pas la taille actuelle de tempdb.

Pour vérifier la taille actuelle de tempdb, exécutez la requête suivante :

select name AS [database_name], physical_name AS [file_name],
convert(decimal(10,2),size*0.0078125) AS [size_on_disk_mb]
from tempdb.sys.database_files;

Comprendre le stockage du moteur SQL Server

Pour optimiser votre stockage, identifiez d'abord les composants qui consomment le plus d'espace et comprenez comment le moteur SQL Server utilise le stockage. Le stockage du moteur SQL Server inclut les catégories suivantes.

Fichiers de base de données

Vous pouvez décomposer le stockage total utilisé par une base de données individuelle en lignes, index et espace libre dans la base de données actuellement active. Pour ventiler l'espace de stockage total, exécutez la requête suivante :

use db_name
EXEC sp_spaceused;

Remarque : Remplacez db_name par le nom de votre base de données.

Fichiers journaux de transactions

Pour déterminer la quantité de stockage utilisée par les journaux de transactions, exécutez la requête suivante :

DBCC SQLPERF(LOGSPACE)

Pour plus de détails sur l'utilisation de l'espace de journal pour chaque base de données, exécutez la requête suivante :

use db_name;

    SELECT
    DB_NAME() AS [Database Name],
    ls.total_log_size_in_bytes / 1048576.0 AS [Total Log Size in MB],
    ls.used_log_space_in_bytes / 1048576.0 AS [Used Log Size in MB],
    (ls.total_log_size_in_bytes - ls.used_log_space_in_bytes) / 1048576.0 AS [Free Log Space in MB],
    ls.used_log_space_in_percent AS [Used Log Space in %],
    ls.log_space_in_bytes_since_last_backup / 1048576.0 AS [Log Since Last Log Backup in MB],
    dls.log_backup_time AS [Last Log Backup Time]
FROM
    sys.dm_db_log_space_usage AS ls
CROSS APPLY
    sys.dm_db_log_stats(DB_ID()) AS dls;

Remarque : Remplacez db_name par le nom de votre base de données.

Il est possible que vous observiez de l'espace libre dans les journaux de transactions. Pour libérer un espace libre excessif, exécutez la commande DBCC SHRINKFILE. Pour plus d'informations, consultez la page DBCC SHRINKFILE (Transact-SQL) sur le site Web de Microsoft.

Pour réduire l'allocation excessive d'espace libre pour les journaux de transactions, utilisez les options de fichier et de groupe de fichiers ALTER DATABASE (transact-SQL). Les options configurent les paramètres de croissance automatique de la base de données. Pour plus d'informations, consultez la page Options de fichiers et de groupes de fichiers ALTER DATABASE (Transact-SQL) sur le site Web de Microsoft.

Base de données temporaire (tempdb)

La base de données tempdb de SQL Server s'agrandit automatiquement. Si la base de données tempdb consomme une grande quantité de stockage disponible, vous pouvez réduire la base de données tempdb.

Remarque : Si vous réduisez une base de données tempdb, vérifiez l’existence de messages d’erreur dans l’onglet Message de SQL Server Management Studio (SSMS) après avoir exécuté la commande.

Si vous recevez une erreur « DBCC SHRINKFILE : Page could not be moved because it is a work table page », consultez les pages DBCC FREESYSTEMCACHE (Transact-SQL) et DBCC FREEPROCCACHE (Transact-SQL) sur le site Web de Microsoft. Vous pouvez également redémarrer l'instance de base de données pour effacer la base de données tempdb.

Il est possible que les instances de base de données dont le stockage est plein ne parviennent pas à redémarrer. Dans ce cas, augmentez le stockage alloué à votre instance de base de données, puis effectuez une nouvelle tentative de redémarrage. Pour plus d’informations, consultez la section Comment puis-je résoudre les problèmes qui surviennent lorsque les instances de base de données Amazon RDS manquent d'espace de stockage ?

Index de base de données

Si vous consacrez une grande partie de votre espace de stockage disponible aux index, vérifiez si le réglage des index permet d'économiser de l'espace. Pour obtenir des informations sur l'utilisation des index, exécutez la requête de vue de gestion dynamique sys.dm_db_index_usage_stats. Pour obtenir des exemples de requêtes et des informations sur la requête de vue de gestion dynamique, consultez la page sys.dm_db_index_usage_stats (Transact-SQL) sur le site Web de Microsoft. Il est recommandé de supprimer les index inutilisés pour récupérer de l'espace. Cela peut vous aider à évaluer les priorités de réglage.

Fichiers de suivi

Les fichiers de suivi, y compris les fichiers C2 Audit Trace et les fichiers de vidage, peuvent consommer une grande quantité d'espace disque. RDS supprime automatiquement les fichiers de suivi et de vidage datant de plus de 7 jours. Toutefois, vous pouvez également ajuster les paramètres de conservation de vos fichiers de suivi.

Espace consommé par l'intégration d'Amazon S3

Si vous avez intégré votre instance de base de données à Amazon Simple Storage Service (Amazon S3), vérifiez si vous avez chargé des fichiers sur votre lecteur D:. Pour vérifier la quantité d'espace utilisée par votre intégration S3, utilisez la procédure stockée rds_gather_file_details et la fonction rds_fn_list_file_details pour répertorier les fichiers de votre instance de base de données. Pour plus d'informations, consultez la section Répertorier les fichiers sur l'instance de base de données RDS.

CDC

Lorsque vous activez la capture de données modifiées (CDC) pour une base de données, les modifications fréquentes apportées aux tables source ou aux bases de données augmentent la taille du fichier journal. L'espace de stockage est peut-être épuisé. Si le disque journal est plein, le CDC ne peut pas traiter d'autres transactions.

Audit

Si l'audit n'est pas configuré correctement pour une instance de base de données, les journaux peuvent augmenter de façon exponentielle et affecter le stockage. Pour plus d'informations, consultez la section SQL Server Audit.

Le mode d'audit C2 enregistre une grande quantité d'informations sur les événements dans le fichier journal. Le fichier journal peut s'agrandir rapidement et placer l'instance de base de données à l’état Stockage plein. Pour plus d'informations, consultez la page Configuration du serveur : mode d'audit c2 sur le site Web de Microsoft.

En outre, si vous activez des fonctionnalités telles que le stockage des requêtes, celles-ci peuvent augmenter l'utilisation de vos ressources.