Come gestire e risolvere i database di BizTalk Server

Riepilogo

I database di Microsoft BizTalk Server e l'integrità dei database sono molto importanti per un ambiente di messaggistica BizTalk Server riuscito. In questo articolo vengono illustrati aspetti importanti da considerare quando si utilizzano i database di BizTalk Server. Queste considerazioni includono le seguenti:

  • È necessario disabilitare le opzioni di aggiornamento automatico delle statistiche e di creazione automatica delle statistiche di Microsoft SQL Server.

  • Devi impostare correttamente la proprietà max degree of parallelism.

  • Determinare quando è possibile ricostruire gli indici di BizTalk Server.

  • Può verificarsi il blocco, il deadlock o il blocco.

  • Potrebbero verificarsi problemi con i database o le tabelle di grandi dimensioni.

  • Processi di BizTalk SQL Server Agent

  • Le istanze del servizio possono essere sospese.

  • È possibile che si verifichino problemi di prestazioni di SQL Server e BizTalk Server.

  • È consigliabile seguire le procedure consigliate in BizTalk Server.

INTRODUZIONE

Questo articolo descrive come gestire i database di BizTalk Server e come risolvere i problemi di database di BizTalk Server.

Ulteriori informazioni

Problemi noti

È necessario disabilitare le opzioni di aggiornamento automatico delle statistiche e di creazione automatica

È necessario disabilitare le opzioni di creazione automatica di statistiche e di aggiornamento automatico nel database di BizTalkMsgBoxDb. Per determinare se queste impostazioni sono disabilitate, eseguire le stored procedure seguenti in SQL Server:

exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

Devi impostare l'impostazione CurrentSetting su disattivato. Se questa impostazione è impostata suattivato, disattivarla eseguendo le stored procedure seguenti in SQL Server:

exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

Per ulteriori informazioni, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito:

Quando si tenta di connettersi al database di BizTalkMsgBoxDb in BizTalk Server, si verificano problemi di blocco, condizioni di deadlock o altri errori di SQL Server

L'opzione Auto Update Statistics, l'opzione Auto Create Statistics e l'impostazione parallelism sono disattivate nell'istanza di database di SQL Server che ospita il database di BizTalkMsgBoxDB di BizTalk Server

È necessario impostare correttamente la proprietà max degree of parallelism

Nel computer in cui è in uso SQL Server e che ospita il database BizTalkMsgBoxDb, impostare il grado massimo di parallelismo run_value e config_value proprietà su un valore pari a 1. Per determinare l'impostazione max degree of parallelism, eseguire la stored procedure seguente per il database master in SQL Server:

exec sp_configure 'max degree of parallelism'

Se le proprietà run_value e config_value non sono impostate su un valore pari a 1, eseguire la stored procedure seguente in SQL Server per impostarle su 1:

exec sp_configure 'max degree of parallelism', '1'reconfigure with override

Per ulteriori informazioni, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito:

Impostazione parallelism per l'istanza di SQL Server quando si configura BizTalk Server

Quando si tenta di connettersi al database di BizTalkMsgBoxDb in BizTalk Server, si verificano problemi di blocco, condizioni di deadlock o altri errori di SQL Server

Determinare quando è possibile ricostruire gli indici di BizTalk Server

La maggior parte degli indici di BizTalk Server è raggruppata (ID indice: 1). Per visualizzare le informazioni sulla frammentazione per le tabelle di BizTalk Server, è possibile usare l'istruzione DBCC SHOWCONTIG SQL Server. Gli indici di BizTalk Server sono basati su GUID. Di conseguenza, la frammentazione si verifica in genere. Se il valore della densità di analisi restituito dall'istruzione DBCC SHOWCONTIG è inferiore al 30%, gli indici di BizTalk Server possono essere ricostruiti durante i tempi di inattività. Molte tabelle di BizTalk Server contengono colonne che usano definizioni di tipo di contenuto. L'indicizzazione online non può essere eseguita in queste colonne. Di conseguenza, non è consigliabile ricompilare gli indici di BizTalk Server mentre BizTalk Server elabora i dati. Per ulteriori informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo nella Microsoft Knowledge Base:

Quando si tenta di connettersi al database di BizTalkMsgBoxDb in BizTalk Server, si verificano problemi di blocco, condizioni di deadlock o altri errori di SQL Server Per altre informazioni su come analizzare l'output dell'istruzione DBCC SHOWCONTIG, visitare il sito Web Microsoft seguente:

Può verificarsi il blocco, il deadlock o il blocco

In genere, i blocchi e i blocchi si verificano in un ambiente BizTalk Server. Tuttavia, questi blocchi non rimangono per un periodo di tempo prolungato. Di conseguenza, il blocco e il deadlock indicano un potenziale problema. Per altre informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente per visualizzare l'articolo:

Quando si tenta di connettersi al database di BizTalkMsgBoxDb in BizTalk Server, si verificano problemi di blocco, condizioni di deadlock o altri errori di SQL Server

Si potrebbero riscontrare problemi con database o tabelle di grandi dimensioni

