Gestire e risolvere i problemi relativi ai database BizTalk Server

Questo articolo fornisce informazioni dettagliate su come gestire e risolvere i problemi relativi ai database di BizTalk Server.

Versione originale del prodotto: database BizTalk Server
Numero KB originale: 952555

Riepilogo

L'integrità dei database di Microsoft BizTalk Server è importante per un ambiente di messaggistica BizTalk Server riuscito. Questo articolo illustra gli aspetti importanti da considerare quando si lavora con i database BizTalk Server. Queste considerazioni includono quanto segue:

• È necessario disabilitare le auto update statistics opzioni e auto create statistics DI SQL Server.
• È necessario impostare correttamente l'opzione max degree of parallelism (MAXDOP).
• Determinare quando è possibile ricompilare gli indici di BizTalk Server.
• È possibile che si verifichino blocchi, deadlock o blocchi.
• Potrebbero verificarsi problemi con database o tabelle di grandi dimensioni.
• Processi di BIZTalk SQL Server Agent.
• Le istanze del servizio possono essere sospese.
• Potrebbero verificarsi 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 BizTalk Server e come risolvere i problemi relativi al database BizTalk Server.

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

È necessario mantenere le auto create statistics opzioni e auto update statistics disabilitate nel BizTalkMsgBoxDb database. 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'

È necessario impostare l'impostazione corrente su off. Se questa impostazione è impostata su on, 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'

È necessario impostare correttamente la proprietà Max Degree of Parallelism

Nel computer che esegue SQL Server e ospita il BizTalkMsgBoxDb database impostare il massimo grado di parallelismo run_value e config_value proprietà su 1. Nelle versioni successive di SQL è anche possibile specificare questa impostazione per ogni database anziché per ogni istanza di SQL. Per altre informazioni, vedere Impostare MAXDOP. Per determinare l'impostazione max degree of parallelism , eseguire la stored procedure seguente sul database master in SQL Server:

EXEC sp_configure 'show advanced options', 1;
GO
EXEC sp_configure 'max degree of parallelism'

Se le run_value proprietà 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 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

Determinare quando è possibile ricompilare gli indici di BizTalk Server

La maggior parte degli indici di BizTalk Server è cluster (ID indice: 1). È possibile usare l'istruzione DBCC SHOWCONTIG SQL Server per visualizzare le informazioni sulla frammentazione per le tabelle di BizTalk Server.

Gli indici di BizTalk Server sono basati su GUID. Pertanto, la frammentazione si verifica in genere. Se il valore densità di analisi restituito dall'istruzione DBCC SHOWCONTIG è inferiore al 30%, gli indici di BizTalk Server possono essere ricompilati durante il tempo di inattività.

Molte tabelle di BizTalk Server contengono colonne che usano DataType definizioni. L'indicizzazione online non può essere eseguita in queste colonne. Pertanto, non è consigliabile ricompilare mai gli indici di BizTalk Server mentre BizTalk Server elabora i dati.

Il blocco, il deadlock o il blocco possono verificarsi

In genere, i blocchi e i blocchi si verificano in un ambiente BizTalk Server. Tuttavia, questi blocchi o blocchi non rimangono per un periodo di tempo prolungato. Pertanto, il blocco e il deadlock indicano un potenziale problema.

Potrebbero verificarsi problemi con database o tabelle di grandi dimensioni

Si è visto che, quando il BizTalkMsgBoxDb database è più grande, possono verificarsi problemi di prestazioni. Idealmente, il BizTalkMsgBoxDb database non deve contenere dati. Il BizTalkMsgBoxDb database deve essere considerato un buffer fino a quando i dati non vengono elaborati o spostati nel BizTalkDTADb database O BAM.

Un ambiente che usa un potente SQL Server nel back-end e molte orchestrazioni a esecuzione prolungata possono avere un BizTalkMsgBoxDb database di dimensioni superiori a 5 GB. Un ambiente con volumi elevati che non usa orchestrazioni a esecuzione prolungata deve avere un BizTalkMsgBoxDb database molto più piccolo di 5 GB.

