Gestire e risolvere i problemi relativi ai database BizTalk Server

Questo articolo fornisce informazioni dettagliate su come gestire e risolvere BizTalk Server database.

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 usano i database BizTalk Server. Queste considerazioni includono quanto segue:

  • È necessario disabilitare le auto update statistics opzioni e SQL Server auto create statistics .
  • È necessario impostare correttamente l'opzione max degree of parallelism (MAXDOP).
  • Determinare quando è possibile ricompilare BizTalk Server indici.
  • È possibile che si verifichino blocchi, deadlock o blocchi.
  • È possibile che si verifichino problemi con database o tabelle di grandi dimensioni.
  • Processi di SQL Server Agent BizTalk.
  • Le istanze del servizio possono essere sospese.
  • È possibile che si verifichino problemi di prestazioni SQL Server e BizTalk Server.
  • È consigliabile seguire le procedure consigliate in BizTalk Server.

Introduzione

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

È necessario disabilitare le opzioni per la creazione automatica di statistiche e l'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 grado massimo di parallelismo run_value e config_value le proprietà su un valore pari a 1. Nelle versioni SQL successive è anche possibile specificare questa impostazione per ogni database anziché per ogni istanza di SQL. Per altre informazioni, vedere Impostare MAXDOP. Per determinare l'impostazionemax degree of parallelism, eseguire la stored procedure seguente nel 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 BizTalk Server indici

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

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

Molte tabelle 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 BizTalk Server mentre BizTalk Server elabora i dati.

È possibile che si verifichino blocchi, deadlock o blocchi

In genere, blocchi e 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.

È possibile che si verifichino 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 BAM o .

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.

Le dimensioni del BizTalkDTADb database non sono impostate. Tuttavia, se le prestazioni diminuiscono, il database è probabilmente troppo grande. Per alcuni clienti 20 GB possono essere considerati troppo grandi, mentre per altri che con 200 GB potrebbe funzionare bene con un server SQL altamente potente in esecuzione su più CPU, molta memoria e una rete e archiviazione veloci. Quando si hanno database di 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 di grandi dimensioni.

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

  • La console di amministrazione bizTalk o le query di rilevamento integrità e attività (HAT) richiedono più tempo del solito e possono verificarsi timeout.

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

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

  • Alcune tabelle sono più grandi 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 SQL Server Agent BizTalk non sono in esecuzione
  • Numero elevato di istanze sospese
  • Errori del disco
  • Monitoraggio
  • 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 dell'evento di rilevamento dal BizTalkMsgBoxDb database al BizTalkDTADb database. Se l'host di rilevamento viene arrestato, TDDS non sposta i dati nel BizTalkDTADb database e le TrackingData_x_x tabelle nel BizTalkMsgBoxDb database aumentano.

È consigliabile dedicare un host al rilevamento. Per consentire a TDDS di gestire 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 è presente un numero impostato di righe troppo numerose. Inoltre, questo numero di righe varia in base al tipo di dati archiviato nella tabella. Ad esempio, una dta_DebugTrace tabella con più di 1 milione di righe probabilmente contiene troppe righe. Una <HostName>Q_Suspended tabella con più di 200.000 righe contiene probabilmente troppe righe.

Usare i processi di SQL Server Agent BizTalk corretti

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

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

Il MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo SQL Server Agent viene eseguito all'infinito. Pertanto, la cronologia dei processi 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 l'errore in modo sicuro. Inoltre, la cronologia del processo 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 SQL Server Agent è l'unico processo BizTalk Server che non deve essere abilitato perché viene avviato dal MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo SQL Server Agent.

Il processo DTA Purge and Archive SQL Server Agent consente di gestire il BizTalkDTADb database eliminando e archiviando i messaggi registrati. 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 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 far 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 Terminate.vbs strumento di script o BizTalk Health Monitor (BHM) per eseguire query, eliminare e gestire i database BizTalk. In alcune situazioni, nel sistema possono essere presenti messaggi orfani o zombie. Lo strumento BHM consente di 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.

Nota

Un messaggio zombie è un messaggio che è stato instradato ma non utilizzato.

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

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

BizTalk Server esegue centinaia di transazioni brevi e rapide da SQL Server entro un minuto. Se il SQL Server non è in grado di sostenere questa attività, BizTalk Server potrebbero 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.

Procedure consigliate in BizTalk Server

Avviare SQL Server Agent sul SQL Server. Quando il SQL Server Agent viene arrestato, non è possibile eseguire i processi biztalk predefiniti SQL Server Agent responsabili della manutenzione del database. Questo comportamento causa l'aumento del database e questa crescita può causare problemi di prestazioni.

Inserire i file SQL Server file di database di log (LDF) e file MDF (Main Database File) 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 trae 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 BizTalk Server aumentano. Se è necessaria un'azienda che richiede l'abilitazione del rilevamento del corpo del messaggio, verificare che i TrackedMessages_Copy_BizTalkMsgBoxDb processi di eliminazione e archiviazione DTA e SQL Server Agent 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 BizTalk Server SQL Server Agent 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. Alla successiva esecuzione del processo backup BizTalk Server, viene creato un set di backup completo del database.

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

