Identificare i colli di bottiglia nel database MessageBox

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

Per impostazione predefinita, il servizio BizTalk applicherà limitazioni se le tabelle Spool, TrackingData o ApplicationQ crescono. Queste tabelle vengono potate dai processi SQL-Agent che, se non sono in esecuzione, faranno aumentare lo Spool, causando l'attivazione della limitazione per proteggere il database da ulteriori pressioni. Controllare lo stato dei contatori delle prestazioni seguenti:

• Stato di limitazione del recapito dei messaggi BizTalk:Message Agent (nome host)

• Stato di limitazione della pubblicazione dei messaggi BizTalk: Message Agent (Nome Host)

  Un valore di 0 indica che non si sta verificando alcuno strozzamento. Il valore 6 indica che il sistema sta limitando le prestazioni a causa della crescita del database. Fare riferimento alla documentazione su come interpretare altri valori di questi contatori.

Crescita della Tabella di Spool

Lo Spool può iniziare a crescere per diversi motivi. Un motivo per la crescita di Spool è l'aumento delle code dell'applicazione. Potrebbero crescere per vari motivi, come ad esempio i colli di bottiglia a valle e/o la contesa di risorse.

Se le code dell'applicazione sono di piccole dimensioni e lo Spool è ancora grande, verificare che i processi di eliminazione stiano al passo. Assicurarsi che il servizio SQL-Agent sia in esecuzione e poi controllare che le attività seguenti siano state portate a termine con successo.

• MessageBox_Message_Cleanup_BizTalkMessageBoxDb

• MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

  Se la tabella MessageZeroSum è grande, indica che i messaggi sono stati elaborati (DeQueue ha completato ed eliminato correttamente i dati dalle tabelle della coda di applicazioni) e che le righe sono state contrassegnate per l'eliminazione. Tuttavia, i processi di eliminazione non sono in grado di tenere il passo con l'eliminazione dei dati. Uno dei motivi è che il computer SQL-Server potrebbe riscontrare una forte contesa della CPU, influenzando la capacità dei processi di ripulitura di tenere il passo a causa della saturazione della CPU.

Crescita della tabella delle code delle applicazioni

Le code delle applicazioni contengono dati di transizione in corso che, una volta elaborati, vengono rimossi da DeQueue.

Dopo l'elaborazione di questi messaggi, è possibile pulire lo Spool (che contiene riferimenti a queste righe).

Ad esempio, RxHostQ pubblica i dati su PxHostQ che a sua volta pubblica i dati su TxHostQ, ognuno dei quali fa riferimento a una riga nella tabella Spool. Dopo che i messaggi per un particolare HostQ sono stati elaborati correttamente tramite il sistema, queste righe vengono eliminate da DeQueue. Dopo l'eliminazione di queste righe, lo spool (a cui non si fa più riferimento da queste righe) può quindi essere ripulito dai processi di ripulitura.

L'aumento della coda di applicazioni indica che le istanze host responsabili dello svuotamento della coda dell'applicazione non sono in grado di mantenere il passo con la velocità in ingresso, ovvero la frequenza con cui i messaggi vengono pubblicati nella coda dell'applicazione specifica.

Ad esempio, la coda dell'applicazione di orchestrazione (PxHostQ) può aumentare perché 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, potrebbe pubblicare più velocemente rispetto a quello che il server di orchestrazione può elaborare causando la crescita della coda dell'applicazione.

Un altro motivo per l'aumento della coda di orchestrazione potrebbe essere la contesa di memoria, in cui numerose istanze di orchestrazione a esecuzione prolungata vengono tutte create contemporaneamente in memoria, causando un sovraccarico di memoria che indirettamente porta a ridurre la velocità del pool di thread fino a quando la pressione sulla memoria non viene alleviata. 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) abbastanza velocemente. Di conseguenza, i messaggi continueranno a risiedere all'interno del sistema BizTalk, causando l'aumento della coda dell'applicazione, che in ultima analisi farà entrare in funzione il controllo del flusso, riducendo la velocità di ricezione e influenzando la capacità complessiva del sistema.

Crescita della tabella TrackingData

La tabella TrackingData nel database MessageBox è una tabella di transizione in cui gli intercettori scrivono dati di rilevamento per il rilevamento di messaggi e istanze del servizio e il rilevamento BAM. Se il rilevamento è disabilitato, la tabella deve essere vuota. Per impostazione predefinita, il rilevamento di messaggi e istanze del servizio è abilitato per le pipeline e per gli eventi di entrata/uscita dell'orchestrazione.

Se il rilevamento del corpo del messaggio è abilitato, assicurarsi che il server MessageBox (cioè l'host con "consentire il tracciamento dell'host") sia in esecuzione. Ridurrà un collo di bottiglia mentre sposta i 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 tenere traccia del corpo del messaggio. Oltre a tenere traccia dei dati, i dati BAM vengono scritti anche in questa tabella. È responsabilità di TDDS (l'host in cui è abilitato il rilevamento) spostare questi dati dal database MessageBox ai database BizTalkDTADb e BAMPrimaryImport e quindi, una volta spostati correttamente, eliminare questi dati. I dati di tracciamento del corpo del messaggio vengono spostati separatamente da un processo identificato come SQL-Agent, TrackedMessages_Copy_BizTalkMsgBoxDb.

Se TDDS non è in grado di tenere il passo con la velocità con cui gli intercettori scrivono dati nella tabella TrackingData, questa tabella crescerà, causando l'avvio della limitazione, che alla fine influirà sulla capacità di mantenere una velocità di trasmissione dati sostenibile. Per risolvere questo problema, assicurarsi che almeno 1 host sia in esecuzione con il rilevamento abilitato.

Se i dati continuano ad accumularsi, controllare il database BizTalkDTADb per assicurarsi che il database non stia crescendo incontrollatamente. Assicurarsi che il processo di archiviazione e eliminazione sia in esecuzione e sia in grado di mantenere il passo con la frequenza con cui arrivano i dati.

Annotazioni

Il processo di eliminazione non è in grado di eliminare i dati dalle tabelle BizTalkDTADb fino a quando questi dati non sono stati archiviati.

Verificare che la tabella TrackingData non sia in crescita. Assicurarsi che almeno 1 istanza host in esecuzione abbia il rilevamento abilitato (TDDS). Se il database BizTalkDTADb è troppo grande, può avere un impatto negativo sulla capacità di TDDS di spostare i dati dal database MessageBox al database BizTalkDTADb.

La crescita nella tabella TrackingData può causare l'attivazione della limitazione, con un impatto sulle prestazioni di runtime sostenibili.