Il BizTalkDTADb database non ha una dimensione impostata. Tuttavia, se le prestazioni diminuiscono, il database è probabilmente troppo grande. Per alcuni clienti 20 GB può essere considerato troppo grande, mentre per altri che con 200 GB potrebbero funzionare correttamente con un server SQL estremamente forte in esecuzione su più CPU, un sacco di memoria e una rete e un'archiviazione veloci. Quando si dispone di database BizTalk Server di grandi dimensioni, è possibile che si verifichino i problemi seguenti:

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

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

• Le query hat (Health and Activity Tracking) della console di amministrazione di BizTalk o del rilevamento delle attività richiedono più tempo del solito e possono verificarsi un timeout.

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

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

• Alcune tabelle sono maggiori o hanno troppe righe rispetto alle normali dimensioni della tabella.

I database possono diventare di grandi dimensioni per vari motivi. Questi motivi possono includere quanto segue:

• I processi di SQL Server Agent bizTalk non sono in esecuzione
• Numero elevato di istanze sospese
• Errori del disco
• Rilevamento
• Limitazione
• Prestazioni di SQL Server
• Latenza di rete

Assicurarsi di sapere cosa è previsto nell'ambiente per determinare se si verifica un problema di dati.

Per impostazione predefinita, il rilevamento è abilitato nell'host predefinito. BizTalk richiede che l'opzione Consenti rilevamento host sia selezionata in un singolo host. Quando il rilevamento è abilitato, il servizio TDDS (Tracking Data Decode Service) sposta i dati degli eventi di rilevamento dal BizTalkMsgBoxDb database al BizTalkDTADb database. Se l'host di rilevamento viene arrestato, TDDS non sposta i dati nel BizTalkDTADb database e TrackingData_x_x le tabelle nel BizTalkMsgBoxDb database aumentano.

È 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 dovrebbero esistere più host di rilevamento.

In una tabella possono essere presenti troppe righe. Non esiste un numero impostato di righe troppo numerose. Inoltre, questo numero di righe varia in base al tipo di dati archiviati nella tabella. Ad esempio, una dta_DebugTrace tabella con più di 1 milione di righe ha probabilmente un numero eccessivo di righe. Una <HostName>Q_Suspended tabella con più di 200.000 righe probabilmente contiene troppe righe.

Usare i processi di BizTalk SQL Server Agent corretti

I processi di BizTalk SQL Server Agent sono importanti per la gestione dei database BizTalk Server e per garantire prestazioni elevate.

Il processo di Backup di BizTalk Server SQL Server Agent è l'unico metodo supportato per eseguire il backup dei database BizTalk Server all'avvio di SQL Server Agent e delle istanze host BizTalkServer. Questo processo richiede che tutti i database BizTalk Server usino un modello di recupero con registrazione completa. È consigliabile configurare questo processo per un ambiente BizTalk Server integro. I metodi di SQL Server possono essere usati per eseguire il backup dei database BizTalk Server solo se SQL Server Agent viene arrestato e se tutte le istanze host di BizTalk Server vengono arrestate.

Il MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo di SQL Server Agent viene eseguito all'infinito. Di conseguenza, la cronologia dei processi di SQL Server Agent non visualizza mai un completamento riuscito. Se si verifica un errore, il processo viene riavviato entro un minuto e continua a essere eseguito all'infinito. Pertanto, è possibile ignorare in modo sicuro l'errore. Inoltre, la cronologia dei processi può essere cancellata. È consigliabile preoccuparsi solo se la cronologia dei processi segnala che il processo ha costantemente esito negativo e viene riavviato.

Il MessageBox_Message_Cleanup_BizTalkMsgBoxDb processo di SQL Server Agent è l'unico processo di BizTalk Server che non deve essere abilitato perché viene avviato dal MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo di SQL Server Agent.

