表性能问题。重建索引超时，紧急求助。

[fireegg]

用DBCC DBREINDEX('aaa')对aaa表重建索引，会一直没有响应。
SELECT * FROM AAA 查出60多万笔，能查出来
DBCC checktable('aaa') 没报错
对aaa改成会提示超时。

将aaa的脚本创建一个新的表bbb，将aaa的60多万笔记录插入到bbb，这个表重建索引才10多秒钟就好了

aaa表是不是有什么问题？要如何处理呢？

[fireegg]

引用 12 楼 DBA_Huangzj 的回复:

你order by一下wait_time ，另外下次引用一下。不然看不到你回复

第二个语句查出来的WAIT_TIME大多是NULL的

[發糞塗牆]

你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

[fireegg]

引用 14 楼 DBA_Huangzj 的回复:

你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

非NULL的WAIT_TIME是0，WAIT_TYPE是NULL。

[發糞塗牆]

你的tempdb有多大？

[fireegg]

引用 14 楼 DBA_Huangzj 的回复:

你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

第一个语句查出有LASTWAITTYPE的

[發糞塗牆]

引用 17 楼 fireegg 的回复:

[quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

第一个语句查出有LASTWAITTYPE的 [/quote]这个我记得是CPU的问题

[fireegg]

引用 16 楼 DBA_Huangzj 的回复:

你的tempdb有多大？

属性里面的大小是792M，昨天重启后可以用，现在程序上执行又卡住。重启后aaa表可以重建索引，现在又卡住，问题仍然出现在aaa表上，又不能重建索引，改名还会提示超时

[niss]

mark一下,备用,嘎嘎

[fireegg]

引用 18 楼 DBA_Huangzj 的回复:

[quote=引用 17 楼 fireegg 的回复:] [quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

第一个语句查出有LASTWAITTYPE的 [/quote]这个我记得是CPU的问题[/quote] CPU使用70％多，在任务管理器里面有看到CPU那边有时会有红色线。

[fireegg]

引用 14 楼 DBA_Huangzj 的回复:

你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

DBCC INPUTBUFFER session_id 看到几个WAIT_TIME不为NULL的几个，上面语句执行出来后就是卡住的SQL语句，那语句关联几个表其中aaa关联了几次。这语句现在复制出来执行也会一直在查询出不来

[發糞塗牆]

引用 19 楼 fireegg 的回复:

[quote=引用 16 楼 DBA_Huangzj 的回复:] 你的tempdb有多大？

属性里面的大小是792M，昨天重启后可以用，现在程序上执行又卡住。重启后aaa表可以重建索引，现在又卡住，问题仍然出现在aaa表上，又不能重建索引，改名还会提示超时[/quote]你试一下用这个来重建： ALTER INDEX [索引名] ON [表名] REBUILD WITH (FILLFACTOR=80,ONLINE =ON) GO

[fireegg]

引用 22 楼 fireegg 的回复:

[quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

DBCC INPUTBUFFER session_id 看到几个WAIT_TIME不为NULL的几个，上面语句执行出来后就是卡住的SQL语句，那语句关联几个表其中aaa关联了几次。这语句现在复制出来执行也会一直在查询出不来[/quote] 是不是把这几个ID给KILL了就能释放？

[發糞塗牆]

引用 24 楼 fireegg 的回复:

[quote=引用 22 楼 fireegg 的回复:] [quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

DBCC INPUTBUFFER session_id 看到几个WAIT_TIME不为NULL的几个，上面语句执行出来后就是卡住的SQL语句，那语句关联几个表其中aaa关联了几次。这语句现在复制出来执行也会一直在查询出不来[/quote] 是不是把这几个ID给KILL了就能释放？[/quote]我感觉应该是在做什么高CPU消耗的操作。

[fireegg]

引用 25 楼 DBA_Huangzj 的回复:

[quote=引用 24 楼 fireegg 的回复:] [quote=引用 22 楼 fireegg 的回复:] [quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

DBCC INPUTBUFFER session_id 看到几个WAIT_TIME不为NULL的几个，上面语句执行出来后就是卡住的SQL语句，那语句关联几个表其中aaa关联了几次。这语句现在复制出来执行也会一直在查询出不来[/quote] 是不是把这几个ID给KILL了就能释放？[/quote]我感觉应该是在做什么高CPU消耗的操作。[/quote] 一个SQL语句，性能上是不太好。但重启后就能用。。 现在这个表改名会超时， 估计执行： ALTER INDEX [索引名] ON [表名] REBUILD WITH (FILLFACTOR=80,ONLINE =ON) 也会报错。

[發糞塗牆]

引用 26 楼 fireegg 的回复:

[quote=引用 25 楼 DBA_Huangzj 的回复:] [quote=引用 24 楼 fireegg 的回复:] [quote=引用 22 楼 fireegg 的回复:] [quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

DBCC INPUTBUFFER session_id 看到几个WAIT_TIME不为NULL的几个，上面语句执行出来后就是卡住的SQL语句，那语句关联几个表其中aaa关联了几次。这语句现在复制出来执行也会一直在查询出不来[/quote] 是不是把这几个ID给KILL了就能释放？[/quote]我感觉应该是在做什么高CPU消耗的操作。[/quote] 一个SQL语句，性能上是不太好。但重启后就能用。。 现在这个表改名会超时， 估计执行： ALTER INDEX [索引名] ON [表名] REBUILD WITH (FILLFACTOR=80,ONLINE =ON) 也会报错。[/quote]我这个也是重建索引，但是是借助tempdb重建，所以性能上应该好点

[fireegg]

引用 27 楼 DBA_Huangzj 的回复:

[quote=引用 26 楼 fireegg 的回复:] [quote=引用 25 楼 DBA_Huangzj 的回复:] [quote=引用 24 楼 fireegg 的回复:] [quote=引用 22 楼 fireegg 的回复:] [quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

DBCC INPUTBUFFER session_id 看到几个WAIT_TIME不为NULL的几个，上面语句执行出来后就是卡住的SQL语句，那语句关联几个表其中aaa关联了几次。这语句现在复制出来执行也会一直在查询出不来[/quote] 是不是把这几个ID给KILL了就能释放？[/quote]我感觉应该是在做什么高CPU消耗的操作。[/quote] 一个SQL语句，性能上是不太好。但重启后就能用。。 现在这个表改名会超时， 估计执行： ALTER INDEX [索引名] ON [表名] REBUILD WITH (FILLFACTOR=80,ONLINE =ON) 也会报错。[/quote]我这个也是重建索引，但是是借助tempdb重建，所以性能上应该好点[/quote] 这个命令也是执行了好久还没结束

[KevinLiu]

引用 36 楼 delphigbg 的回复:

你是哪个版本的SQL。新版本的重建或是建索引时，可以支持在线建索引。on line

在线重建索引开销更大

[Barton]

你的表aaa上面有几个索引？？ 你dbreindex没有指定索引，如果索引比较多，这命令会全部重新建。

SELECT * FROM sys.indexes WHERE object_id=object_id('aaa')

[Barton]

引用 17 楼 fireegg 的回复:

[quote=引用 14 楼 DBA_Huangzj 的回复:] 你找出最高wait_time的那些，然后看看他们的session_id ，用dbcc inputbuffer来看看他们是在干什么，还有wait_type，要不你把非null的结果贴出来看看

第一个语句查出有LASTWAITTYPE的 [/quote] 出现这个等待是正常现象 。reindex的时候需要对data进行排序，而且还要读data page，所以SQL Server Scheduler会经常做yield,你reindex最少在下面两种情况做yield 1.如果SQL运行超过4ms，每次读page的时候就yield一次 2.每对64kb排序一次就需要yield一次。

[蝈蝈(GuoGuo)]

你是哪个版本的SQL。新版本的重建或是建索引时，可以支持在线建索引。on line