У нас есть машина с SQL Server 2005 SP2, на которой работает большое количество баз данных, каждая из которых содержит полнотекстовые каталоги. Каждый раз, когда мы пытаемся отбросить одну из этих баз данных или перестроить полнотекстовый индекс, процесс отбрасывания или перестроения зависает на неопределенное время с типом ожидания MSSEARCH. Процесс не может быть остановлен, и требуется перезагрузка сервера, чтобы все снова заработало. Судя по сообщению 1 на форумах Microsoft, проблема может заключаться в неправильно удаленном полнотекстовом каталоге. Может ли кто-нибудь порекомендовать способ определить, какой каталог вызывает проблему, без необходимости удалять их все?
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, перезагрузить сервер, чтобы все БД могли подключиться к сети, найти проблемную базу данных, перевести ее в автономный режим, исправить путь к файлу с помощью команды alter database и перевести БД в оперативный режим. Затем запустите MSSEARCH и установите автоматический запуск.
Интересно. ProcMon сообщает о нарушении общего доступа к файлу полнотекстового индекса из одной из других баз данных на сервере. Так что восстановление может помочь. Ошибка возникает очень периодически, поэтому потребуется время, чтобы выяснить, исправлена она или нет.