Il processo di eliminazione e archiviazione di SQL Server Agent DTA consente di gestire il BizTalkDTADb database eliminando e archiviando i messaggi rilevati. Questo processo legge ogni riga della tabella e confronta il timestamp per determinare se il record deve essere rimosso.

Tutti i processi di SQL Server Agent bizTalk, ad eccezione del MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo di SQL Server Agent, devono essere eseguiti correttamente.

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 aumentare inutilmente il BizTalkMsgBoxDb database e possono essere terminate. È possibile usare l'hub di gruppo per eseguire query, riprendere o terminare i messaggi. È anche possibile usare lo script Terminate.vbs o lo strumento BHM (BizTalk Health Monitor) per eseguire query, eliminare e gestire i database BizTalk. In alcune situazioni, nel sistema possono essere lasciati messaggi orfani o zombie. Lo strumento BHM può aiutare a correggere queste situazioni.

Per altre informazioni sullo script Terminate.vbs , vedere Rimozione di istanze del servizio sospese.

Le istanze di memorizzazione nella cache non vengono visualizzate nella pagina Hub di gruppo e non è possibile sospenderle o terminarle. Questa restrizione è una causa comune dell'aumento delle tabelle. Per evitare 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.

Per una descrizione dei messaggi zombie, visitare il seguente sito Web MSDN: WebLog di BizTalk Core Engine

Potrebbero verificarsi problemi di prestazioni di SQL Server e BizTalk Server

BizTalk Server effettua centinaia di transazioni brevi e rapide in SQL Server entro un minuto. Se SQL Server non riesce a sostenere questa attività, BizTalk Server potrebbe riscontrare problemi di prestazioni. In Monitor prestazioni monitorare i contatori Avg. Disk sec/Read, Avg. Disk sec/Transfer e Avg. Disk sec/Write Monitor prestazioni nell'oggetto prestazioni PhysicalDisk. Il valore ottimale è minore di 10 ms (millisecondi). Un valore di 20 ms o superiore è considerato prestazioni scarse.

• Risoluzione dei problemi di prestazioni in SQL Server 2005

• Disponibilità elevata per i database BizTalk Server

• Come risolvere i problemi di prestazioni di SQL Server

Procedure consigliate in BizTalk Server

Avviare SQL Server Agent in SQL Server. Quando SQL Server Agent viene arrestato, i processi predefiniti di BizTalk SQL Server Agent responsabili della manutenzione del database non possono essere eseguiti. Questo comportamento causa la crescita del database e questa crescita può causare problemi di prestazioni.

Inserire i file LDF (Log Database File) e File di database principale (MDF) di SQL Server in unità separate. Quando i file LDF e MDF per i BizTalkMsgBoxDb database e BizTalkDTADb si trovano nella stessa unità, può verificarsi una contesa del disco.

Se non si traggono vantaggio dal rilevamento del corpo del messaggio, non abilitare questa funzionalità. Tuttavia, è consigliabile abilitare il rilevamento del corpo del messaggio durante lo sviluppo e la risoluzione dei problemi di una soluzione. In questo caso, assicurarsi di disabilitare il rilevamento del corpo del messaggio al termine. Quando il rilevamento del corpo del messaggio è abilitato, i database di BizTalk Server aumentano. Se è necessaria un'azienda che richiede l'abilitazione del rilevamento del corpo del messaggio, verificare che i processi di eliminazione e eliminazione dell'archiviazione TrackedMessages_Copy_BizTalkMsgBoxDb di SQL Server Agent e DTA siano in esecuzione correttamente.

In genere, i log delle transazioni più piccoli causano prestazioni migliori. Per mantenere i log delle transazioni più piccoli, configurare il processo backup di SQL Server Agent di BizTalk Server per l'esecuzione più frequente.