Quando il database di BizTalkMsgBoxDb è maggiore di 5GB, è possibile che si verifichino problemi di prestazioni. In teoria, il database BizTalkMsgBoxDb non deve contenere dati. Il database BizTalkMsgBoxDb deve essere considerato un buffer finché i dati non vengono elaborati o spostati nel database BizTalkDTADb. Un ambiente che usa un potente SQL Server al back-end e che molte orchestrazioni a lunga durata possono avere un database di BizTalkMsgBoxDb di dimensioni maggiori di 5 GB. Un ambiente di grandi volumi che non usa orchestrazioni a lunga durata deve avere un database di BizTalkMsgBoxDb molto più piccolo di 5 GB. Il database BizTalkDTADb non ha dimensioni impostate. Tuttavia, se le prestazioni diminuiscono, il database è probabilmente troppo grande. In genere, da 15 GB a 20 GB è considerato troppo grande. Quando si dispone di database di BizTalk Server di grandi dimensioni, è possibile che si verifichino i problemi seguenti:

  • Il database di BizTalkMsgBoxDb continua a crescere. Tuttavia, sia il file di log che le dimensioni dei dati rimangono grandi.

  • BizTalk Server richiede più tempo del normale per elaborare anche un semplice scenario di flusso dei messaggi.

  • Le query di monitoraggio dell'integrità e delle attività (HAT) richiedono più tempo del normale e potrebbero uscire.

  • Il file di log del database non viene mai troncato.

  • I processi di SQL Server Agent di BizTalk vengono eseguiti più lentamente del solito.

  • Alcune tabelle sono significativamente più grandi o hanno un numero eccessivo di righe rispetto alle dimensioni normali della tabella.

I database possono diventare grandi per diversi motivi. Questi motivi possono includere i seguenti:

  • I processi di BizTalk SQL Server Agent non vengono eseguiti

  • Numero elevato di istanze sospese

  • Errori del disco

  • Verifica

  • Limitazione

  • Prestazioni di SQL Server

  • Latenza di rete

Verificare che l'ambiente in questione sia in grado di determinare se si verifica un problema di dati. Per impostazione predefinita, il rilevamento è abilitato nell'host predefinito. BizTalk richiede che l'opzione Consenti il rilevamento dell'host sia selezionata in un singolo host. Quando il rilevamento è abilitato, il servizio di decodificazione dei dati di rilevamento (TDDS) sposta i dati dell'evento di rilevamento dal database BizTalkMsgBoxDb al database BizTalkDTADb. Se l'host di rilevamento viene interrotto, TDDS non trasferisce i dati al database BizTalkDTADb e si svilupperanno le tabelle TrackingData_x_x nel database BizTalkMsgBoxDb. È consigliabile dedicare un host al rilevamento. Per consentire a TDDS di mantenere nuovi eventi di rilevamento in scenari con volumi elevati, creare più istanze di un singolo host di rilevamento. Non deve esistere più di un host di rilevamento. In una tabella possono essere presenti troppe righe. Non esiste un numero impostato di righe troppo numerosi. Inoltre, questo numero di righe varia in base al tipo di dati archiviati nella tabella. Ad esempio, una tabella dta_DebugTrace con più di 1 milione righe ha probabilmente troppe righe. Un nome hostQ_Suspended tabella con più di 200.000 righe ha probabilmente troppe righe.

Usare i processi corretti di BizTalk SQL Server Agent

I processi di SQL Server Agent di BizTalk sono importanti per la gestione dei database di BizTalk Server e per il mantenimento di prestazioni elevate. Il processo di backup di SQL Server Agent di BizTalk server è l'unico metodo supportato per eseguire il backup dei database di BizTalk Server quando vengono avviate le istanze di SQL Server Agent e BizTalkServer host. Questo processo richiede che tutti i database di BizTalk Server usino un modello di recupero completo. È consigliabile configurare questo processo per un ambiente di BizTalk Server integro. I metodi di SQL Server possono essere usati per eseguire il backup dei database di BizTalk Server solo se SQL Server Agent viene arrestato e se tutte le istanze dell'host BizTalk Server vengono interrotte. Il processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent viene eseguito infinitamente. Di conseguenza, la cronologia dei processi di SQL Server Agent non visualizza mai il completamento corretto. Se si verifica un errore, il processo viene riavviato entro un minuto e continua a essere eseguito infinitamente. Puoi quindi ignorare in modo sicuro l'errore. Inoltre, la cronologia dei processi può essere deselezionata. È consigliabile preoccuparsi solo se la cronologia dei processi segnala che il processo non riesce e viene riavviato costantemente. Il processo di MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server Agent è l'unico processo di BizTalk Server che non deve essere abilitato perché viene avviato dal processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb agente SQL Server. Il processo DTA Purge and Archive di SQL Server Agent consente di gestire il database BizTalkDTADb eliminando e archiviando i messaggi rilevati. Questo processo legge tutte le righe della tabella e confronta l'indicatore di data e ora per determinare se il record deve essere rimosso. Tutti i processi di BizTalk SQL Server Agent eccetto il processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent devono essere eseguiti correttamente. Per altre informazioni su tutti i processi di SQL Server Agent di BizTalk Server, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente per visualizzare l'articolo:

