我运行了一个由 Microsoft 员工提供的脚本，以根据平均碎片找出哪些索引需要重建/重组。我得到了一个合理的列表，但是在尝试在特定数据库上重建其中一些时，我一直收到错误：
我得到的第一个想法是将数据库设置为单用户模式，重建索引，然后使其恢复活力。好吧，这并没有帮助，因为数据库正在由 Windows 服务填充，具有讽刺意味的是，该服务使用与我连接的同一用户，并且只有我有足够的权限才能使用。我正在一个公司环境中工作，所以月亮比获得另一个用户凭据更近一些。我也无法在执行任务时停止服务，因为它用于许多其他事情。
我的问题很简单：如何强制单用户模式强制单连接源？换句话说，如何从服务中隐藏数据库或最终的 SQL 服务器？它将正确处理缺席作为网络问题，因此我不必担心那部分。
我找到了一个很好的解决方案，可以帮助其他人。我首先使用以下方法获取当前表上带有锁的事务列表：
USE [Your DB Name]
SELECT REQUEST_MODE, REQUEST_TYPE, REQUEST_SESSION_ID
FROM sys.dm_tran_locks
WHERE RESOURCE_TYPE = 'OBJECT'
AND RESOURCE_ASSOCIATED_ENTITY_ID =(SELECT OBJECT_ID('YourTableName'))
这REQUEST_SESSION_ID是在表上设置了锁的会话的 ID。然后我运行EXEC sp_who2以确保 SPID 是预期服务的 SPID。最后我需要做的就是KILL <SPID>重建索引。如果您要构建多个索引，则可能需要多次执行此操作，因为可能会再次设置锁定。
在 SQL Server 2005 及更高版本中重建索引时，有一个 ONLINE = ON/OFF 选项可用，它控制用户如何访问基础表，这可能会解决您的问题。
http://msdn.microsoft.com/en-us/library/ms188388(v=sql.110).aspx
您的问题是界面只会等待一定的时间才能决定失败。我一直遇到这个问题。
您可以尝试编写更改脚本，然后手动运行它，这样您就可以等到当前使用索引的用户释放所有锁。但是，您必须小心，索引重建会在索引运行时锁定索引（当然，除非您有企业版，重建在线，而且一切都是用钱做的）