web-dev-qa-db-fra.com

TEMPDB utilise beaucoup d'espace dans la piscine tampon

Je suis en cours d'exécution SQL Server 2014 avec 2 cœurs et une mémoire maximale de 6 Go. Quand je vérifie ce qui est dans la piscine tampon, je vois que TempDB utilise 1 Go de mémoire. Voilà la question que j'ai utilisé:

SELECT COUNT(*) AS cached_pages_count ,
(count(*) * 8.0)/1024 as MB,
        CASE database_id
          WHEN 32767 THEN 'ResourceDb'
          ELSE DB_NAME(database_id)
        END AS Database_name
    FROM sys.dm_os_buffer_descriptors
    GROUP BY DB_NAME(database_id) ,
        database_id
    ORDER BY cached_pages_count DESC;

Mais quand je vérifie ce que les tables sont en TempDB, il n'y a que 40 tables et ils utilisent 728KB. Ceci est la requête:

SELECT 
    t.NAME AS TableName,
    s.Name AS SchemaName,
    p.rows AS RowCounts,
    SUM(a.total_pages) * 8 AS TotalSpaceKB, 
    SUM(a.used_pages) * 8 AS UsedSpaceKB, 
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM sys.tables t
INNER JOIN sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN sys.schemas s ON t.schema_id = s.schema_id
GROUP BY  t.Name, s.Name, p.Rows
ORDER BY  t.Name

J'ai également vérifié sys.dm_db_session_space_usage pour voir s'il y avait une session qui a alloué tout cet espace dans tempdb

Mon cache de mémoire tampon est 2.2GB et près de 50% est prise par TempDB

Quelqu'un peut-il essayer d'expliquer pourquoi TempDB est si grand?

MISE À JOUR Je l'ai fait une DBCC PAGE de certaines pages trouvées dans les dm_os_buffer_descriptors et on dirait qu'ils ne sont pas attribués (GAM/SGAM Non Alloué, PFS 0_PCT_FULL)

PAGE HEADER:

Page @ 0x0000000DB026C000

m_pageId = (1: 159.735) m_headerVersion = 1
M_type = 1 m_typeFlagBits = 0x0 = 0 m_level
M_flagBits = 0x20 m_objId (AllocUnitId.idObj) = -1948083318
M_indexId (AllocUnitId.idInd) = 1 Metadata: AllocUnitId = 435280365092864 métadonnées: partitionID = 0 métadonnées: IndexId = -1 métadonnées: ObjectId = 0 m_prevPage = (1: 160.115) m_nextPage = (1: 160.144) = pminlen 13 m_slotCnt = 217 = 3406 m_freeCnt
M_freeData = 4352 m_reservedCnt = 0 m_lsn = (13668: 97392: 89) m_xactReserved = 0
M_xdesId = (0: 0) m_ghostRecCnt = 0 = 0 m_tornBits
DB Frag ID = 1

Statut d'allocation

GAM (1: 2) = Non attribué SGAM (1: 3) = non alloués
PFS (1: 153.672) = 0x0 0_PCT_FULL DIFF (1: 6) = pas changé
ML (1: 7) = NON MIN_LOGGED

sql-serversql-server-2014tempdbdatabase-internals
4
Frederik Vanderhaegen

Cela ressemble à une page de données (Type de page = 1) à partir d'une variable de table ou d'une table TEMP (ID d'objet négatif de -1948083318) dans la feuille d'un index en cluster (index = 1).

À partir des informations sur l'allocation et le fait que cela ne s'affiche pas dans votre deuxième requête vraisemblablement, l'objet sous-jacent a été supprimé. Vous pourrez peut-être obtenir des informations supplémentaires à ce sujet, telles que le nom d'objet d'origine, en recherchant cet identifiant d'unité d'allocation dans sys.fn_dblog si tu es chanceux.

S'il appartient à un objet abandonné, on espère certainement que ces pages sont les premiers candidats à la mise en place de la liste gratuite.

Cependant, l'article Fuite de la mémoire TEMPDB? et élément de connexion associé Indique qu'il pourrait y avoir un problème dans cette zone ...

2
Martin Smith