Descrizione dei processi di SQL Server Agent in BizTalk Server

Le istanze del servizio possono essere sospese

Le istanze del servizio possono essere sospese (ripristinabili) o sospese (non ripristinabili). Queste istanze del servizio possono essere messaggistica, orchestrazione o porta. Queste istanze del servizio possono rendere inutilmente il database BizTalkMsgBoxDb e possono essere terminati. La tabella seguente elenca il metodo che può essere usato, a seconda della versione di BizTalk:

Hub gruppo

CAPPELLO

Terminate.vbs

Strumento Terminator

BizTalk Server 2010

No

BizTalk Server 2009

No

BizTalk Server 2006 R2

BizTalk Server 2006

BizTalk Server 2004

No

Per altre informazioni sullo script Terminate. vbs, visitare il sito Web MSDN seguente:

Le istanze di memorizzazione nella cache non vengono visualizzate nella pagina Hub gruppo e non è possibile sospenderle o terminarle. Questa restrizione è una causa comune della crescita della tabella. Per impedire l'inserimento di nuovi messaggi zombie per le istanze del servizio cache in BizTalk Server 2006, installare l'hotfix nell'articolo della Microsoft Knowledge base 936536. Questo problema è stato risolto in BizTalk Server 2006 R2 e versioni successive.Nota Un messaggio di zombie è un messaggio instradato ma non usato. Per altre informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo nella Knowledge Base Mirosoft:

Correzione: si verificano problemi di prestazioni con BizTalk Server 2006 e i messaggi di limitazione vengono registrati nel file di log delle prestazioni Quando un'istanza dell'host BizTalk Server termina, non è possibile rimuovere istanze della cache. Per risolvere il problema in BizTalk Server 2006, installare l'hotfix nell'articolo della Microsoft Knowledge base 944426. In BizTalk Server 2006 R2 installare BizTalk 2006 R2 Service Pack 1. Questo problema è stato risolto in BizTalk Server 2009 e versioni successive. Per altre informazioni, fare clic sui numeri di articolo seguenti per visualizzare gli articoli della Microsoft Knowledge Base:

Elenco degli hotfix di Microsoft BizTalk Server inclusi in BizTalk Server 2006 R2 Service Pack 1

FIX: le istanze della cache orfane possono essere compilate nelle tabelle delle istanze e degli host del database BizTalkMsgBoxDb in BizTalk Server 2006 e in BizTalk Server 2006 R2

Un altro problema comune è che i report sugli errori di routing (RFRs) possono essere accumulati nelle tabelle di Q_Suspended BizTalkHostQ e BizTalkHost. Il RFRs non viene rimosso e questo comportamento può causare un aumento del database di BizTalkMsgBoxDb. Per risolvere il problema in BizTalk Server 2006, installare l'hotfix nell'articolo della Microsoft Knowledge base 941690. Questo problema è stato risolto in BizTalk Server 2006 R2 e versioni successive. Per ulteriori informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo nella Microsoft Knowledge Base:

Correzione: i report di errore di routing non vengono rimossi dalla <BizTalkHostName>Q_Suspended tabella in un Server 2006 di BizTalk Server

I termini "messaggi orfani" e "messaggi zombie" vengono usati di frequente in intercambiabilità. Un messaggio orfano è un messaggio che non ha un'istanza associata. Ad esempio, un report di errore di routing è un messaggio orfano. Un messaggio di zombie è un messaggio instradato ma non usato. Ad esempio, un messaggio è stato recapitato a un'orchestrazione convoglio. Tuttavia, l'orchestrazione convoglio è scesa in un altro percorso di codice. Termina l'istanza di orchestrazione. Il messaggio viene scartato ed è ora noto come messaggio zombie. Per una descrizione dei messaggi di zombie, visitare il sito Web MSDN seguente:

È possibile che si verifichino problemi di prestazioni di SQL Server e BizTalk Server

BizTalk Server esegue centinaia di brevi transazioni rapide in SQL Server entro un minuto. Se SQL Server non è in grado di supportare questa attività, BizTalk Server potrebbe riscontrare problemi di prestazioni. In performance monitor monitorare l' AVG. disco sec/Read, media Disk sec/transfer e monitoraggio delle prestazioni di media Disk sec/Write contatori nell'oggetto prestazione PhysicalDisk . Il valore ottimale è minore di 10 ms (millisecondi). Un valore pari a 20 ms o più grande è considerato prestazioni scarse. Per altre informazioni sulle prestazioni di SQL Server, visitare il sito Web Microsoft seguente:

Per altre informazioni sulla disponibilità elevata di database di BizTalk Server 2004, visitare il sito Web MSDN seguente:

Per altre informazioni sulla disponibilità elevata di database di BizTalk Server 2006, visitare il sito Web MSDN seguente:

