Знайдіть, який сеанс проводить, який тимчасовий стіл


14

У нас є база даних SQL Server 2005, база даних temp стала повною. Зайшовши в студію управління SQL Server, я можу побачити всі тимчасові таблиці в tempdb. Чи можна сказати, який сеанс проводить таку тимчасову таблицю? В ідеалі запит, у якому перераховуються темп-таблиці, що використовуються кожним сеансом.

Дякую,


1
Ми хотіли б відстежити конкретного користувача, який використовує простір у базі даних temp.
Нас

Відповіді:


16

Я попросив щось збудувати ще в 2007 році на Connect. Його було відхилено до випуску 2008 року та згодом проігноровано, поки Connect не померла кілька років тому. Я намагався знайти його на новому сайті зворотного зв’язку для SQL Server , але цей пошук - це абсолютна пожежа сміттєзвалища. Назва мого запиту була "dmv to map temp table to session_id" - оскільки пошук може робити АБО, "map temp table" повертає 118 сторінок результатів. Google, здається, припускає, що предмет не зробив розріз, коли вони вбили Connect .

Тим часом для SQL Server 2005 та 2008 року ви повинні мати змогу витягнути цю інформацію із сліду за замовчуванням:

DECLARE @FileName VARCHAR(MAX)  

SELECT @FileName = SUBSTRING(path, 0,
   LEN(path)-CHARINDEX('\', REVERSE(path))+1) + '\Log.trc'  
FROM sys.traces   
WHERE is_default = 1;  

SELECT   
     o.name,   
     o.OBJECT_ID,  
     o.create_date, 
     gt.NTUserName,  
     gt.HostName,  
     gt.SPID,  
     gt.DatabaseName,  
     gt.TEXTData 
FROM sys.fn_trace_gettable( @FileName, DEFAULT ) AS gt  
JOIN tempdb.sys.objects AS o   
     ON gt.ObjectID = o.OBJECT_ID  
WHERE gt.DatabaseID = 2 
  AND gt.EventClass = 46 -- (Object:Created Event from sys.trace_events)  
  AND o.create_date >= DATEADD(ms, -100, gt.StartTime)   
  AND o.create_date <= DATEADD(ms, 100, gt.StartTime)

Безсоромно піднявся з цієї публікації блогу Джонатана Кехаяса .

Щоб визначити використання місця, ви можете додатково покращити це, щоб приєднатись до даних із видів, наприклад sys.db_db_partition_stats- наприклад:

DECLARE @FileName VARCHAR(MAX)  

SELECT @FileName = SUBSTRING(path, 0,
   LEN(path)-CHARINDEX('\', REVERSE(path))+1) + '\Log.trc'  
FROM sys.traces   
WHERE is_default = 1;  

SELECT   
     o.name,   
     o.OBJECT_ID,  
     o.create_date, 
     gt.NTUserName,  
     gt.HostName,  
     gt.SPID,  
     gt.DatabaseName,  
     gt.TEXTData,
     row_count = x.rc,
     used_page_count = x.upc
FROM sys.fn_trace_gettable( @FileName, DEFAULT ) AS gt  
JOIN tempdb.sys.objects AS o   
     ON gt.ObjectID = o.OBJECT_ID
INNER JOIN
(
 SELECT [object_id], SUM(row_count), SUM(used_page_count)
   FROM tempdb.sys.dm_db_partition_stats
   WHERE index_id IN (0,1)
   GROUP BY [object_id]
) AS x(id, rc, upc)
ON x.id = o.[object_id]
WHERE gt.DatabaseID = 2 
  AND gt.EventClass = 46 -- (Object:Created Event from sys.trace_events)  
  AND o.create_date >= DATEADD(ms, -100, gt.StartTime)   
  AND o.create_date <= DATEADD(ms, 100, gt.StartTime)

Проблема тут полягає у спробі співвіднести назву таблиці з текстом запиту; це просто не практично, оскільки більшість часу користувач все ще не виконує запит проти цієї таблиці (не майте на увазі, як і раніше працює той, хто створив / заселив його).

Однак, і це стосується інших читачів (або для вас, коли ви оновлюєтесь), за замовчуванням слід у 2012+ більше не відстежує створення об’єктів темп-таблиці , якщо таблиця #temp - це купа. Не впевнений, чи це збіг чи безпосередньо пов'язаний з тим, що починаючи з 2012 року, всі тимчасові таблиці мають мінусobject_id . Ви, звичайно, можете перейти до Розширених подій, щоб допомогти вам збирати та відслідковувати цю інформацію, але це, можливо, багато ручної роботи (і я лише переконався, що це більше не простежується в сліді - ви, можливо, не зможете її вибрати в розширених подіях). Трасування за замовчуванням буде підберіть таблиці #temp, створені з ПК або іншим обмеженням, або із обмеженнями або індексами, доданими після події створення, але тоді вам доведеться послабити вищезазначені часові обмеження (індекс можна створити набагато пізніше ніж через 100 мс після створення).

Ще кілька відповідей на цьому веб-сайті, які можуть бути корисними:

Я також вела блог про це, за допомогою спеціального сеансу розширених подій для відстеження цієї інформації в SQL Server 2012 і новіших версіях:

А Пол Уайт веде блог про читання сторінок безпосередньо (не саме для слабкого серця, ані легко автоматизувати жодним чином):


5

Ось запит, з якого слід почати дізнаватися інформацію, яку ви шукаєте:

select top 10
    tsu.session_id,
    tsu.request_id,
    r.command,
    s.login_name,
    s.host_name,
    s.program_name,
    total_objects_alloc_page_count = 
        tsu.user_objects_alloc_page_count + tsu.internal_objects_alloc_page_count,
    tsu.user_objects_alloc_page_count,
    tsu.user_objects_dealloc_page_count,
    tsu.internal_objects_alloc_page_count,
    tsu.internal_objects_dealloc_page_count,
    st.text
from sys.dm_db_task_space_usage tsu
inner join sys.dm_exec_requests r
on tsu.session_id = r.session_id
and tsu.request_id = r.request_id
inner join sys.dm_exec_sessions s
on r.session_id = s.session_id
outer apply sys.dm_exec_sql_text(r.sql_handle) st
where tsu.user_objects_alloc_page_count > 0
or tsu.internal_objects_alloc_page_count > 0
order by total_objects_alloc_page_count desc;

Цей запит містить корисну інформацію для 10 головних завдань, таких як сторінки, виділені / розміщені, текст SQL завдань (за наявності) тощо.

Ці DMV рясніють чудовою інформацією, тож якщо вам потрібно більше даних, ви можете змішати та співставити з тим, що ви тягнете. Але це має стати відправною точкою для усунення несправностей із поточними завданнями споживання tempdb.


Спасибі це виглядає досить добре. Дивна річ, якщо я запускаю звіт "Використання диска за верхніми таблицями" на tempdb, таблиця, яка використовує найбільше місця, не відображається в st.text. Таблиця все ще існує після запуску запиту.
SQLMIKE

1
@SQLMIKE, якщо ви просто хочете знати, яка таблиця найбільша, ви можете отримати її tempdb.sys.dm_db_partition_stats. На жаль, ви не можете #some_table_nameточно сказати, яка копія належить тому користувачеві, і ви не завжди зможете витягнути текст заяви, який посилається на цю таблицю в будь-який момент часу - це може бути не запитом, який користувач наразі виконує. Ви можете побачити це і це
Аарон Бертран
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.