Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
I database di BizTalk Server e la loro salute sono molto importanti per un ambiente di messaggistica di BizTalk Server efficace. In questo argomento vengono elencati i passaggi da seguire per la gestione o la risoluzione dei problemi relativi ai database di BizTalk Server.
Gestione dei database BizTalk Server
Disabilitare le opzioni Aggiornamento automatico statistiche e Creazione automatica statistiche (si applica solo ai database MessageBox di BizTalk Server). Per impostazione predefinita, queste impostazioni vengono configurate come parte della configurazione di BizTalk Server. Non è consigliabile apportare modifiche a queste impostazioni.
Per verificare se queste impostazioni sono disabilitate, eseguire le seguenti procedure memorizzate in SQL Server:
SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoCreateStatistics') AS IsAutoCreateStatistics SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoUpdateStatistics') AS IsAutoUpdateStatisticsI valori restituiti devono essere 0 per indicare che l'impostazione è disabilitata. Se 0 non viene restituito, disabilitare l'impostazione eseguendo quanto segue in SQL Server:
ALTER DATABASE BizTalkMsgBoxDB SET AUTO_CREATE_STATISTICS OFF ALTER DATABASE BizTalkMsgBoxDB SET AUTO_UPDATE_STATISTICS OFFPer altre informazioni su queste impostazioni, vedere Si verificano problemi di blocco, deadlock o altri problemi di SQL Server quando si tenta di connettersi al database BizTalkMsgBoxDb in BizTalk Server.
Imposta la proprietà Max Degree of Parallelism. Per impostazione predefinita, queste impostazioni vengono configurate come parte della configurazione di BizTalk Server. Non è consigliabile apportare modifiche a queste impostazioni.
Impostare le proprietà Max Degree of Parallelism run_value e config_value su un valore pari a uno (1) nelle istanze di SQL Server che ospitano i database MessageBox di BizTalk Server. Per controllare l'impostazione "Max Degree of Parallelism", eseguire la procedura memorizzata seguente sul database master in SQL Server.
exec sp_configure 'max degree of parallelism'Se i valori di run_value e config_value non sono impostati su uno (1), eseguire la seguente procedura memorizzata in SQL Server:
exec sp_configure 'max degree of parallelism', '1' reconfigure with overridePer altre informazioni su come l'impostazione Max Degree of Parallelism influisce su BizTalk Server, vedere Si verificano problemi di blocco, deadlock o altri problemi di SQL Server quando si tenta di connettersi al database BizTalkMsgBoxDb in BizTalk Server.
Determinare quando è possibile ricompilare gli indici di BizTalk Server.
La maggior parte degli indici nei database di BizTalk Server è clusterizzato (ID indice: 1). Il comando DBCC SHOWCONTIG può essere usato per visualizzare le informazioni sulla frammentazione per le tabelle nei database bizTalk Server. Questi indici sono basati su GUID, quindi è normale che si verifichi la frammentazione. Se il valore della densità di scansione di DBCC SHOWCONTIG è inferiore a 30%, gli indici possono essere ricompilati durante il tempo di inattività. Molte tabelle nei database BizTalk Server contengono colonne che usano definizioni DataType in cui non è possibile eseguire l'indicizzazione online. Pertanto, gli indici per le tabelle nei database BizTalk Server non devono mai essere ricompilati mentre BizTalk elabora i dati.
Per altre informazioni su come ricompilare gli indici BizTalk, vedere Si verificano problemi di blocco, deadlock o altri problemi di SQL Server quando si tenta di connettersi al database BizTalkMsgBoxDb in BizTalk Server.
È anche possibile usare la funzione sys.dm_db_index_physical_stats per cercare informazioni sulla frammentazione in SQL Server. Per altre informazioni, vedere sys.dm_db_index_physical_stats (Transact-SQL).
Monitorare il database per blocchi, ostruzioni o deadlock.
È un comportamento atteso che si verifichino blocchi e lock nei database di SQL Server utilizzati da BizTalk Server. Tuttavia, non è previsto che questi blocchi continuino per un lungo periodo di tempo. Il blocco esteso e il deadlock nei database di SQL Server usati da BizTalk Server sono indicatori di un potenziale problema.
Per le cause note correnti di deadlock e ostruzione nei database di SQL Server utilizzati da BizTalk Server, consultare la pagina Si verificano problemi di blocco, condizioni di deadlock o altri problemi relativi a SQL Server quando si tenta di connettersi al database BizTalkMsgBoxDb su BizTalk Server.
Monitorare le dimensioni dei database e delle tabelle.
Le dimensioni del database MessageBox di BizTalk Server devono in genere essere pari a circa 5 GB. Il database BizTalkMsgBoxDb non deve contenere dati e deve essere considerato un buffer fino a quando i dati non vengono elaborati o spostati nel database BizTalkDTADb. Un ambiente con un potente back-end di SQL Server e numerose orchestrazioni a esecuzione prolungata può avere un database BizTalkMsgBoxDb di dimensioni superiori a 5 GB. Un ambiente con volumi elevati senza orchestrazioni a esecuzione prolungata deve avere un database MessageBox bizTalk Server molto più piccolo di 5 GB.
Il database di rilevamento di BizTalk Server può variare notevolmente nelle dimensioni, ma se le prestazioni delle query diminuiscono drasticamente, il database di rilevamento è probabilmente troppo grande. Come regola generale, un database di rilevamento di BizTalk Server maggiore di 15-20 GB è considerato troppo grande e può influire negativamente sulle prestazioni.
I problemi seguenti possono essere attribuibili ai database BizTalk Server troppo grandi:
- Il database MessageBox di BizTalk Server continua a crescere, mentre le dimensioni dei dati (non solo il file di log) rimangono grandi. BizTalk Server richiede più tempo del normale per elaborare anche un semplice scenario di flusso di messaggi.
- Le interrogazioni dell'hub di gruppo richiedono più tempo del normale e possono anche andare in timeout.
- Il file di log del database non viene mai troncato.
- I processi di BizTalk SQL Agent vengono eseguiti più lentamente del normale.
- Alcune tabelle sono notevolmente grandi o hanno troppe righe rispetto alla normale.
I database BizTalk Server possono diventare di grandi dimensioni per diversi motivi, tra cui:
- Attività di SQL Agent BizTalk non funzionano
- Un numero eccessivo di istanze di messaggi o servizi sospesi
- Errori del disco
- Livelli elevati di rilevamento
- Controllo delle prestazioni di BizTalk Server
- Prestazioni scarse di SQL Server
- Problemi di latenza di rete
Analogamente, è possibile avere troppe righe in una tabella. 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 tabella dta_DebugTrace con più di 1 milione di righe probabilmente contiene troppe righe. Una tabella HostNameQ_Suspended con più di 200.000 righe probabilmente contiene troppe righe.
Assicurarsi di sapere cosa è previsto nell'ambiente per determinare se si verifica un problema di dati.
Abilitare il rilevamento nell'host BizTalk Server.
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 database MessageBox di BizTalk Server al database di rilevamento di BizTalk Server. Se non sono configurati host BizTalk Server con l'opzione Consenti il tracciamento dell'host o se l'host di tracciamento viene arrestato, TDDS non verrà eseguito e le tabelle TrackingData_x_x nel database MessageBox di BizTalk Server cresceranno senza controllo.
Pertanto, è necessario configurare un host BizTalk Server dedicato con l'opzione Consenti rilevamento host. Per altre informazioni sulla configurazione di un host di rilevamento dedicato, vedere Configurazione di un host di rilevamento dedicato.
Per consentire a TDDS di mantenere nuovi eventi di rilevamento in scenari con volumi elevati, è possibile creare più istanze di un singolo host di rilevamento, ma non è necessario configurare più host per il rilevamento.
Usare i corretti processi di BizTalk SQL Server Agent.
L'esecuzione dei processi di BizTalk Server SQL Agent è fondamentale per la gestione dei database BizTalk Server e per garantire prestazioni ottimali.
Il processo di Backup di BizTalk Server SQL Server Agent è l'unico metodo supportato per eseguire il backup dei database bizTalk Server. Questo compito richiede di configurare tutti i database di BizTalk Server per utilizzare un Modello di recupero completo. Dovresti configurare questa attività per un ambiente BizTalk Server ottimale. È possibile usare i metodi di SQL Server per eseguire il backup dei database BizTalk Server solo se il servizio SQL Server viene arrestato e se tutti i processi di BizTalk Server vengono arrestati.
Per ulteriori informazioni sull'uso del modello di recupero completo di SQL Server durante la configurazione del processo di backup SQL Agent di BizTalk Server, vedere Log Shipping o Backup nel modello di recupero completo.
Il MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb processo di SQL Server Agent è progettato per l'esecuzione illimitata. Di conseguenza, la cronologia dei processi di SQL Agent potrebbe non indicare che il processo di SQL Agent è stato completato correttamente; questo comportamento è in base alla progettazione. Se si verifica un errore, il processo verrà riavviato entro 1 minuto e continuerà a essere in esecuzione senza interruzioni. Pertanto, le notifiche di errore per questo processo possono essere in genere ignorate.
Se la cronologia del processo MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb di SQL Server Agent indica che questo processo ha costantemente esito negativo e si riavvia, potrebbe essere necessario analizzare ulteriormente la causa del ciclo di fallimento/riavvio.
L'MessageBox_Message_Cleanup_BizTalkMsgBoxDb processo di SQL Server Agent è l'unico processo che non deve essere abilitato manualmente perché viene avviato dal processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb.
Il processo DTA Purge and Archive di SQL Server Agent mantiene il database di rilevamento di BizTalk Server eliminando e archiviando i messaggi rilevati. Questo processo legge ogni riga della tabella e confronta il timestamp di ogni riga per determinare se il record deve essere rimosso.
Durante la risoluzione dei problemi relativi ai processi di SQL Server Agent di BizTalk Server, verificare che tutti i processi di SQL Agent ad eccezione del MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb vengano completati senza errori.
Per ulteriori informazioni sulle attività di SQL Agent di BizTalk Server utilizzate in SQL Server:
Monitorare e terminare le istanze sospese.
Le istanze del servizio possono essere sospese (ripristinabili) o sospese (non ripristinabili). Queste istanze del servizio possono essere di Messaggistica, Orchestrazione o Porta. BizTalk Server supporta la terminazione e la rimozione di queste istanze tramite la pagina Hub di gruppo nella Console di amministrazione di BizTalk Server o tramite l'uso dello script Terminate.vbs. Per ulteriori informazioni sullo script Terminate.vbs, vedere Rimozione dell'istanza sospesa del servizio.
È anche possibile usare lo strumento Terminator per rimuovere le istanze sospese. Lo strumento Terminator è incluso in BizTalk Health Monitor.
I termini "orfani" e "zombie" vengono spesso usati in modo intercambiabile. Un messaggio orfano o zombie è un messaggio che non dispone di un'istanza del servizio associata, in genere perché l'istanza del servizio è stata terminata prima della ricezione del messaggio. Un servizio orfano o zombie è un servizio che non dispone di messaggi associati. Per altre informazioni sui messaggi zombie e sulle istanze del servizio in BizTalk Server, vedere Zombies in BizTalk Server.
Monitorare i contatori di prestazione dell'oggetto di prestazione PhysicalDisk.
BizTalk Server rende un numero elevato di transazioni brevi e molto rapide in SQL Server entro un minuto. Se SQL Server non riesce a sostenere questa attività, potrebbero verificarsi problemi di prestazioni di BizTalk Server. Monitorare i contatori delle prestazioni Avg. Disk sec/Read, Avg. Disk sec/Transfer e Avg. Disk sec/Write nell'oggetto delle prestazioni PhysicalDisk. Il valore ottimale è minore di 10 ms (millisecondi). Un valore di 20 ms o superiore è considerato prestazioni scarse.
Per altre informazioni sulla disponibilità elevata del database BizTalk Server, vedere Disponibilità elevata per i database BizTalk Server.
Seguire le procedure consigliate per i database BizTalk Server. Vedere Procedure consigliate per la gestione dei database BizTalk Server.
Risoluzione dei problemi relativi ai database di BizTalk Server
Eseguire le attività seguenti per risolvere eventuali problemi con i database di BizTalk Server.
Verificare che tutti i processi di BizTalk SQL Server Agent necessari siano abilitati e in esecuzione.
Tutti i processi di BizTalk SQL Server Agent ad eccezione del processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb devono essere abilitati ed eseguiti correttamente. Non disabilitare nessun altro compito.
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 messageBox _Message_ManageRefCountLog_BizTalkMsgBoxDb processo di SQL Server Agent viene eseguito all'infinito. Pertanto, dovresti preoccuparti solo se la cronologia dei lavori segnala che il lavoro fallisce costantemente e viene riavviato.Usare lo strumento MsgBoxViewer per analizzare BizTalk MessageBox e altri database.
Lo strumento MsgBoxViewer è incluso in BizTalk Health Monitor. Lo strumento MsgBoxViewer è 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 sta controllando il carico. Inoltre, lo strumento fornisce uno snapshot dei database BizTalk Server e della configurazione di BizTalk Server.
Quando BizTalk Server è in esecuzione più lento del solito, eseguire lo strumento MsgBoxViewer, fare clic per selezionare tutte le query nella scheda Query facoltative e quindi esaminare il report HTML generato per eventuali problemi. La sezione Report di riepilogo elenca gli avvisi in giallo e i potenziali problemi in rosso.
Inoltre, è possibile usare lo strumento MsgBoxViewer per determinare quali tabelle sono le più grandi e hanno il maggior numero di record. Per un elenco di tabelle che in genere aumentano le dimensioni e per istruzioni su come gestire tali tabelle, vedere Tabelle di database BizTalk Server in aumento di grandi dimensioni.
Usare lo strumento Terminator per risolvere i problemi, se presenti, identificati dallo strumento MsgBoxViewer.
Lo strumento Terminator è incluso in BizTalk Health Monitor. Questo strumento consente agli utenti di risolvere facilmente eventuali problemi identificati dallo strumento BizTalk MsgBoxViewer.
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 eseguire l'istruzione seguente per abilitare la traccia DBCC per gli scenari di deadlock:
DBCC TRACEON (1222,-1)È anche possibile usare l'utilità PSSDIAG per raccogliere dati sull'evento Lock:Deadlock e l'evento Lock:Deadlock Chain . Per altre informazioni, vedere Utilità di raccolta dati PSSDIAG.
Il database BizTalkMsgBoxDB è un database OLTP (Elaborazione Transazioni Online ad alto volume e alta frequenza). Con questi database, è previsto che si verifichi uno stallo, e questi stalli vengono gestiti internamente dal motore di 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.
Cerca processi bloccati.
È possibile usare Monitoraggio attività in SQL Server per ottenere l'identificatore del processo server (SPID) di un processo di sistema di blocco. È quindi possibile eseguire SQL Profiler per determinare l'istruzione SQL in esecuzione nello SPID di blocco. È possibile usare l'utilità PSSDIAG per diagnosticare i problemi di blocco e interferenze in SQL Server. L'utilità acquisisce tutti gli eventi Transact-SQL in cui è abilitato lo script di blocco. Per altre informazioni, vedere Utilità di raccolta dati PSSDIAG
In SQL Server è possibile specificare l'impostazione della soglia del processo bloccato per determinare quali SPID o SPID bloccano per un periodo più lungo della soglia specificata. Per ulteriori informazioni sull'opzione soglia processo bloccato, vedere opzione soglia processo bloccato.
Quando si verifica un problema di blocco o inattività in SQL Server, è possibile contattare il supporto clienti Microsoft.
Eliminare tutti i dati indesiderati.
Se i database sono diventati troppo grandi e se i dati contenuti nei database non saranno più necessari, il metodo preferito consiste nell'eliminare i dati. Cautela: Non usare questo metodo in qualsiasi ambiente in cui i dati sono business critical o se i dati sono necessari.
Per eliminare il database BizTalkMsgBox:
Scarica e installa lo strumento Terminator, incluso in BizTalk Health Monitor.
Seguire la procedura descritta nell'argomento Come eliminare manualmente i dati dal database MessageBox in un ambiente di test per creare la stored procedure bts_CleanupMsgbox nel database MessageBox BizTalk.
Usare lo strumento Terminator per eseguire la stored procedure bts_CleanupMsgbox e ripulire il database BizTalk MessageBox.
La stored procedure bts_CleanupMsgbox elimina i dati. Prestare attenzione durante l'esecuzione di questa procedura memorizzata in un ambiente di produzione.
Riavviare tutti gli host e i servizi BizTalk Server.
Per eliminare il database BizTalkDTADb:
Metodo 1
- Eseguire il backup di tutti i database bizTalk Server.
- Eseguire la stored procedure dtasp_PurgeAllCompletedTrackingData . Per ulteriori informazioni sulla procedura memorizzata, vedere Come eliminare manualmente i dati dal database di tracciamento di BizTalk.
Metodo 2: usare questa opzione solo se il database BizTalkDTADb contiene molte istanze incomplete che devono essere rimosse.
- Eseguire il backup di tutti i database bizTalk Server.
- Fermare tutti gli host, i servizi e gli adattatori isolati personalizzati di BizTalk. Se si usa HTTP o l'adapter SOAP, riavviare i servizi IIS.
- Eseguire la procedura di archiviazione dtasp_CleanHMData nel database BizTalkDTADb.
- Riavviare tutti gli host e i servizi BizTalk Server.
Se è necessario disporre dei dati di rilevamento, eseguire il backup del database BizTalkDTADb, ripristinare il database in un altro SQL Server e quindi eliminare il database BizTalkDTADb originale.
Per assistenza nell'analisi dei dati msgBoxViewer o dell'output PSSDIAG, contattare il servizio supporto tecnico Microsoft. Prima di contattare il Servizio supporto tecnico clienti, comprimete i dati MsgBoxViewer, l'output PSSDIAG e i registri degli eventi aggiornati (file con estensione .evt). Potrebbe essere necessario inviare questi file a un tecnico del supporto di BizTalk Server.