Per ulteriori informazioni, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito:

Come risolvere i problemi di prestazioni di SQL Server 2000 2005, XXX XXX XX XXX XX XXX XX XXX

Procedure consigliate in BizTalk Server

Avviare SQL Server Agent in SQL Server. Quando l'agente SQL Server viene arrestato, non è possibile eseguire i processi predefiniti di SQL Server Agent di BizTalk responsabili della manutenzione del database. Questo comportamento causa lo sviluppo di database e questo aumento può causare problemi di prestazioni. La manutenzione del database di BizTalk Server è notevolmente migliorata in BizTalk Server 2004 Service Pack 2 (SP2) e versioni successive. Inserire i file di SQL Server LDF e MDF in unità separate. Quando i file LDF e MDF per i database BizTalkMsgBoxDb e BizTalkDTADb si trovano nella stessa unità, è possibile che si verifichi il conflitto del disco. Se non si beneficia della verifica del corpo del messaggio, non abilitare questa caratteristica. Tuttavia, è consigliabile abilitare il rilevamento del corpo del messaggio durante lo sviluppo e la risoluzione dei problemi di una soluzione. In questo caso, assicurati di disabilitare il rilevamento del corpo del messaggio al termine. Quando è abilitata la verifica del corpo del messaggio, i database di BizTalk Server crescono. In caso di esigenze aziendali che richiedono l'abilitazione del rilevamento del corpo del messaggio, verificare che i processi di eliminazione dei TrackedMessages_Copy_BizTalkMsgBoxDb e DTA e di archiviazione di SQL Server Agent vengano eseguiti correttamente. In genere, i log delle transazioni più piccoli causano prestazioni migliori. Per ridurre i registri delle transazioni, configurare il processo di backup di SQL Server Agent di BizTalk server in modo che venga eseguito più di frequente. Per altre informazioni sull'ottimizzazione di BizTalk Server, visitare il sito Web MSDN seguente:

La stored procedure sp_ForceFullBackup nel database BizTalkMgmtDb può essere usata anche per facilitare l'esecuzione di un backup completo ad-hoc dei file di dati e di log. La stored procedure aggiorna la tabella adm_ForceFullBackup con un valore 1. La volta successiva che viene eseguito il processo di backup di BizTalk Server , viene creato un set di backup completo del database. BizTalk Server Best Practices Analyzer (BPA) può essere usato per valutare una distribuzione di BizTalk Server esistente. Il BPA esegue numerosi controlli correlati al database.

Risoluzione dei problemi

Le procedure consigliate per la risoluzione dei problemi per i database di SQL Server di BizTalk Server dipendono dal tipo di problema di database, ad esempio il blocco o il deadlock. Per risolvere i problemi di un database di BizTalk Server, eseguire la procedura seguente.

Passaggio 1: abilitare ed eseguire tutti i processi necessari di BizTalk SQL Server Agent

Tutti i processi di BizTalk SQL Server Agent eccetto il processo MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb devono essere abilitati ed eseguiti correttamente. Non disabilitare altri processi. Se si verifica un errore, usare l'opzione Visualizza cronologia in SQL Server per visualizzare le informazioni sugli errori e quindi risolvere il problema di conseguenza. Tenere presente che il processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent viene eseguito infinitamente. Pertanto, dovresti essere interessato solo se la cronologia dei processi segnala che il processo non riesce e viene riavviato costantemente.

Passaggio 2: usare lo strumento MsgBoxViewer

Raccogliere i dati di MsgBoxViewer durante la riproduzione di un problema. Lo strumento MsgBoxViewer è utile per la risoluzione dei problemi perché fornisce un report HTML con informazioni dettagliate sulle dimensioni delle tabelle e sul numero di righe. Il report può anche determinare se BizTalk Server sta strozzando. Lo strumento fornisce inoltre uno snapshot dei database di BizTalk Server e della configurazione di BizTalk Server. Per altre informazioni su come scaricare lo strumento MsgBoxViewer, visitare il sito Web Microsoft seguente:

Per altre informazioni sulla limitazione in BizTalk Server, visitare il sito Web MSDN seguente:

Quando BizTalk Server è in esecuzione più lento del solito, eseguire lo strumento MsgBoxViewer e quindi rivedere il report HTML generato per eventuali problemi. La sezione Riepilogo elenca gli avvisi in giallo e i potenziali problemi in rosso. Inoltre, puoi usare l'output dello strumento MsgBoxViewer per determinare quali tabelle sono le più grandi e hanno la maggior parte dei record. Nella tabella seguente sono elencate le tabelle di BizTalk Server che in genere aumentano la maggiore. Puoi usare questi dati per determinare dove potrebbe esistere un potenziale problema.

tavolo

Descrizione

HostNameQ_Suspended

Questa tabella contiene un riferimento ai messaggi nella tabella di spooling associati alle istanze sospese per l'host specifico. Questa tabella si trova nel database BizTalkMsgBoxDb.

HostNameQ