Risoluzione dei problemi

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

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

Tutti i processi bizTalk SQL Server Agent ad eccezione del MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo devono essere abilitati ed eseguiti correttamente. Non disabilitare nessun altro processo.

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 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo SQL Server Agent viene eseguito all'infinito. Pertanto, è consigliabile preoccuparsi solo se la cronologia del processo segnala che il processo ha costantemente esito negativo e viene riavviato.

Passaggio 2: Usare lo strumento BizTalk Health Monitor (BHM)/MsgBoxViewer

Raccogliere un report BHM durante la riproduzione di un problema.

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

Per altre informazioni sulla limitazione delle richieste in BizTalk Server, vedere How BizTalk Server Implements Host Throttling(Come implementa la limitazione host).

Quando BizTalk Server è in esecuzione più lentamente 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 BizTalk Server che in genere aumentano di dimensioni maggiori. È possibile usare questi dati per determinare dove può esistere un potenziale problema.

Tabella Descrizione
<HostName>Q_Suspended Questa tabella contiene un riferimento ai messaggi nella Spool tabella associati alle istanze sospese per l'host specifico. Questa tabella si trova nel BizTalkMsgBoxDb database.
<HostName>Q Questa tabella contiene un riferimento ai messaggi nella Spool tabella associati all'host specifico e non sospesi. Questa tabella si trova nel BizTalkMsgBoxDb database.
Spool

Parts

Fragments
Queste tabelle archivia i dati effettivi dei messaggi nel BizTalkMsgBoxDb database.
Instances Questa tabella archivia tutte le istanze e il relativo stato corrente nel BizTalkMsgBoxDb database.
TrackingData_0_x Queste quattro tabelle archivia gli eventi di rilevamento di Business Activity Monitoring (BAM) nel BizTalkMsgBoxDb database per TDDS per spostare gli eventi nel BAMPrimaryImport database.
TrackingData_1_x Queste quattro tabelle archivia gli eventi registrati nel BizTalkMsgBoxDb database per TDDS per spostare gli eventi nel BizTalkDTADB database.
Tracking_Fragmentsx
Tracking_Partsx
Tracking_Spoolx
Due di ognuna di queste tabelle si trova nei BizTalkMsgBoxDb database e BizTalkDTADb . Uno è online e l'altro è offline.

In BizTalk Server 2004 SP2 e nelle versioni successive, il TrackedMessages_Copy_BizTalkMsgBoxDb processo SQL Server Agent sposta i corpi dei messaggi registrati direttamente in queste tabelle nel BizTalkDTADb database.

In BizTalk Server 2004 Service Pack 1 (SP1) e nelle versioni precedenti di BizTalk Server 2004, il TrackedMessages_Copy_BizTalkMsgBoxDb processo SQL Server Agent copia i corpi dei messaggi rilevati in queste tabelle del BizTalkMsgBoxDb database. Il TrackingSpool_Cleanup_BizTalkMsgBoxDb processo SQL Server Agent elimina le tabelle offline e rende online le tabelle mentre il processo porta offline anche le tabelle online.
dta_ServiceInstances Questa tabella archivia gli eventi rilevati per le istanze del servizio nel BizTalkDTADb database. Se questa tabella è di grandi dimensioni, il BizTalkDTADb database è probabilmente di grandi dimensioni.
dta_DebugTrace Questa tabella archivia gli eventi del debugger orchestrazione nel database BizTalkDTADb.
dta_MessageInOutEvents Questa tabella archivia i messaggi di evento rilevati nel BizTalkDTADb database. Questi messaggi di evento registrati includono informazioni sul contesto del messaggio.
dta_ServiceInstanceExceptions Questa tabella archivia le informazioni sugli errori per qualsiasi istanza del servizio sospesa nel BizTalkDTADb database.