La sp_ForceFullBackup stored procedure nel BizTalkMgmtDb database può essere usata anche per eseguire un backup completo ad hoc dei file di dati e di log. La stored procedure aggiorna la adm_ForceFullBackup tabella con un valore 1. Al successivo esecuzione del processo di Backup di BizTalk Server, viene creato un set di backup completo del database.

Lo strumento BHM (BizTalk Health Monitor) può essere usato per valutare una distribuzione di BizTalk Server esistente. BHM esegue numerosi controlli correlati al database.

Risoluzione dei problemi

I passaggi migliori per la risoluzione dei problemi per i database di SQL Server BizTalk Server dipendono dal tipo di problema del database, ad esempio blocco o deadlocking. Per risolvere un problema di database BizTalk Server, seguire questa procedura.

Passaggio 1: Abilitare ed eseguire tutti i processi di BIZTalk SQL Server Agent necessari

Tutti i processi di BizTalk SQL Server Agent ad eccezione del MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo 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 sull'errore e quindi risolvere l'errore di conseguenza. Tenere presente che il processo MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb di SQL Server Agent viene eseguito all'infinito. Pertanto, è necessario preoccuparsi solo se la cronologia dei processi segnala che il processo ha costantemente esito negativo e viene riavviato.

Passaggio 2: Usare lo strumento Monitoraggio integrità BizTalk (BHM)/MsgBoxViewer

Raccogliere il report BHM durante la riproduzione di un problema.

Lo strumento BHM è utile per la risoluzione dei problemi perché fornisce un report HTML con informazioni dettagliate sulle dimensioni della tabella e sul numero di righe. Il report può anche aiutare a determinare se BizTalk Server è limitato. Inoltre, lo strumento fornisce una visualizzazione snapshot dei database BizTalk Server e della configurazione di BizTalk Server.

Per altre informazioni sulla limitazione in BizTalk Server, vedere Come BizTalk Server implementa la limitazione delle richieste dell'host.

Quando BizTalk Server è in esecuzione più lento del solito, eseguire lo strumento BHM e quindi esaminare il report HTML generato per eventuali problemi. La sezione Riepilogo elenca gli avvisi in giallo e i potenziali problemi in rosso.

Inoltre, è possibile usare l'output dello strumento BHM per determinare quali tabelle sono le più grandi e hanno il maggior numero di record. Nella tabella seguente sono elencate le tabelle di BizTalk Server che in genere aumentano le dimensioni maggiori. È possibile usare questi dati per determinare dove può esistere un potenziale problema.

Esaminare gli scenari seguenti:

• <HostName>Q_Suspended Tabelle

  Se le <HostName>Q_Suspended tabelle hanno molti record, le tabelle potrebbero essere istanze sospese valide visualizzate nell'hub di gruppo o in HAT. Queste istanze possono essere terminate. Se queste istanze non vengono visualizzate nell'hub di gruppo o in HAT, è probabile che le istanze di memorizzazione nella cache o i report degli errori di routing orfani. Quando le istanze sospese vengono terminate, gli elementi di questa tabella e le Spool relative righe associate nelle tabelle e Instances vengono puliti.

  In questo scenario, gestire le istanze sospese riprendendole o terminandole. È anche possibile usare lo strumento BHM.

• <HostName>Q Tabelle

  Se le <HostName>Q tabelle hanno molti record, possono esistere i tipi di istanze seguenti:

  • Istanze pronte per l'esecuzione
  • Istanze attive
  • Le istanze disidratate di BizTalk Server devono avere tempo per "recuperare" ed elaborare le istanze.

  Questa tabella può aumentare quando la velocità di elaborazione in ingresso supera la velocità di elaborazione in uscita. Questo scenario può verificarsi quando si verifica un altro problema, ad esempio un database di grandi dimensioni BizTalkDTADb o ritardi del disco di SQL Server.