Questa tabella contiene un riferimento ai messaggi nella tabella di spooling associati all'host specifico e non vengono sospesi. Questa tabella si trova nel database BizTalkMsgBoxDb.

Bobina Parti Frammenti

Queste tabelle archiviano i dati dei messaggi effettivi nel database di BizTalkMsgBoxDb.

Istanze

Questa tabella archivia tutte le istanze e lo stato corrente nel database di BizTalkMsgBoxDb.

TrackingData_0_x

Queste quattro tabelle archiviano gli eventi di monitoraggio delle attività aziendali (BAM) nel database di BizTalkMsgBoxDb per TDDS per trasferire gli eventi nel database di BAMPrimaryImport.

TrackingData_1_x

Queste quattro tabelle archiviano gli eventi rilevati nel database di BizTalkMsgBoxDb per TDDS per trasferire gli eventi nel database BizTalkDTADB.

Tracking_Fragmentsx Tracking_Partsx Tracking_Spoolx

Due di queste tabelle si trovano nei database BizTalkMsgBoxDb e BizTalkDTADb. Uno è online e l'altro è offline. In BizTalk Server 2004 SP2 e nelle versioni successive, il processo di TrackedMessages_Copy_BizTalkMsgBoxDb agente SQL Server sposta i corpi dei messaggi rilevati direttamente in queste tabelle nel database BizTalkDTADb. In BizTalk Server 2004 Service Pack 1 (SP1) e nelle versioni precedenti di BizTalk Server 2004, il processo di TrackedMessages_Copy_BizTalkMsgBoxDb agente SQL Server copia i corpi dei messaggi rilevati in queste tabelle nel database di BizTalkMsgBoxDb. Il processo di TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server Agent Elimina le tabelle offline e rende le tabelle online mentre il processo accetta anche le tabelle online.

dta_ServiceInstances

Questa tabella archivia gli eventi rilevati per le istanze del servizio nel database BizTalkDTADb. Se la tabella è di grandi dimensioni, il database BizTalkDTADb è probabilmente di grandi dimensioni.

dta_DebugTrace

Questa tabella archivia gli eventi del debugger dell'orchestrazione nel database BizTalkDTADb.

dta_MessageInOutEvents

Questa tabella archivia i messaggi di evento rilevati nel database BizTalkDTADb. Questi messaggi di evento rilevati includono informazioni sul contesto dei messaggi.

dta_ServiceInstanceExceptions

Questa tabella archivia le informazioni sugli errori per qualsiasi istanza di servizio sospesa nel database BizTalkDTADb.

Consideriamo gli scenari seguenti.

HostNameQ_Suspended tabelle

Se il nome hostQ_Suspended tabelle è costituito da più record, le tabelle potrebbero essere istanze di sospensione valide visualizzate nell' hub del gruppo o in Hat. Queste istanze possono essere terminate. Se queste istanze non vengono visualizzate nell' Hub di gruppo o in Hat, le istanze stanno probabilmente memorizzando nella cache le istanze o i report degli errori di routing orfani. Quando vengono terminate le istanze sospese, gli elementi della tabella e le righe associate nelle tabelle Spool e instances vengono eliminati. In questo scenario, gestire le istanze sospese riprenderle o chiuderle. È anche possibile usare lo strumento di terminazione BizTalk.

HostNameTabelle Q

Se le tabelle hostnameQ hanno molti record, potrebbero esistere i seguenti tipi di istanze:

  • Istanze pronte per l'esecuzione

  • Istanze attive

  • Istanze disidratate

BizTalk Server richiede tempo per "recuperare il ritardo" ed elaborare le istanze. Questa tabella può aumentare quando il tasso di elaborazione in arrivo supera il tasso di elaborazione in uscita. Questo scenario può verificarsi quando si verifica un altro problema, ad esempio un database BizTalkDTADb di grandi dimensioni o ritardi del disco di SQL Server.

Tabelle Spool, Parts e Fragments

Se le tabelle Spool, Parts e Fragments includono molti record, molti messaggi sono attualmente attivi, disidratati o sospesi. In base alle dimensioni, al numero di parti e alle impostazioni di frammentazione in queste tabelle, un singolo messaggio può generare tutte le tabelle. Ogni messaggio contiene esattamente una riga nella tabella di spooling e almeno una riga nella tabella parti.

Tabella istanze

L'amministratore di BizTalk non deve consentire la permanenza di molte istanze sospese nella tabella istanze. Le istanze disidratate devono rimanere solo se la logica aziendale richiede le orchestrazioni a lunga durata. Tenere presente che un'istanza del servizio può essere associata a molti messaggi nella tabella di spooling.

TrackingData_x_x tabelle

