Condividi tramite


Come identificare colli di bottiglia nel database MessageBox

Per identificare colli di bottiglia nel database MessageBox, assicurarsi innanzitutto che il servizio SQL-Server Agent sia avviato. Modificare lo stato di avvio del servizio da Manuale a Auto in modo che se il server viene riavviato, il servizio verrà riavviato automaticamente.

Per impostazione predefinita, il servizio BizTalk limita se le tabelle Spool, TrackingData o ApplicationQ aumentano. Queste tabelle vengono eliminate dai processi SQL-Agent, che, se non in esecuzione, causano l'aumento della limitazione della limitazione dell'avvio e protezione del database da una pressione aggiuntiva. Verificare lo stato dei contatori delle prestazioni seguenti:

Crescita della tabella Spool

La tabella Spool può crescere per molteplici motivi. Un motivo per la crescita di Spool è se le code di applicazioni sono in crescita. Potrebbero crescere a causa di motivi come colli di bottiglia downstream e/o contesa delle risorse.

Se le code dell'applicazione sono piccole e la proprietà Spool è ancora grande, verificare che i processi di eliminazione siano in corso. Verificare che il servizio SQL-Agent sia in esecuzione e che i processi seguenti vengano completati correttamente:

  • MessageBox_Message_Cleanup_BizTalkMessageBoxDb

  • MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

    Se la tabella MessageZeroSum è grande, indica che i messaggi sono stati elaborati. Ciò significa che DeQueue ha completato e eliminato correttamente i dati dalle tabelle della coda dell'applicazione e le righe sono state contrassegnate per l'eliminazione. I processi di eliminazione tuttavia non sono in grado di gestire l'eliminazione dei dati. Ciò può verificarsi se il computer che esegue SQL Server sta riscontrando una grave contesa della CPU, che influisce sulla capacità dei processi di eliminazione di mantenere a causa della starva della CPU.

Crescita della tabella della coda dell'applicazione

Le code di applicazioni ospitano dati di transizione in anteprima che, una volta elaborati, vengono puliti da DeQueue.

Dopo l'elaborazione di questi messaggi, la tabella Spool (che contiene riferimenti a queste righe) può essere pulita.

Ad esempio, RxHostQ pubblica i dati nell'orchestrazione PxHostQ. Questa coda pubblica i dati nell'invio di TxHostQ ogni riga che fa riferimento a una riga nella tabella Spool. Dopo aver elaborato correttamente i messaggi per un determinato hostQ tramite il sistema, queste righe vengono eliminate da DeQueue. Dopo l'eliminazione delle righe, la tabella Spool, in cui non esistono più riferimenti alle righe, può essere rimossa dai processi di eliminazione.

La crescita della coda di applicazioni indica che le istanze host responsabili dello svuotamento della coda dell'applicazione non sono in grado di mantenere la velocità in ingresso.

Ad esempio, la coda dell'applicazione di orchestrazione (PxHostQ) può crescere in quanto il server responsabile dell'elaborazione delle orchestrazioni è associato alla CPU e non è in grado di elaborare più velocemente. Tuttavia, se il server di ricezione è veloce può pubblicare più velocemente di quello che il server di orchestrazione può elaborare causando la crescita della coda di applicazioni.

Un altro motivo per la crescita della coda di orchestrazione potrebbe essere dovuto alla contesa della memoria. Quando molte istanze di orchestrazione a esecuzione prolungata vengono create simultaneamente in memoria, il blocco della memoria causa indirettamente la limitazione della limitazione del pool di thread fino a quando la pressione della memoria non viene ridotta.

Un motivo per cui la coda dell'applicazione di invio può crescere è se il sistema downstream non è in grado di ricevere messaggi (in uscita da BizTalk Server) abbastanza velocemente. Pertanto, i messaggi continueranno a risiedere all'interno del sistema BizTalk causando la crescita della coda di applicazioni. Ciò può causare la limitazione dell'avvio e la riduzione della velocità effettiva complessiva del sistema.

Crescita della tabella TrackingData

La tabella TrackingData nel database MessageBox è una tabella di transizione in cui gli intercettori scrivono i dati di rilevamento per il rilevamento sia dell'integrità che dell'attività (HAT) e del monitoraggio attività aziendali (BAM). Se il rilevamento è disattivato, questa tabella dovrebbe essere vuota. Per impostazione predefinita, il rilevamento HAT è abilitato per gli eventi in/out delle pipeline e delle orchestrazioni.

Se il rilevamento del corpo del messaggio è abilitato, assicurarsi che il server di database MessageBox (ovvero l'host con "consenti rilevamento host") sia in esecuzione. Assicurarsi che l'host con "consenti rilevamento host" sia in esecuzione ridurrà la probabilità di un collo di bottiglia durante lo spostamento dei dati dell'host dalla tabella TrackingData nel database MessageBox alle tabelle del database Di rilevamento BizTalk.

È possibile tenere traccia degli eventi personalizzati abilitando, ad esempio, il rilevamento personalizzato di HAT, sulle proprietà promosse e sul rilevamento del corpo dei messaggi. Oltre ai dati di rilevamento HAT, i dati BAM vengono scritti anche nella tabella TrackingData. Il servizio di decodifica dei dati di rilevamento (TDDS, eseguito nell'istanza host in cui è abilitato il rilevamento) è responsabile dello spostamento di questi dati dal database MessageBox ai database di rilevamento BizTalk e dell'importazione primaria BAM. Dopo aver spostato correttamente i dati, TDDS elimina questi dati. I dati di rilevamento del corpo del messaggio vengono spostati separatamente da un processo SQL-Agent TrackedMessages_Copy_BizTalkMsgBoxDb.

Se TDDS non è in grado di mantenere la frequenza con cui gli intercettori scrivono dati nella tabella TrackingData, questa tabella crescerà, causando la limitazione dell'avvio. Ciò influisce sulla velocità effettiva sostenibile. Per ridurre questo problema, assicurarsi che almeno un host sia in esecuzione con il rilevamento abilitato.

Se i dati vengono ancora compilati, assicurarsi che il database di rilevamento BizTalk non sia in crescita dal controllo. Assicurarsi inoltre che il processo di archiviazione e eliminazione sia in esecuzione ed è in grado di mantenere la frequenza in cui arrivano i dati.

Nota

Per impostazione predefinita, il processo di eliminazione non è in grado di eliminare i dati dalle tabelle del database di rilevamento BizTalk fino a quando questi dati non sono stati archiviati. Se non è necessario archiviare i dati di rilevamento, è possibile modificare il processo per eliminare il database di rilevamento BizTalk senza archiviare seguendo la procedura descritta in How to Purge Data from the BizTalk Tracking Database (https://go.microsoft.com/fwlink/?LinkID=153817).

Vedere anche

Colli di bottiglia a livello di database