• SpoolTabelle , Partse Fragments

  Se le Spooltabelle , Partse Fragments hanno molti record, molti messaggi sono attualmente attivi, disidratati o sospesi. A seconda delle dimensioni, del numero di parti e delle impostazioni di frammentazione in queste tabelle, un singolo messaggio può generare tutte queste tabelle. Ogni messaggio ha esattamente una riga nella Spool tabella e almeno una riga nella Parts tabella.

• InstancesTabella

  L'amministratore BizTalk non deve consentire a molte istanze sospese di rimanere nella Instances tabella. Le istanze disidratate devono rimanere solo se la logica di business richiede orchestrazioni a esecuzione prolungata. Tenere presente che un'istanza del servizio può essere associata a molti messaggi nella Spool tabella.

• TrackingData_x_x Tabelle

  Se le TrackingData_x_x tabelle sono di grandi dimensioni, l'host di rilevamento (TDDS) non viene eseguito correttamente. Se l'istanza host di rilevamento è in esecuzione, esaminare i registri eventi e la TDDS_FailedTrackingData tabella nel database per ottenere informazioni sull'errore BizTalkDTADb . Se BizTalk è limitato con uno stato pari a 6 (database di grandi dimensioni), queste tabelle possono essere troncate anche usando lo strumento Terminator BizTalk se i dati non sono necessari.

  Se si verifica un grande divario tra i numeri di sequenza nelle BizTalkMsgBoxDb TrackingData_x_x tabelle e nelle BAMPrimaryImport tabelle o BizTalkDTADb TDDS_StreamStatus , TDDS potrebbe non spostare i dati dal BizTalkMsgBoxDb database. Per risolvere il problema, usare lo strumento BHM per eliminare queste tabelle e reimpostare il numero di sequenza.

• dta_DebugTracetabelle e dta_MessageInOutEvents

  La dta_DebugTrace tabella viene popolata quando l'inizio e la fine della forma sono abilitati in un'orchestrazione. Se la dta_DebugTrace tabella contiene molti record, questi eventi di debug dell'orchestrazione vengono usati o usati. Se il debug dell'orchestrazione non è necessario per le normali operazioni, deselezionare la casella di controllo Inizio forma e fine nelle proprietà orchestrazione .

  La dta_MessageInOutEvents tabella viene popolata quando l'invio e la ricezione di messaggi è abilitata nelle orchestrazioni e/o nelle pipeline. Se questi eventi di rilevamento non sono necessari, deselezionare la casella di controllo per questa opzione nelle proprietà dell'orchestrazione e/o della pipeline.

  Se questi eventi di traccia sono disabilitati o se esiste un backlog nel BizTalkMsgBoxDb database, queste tabelle potrebbero continuare a crescere perché TDDS continua a spostare questi dati in queste tabelle.

  Per impostazione predefinita, il rilevamento globale è abilitato. Se il rilevamento globale non è necessario, può essere disabilitato. Per altre informazioni, vedere Come disattivare il rilevamento globale.

  Se la dta_DebugTrace tabella e/o la dta_messageInOutEvents tabella nel BizTalkDTADb database sono troppo grandi, è possibile troncare le tabelle manualmente dopo aver arrestato l'host di rilevamento. Lo strumento BHM fornisce anche questa funzionalità.

  Per troncare tutte le tabelle di rilevamento nel BizTalkMsgBoxDb database, usare lo strumento BHM. Lo strumento BHM è disponibile esternamente nell'Area download Microsoft.

  Per altre informazioni sulle linee guida sul ridimensionamento del database di rilevamento, visitare il seguente sito Web MSDN: Linee guida per il ridimensionamento del database di rilevamento.

• dta_ServiceInstanceExceptionsTabella

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

Passaggio 3: Analizzare gli scenari di deadlock

In uno scenario di deadlock abilitare la traccia DBCC in SQL Server in modo che le informazioni sui deadlock vengano scritte nel log 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, usare l'utilità PSSDiag per raccogliere dati sull'evento Lock:Deadlock e sull'evento Lock:Deadlock Chain.