Se le tabelle TrackingData_x_x sono di grandi dimensioni, l'host di rilevamento (TDDS) non è in funzione o non viene eseguito correttamente. Se l'istanza dell'host di rilevamento è in corso, esaminare i registri eventi e la tabella TDDS_FailedTrackingData nel database BizTalkDTADb per informazioni sugli errori. Se BizTalk sta strozzando con uno stato di 6 (database di grandi dimensioni), queste tabelle possono essere troncate anche usando lo strumento di terminazione BizTalk. Se c'è un grande divario tra i numeri di sequenza nelle tabelle BizTalkMsgBoxDb TrackingData_x_x e le tabelle BAMPrimaryImport o BizTalkDTADb TDDS_StreamStatus, TDDS potrebbe non trasferire i dati dal database di BizTalkMsgBoxDb. Per risolvere il problema, usare lo strumento terminatore BizTalk per eliminare queste tabelle e reimpostare il numero di sequenza. In BizTalk Server 2006 R2 installare BizTalk 2006 R2 Service Pack 1 per risolvere un problema noto con i dati di rilevamento. Per ulteriori informazioni, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito:

FIX: i dati di rilevamento non vengono spostati come previsto dal database BizTalkMsgBoxDb al database BizTalkDTADb in BizTalk Server 2006 R2 elenco degli hotfix di Microsoft BizTalk Server inclusi in biztalk Server 2006 R2 Service Pack 1

Tracking_Spool1 o Tracking_Spool2 tabelle

Se le tabelle Tracking_Spool1 o Tracking_Spool2 diventano estese in BizTalk Server 2004 SP1 e nelle versioni precedenti di BizTalk Server 2004, verificare che il processo di TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server Agent sia abilitato ed eseguito. Per ulteriori informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo nella Microsoft Knowledge Base:

Le tabelle Tracking_Spool1 o Tracking_Spool2 nel database di BiztalkMsgBoxDb diventano molto estese in BizTalk Server 2004 Per altre informazioni su un esempio di SDK per la manutenzione di database, visitare il sito Web MSDN seguente:

dta_DebugTrace tabella e dta_MessageInOutEvents

La tabella dta_DebugTrace viene popolata quando l' inizio e la fine della forma sono abilitate in un'orchestrazione. Se nella tabella dta_DebugTrace sono presenti molti record, questi eventi di debug dell'orchestrazione vengono usati o usati. Se il debug dell'orchestrazione non è necessario per le operazioni regolari, deselezionare la casella di controllo relativa all'opzione di inizio e fine delle forme nelle proprietà dell'orchestrazione. La tabella dta_MessageInOutEvents viene popolata quando l' invio e la ricezione dei messaggi è abilitato per le orchestrazioni e/o le pipeline. Se questi eventi di rilevamento non sono necessari, deselezionare la casella di controllo relativa a questa opzione nelle Proprietà orchestrazione e/o pipeline. Se questi eventi di traccia sono disabilitati o se nel database di BizTalkMsgBoxDb è presente un backlog, queste tabelle possono continuare a crescere perché TDDS continua a trasferire questi dati in queste tabelle. Per impostazione predefinita, il rilevamento globale è abilitato. Se il rilevamento globale non è necessario, è possibile disabilitarlo. Per altre informazioni, visitare il sito Web Microsoft seguente:

Se la tabella dta_DebugTrace e/o la tabella dta_messageInOutEvents nel database BizTalkDTADb sono troppo grandi, è possibile troncare manualmente le tabelle dopo l'interruzione dell'host di rilevamento. Lo strumento di terminazione BizTalk offre anche questa funzionalità. In BizTalk Server 2004 la visualizzazione dtav_FindMessageFacts nel database BizTalkDTADb impedisce il troncamento della tabella dta_MessageInOutEvents. Per risolvere il problema, eseguire le operazioni seguenti:

  1. Arrestare l'host di rilevamento e il processo di eliminazione e archiviazione DTA.

  2. Se si vuole troncare la tabella dta_messageInOutEvents, salvare e quindi eliminare la visualizzazione dtav_FindMessageFacts. A tal fine, attenersi alla seguente procedura:

    1. In SQL Server accedere alla visualizzazione dtav_FindMessageFacts nel database BizTalkDTADb.

    2. Fare clic con il pulsante destro del mouse sulla visualizzazione dtav_FindMessageFacts , scegliere tutte le attivitàe quindi fare clic su Genera script SQL. Quando viene visualizzata la finestra di dialogo Genera script SQL , apportare modifiche e quindi fare clic su OK.

    3. Assegnare un nome al file dtav_FindMessageFacts. SQL e quindi fare clic su Salva.

    4. Fare clic con il pulsante destro del mouse sulla visualizzazione dtav_FindMessageFacts e quindi scegliere Elimina. Fare clic su rilascia tutto.

Ora è possibile troncare la tabella o le tabelle. Se si tronca la tabella dta_messageInOutEvents, è necessario troncare anche la tabella dta_url. La tabella dta_url esiste solo in BizTalk Server 2004. Al termine, eseguire la procedura seguente per ricreare la visualizzazione dtav_FindMessageFacts:

  1. Aprire una nuova query in SQL Server.

  2. Nell'elenco database disponibili selezionare il database BizTalkDTADb .

  3. Eseguire lo script dtav_FindMessageFacts. SQL salvato. In questo modo, la visualizzazione verrà ricreata nel database BizTalkDTADb.

