Как я могу сказать, почему мой запрос занимает так много времени?

Question

У меня запрос, который занимает намного больше времени, чем обычно, и я не могу сказать, застрял ли он.

Запрос выглядит примерно так:

INSERT XXXXXX WITH (TABLOCK)
SELECT * FROM YYYYYY with (NOLOCK)
WHERE ZZZZZZZZ = 1

Это вставитсотни миллионов строк.У меня есть индекс на ZZZZZZZZ.

Нет блокирующих сессий.Когда я проверяю sys.dm_exec_requests, он показывает, что последний тип ожидания равен PAGEIOLATCH_SH Я не уверен, что это значит, за исключением того, что это как-то связано с вводом / выводом.

sys.dm_exec_sessions показывает, что статус RUNNING, но sp_who2 показывает его как SUSPENDED.

Я пытался увидеть, растет ли таблица, но когда я вызываю sp_spaceused XXXXXX, я получаю те же значения.* Что еще я могу сделать?

ОБНОВЛЕНИЕ:

С помощью ответов ниже я обнаружил, что проблема ввода / вывода , и в результате моего запроса в среднем вставляется около 600 записей в минуту ).

Каков мой следующий шаг?

Что я могу сделать, прежде чем начать предполагать, что мой диск работает плохо?

Answer 1

Если вы попробуете следующее

select * from sys.dm_os_waiting_tasks

, изменяется ли адрес ресурса, который он ожидает, при изменении?

select * 
into #t1
from sys.dm_os_wait_stats

waitfor delay '00:01'

select * 
into #t2
from sys.dm_os_wait_stats

SELECT #t2.wait_type, 
#t2.waiting_tasks_count - #t1.waiting_tasks_count as waiting_tasks_count, 
#t2.wait_time_ms- #t1.wait_time_ms as wait_time_ms, 
#t2.signal_wait_time_ms- #t1.signal_wait_time_ms as signal_wait_time_ms
FROM #t2  JOIN #t1 ON #t2.wait_type = #t1.wait_type
where #t2.wait_type not in ('CHECKPOINT_QUEUE','CHKPT','FT_IFTS_SCHEDULER_IDLE_WAIT',
'KSOURCE_WAKEUP',
'LAZYWRITER_SLEEP',
'LOGMGR_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH',
'SQLTRACE_BUFFER_FLUSH' ,
'XE_DISPATCHER_WAIT',
'XE_TIMER_EVENT', 'WAITFOR')
order by wait_time_ms desc       

Answer 2

Некоторые мысли, которые могут помочь со вставкой:

Есть ли какие-либо триггеры вставки на xxxxxx? Это может оказать значительное влияние на большую операцию вставки.

Есть ли некластеризованные индексы на xxxxxx, которые можно отключить во время загрузки? Это также очень помогло бы.

/* Before */
alter index YourIndex on xxxxxx disable
/* After */
alter index YourIndex on xxxxxx rebuild

Answer 3

Хорошо, звучит так, как будто вы находитесь в среде в стиле DW, перемещая много данных из одной таблицы в другую.Предполагая, что вы используете SQL Server 2008, см. Этот технический документ:

Руководство по повышению производительности загрузки данных

См. Разделы минимальное ведение журнала и другие.выключено переключение раздела .

Это помогает прочитать всю статью несколько раз, так что вы действительно понимаете, что происходит под обложками, и почему некоторые комбинации данных + индексирование работают, а другие нет.

Переключение разделов позволяет легко выполнить минимальное ведение журнала, поскольку оно дает пустую таблицу назначения и позволяет новым данным мгновенно поступать в оперативный режим после завершения загрузки.Возможно, потребуется корпоративная версия.

Answer 4

Вставка внутри транзакции? Если это так, вы можете попробовать проверить детали транзакции внутри Sys.Dm_tran_database_Transactions. Он показывает текущее количество записей, записанных в журнал транзакций, а также некоторые другие показатели состояния, которые должны изменяться с течением времени:

SELECT * FROM Sys.Dm_tran_Database_Transactions

Это ссылка на статью MSDN, в которой поясняются столбцы: Документация по столбцам MSDN

Надеюсь, что поможет

Answer 5

DW Таблица фактов?

http://books.google.com/books?id=eBacaL61sa4C&pg=PA268&lpg=PA268&dq=remove+index+when+updating+fact+table&source=bl&ots=MFB8HnmYRl&sig=w680N0GA3oSiJaS1mU_Z_WzW1VY&hl=en&ei=-EeOTKaQDtPyOeqZtLsK&sa=X&oi=book_result&ct=result&resnum=8&ved=0CD4Q6AEwBw#v=onepage&q&f=false

p268