Il BizTalkMsgBoxDB database è un database OLTP (High-Volume e High Transaction Online Transaction Processing). È previsto un deadlocking e questo deadlocking viene gestito internamente dal motore bizTalk Server. Quando si verifica questo comportamento, non vengono elencati errori nei log degli errori. Quando si esamina uno scenario di deadlock, il deadlock analizzato nell'output deve essere correlato a un errore di deadlock nei registri eventi.

Il comando di rimozione dalla coda e alcuni processi di SQL Server Agent dovrebbero essere deadlock. In genere, questi posti di lavoro vengono selezionati come vittime di deadlock. Questi processi verranno visualizzati in una traccia deadlock. Tuttavia, non vengono elencati errori nei registri eventi. Pertanto, questo deadlocking è previsto ed è possibile ignorare in modo sicuro il deadlock con questi processi.

Se i deadlock frequenti vengono visualizzati in una traccia deadlock e se un errore di correlazione è elencato nei registri eventi, è possibile che si desideri che il deadlock sia.

Passaggio 4: Cercare i processi bloccati

Usare Monitoraggio attività in SQL Server per ottenere l'identificatore del processo server (SPID) di un processo di sistema di blocco. Eseguire 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 per SQL per acquisire tutti gli eventi Transact-SQL con lo script di blocco abilitato.

In SQL Server 2005 e versioni successive è possibile specificare l'impostazione di soglia del processo bloccata per determinare quali SPID o SPID bloccano più a lungo della soglia specificata.

Per altre informazioni sull'impostazione di soglia del processo bloccata, vedere Opzione di configurazione del server blocked process threshold.

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

Le versioni successive di BizTalk Server sono state spostate in un modello di aggiornamento cumulativo (CU). Gli aggiornamenti cumulativi conterranno le correzioni più recenti.

Eliminare tutti i dati

Se i database sono troppo grandi o se il metodo preferito consiste nell'eliminare tutti i dati, è possibile eliminare tutti i dati.

Passaggi di eliminazione del database BizTalkMsgBoxDb

Per eliminare tutti i dati nel BizTalkMsgBoxDb database, usare lo strumento BHM (BizTalk Health Monitor).

Opzioni di eliminazione del database BizTalkDTADb

Per eliminare tutti i dati dal BizTalkDTADb database, usare lo strumento BHM (BizTalk Health Monitor). In caso contrario, utilizzare uno dei metodi seguenti.

• Metodo 1:

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

  2. Eseguire la dtasp_PurgeAllCompletedTrackingData stored procedure. Per altre informazioni sulla dtasp_PurgeAllCompletedTrackingData stored procedure, vedere How to Manually Purge Data from the BizTalk Tracking Database.

     Note

     Questa azione elimina tutti i messaggi completati.

• Metodo 2:

  1. Eseguire il backup di tutti i database BizTalk.

  2. Eseguire la dtasp_CleanHMData stored procedure. Utilizzare questa opzione solo se il BizTalkDTADb database contiene molte istanze incomplete che devono essere rimosse.

     A tale scopo, effettuare i passaggi seguenti:

     1. Arrestare tutti gli host, i servizi e gli adattatori isolati personalizzati di BizTalk. Se si usa HTTP o l'adapter SOAP, riavviare i servizi IIS.
     2. Eseguire la dtasp_CleanHMData stored procedure nel BizTalkDTADb database.
     3. Riavviare tutti gli host e i servizi BizTalk Server.

Passaggi di solo BizTalk Server 2004

Se è necessario assistenza per analizzare i dati BHM o l'output di PSSDiag, contattare il Servizio supporto tecnico Microsoft. Per un elenco completo dei numeri di telefono e delle informazioni sui costi di supporto tecnico, vedere Contattare supporto tecnico Microsoft.

Si applica a

• BizTalk Server 2009
• BizTalk Server 2010
• BizTalk Server 2013
• BizTalk Server 2013 R2
• BizTalk Server 2016
• BizTalk Server 2020