Riavviare l'host di rilevamento e il processo di eliminazione e archiviazione DTA .

Per altre informazioni sul monitoraggio delle linee guida per il ridimensionamento del database, visitare il sito Web MSDN seguente:

tabella dta_ServiceInstanceExceptions

La tabella dta_ServiceInstanceExceptions in genere diventa grande in un ambiente che contiene regolarmente istanze sospese.

Passaggio 3: esaminare gli scenari di deadlock

In uno scenario di deadlock, abilitare la traccia DBCC in SQL Server in modo che le informazioni sul deadlock vengano scritte nel log di SQLERROR. In SQL Server 2005 e versioni successive eseguire l'istruzione seguente:

DBCC TRACEON (1222,-1)

In SQL Server 2000 eseguire l'istruzione seguente:

DBCC TRACEON (1204)

Inoltre, usa l'utilità PSSDiag per raccogliere dati nell'evento Lock: deadlock e nell'eventoLock: Deadlock Chain . Il database di BizTalkMsgBoxDB è un database di elaborazione delle transazioni online ad alto volume e ad alta transazione (OLTP). È previsto un deadlock e questo deadlock viene gestito internamente dal motore di BizTalk Server. Quando si verifica questo comportamento, nessun errore viene elencato nei log degli errori. Quando si esamina uno scenario di deadlock, il deadlock che si sta esaminando nell'output deve essere correlato con un errore di deadlock nei registri eventi. Per altre informazioni su PSSDiag per SQL, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente per visualizzare l'articolo:

Utilità per la raccolta dati PSSDIAG

Passaggio 4: cercare processi bloccati

Usare monitoraggio attività in SQL Server per ottenere l'identificatore del processo server (SPID) di un processo di sistema di blocco. Esegui quindi SQL Profiler per determinare l'istruzione SQL in esecuzione nello SPID di blocco. Per risolvere un problema di blocco e blocco in SQL Server, usare l'utilità PSSDiag for SQL per acquisire tutti gli eventi Transact-SQL che hanno attivato lo script di blocco. In SQL Server 2005 e versioni successive è possibile specificare l'impostazione di soglia del processo bloccata per determinare quali SPID o SPID vengono bloccati più a lungo rispetto alla soglia specificata. Per altre informazioni su PSSDiag per SQL, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente per visualizzare l'articolo:

Utilità per la raccolta dati PSSDIAG Per altre informazioni sulla soglia dei processi bloccati, visitare il sito Web MSDN seguente:

Nota Quando si verifica un problema di blocco o blocco in SQL Server, è consigliabile contattare il servizio di supporto tecnico clienti Microsoft. I servizi di supporto tecnico clienti Microsoft consentono di configurare le opzioni di utilità PSSDiag corrette.

Passaggio 5: installare il Service Pack e l'aggiornamento cumulativo più recenti di BizTalk Server

BizTalk Server 2006 R2 e versioni successive si sono spostati in un modello di aggiornamento cumulativo (CU). Gli aggiornamenti cumulativi conterranno le correzioni rapide più recenti. BizTalk Server 2006 R2 Service Pack 1 è disponibile anche:

BizTalk Server 2004 SP1 non include funzionalità di eliminazione e archiviazione predefinite per il database BizTalkDTADb. Questa funzionalità è inclusa in BizTalk Server 2004 SP2. A seconda delle dimensioni del database BizTalkDTADb, l'installazione di BizTalk Server 2004 SP2 può richiedere ore perché il programma di installazione Elimina il database BizTalkDTADb. Per informazioni sui problemi noti durante l'installazione di BizTalk Server 2004 Service Pack 2, fare clic sul numero dell'articolo seguente per visualizzare l'articolo della Microsoft Knowledge Base:

Problemi noti di BizTalk Server 2004 Service Pack 2 non documentati nel file ReadmeSP2. htm

Quando si installa BizTalk Server 2004 SP2, è consigliabile eseguire le operazioni seguenti:

  1. Installare l'hotfix nell'articolo 894253 della Microsoft Knowledge base. Seguire i passaggi descritti in questo articolo della Knowledge base per eseguire lo script bts_tracking_shrinkexistingdatabase. SQL in SQL Server 2000. Per ulteriori informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo nella Microsoft Knowledge Base:

    FIX: la stored procedure dtasp_PruneTrackingdatabase () può richiedere molte ore per pulire il database DTA in BizTalk Server 2004

  2. Installare BizTalk Server 2004 SP2. Per ulteriori informazioni, fare clic sul numero dell'articolo seguente per visualizzare l'articolo nella Microsoft Knowledge Base:

    Come ottenere l'ultimo Service Pack di BizTalk Server 2004

Eliminare tutti i dati

Se i database sono troppo grandi o se il metodo preferito consiste nell'eliminare tutti i dati, è possibile eliminarli tutti.Attenzione Non usare questo metodo in qualsiasi ambiente in cui i dati sono critici per le aziende o se i dati sono necessari.

Procedura di eliminazione del database BizTalkMsgBoxDb

