L'indice full-text di SQL Server 2008 non sembra mai completo

Il nostro sito Web ha un database SQL Server 2008 R2 Express Edition con indicizzazione full-text per la ricerca del nostro sito Web. Ogni volta che un nuovo record viene aggiunto o aggiornato in una delle tabelle indicizzate, il processo di indicizzazione non sembra completarsi.

Ho monitorato lo stato nelle ultime settimane usando sostanzialmente la stessa query trovata su questo sito: http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server-search/2155/Why-is-this -population-taking-così a lungo

Questo è quello che vedo quando eseguo la query (fai clic per ingrandire):

I record più recenti nelle tabelle indicizzate non vengono mai completati e non sono ricercabili. Anche se non ci sono molti dati nelle tabelle, ho atteso giorni per vedere se l'indicizzazione è stata completata, ma nulla è cambiato.

L'unico modo in cui riesco a completare correttamente l'indicizzazione è ricostruire il catalogo o eliminare e ricreare tutti gli indici.

Ogni volta che l'ho fatto, lo stesso problema si ripresenta non appena viene aggiunto il primo nuovo record.

Ecco le statistiche del server per ogni evenienza:

• Opteron AMD Quad-Core 2.34GHz
• 4 GB di RAM
• Windows Server 2008 R2 Enterprise SP1 x64
• SQL Server 2008 R2 Express Edition con Advanced Services x64

Finalmente ho trovato la causa del mio problema!

Ho provato per mesi a rintracciare il problema, ma alla fine ho rinunciato, disabilitato il rilevamento automatico delle modifiche, ho appena avviato la popolazione incrementale manualmente e sono andato avanti con la mia vita.

Nel frattempo, c'era stato un altro errore fastidioso che avevo problemi a rintracciare. Periodicamente il sito web genera un errore di connessione DB:

Impossibile aprire il database "XXXX" richiesto dall'account di accesso. Accesso fallito. Accesso non riuscito per l'utente 'XXXX'.

Si è scoperto che entrambi questi problemi avevano la stessa soluzione. Tutto quello che dovevo fare è disattivare un'impostazione del database denominata Chiusura automatica. Per fare ciò, basta fare clic con il tasto destro del mouse sul database e fare clic su Proprietà. Nella finestra delle proprietà selezionare Opzioni e impostare "Chiusura automatica" su false.

Non appena ho disabilitato la chiusura automatica, i miei problemi di accesso al DB sono scomparsi e il rilevamento automatico delle modifiche ha funzionato perfettamente.

Grazie ancora per l'aiuto di tutti. Lo apprezzo!

Curioso se hai seguito i passaggi per la risoluzione dei problemi in BOL per le prestazioni full-text - http://technet.microsoft.com/en-us/library/ms142560.aspx .

Scommetto che SQL Server sta mangiando tutta la tua memoria e non lasciando che il demone filtro ne abbia, quindi la tua popolazione è lenta, poiché è molto probabile che debba scambiare roba nel file di paging. Dovresti limitare la quantità di memoria che SQL può usare (penso a circa 3 GB in base alle tue attuali specifiche di sistema - che lascerebbe 1 GB per FDHost e il sistema operativo).

Ecco uno script che ho creato usando i cursori per ricostruire e popolare gli indici completi per qualsiasi tabella che ne abbia uno per MSSQL2008. Funziona in un ambiente di produzione con database migrati da un server MSSQL 2000. Ho disattivato il rilevamento delle modifiche ed ho appena eseguito questa procedura memorizzata tramite SQL Server Agent. Se si utilizza Express, è possibile utilizzare uno script VBS per eseguirlo tramite l'Utilità di pianificazione.

Nella sceneggiatura era importante fare prima una ricostruzione su ogni catalogo prima di provare a popolare gli indici.

CREATE PROCEDURE [dbo].[rebuild_repopulate_fulltext] 
AS
BEGIN

