Avez-vous déjà reçu un appel au milieu de la nuit d’un client se plaignant de messages d’erreur dus à un TempDB plein? C’est un problème courant auquel de nombreux administrateurs SQL Server sont confrontés. Dans cet article, nous explorerons certains concepts et idées liés à TempDB dans SQL Server.

Lors du dépannage des problèmes de TempDB, l’une des premières étapes consiste à identifier quelles sessions ont des allocations dans TempDB. Cela peut être fait en utilisant la requête suivante:

SELECT session_id, database_id, user_objects_alloc_page_count + internal_objects_dealloc_page_count AS TotalAllocatedPages
FROM sys.dm_db_session_space_usage
ORDER BY TotalAllocatedPages DESC

Cependant, que se passe-t-il si la requête revient vide et que vous ne pouvez pas voir d’allocations qui expliqueraient l’espace occupé dans TempDB? C’est là que les choses deviennent intéressantes.

Si vous utilisez l’isolation de lecture engagée avec capture d’instantané (RCSI) ou l’isolation de lecture engagée avec capture d’instantané (RCSI), vous aurez également un magasin de versions dans votre base de données. Le magasin de versions est utilisé pour stocker les versions de lignes pour les transactions concurrentes. SQL Server maintient le magasin de versions réduit et ne conserve que les lignes nécessaires. Cependant, il ne peut effacer que les lignes plus anciennes que la transaction la plus ancienne, car il ne sait pas quelles lignes seront nécessaires par la transaction.

Cela nous amène à un problème potentiel – que se passe-t-il si quelqu’un laisse une transaction ouverte? Le magasin de versions commencera à se remplir. Pour vérifier cela, vous pouvez utiliser le script suivant:

USE tempdb
 
SELECT SUM(version_store_reserved_page_count) AS Version_Store_Reserved,
       SUM(user_object_reserved_page_count) AS User_Object_Reserved,
       SUM(internal_object_reserved_page_count) AS Internal_Object_Reserved,
       SUM(mixed_extent_page_count) AS Mixed_Extent
FROM sys.dm_db_file_space_usage

Ce script vous montrera où les pages de TempDB sont allouées. Si vous constatez que la plupart de l’espace est utilisé par le magasin de versions, la prochaine étape consiste à identifier les sessions qui s’exécutent depuis longtemps et qui pourraient empêcher le magasin de versions de se vider.

Vous pouvez utiliser la requête suivante pour trouver ces sessions:

SELECT session_id, elapsed_time_seconds
FROM sys.dm_tran_active_snapshot_database_transactions

Une fois que vous avez identifié la session qui pose problème, faites preuve de prudence lorsque vous tuez la session. La fin de la session effacera probablement le magasin de versions et résoudra les problèmes de TempDB, du moins jusqu’à ce que quelqu’un d’autre laisse une transaction ouverte.

Il est bon de surveiller régulièrement TempDB pour détecter ces problèmes avant qu’ils ne deviennent un problème. En fait, une prochaine version de notre outil Undercover Inspector inclura des fonctionnalités de surveillance et d’alerte TempDB, afin que vous puissiez anticiper tout problème potentiel de TempDB.

Comprendre TempDB et ses défis associés est crucial pour les administrateurs SQL Server. En suivant les étapes décrites dans cet article, vous pouvez résoudre efficacement les problèmes de TempDB, assurant un fonctionnement fluide de votre environnement SQL Server.