2008-09-05 27 views
4

Tümü tam metin katalogları içeren çok sayıda veritabanını çalıştıran bir SQL Server 2005 SP2 makinesine sahibiz. Bu veritabanlarından birini veya bir tam metin dizinini yeniden oluşturmaya çalıştığımızda, bırakma veya yeniden oluşturma işlemi bir MSSEARCH bekleme türü ile süresiz olarak askıda kalıyor. Süreç öldürülmez ve bir şeylerin yeniden yayınlanmasını sağlamak için bir sunucu yeniden başlatılması gerekir. Bir Microsoft forumlarında 1 numaralı yayına dayanarak, sorunun yanlış bir şekilde kaldırılmış tam metin kataloğu olabileceği ortaya çıkıyor. Herkesin hepsini kaldırmak zorunda kalmadan soruna hangi kataloğun neden yol açtığını belirlemek için bir yol önerilebilir mi?SQL Server Tam Metin Araması: MSSEARCH bekleme işlemleri ile bekletme işlemleri

1 [http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2681739&SiteID=1] “Evet veritabanında tam metin katalogları var mı, ama ben veritabanı için devre dışı tam metin araması ve engelli MSFTESQL beri, ben onları şüphelenmedi. Ancak, Microsoft desteğiyle ilgili bir makalem var, nasıl düzgün şekilde kaldırılmadığı için katalogları nasıl test edebildiğimi gösteriyor. Bu yüzden, eski bir kataloğun var olduğunu keşfettim, sonra, tam metin aramasını yeniden etkinleştirdikten sonra ve sonra silme işlemini yapabildim, o zamandan beri yedeklerim çalıştı. ”

cevap

1

Çalışan işlem monitörünü denediniz mi? temel hata nedir ve hantal? Proses monitörü kullanarak whick dosyasını/kaynağı beklediği/hata yaptığını söyleyebilmelisiniz.

+0

İlginç. ProcMon, sunucudaki diğer veritabanlarından birinden bir tam metin dizin dosyasında bir paylaşım ihlali bildirir. Yani yeniden inşa etmek yardımcı olabilir. Hata çok aralıklı olarak gerçekleşir, bu yüzden düzeltilip düzeltilmediğini öğrenmek biraz zaman alır. – RedGreenCode

2

İşte bir öneri. Ben herhangi bir bozuk veritabanlarını yok ama bunu deneyebilirsiniz: işe yaramazsa

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 '[email protected]+'.sys.fulltext_catalogs) AND NOT EXISTS(SELECT * FROM sys.databases where is_fulltext_enabled=1 AND name='''[email protected]+''') PRINT ''' [email protected] + ' Could be the culprit''' 
    print @sql 
    exec sp_sqlexec @SQL 
    delete from @t where name = @name 
end 

, sys.databases kontrol filtreyi kaldırmak.

+0

Öneriniz için teşekkürler. Ancak, veritabanlarının hiçbiri potansiyel suçlu olarak işaretlenmedi. – RedGreenCode

1

Geçersiz tam metin kataloğu konumlarıyla benzer bir sorun yaşadım. Sunucu, başlangıçta tüm veritabanlarını çevrimiçi duruma getirmez. Veritabanlarını kirli düzende işler ve yarıya kadar durup durur. Sadece eski DB'ler çevrimiçi duruma getirildi ve geri kalanı erişilemez oldu. Sysprocesses bakıldığında waittype = 0x00CC, lastwaittype = MSSEARCH ile bir düzine veya daha fazla işlem ortaya çıktı. MSSEARCH durdurulamadı. Sorun, tam metin kataloglarını yeniden yerleştirdiğimizde, ancak değiştirilen veritabanı ... modifyfile komutunu çalıştırırken bunlardan biri için yanlış yola girdiğimizde ortaya çıkmıştı. Çözüm, MSSEARCH'yi devre dışı bırakmak, tüm DB'lerin çevrimiçi olmasına izin vermek, rahatsız edici veritabanını bulmak, çevrimdışına almak, veritabanı yolunu değiştir komutunu kullanarak dosya yolunu düzeltmek ve DB'yi çevrimiçi duruma getirmek için sunucuyu yeniden başlatmaktı. Sonra MSSEARCH'ı başlatın ve otomatik başlatmaya ayarlayın.