Texte intégral: de nombreux FT_MASTER_MERGE attendent à l'état SUSPENDU après la création de plusieurs index de texte intégral (le serveur se bloque)

Nous avons fait un test sur SQL Server 2014 lorsque nous avions 10 bases de données, 100 schémas différents dans chaque base de données, 10 petites tables (~ 50 lignes) dans chaque schéma (donc 10K tables au total) et nous avons créé des index de texte intégral sur toutes ces tables dans toutes ces bases de données simultanément.

En quelques minutes, nous avons constaté que SQL Server s'est arrêté pour accepter toutes les connexions (sauf la ADMIN:.connexion). Si nous redémarrons le serveur, nous pouvons nous connecter, mais dans un certain temps, il se bloque à nouveau. Après une enquête, nous avons constaté que cela était dû à la consommation de tous les threads de travail dm_os_taskset dm_os_waiting_tasksnous avons montré qu'il y avait beaucoup d' FT_MASTER_MERGEattente en l' SUSPENDEDétat. Nous avons googlé que "le texte intégral attend l'opération de fusion principale", mais nous n'avons trouvé aucune information plus réelle à ce sujet.

Nous avons essayé différentes configurations de catalogue de texte intégral: un catalogue par base de données, un catalogue par schéma, un catalogue par index. Quoi qu'il en soit, le serveur se bloque avec toutes ces tâches suspendues.

Quelle est la cause première des attentes, comment cela peut-il être corrigé / atténué?

Et quelle est la méthode recommandée pour activer le texte intégral sur un si grand nombre de tableaux?

Vous devrez échelonner les opérations au lieu de tout faire en même temps. L'élément Connect ne parle pas d'accepter de nouvelles connexions. Mais à cause de cette attente, les threads ne sont pas libérés (dans votre cas) et de nouvelles connexions ne sont pas possibles.

Réf:

• https://connect.microsoft.com/SQLServer/feedback/details/1069538/fulltextindex-master-merge-operation-was-not-done
• https://www.sqlskills.com/help/waits/ft_master_merge/

Il s'agit d'un problème connu avec SQL Server. Depuis l'élément de connexion:

Cela est dû à la façon dont notre planificateur de travaux actuel est configuré, ce qui entraîne la mise en file d'attente de plusieurs opérations de fusion principales mais jamais signalées. Pour être clair, cela ne se produit que lorsque plusieurs opérations d'indexation / réorganisation sont appelées simultanément - l'opération d'indexation se termine très bien et les résultats sont interrogeables. Seule la fusion principale expire et est reprogrammée pour une période ultérieure.

En raison de la complexité du correctif, nous avons décidé d'attendre la prochaine version majeure avant de la trier. Pour le moment, il est conseillé d' échelonner les populations d'index afin de ne pas provoquer de tels problèmes de timeout . Veuillez me faire savoir si vous avez d'autres questions.