Identificare i 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 in Automatico in modo che anche se il server viene riavviato, il servizio verrà riavviato automaticamente.
In base all'impostazione predefinita il servizio BizTalk limita le richieste a fronte della crescita delle tabelle Spool, TrackingData o ApplicationQ. Queste tabelle vengono eliminate dai processi di SQL Server Agent, che se non in esecuzione provocano la crescita della tabella Spool causando la limitazione delle richieste da avviare per la protezione del database da pressione aggiuntiva. Verificare lo stato dei contatori delle prestazioni seguenti:
Stato limitazione recapito messaggi BizTalk:Agente messaggi (Nome Host)
Stato limitazione pubblicazione messaggi BizTalk:Agente messaggi (Nome Host)
Il valore 0 indica che non vi sono limitazioni. Il valore 6 indica che il sistema utilizza delle limitazioni a causa della crescita del database. Fare riferimento alla documentazione sulle modalità di interpretazione di altri valori dei contatori.
Crescita della tabella Spool
La tabella Spool può crescere per molteplici motivi. Uno dei motivi è riconducibile all'eventuale crescita delle code dell'applicazione. Le code possono aumentare in termini di dimensioni per vari motivi, ad esempio colli di bottiglia a valle e/o conflitto di risorse.
Se le code dell'applicazione sono di piccole dimensioni mentre la tabella Spool è di grandi dimensioni, verificare la gestione dei processi di eliminazione. 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 è di grandi dimensioni ciò significa che i messaggi sono stati elaborati (la coda DeQueue ha completato ed eliminato i dati correttamente dalle tabelle delle code dell'applicazione) e che le righe sono state contrassegnate per l'eliminazione. I processi di eliminazione tuttavia non sono in grado di gestire l'eliminazione dei dati. Uno dei motivi è riconducibile al fatto che se nel computer SQL-Server si verificano gravi conflitti CPU ciò influisce negativamente sulla capacità di gestione dei processi di eliminazione a causa dell'arresto della CPU.
Crescita delle code dell'applicazione
Nelle code dell'applicazione risiedono dati di transizione in elaborazione che, una volta elaborati, vengono rimossi dalla coda DeQueue.
Dopo l'elaborazione di tali messaggi, la tabella Spool, che mantiene riferimenti a queste righe, può essere rimossa.
Ad esempio, la coda RxHostQ pubblica dati nella coda PxHostQ dell'orchestrazione che a sua volta pubblica dati nella coda TxHostQ di trasmissione, ognuna facendo riferimento a una riga della tabella Spool. Dopo la corretta elaborazione dei messaggi di una determinata coda HostQ tramite il sistema, tali righe vengono eliminate dalla coda 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 delle code dell'applicazione indica che le istanze host responsabili dello svuotamento delle code dell'applicazione non sono in grado di supportare la velocità in entrata, ovvero la velocità in base alla quale i messaggi vengono pubblicati in una determinata coda dell'applicazione.
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. Se il server ricevente è veloce più pubblicare più velocemente di quanto il server di orchestrazione non possa elaborare portando alla crescita delle code dell'applicazione.
Un altro motivo per la crescita delle code dell'applicazione può essere riconducibile ai conflitti in memoria in cui numerose istanze di orchestrazione a esecuzione prolungata vengono create contemporaneamente, provocando il sovraccarico della memoria stessa e indirettamente la limitazione delle richieste per compattare il pool di thread fin quando non diminuisce la pressione della memoria. Un motivo per cui la coda dell'applicazione di trasmissione può crescere può verificarsi se il sistema a valle non è in grado di ricevere messaggi a una velocità sufficiente (in uscita da BizTalk). Di conseguenza, i messaggi continueranno a risiedere all'interno del sistema BizTalk provocando la crescita delle code dell'applicazione causando la limitazione delle richieste da avviare, riducendo la velocità di ricezione che influisce negativamente sulla velocità effettiva generale del sistema.
Crescita della tabella TrackingData
La tabella TrackingData del database MessageBox è una tabella di transizione in cui gli intercettori scrivono dati di rilevamento relativi sia al rilevamento delle istanze di servizio, sia al rilevamento BAM. Se il rilevamento è disattivato, questa tabella dovrebbe essere vuota. Per impostazione predefinita, il rilevamento delle istanze di servizio è attivato per gli eventi in ingresso e in uscita di orchestrazioni e pipeline.
Se il rilevamento del corpo del messaggio è attivato, assicurarsi che il server MessageBox, ovvero l'host con l'opzione "Consenti rilevamento host", sia in esecuzione. Ciò ridurrà un collo di bottiglia dal momento che sposta dati dalla tabella TrackingData nel database MessageBox alle tabelle BizTalkDTADb.
È possibile tenere traccia degli eventi personalizzati abilitando il rilevamento personalizzato di messaggi e istanze del servizio, ad esempio su proprietà promosse e rilevamento del corpo dei messaggi. Oltre ai dati di rilevamento, anche i dati BAM vengono scritti in questa tabella. È responsabilità di TDDS (l'host in cui il rilevamento è attivato) di spostare questi dati dal database MessageBox ai database BizTalkDTADb e BAMPrimaryImport, quindi una volta spostati correttamente di eliminarli. 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 supportare la velocità di scrittura dei dati degli intercettori nella tabella TrackingData, quest'ultima crescerà causando la limitazione delle richieste da avviare, influenzando negativamente la velocità effettiva sostenibile. Per risolvere il problema, assicurarsi che almeno un host sia in esecuzione con il rilevamento attivato.
Se i dati continuano a crescere, verificare il database BizTalkDTADb per assicurarsi che non stia crescendo fuori controllo. Assicurarsi che il processo di eliminazione e di archiviazione sia in esecuzione e che sia in grado di supportare la velocità di arrivo dei dati.
Nota
Il processo di eliminazione non è in grado di eliminare dati dalle tabelle BizTalkDTADb fin quando i dati non sono stati archiviati.
Verificare che la tabella TrackingData non stia aumentando in termini di dimensioni. Assicurarsi che almeno un'istanza host in esecuzione abbia il rilevamento attivato (TDDS). Se le dimensioni del database BizTalkDTADb sono aumentate di molto, ciò può avere un impatto negativo sulla capacità di TDDS di spostare dati dal database MessageBox al database BizTalkDTADb.
La crescita della tabella TrackingData può provocare la limitazione delle richieste da avviare, influenzando negativamente la velocità di runtime sostenibile.