Declare @cmdA NVARCHAR(255)
Declare @cmdB NVARCHAR(255)
Declare @cmdC NVARCHAR(255)
DECLARE @Database VARCHAR(255)   
DECLARE @Table VARCHAR(255)  
DECLARE @cmd NVARCHAR(500)  
DECLARE @fillfactor INT 
DECLARE @Catalog VARCHAR(255)
DECLARE @Schema VARCHAR(255)

SET @fillfactor = 90 

DECLARE DatabaseCursor CURSOR FOR  
SELECT name FROM MASTER.dbo.sysdatabases   
WHERE name NOT IN ('master','msdb','tempdb','model','distribution')   
ORDER BY 1  

OPEN DatabaseCursor  

FETCH NEXT FROM DatabaseCursor INTO @Database  
WHILE @@FETCH_STATUS = 0  
BEGIN  

   -- rebuild fulltext catalog
   set @cmd = 'DECLARE CatalogCursor CURSOR FOR 
        SELECT t.name AS TableName, c.name AS FTCatalogName, s.name as schemaname
        FROM ['+ @Database + '].sys.tables t JOIN ['+ @Database +'].sys.fulltext_indexes i
        ON t.object_id = i.object_id
        JOIN ['+ @Database + '].sys.fulltext_catalogs c
        ON i.fulltext_catalog_id = c.fulltext_catalog_id
        JOIN ['+ @Database + '].sys.schemas s ON t.schema_id = s.schema_id'
   --PRINT @cmd
   EXEC (@cmd)  


   OPEN CatalogCursor   

   FETCH NEXT FROM CatalogCursor INTO @Table, @Catalog, @Schema
   WHILE @@FETCH_STATUS = 0   
   BEGIN  

    SET @cmdB = 'USE ['+ @Database + ']; ALTER FULLTEXT CATALOG ' + @Catalog + ' REBUILD;'
    --PRINT @cmdB
    EXEC (@cmdB)


    FETCH NEXT FROM CatalogCursor INTO @Table, @Catalog, @Schema
   END   

   CLOSE CatalogCursor   


   OPEN CatalogCursor   

   FETCH NEXT FROM CatalogCursor INTO @Table, @Catalog, @Schema
   WHILE @@FETCH_STATUS = 0   
   BEGIN  

    SET @cmdC = 'USE ['+ @Database + ']; ALTER FULLTEXT INDEX ON ['+ @Database + '].[' + @Schema + '].[' + @Table + '] START FULL POPULATION;' 
    --PRINT @cmdC
    EXEC (@cmdC)

    FETCH NEXT FROM CatalogCursor INTO @Table, @Catalog, @Schema
   END   

   CLOSE CatalogCursor   
   DEALLOCATE CatalogCursor  



   FETCH NEXT FROM DatabaseCursor INTO @Database  
END  

CLOSE DatabaseCursor   
DEALLOCATE DatabaseCursor

END

Qualcuno ha un metodo che non richiede cursori?

Di solito si consiglia di aggiornare il catalogo full-text utilizzando i trigger. Questo è l'approccio che uso su mssql, ma nel mio caso perché ho un'applicazione localizzata con diversi requisiti specifici che mi portano a una soluzione che utilizza i trigger, che funziona al 100% a partire da 2 anni fa.

Rivedi la tua implementazione rispetto a questo esempio .

Non sei sicuro di quale sia la causa principale nella tua situazione, ma ciò può accadere dopo un backup. Non sono sicuro se questo è ciò che sta accadendo nel tuo caso o come quella tabella sia diversa dalle altre. Ora mi hai incuriosito. Hai la replica SQL attivata?

Per una correzione temporanea, eseguivo un "Crawl" (popolazione) sul tavolo quando questo accade.

http://msdn.microsoft.com/en-us/library/ms142575(v=sql.105).aspx

Usa questo codice:

ALTER FULLTEXT INDEX ON dbname.dbo.tablename
START FULL POPULATION;