我的查询比往常花了很长时间，我不知道它是否卡住了。
查询是这样的：
INSERT XXXXXX WITH (TABLOCK)
SELECT * FROM YYYYYY with (NOLOCK)
WHERE ZZZZZZZZ = 1
这将插入数亿行。我有一个关于ZZZZZZZZ的索引。
没有阻止会话。当我检查sys.dm_exec_requests时，它显示最后一个等待类型是 PAGEIOLATCH_SH 我不知道这意味着什么，除了它与I / O有关。
sys.dm_exec_sessions显示状态为RUNNING，但sp_who2将其显示为SUSPENDED。
我试着查看表是否在增长，但是当我调用sp_spaceused XXXXXX时，我会继续获得相同的值。
我还能做什么？
更新
借助以下答案，我发现有an I/O issue，我的查询is resulting in an average of about 600 records being inserted per minute）。
我的下一步是什么？
在我开始假设我的磁盘坏了之前我该怎么办？
答案 0 :(得分：4)
如果您尝试以下
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
答案 1 :(得分：2)
可能有助于插入的一些想法：
xxxxxx上是否有任何插入触发器？这些可能会对大型插入操作产生重大影响。
xxxxxx上的非聚集索引是否可以在加载期间禁用？这对帮助也有很长的路要走。
/* Before */
alter index YourIndex on xxxxxx disable
/* After */
alter index YourIndex on xxxxxx rebuild
答案 2 :(得分：1)
插入是否在事务中？如果是，您可以尝试检查Sys.Dm_tran_database_Transactions中的事务详细信息。它显示了写入事务日志的当前条目数以及应随时间变化的一些其他健康状况：
SELECT * FROM Sys.Dm_tran_Database_Transactions
这是MSDN artical的链接，用于解释列：MSDN Column documentation
希望有所帮助
答案 3 :(得分：1)
好吧，听起来你可能处于DW风格的环境中，将大量数据从一个表移动到另一个表。假设您使用的是SQL Server 2008，请参阅此白皮书：
The Data Loading Performance Guide
请参阅最小日志记录部分，并进一步了解分区切换。
这有助于阅读整篇论文几次，所以你真的了解了封面下发生了什么，以及为什么某些数据组合+索引工作和其他组合没有。
分区切换使得最小化日志记录变得容易实现，因为它为您提供了一个空目标表，并允许新数据在加载完成后立即联机。不过可能需要企业版。
答案 4 :(得分：0)