Per eliminare tutti i dati nel database di BizTalkMsgBoxDb, è possibile usare lo strumento di terminazione BizTalk. In caso contrario, seguire questa procedura.Nota Questa azione Elimina tutti i messaggi. Prestare estrema cautela se si seguono questi passaggi in un ambiente di produzione.

  1. Eseguire il backup di tutti i database di BizTalk Server. Ricorda che la stored procedure BizTalkMgmtDb. dbo. sp_ForceFullBackup può essere usata per forzare un backup completo dei file di dati e di log. Eseguire questa stored procedure e quindi eseguire il processo di backup dell'agente SQL di BizTalk Server.

  2. Copiare lo script Msgbox_cleanup_logic. SQL da unità: \programmi\microsoft BizTalk 200x\schema a SQL Server.

  3. Eseguire questo script SQL nel database BizTalkMsgBoxDb per aggiornare la stored procedure bts_CleanupMsgbox.

  4. Arrestare tutti gli host BizTalk, i servizi e gli adapter isolati personalizzati. Se si usa l'adapter HTTP o SOAP, riavviare i servizi IIS.

  5. Eseguire la stored procedure bts_CleanupMsgbox in tutti i database di BizTalkMsgBoxDb.

  6. Riavviare tutte le istanze host e i servizi BizTalk Server.

Per informazioni su un problema noto con la bts_CleanupMsgbox stored procedure in BizTalk Server 2006, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente per visualizzare l'articolo:

Correzione: i dati del messaggio non vengono eliminati dal database di rilevamento dopo l'esecuzione della bts_CleanupMsgbox stored procedure in un ambiente di test di BizTalk Server 2006

Opzioni di eliminazione del database BizTalkDTADb

Per eliminare tutti i dati dal database BizTalkDTADb, è possibile usare lo strumento di terminazione BizTalk. In caso contrario, usa uno dei metodi seguenti.Nota Entrambi i metodi eliminano tutti i messaggi. Il metodo 2 è più veloce.

  • Metodo 1:

    1. Eseguire il backup di tutti i database di BizTalk Server.

    2. Eseguire la stored procedure dtasp_PurgeAllCompletedTrackingData. Per altre informazioni sulla dtasp_PurgeAllCompletedTrackingData stored procedure, visitare il sito Web MSDN seguente:

      Nota Questa azione Elimina tutti i messaggi completati.

  • Metodo 2:

    1. Eseguire il backup di tutti i database BizTalk.

    2. Eseguire la stored procedure dtasp_CleanHMData. Usa questa opzione solo se il database BizTalkDTADb contiene molte istanze incomplete che devono essere rimosse. A questo scopo, eseguire le operazioni seguenti:

      1. Arrestare tutti gli host BizTalk, i servizi e gli adapter isolati personalizzati. Se si usa l'adapter HTTP o SOAP, riavviare i servizi IIS.

      2. Eseguire la stored procedure dtasp_CleanHMData nel database BizTalkDTADb.

      3. Riavviare tutti gli host e i servizi di BizTalk Server.

Procedura solo per BizTalk Server 2004

Per eliminare tutti i dati dal database BizTalkDTADb in BizTalk Server 2004, eseguire la procedura seguente.Nota Questa azione Elimina tutti i messaggi completati.

  1. Eseguire il backup di tutti i database di BizTalk Server.

  2. Arrestare tutti gli host BizTalk, i servizi e gli adapter isolati personalizzati. Se si usa l'adapter HTTP o SOAP, riavviare i servizi IIS.

  3. Installare l'hotfix nell'articolo 894253 della Microsoft Knowledge base. Seguire i passaggi descritti in questo articolo della Knowledge base per eseguire lo script Bts_tracking_shrinkexistingdatabase. SQL in SQL Server 2000. Per informazioni sulla dtasp_PruneTrackingdatabase stored procedure, fare clic sul numero dell'articolo della Microsoft Knowledge Base seguente per visualizzare l'articolo:

    FIX: la stored procedure dtasp_PruneTrackingdatabase () può richiedere molte ore per pulire il database DTA in BizTalk Server 2004

  4. Riavviare tutti gli host e i servizi BizTalk.

Nota Se è necessario disporre dei dati di rilevamento, eseguire il backup del database BizTalkDTADb, ripristinare il database in un altro server SQL e quindi eliminare il database BizTalkDTADb originale. Se serve aiuto per analizzare i dati di MsgBoxViewer o l'output di PSSDiag, contattare il servizio di supporto tecnico clienti Microsoft. Per un elenco completo dei numeri di telefono di servizi di supporto tecnico e informazioni sui costi di supporto, visitare il sito Web Microsoft seguente:

Nota Prima di contattare il servizio di supporto tecnico clienti, comprimere i dati di MsgBoxViewer, l'output di PSSDiag e i registri eventi aggiornati (file con estensione evt). Potrebbe essere necessario inviare questi file a un tecnico del supporto di BizTalk Server.

Serve aiuto?

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa a Microsoft Insider

Queste informazioni sono risultate utili?

Grazie per il feedback!

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×