我们有一台运行大量数据库的SQL Server 2005 SP2计算机，所有数据库都包含全文目录。每当我们尝试删除这些数据库之一或者重建全文索引时，使用MSSEARCH等待类型都会无限期地挂起拖放或者重建过程。无法终止该进程，并且需要重新启动服务器才能使事情再次运行。根据Microsoft论坛post1，似乎该问题可能是未正确删除的全文目录。任何人都可以推荐一种方法来确定导致该问题的目录，而不必删除所有目录？

1 [http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2681739&SiteID=1]
是的，我们确实在数据库中有全文目录，但是由于我已禁用了数据库的全文本搜索并禁用了msftesql，因此我不怀疑它们。但是，我从Microsoft支持部门获得了一篇文章，向我展示了如何测试未正确删除的目录。因此，我发现仍然存在一个旧目录，在重新启用全文搜索之后，并且只有在重新启用全文搜索之后，我才能删除该目录，此后我的备份开始了

解决方案

回答

我们是否尝试过运行进程监视器，以及它何时挂起并查看潜在的错误是什么？使用进程监视器，我们应该能够告诉鞭打文件/资源​​等待/出错。

回答

这是一个建议。我没有任何损坏的数据库，但是我们可以尝试以下操作：

declare @t table (name nvarchar(128))
insert into @t select name from sys.databases --where is_fulltext_enabled 

while exists(SELECT * FROM @t)
begin
    declare @name nvarchar(128)
    select @name = name from @t
    declare @SQL nvarchar(4000)
    set @SQL = 'IF EXISTS(SELECT * FROM '+@name+'.sys.fulltext_catalogs) AND NOT EXISTS(SELECT * FROM sys.databases where is_fulltext_enabled=1 AND name='''+@name+''') PRINT ''' +@Name + ' Could be the culprit'''
    print @sql
    exec sp_sqlexec @SQL
    delete from @t where name = @name
end

如果它不起作用，请删除检查sys.databases的过滤器。

回答

我有一个无效的全文目录位置类似的问题。
服务器在启动时不会使所有数据库联机。它将以dbid顺序处理数据库，并中途通过并停止。只有较早的数据库才联机，其余的则无法访问。
查看sysprocesses，发现有十几个或者更多具有waittype = 0x00CC，lastwaittype = MSSEARCH的进程。 MSSEARCH无法停止。
当我们重定位全文目录但在运行alter database ... Modifyfile命令时为其中一个目录输入了错误的路径时，便导致了问题。
解决方案是禁用MSSEARCH，重新启动服务器以允许所有DB联机，找到有问题的数据库，使其脱机，使用alter database命令更正文件路径并使DB联机。然后启动MSSEARCH并将其设置为自动启动。