Considerate i seguenti scenari.

  • <HostName>Q_Suspended Tabelle

    Se le tabelle hanno molti record, le tabelle potrebbero essere istanze sospese valide visualizzate nell'hub <HostName>Q_Suspendeddi gruppo o in HAT. Queste istanze possono essere terminate. Se queste istanze non vengono visualizzate nell'hub di gruppo o in HAT, le istanze probabilmente memorizzano nella cache istanze o report di errori di routing orfani. Quando le istanze sospese vengono terminate, gli elementi di questa tabella e le relative righe associate nelle Spool 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 BizTalk Server hanno bisogno di 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 SQL Server.

  • Spool, Partse Fragments tabelle

    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 contiene esattamente una riga nella Spool tabella e almeno una riga nella Parts tabella.

  • Instances tavolo

    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 dell'host di rilevamento è in esecuzione, esaminare i log eventi e la TDDS_FailedTrackingData tabella nel database per informazioni sugli BizTalkDTADb errori. Se BizTalk limita lo stato 6 (database di grandi dimensioni), queste tabelle possono anche essere troncate usando lo strumento Terminator BizTalk se i dati non sono necessari.

    Se esiste un ampio divario tra i numeri di sequenza nelle BizTalkMsgBoxDbTrackingData_x_x tabelle e nelle BAMPrimaryImport tabelle o BizTalkDTADbTDDS_StreamStatus , TDDS potrebbe non spostare i dati dal BizTalkMsgBoxDb database. Per correggere questo errore, usare lo strumento BHM per eliminare queste tabelle e reimpostare il numero di sequenza.

  • dta_DebugTrace e dta_MessageInOutEvents tabelle

    La dta_DebugTrace tabella viene popolata quando l'inizio e la fine di Shape sono abilitati per 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 e fine forma nelle proprietà Orchestration .

    La dta_MessageInOutEvents tabella viene popolata quando Message send and receive è abilitato per orchestrazioni e/o pipeline. Se questi eventi di rilevamento non sono necessari, deselezionare la casella di controllo per questa opzione nelle proprietà di orchestrazione e/o 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 manualmente le tabelle dopo l'arresto dell'host di rilevamento. Lo strumento BHM offre 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 sul rilevamento delle linee guida per il ridimensionamento del database, visitare il sito Web MSDN seguente: Linee guida per il rilevamento del ridimensionamento del database.

  • dta_ServiceInstanceExceptions tavolo

    La dta_ServiceInstanceExceptions tabella diventa in genere di grandi dimensioni in un ambiente con istanze sospese regolarmente.

Passaggio 3: Analizzare gli scenari di deadlock

In uno scenario deadlock abilitare la traccia DBCC nel SQL Server in modo che le informazioni sui deadlock siano 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)

Usare anche l'utilità PSSDiag per raccogliere dati sull'evento Lock:Deadlock e sull'evento Lock:Deadlock Chain.

Il BizTalkMsgBoxDB database è un database OLTP (Online Transaction Processing) con volumi elevati e transazioni elevate. È previsto un deadlock e questo deadlock viene gestito internamente dal motore di BizTalk Server. Quando si verifica questo comportamento, non vengono elencati errori nei log degli errori. Quando si analizza uno scenario di deadlock, il deadlock che si sta analizzando nell'output deve essere correlato a un errore di deadlock nei log eventi.

È previsto un deadlock del comando dequeue e di alcuni processi SQL Server Agent. In genere, questi processi vengono selezionati come vittime di deadlock. Questi processi verranno visualizzati in una traccia deadlock. Tuttavia, non sono elencati errori nei log eventi. Di conseguenza, questo deadlock è previsto ed è possibile ignorare in modo sicuro il deadlock con questi processi.

Se i deadlock frequenti vengono visualizzati in una traccia deadlock e se nei log eventi è elencato un errore di correlazione, potrebbe essere necessario il deadlock.

Passaggio 4: Cercare i processi bloccati

Usare Activity Monitor in SQL Server per ottenere l'identificatore del processo del 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 in cui è abilitato lo script di blocco.

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

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

Nota

Quando si verifica un problema di blocco o blocco in SQL Server, è consigliabile contattare il Servizio Supporto Tecnico Clienti Microsoft. Il Servizio Supporto Tecnico Clienti Microsoft consente di configurare le opzioni dell'utilità PSSDiag corrette.

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

BizTalk Server versioni successive sono state spostate in un modello di aggiornamento cumulativo (CU). Gli aggiornamenti cumulativi conterrà 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.

Attenzione

Non usare questo metodo in qualsiasi ambiente in cui i dati sono business critical o se i dati sono necessari.

Procedura di eliminazione del database BizTalkMsgBoxDb

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

Opzioni di eliminazione del database BizTalkDTADb

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

Nota

Mentre entrambi i metodi eliminano tutti i messaggi, il metodo 2 è più veloce.

  • 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 Come eliminare manualmente i dati dal database di rilevamento BizTalk.

      Nota

      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. Usare questa opzione solo se il BizTalkDTADb database contiene molte istanze incomplete che devono essere rimosse.

      A tal fine, attenersi alla seguente procedura:

      1. Arrestare tutti gli host BizTalk, i servizi e gli adapter isolati personalizzati. 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.

BizTalk Server passaggi solo 2004

Nota

Se è necessario disporre dei dati di rilevamento, eseguire il backup del BizTalkDTADb database, ripristinare il database in un altro SQL Server e quindi eliminare il database originaleBizTalkDTADb.

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

Nota

Prima di contattare il Servizio Supporto Tecnico Clienti, comprimere i dati del report BHM, l'output di PSSDiag e i log eventi aggiornati (file con estensione evt). Potrebbe essere necessario inviare questi file a un tecnico del supporto BizTalk Server.

Si applica a

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