Testo completo: molti FT_MASTER_MERGE sono in attesa in stato SOSPESO dopo la creazione di più indici full-text (blocco del server)

Abbiamo eseguito un test su SQL Server 2014 quando disponevamo di 10 database, 100 schemi diversi in ciascun database, 10 tabelle piccole (~ 50 righe) in ogni schema (quindi 10.000 tabelle in totale) e abbiamo creato indici full-text su tutti questi tabelle in tutti questi database contemporaneamente.

In alcuni minuti abbiamo scoperto che SQL Server ha smesso di accettare qualsiasi connessione (tranne la ADMIN:.connessione). Se riavviamo il server, possiamo connetterci, ma dopo qualche tempo si blocca di nuovo. Dopo alcune indagini abbiamo scoperto che è causato dal consumo di tutti i thread di lavoro dm_os_taskse dm_os_waiting_tasksci ha mostrato che ci sono molte FT_MASTER_MERGEattese nello SUSPENDEDstato. Abbiamo cercato su Google che "Full-text è in attesa dell'operazione di unione principale", ma non abbiamo trovato più informazioni effettive al riguardo.

Abbiamo provato diverse configurazioni di catalogo full-text: un catalogo per DB, un catalogo per schema, un catalogo per indice. Ad ogni modo il server si blocca con tutte queste attività sospese.

Qual è la causa principale delle attese, come può essere risolto / mitigato?

E qual è il modo consigliato per abilitare il full-text su una così grande quantità di tabelle?

Dovrai scaglionare le operazioni invece di fare tutto in una volta. L'elemento Connect non parla dell'accettazione di nuove connessioni. Ma a causa di questa attesa i thread non vengono rilasciati (nel tuo caso) e non sono possibili nuove connessioni.

Rif:

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

Questo è un problema noto con SQL Server. Dall'elemento di connessione:

Ciò è causato dal modo in cui il nostro attuale pianificatore di lavori viene impostato, causando la messa in coda di più operazioni di unione principale, ma mai segnalate. Per essere chiari, ciò accade solo quando vengono invocate simultaneamente più operazioni di indicizzazione / riorganizzazione: l'operazione di indicizzazione si completa correttamente e i risultati sono interrogabili. È solo l'unione principale che scade e viene riprogrammata per un periodo di tempo successivo.

A causa della complessità della correzione, abbiamo deciso di attendere fino alla prossima versione principale prima di eseguirla. Al momento, si consiglia di scaglionare le popolazioni di indici al fine di non causare tali problemi di timeout . Per favore fatemi sapere se avete ulteriori domande.