L'index de texte intégral SQL Server 2008 ne semble jamais complet

Notre site Web dispose d'une base de données SQL Server 2008 R2 Express Edition avec indexation en texte intégral pour notre recherche de site Web. Chaque fois qu'un nouvel enregistrement est ajouté ou mis à jour dans l'une des tables indexées, le processus d'indexation ne semble jamais se terminer.

J'ai surveillé l'état au cours des dernières semaines en utilisant essentiellement la même requête trouvée sur ce site: http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server-search/2155/Why-is-this -population-si-longue

Voici ce que je vois lorsque j'exécute la requête (cliquez pour agrandir):

Les enregistrements les plus récents des tables indexées ne sont jamais terminés et ne peuvent pas être recherchés. Même s'il n'y a pas beaucoup de données dans les tables, j'ai attendu des jours pour voir si l'indexation se termine, mais rien ne change jamais.

La seule façon dont je suis en mesure de réussir l'indexation est de reconstruire le catalogue ou de supprimer et recréer tous les index.

Chaque fois que je l'ai fait, le même problème finit par revenir dès que le premier nouvel album est ajouté.

Voici les statistiques du serveur au cas où:

• Quad-Core AMD Opteron 2,34 GHz
• 4 Go de RAM
• Windows Server 2008 R2 Enterprise SP1 x64
• SQL Server 2008 R2 Express Edition avec Advanced Services x64

J'ai enfin trouvé la cause de mon problème!

J'ai essayé pendant des mois de dépister le problème, mais j'ai finalement abandonné, désactivé le suivi automatique des modifications, lancé manuellement une population incrémentielle et continué ma vie.

Pendant ce temps, il y avait eu une autre erreur lancinante que j'avais du mal à retrouver. Périodiquement, le site Web générait une erreur de connexion DB:

Impossible d'ouvrir la base de données "XXXX" demandée par la connexion. La connexion a échoué. La connexion a échoué pour l'utilisateur «XXXX».

Il s'est avéré que ces deux problèmes avaient la même solution. Tout ce que j'avais à faire était de désactiver un paramètre de base de données appelé fermeture automatique. Pour ce faire, cliquez simplement avec le bouton droit sur la base de données et cliquez sur Propriétés. Dans la fenêtre des propriétés, sélectionnez Options et définissez "Fermeture automatique" sur false.

Dès que j'ai désactivé la fermeture automatique, mes problèmes de connexion à la base de données ont disparu et le suivi automatique des modifications a parfaitement fonctionné.

Merci encore pour l'aide de chacun. Je vous en suis reconnaissant!

Curieux de savoir si vous avez suivi les étapes de dépannage dans BOL pour les performances de texte intégral - http://technet.microsoft.com/en-us/library/ms142560.aspx .

Je parie que SQL Server mange toute votre mémoire et ne laisse pas le démon de filtre en avoir, donc votre population est lente, car il est très probable qu'il doive échanger des trucs vers le fichier de page. Vous devez limiter la quantité de mémoire que SQL peut utiliser (je pense à environ 3 Go compte tenu de vos spécifications système actuelles - cela laisserait 1 Go pour FDHost et le système d'exploitation).

Voici un script que j'ai créé à l'aide de curseurs pour reconstruire et remplir des index complets pour toute table qui en a un pour MSSQL2008. Cela fonctionne dans un environnement de production avec des bases de données migrées à partir d'un serveur MSSQL 2000. J'ai désactivé le suivi des modifications et je viens d'exécuter cette procédure stockée via l'Agent SQL Server. Si vous utilisiez express, vous pouvez utiliser un script VBS pour l'exécuter via le Planificateur de tâches.

Il était important dans le script de faire une reconstruction d'abord sur chaque catalogue avant d'essayer de remplir les index.

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

Quelqu'un at-il une méthode qui ne nécessite pas de curseurs?

Il est généralement recommandé de mettre à jour le catalogue de texte intégral à l'aide de déclencheurs. C'est l'approche que j'utilise sur mssql, mais dans mon cas, parce que j'ai une application localisée avec plusieurs exigences spécifiques qui me conduisent à une solution utilisant des déclencheurs, cette solution fonctionne à 100% à partir de 2 ans en arrière.

Passez en revue votre implémentation par rapport à cet exemple .

Vous ne savez pas quelle est la cause principale de votre situation, mais cela peut se produire après une sauvegarde. Je ne sais pas si c'est ce qui se passe dans votre cas ou en quoi ce tableau est différent des autres. Maintenant tu m'as curieux. La réplication SQL est-elle activée?

Pour un correctif temporaire, j'effectuerais une "exploration" (population) sur la table lorsque cela se produit.

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

Utilisez ce code:

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