Utilisation de TempDB SQL Server 2012

Question

Nous avons une base de données de production de 60 Go dans ma nouvelle organisation. Nous exécutons près de 500 rapports pendant la nuit à partir de cette base de données. Je remarque que tous les scripts de rapport créent des tables dans TempDB, puis remplissent le rapport final. TempDB taille est de 6 GB. Aucune dépendance n'est définie pour ces scripts de rapport, appelés depuis PowerShell.

Est-ce une bonne pratique d'utiliser largement TempDB de cette manière? Ou est-il préférable de créer toutes les tables de transfert dans la base de données de production et de les supprimer après la génération du rapport?

Merci, Roopesh

Answer 1

tables temporaires toujours est créé dans tempdb. Cependant, il n'est pas nécessaire que la taille de TempDb soit uniquement due aux tables temporaires. Tempdb est utilisé de différentes façons

• objets internes (Trier & bobine, CTE, Reconstruire l'index, jointure de hachage etc.)
• objets utilisateur (table temporaire, les variables de table)
• magasin version (APRÈS/INSTEAD OF triggers, MARS)

Donc, comme il est clair qu'il est utilisé dans diverses opérations SQL, la taille peut augmenter également pour d'autres raisons. Cependant, dans votre cas, votre TempDb dispose de suffisamment d'espace pour fonctionner normalement et si votre processus interne utilise TempDb pour créer des tables temporaires et que cela ne pose aucun problème. Vous pouvez considérer TempDb comme une toilette pour SQL Server.

Vous pouvez vérifier ce qui est à l'origine TEMPDB croître sa taille avec ci-dessous requête

SELECT 
SUM (user_object_reserved_page_count)*8 as usr_obj_kb, 
SUM (internal_object_reserved_page_count)*8 as internal_obj_kb, 
SUM (version_store_reserved_page_count)*8 as version_store_kb, 
SUM (unallocated_extent_page_count)*8 as freespace_kb, 
SUM (mixed_extent_page_count)*8 as mixedextent_kb 
FROM sys.dm_db_file_space_usage 

si ci-dessus montre la requête,

• Un plus grand nombre d'objets utilisateur, cela signifie qu'il ya plus d'utilisation de Tables temporaires, curseurs ou variables temp
• Un nombre plus élevé d'objets internes indique que le plan de requête utilise beaucoup de base de données. Ex: tri, groupe par etc.
• Augmentation du nombre de magasins de version montre longue transaction en cours d'exécution ou le débit élevé de transactions

Vous pouvez surveiller TempDB via le script ci-dessus et d'identifier la cause réelle de sa croissance au premier. Cependant, 60 Go est une petite base de données avec 6 Go de taille TempDB est assez acceptable.

Une partie de la réponse ci-dessus est copiée à partir de other answer à partir de SO.