Condividi tramite


Elenco di controllo: Gestione e risoluzione dei problemi di database BizTalk Server

BizTalk Server database e l'integrità sono molto importanti per un ambiente di messaggistica di database di BizTalk Server riuscito. In questo argomento vengono elencati i passaggi da seguire per la gestione o la risoluzione dei problemi relativi ai database BizTalk Server.

Gestione dei database BizTalk Server

  • Disabilitare le opzioni Aggiorna automaticamente statistiche e Creazione automatica statistiche (si applica solo ai database MessageBox 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 stored procedure seguenti in SQL Server:

    SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoCreateStatistics') AS IsAutoCreateStatistics
    SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoUpdateStatistics') AS IsAutoUpdateStatistics
    

    I 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 OFF
    

    Per 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.

  • Impostare la proprietà Max Degree of Parallelism. Per impostazione predefinita, queste impostazioni vengono configurate come parte della configurazione 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 BizTalk Server. Per controllare l'impostazione Max Degree of Parallelism, eseguire la stored procedure seguente sul database Master in SQL Server:

    exec sp_configure 'max degree of parallelism'
    

    Se il run_value e il config_value non sono impostati su un valore pari a uno (1), eseguire la stored procedure seguente in SQL Server:

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

    Per altre informazioni sull'impatto dell'impostazione Max Degree of Parallelism 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 BizTalk Server indici.

    La maggior parte degli indici in BizTalk Server database è raggruppata (ID indice: 1). Il comando DBCC SHOWCONTIG può essere utilizzato 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 densità di analisi di DBCC SHOWCONTIG è minore del 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).For more information, see sys.dm_db_index_physical_stats (Transact-SQL).

  • Monitorare il database per i blocchi, i blocchi o i deadlock.

    Si tratta di un comportamento previsto per i blocchi e i blocchi nei database SQL Server usati da BizTalk Server. Tuttavia, non è previsto che questi blocchi continuino per un lungo periodo di tempo. Il blocco esteso e il deadlock nei database SQL Server usati da BizTalk Server sono indicatori di un potenziale problema.

    Per le cause note correnti del deadlock e del blocco nei database SQL Server usati da BizTalk Server, passare a Si verificano problemi di blocco, deadlock o altri problemi di SQL Server quando si tenta di connettersi al database BizTalkMsgBoxDb in BizTalk Server.

  • Monitorare le dimensioni dei database e delle tabelle.

    Le dimensioni del database MessageBox di BizTalk Server devono essere in genere pari a circa 5 GB. Il database BizTalkMsgBoxDb non deve contenere dati e deve essere considerato un buffer finché i dati non vengono elaborati o spostati nel database BizTalkDTADb. Un ambiente con un potente back-end SQL Server e numerose orchestrazioni a esecuzione prolungata può avere un database BizTalkMsgBoxDb superiore 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 BizTalk Server può variare notevolmente nelle dimensioni, ma se le prestazioni delle query diminuiscono notevolmente, 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 a BizTalk Server database troppo grandi:

    • Il database messageBox 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 query dell'hub di gruppo richiedono più tempo del normale e possono anche verificarsi un 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:

    • Processi di BizTalk SQL Agent non in esecuzione
    • Istanze eccessive di messaggi o servizi sospesi
    • Errori del disco
    • Livelli elevati di rilevamento
    • BizTalk Server limitazione
    • Prestazioni SQL Server scarse
    • 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 BizTalk Server al database di rilevamento BizTalk Server. Se nessun host BizTalk Server è configurato con l'opzione Consenti rilevamento host o se l'host di rilevamento viene arrestato, TDDS non verrà eseguito e le tabelle TrackingData_x_x nel database MessageBox BizTalk Server aumentano deselezionate.

    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 processi di SQL Server Agent BizTalk corretti.

    L'esecuzione dei processi di SQL Agent BizTalk Server è fondamentale per la gestione dei database BizTalk Server e per garantire prestazioni ottimali.

    • Il processo di backup BizTalk Server SQL Server Agent è l'unico metodo supportato per eseguire il backup dei database BizTalk Server. Questo processo richiede di configurare tutti i database BizTalk Server per l'uso di un modello di recupero con registrazione completa. È consigliabile configurare questo processo per un ambiente di BizTalk Server integro. È possibile utilizzare 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 BizTalk Server vengono arrestati.

      Per altre informazioni sull'uso del modello di recupero con registrazione completa SQL Server durante la configurazione del processo di backup di SQL Agent BizTalk Server, vedere Log Shipping o Backup nel modello di recupero con registrazione completa.

    • Il processo MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb 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 è previsto dalla progettazione. Se si verifica un errore, il processo verrà riavviato entro 1 minuto e continuerà a essere eseguito senza errori. Di conseguenza, le notifiche di errore per questo processo possono essere in genere ignorate.

      Se la cronologia dei processi per il processo MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent indica che questo processo ha costantemente esito negativo e riavviato, potrebbe essere necessario analizzare ulteriormente la causa del ciclo di errore/riavvio.

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

    • Il processo di eliminazione e archiviazione DTA SQL Server Agent gestisce il database di rilevamento 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 BizTalk Server SQL Server Agent, verificare che tutti i processi di SQL Agent ad eccezione del MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb vengano completati senza errori.

    Per altre informazioni sui processi di SQL Agent BizTalk Server usati 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 Messaggistica, Orchestrazione o Porta. BizTalk Server supporta la terminazione e la rimozione di queste istanze usando la pagina Hub di gruppo nella console di amministrazione BizTalk Server o tramite l'uso dello script Terminate.vbs. Per altre informazioni sullo script di Terminate.vbs, vedere Rimozione dell'istanza del servizio sospesa.

    È anche possibile usare lo strumento Terminator per rimuovere le istanze sospese. Lo strumento Terminator è incluso nel BizTalk Health Monitor.

    I termini "orfani" e "zombie" vengono spesso usati in modo intercambiabile. Un messaggio orfano o zombie è un messaggio che non ha 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 ha messaggi associati. Per altre informazioni sui messaggi zombie e sulle istanze di servizio in BizTalk Server vedere Zombies in BizTalk Server.

  • Monitorare i contatori delle prestazioni dell'oggetto prestazioni PhysicalDisk .

    BizTalk Server rende un numero elevato di transazioni brevi e molto rapide per SQL Server entro un minuto. Se l'SQL Server non può sostenere questa attività, è possibile che si verifichino problemi di prestazioni BizTalk Server. Monitorare i contatori di monitoraggio delle prestazioni media /Sec/Read, Avg. Disk sec/Transfer e Avg. Monitor prestazioni sec/Write del disco nell'oggetto prestazioni PhysicalDisk . Il valore ottimale è minore di 10 ms (millisecondi). Un valore di 20 ms o maggiore è 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 di database BizTalk Server.

Risoluzione dei problemi relativi ai database BizTalk Server

Eseguire le attività seguenti per risolvere eventuali problemi relativi ai database BizTalk Server.

  • Assicurarsi che tutti i processi di SQL Server Agent BizTalk necessari siano abilitati ed in esecuzione.

    Tutti i processi di SQL Server Agent BizTalk, ad eccezione del processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb, devono essere abilitati ed eseguiti correttamente. Non disabilitare alcun 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 messageBox _Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent processo viene eseguito infinitamente. Pertanto, è consigliabile preoccuparsi solo se la cronologia dei processi segnala che il processo ha esito negativo e riavvia costantemente.

  • Usare lo strumento MsgBoxViewer per analizzare BizTalk MessageBox e altri database.

    Lo strumento MsgBoxViewer è incluso nel BizTalk Health Monitor. Lo strumento MsgBoxViewer è utile per la risoluzione dei problemi perché fornisce un report HTML che contiene 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 uno snapshot dei database di BizTalk Server e della configurazione 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 potenziali problemi in rosso.

    Inoltre, è possibile usare lo strumento MsgBoxViewer per determinare quali tabelle sono le più grandi e avere la maggior parte dei record. Per un elenco di tabelle che in genere aumentano le dimensioni e per istruzioni su come gestire tali tabelle, BizTalk Server vedere Tabelle di database in crescita di grandi dimensioni.

  • Usare lo strumento Terminator per risolvere i problemi, se presenti, identificati dallo strumento MsgBoxViewer.

    Lo strumento Terminator è incluso nel BizTalk Health Monitor. Questo strumento consente agli utenti di risolvere facilmente eventuali problemi identificati dallo strumento MsgBoxViewer BizTalk.

  • Analizzare gli scenari di deadlock.

    In uno scenario di deadlock abilitare la traccia DBCC nel SQL Server in modo che le informazioni sul 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 sull'evento Lock :Deadlock Chain . Per altre informazioni, vedere Utilità di raccolta dati PSSDIAG.

    Il database BizTalkMsgBoxDB è un database OLTP (high-volume e high-transaction Transaction Processing). Con tali database, è previsto un deadlocking e questo deadlocking viene gestito 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 che si sta esaminando nell'output deve essere correlato a un errore di deadlock nei log eventi.

  • Cercare processi bloccati.

    È possibile usare Monitoraggio attività in SQL Server per ottenere l'identificatore del processo del server (SPID) di un processo di sistema di blocco. È quindi possibile eseguire SQL Profiler per determinare l'istruzione SQL in esecuzione nel blocco SPID. È possibile usare l'utilità PSSDIAG per risolvere i problemi di blocco e blocco in SQL Server. L'utilità acquisisce tutti gli eventi Transact-SQL abilitati per lo script di blocco. Per altre informazioni, vedere Utilità di raccolta dati PSSDIAG

    In SQL Server è possibile specificare l'impostazione soglia del processo bloccata per determinare quali SPID o SPID bloccano più a lungo della soglia specificata. Per altre informazioni sull'opzione soglia di processo bloccata, vedere Opzione soglia di processo bloccata.

    Quando si verifica un problema di blocco o blocco in SQL Server, è possibile contattare i servizi di supporto tecnico 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. Attenzione: 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:

    1. Scaricare e installare lo strumento Terminator, incluso nella BizTalk Health Monitor.

    2. 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 BizTalk MessageBox.

    3. Usare lo strumento Terminator per eseguire la stored procedure bts_CleanupMsgbox ed eliminare il database BizTalk MessageBox.

      La stored procedure bts_CleanupMsgbox elimina i dati. Prestare attenzione quando si esegue questa stored procedure in un ambiente di produzione.

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

    Per eliminare il database BizTalkDTADb:

    • Metodo 1

      1. Eseguire il backup di tutti i database BizTalk Server.
      2. Eseguire la stored procedure dtasp_PurgeAllCompletedTrackingData . Per altre informazioni sulla stored procedure, vedere Come eliminare manualmente i dati dal database di rilevamento BizTalk.
    • Metodo 2: usare questa opzione solo se il database BizTalkDTADb contiene molte istanze incomplete che devono essere rimosse.

      1. Eseguire il backup di tutti i database BizTalk Server.
      2. Arrestare tutti gli host, i servizi e gli adattatori isolati personalizzati di BizTalk. Se si usa HTTP o l'adattatore SOAP, riavviare i servizi IIS.
      3. Eseguire la stored procedure dtasp_CleanHMData nel database BizTalkDTADb.
      4. Riavviare tutti gli host e i servizi di 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.

Se si vuole aiutare ad analizzare i dati msgBoxViewer o l'output PSSDIAG, contattare i servizi di supporto tecnico Microsoft. Prima di contattare Customer Support Services, comprimere i dati msgBoxViewer, l'output PSSDIAG e i log eventi aggiornati (file con estensione evt). Potrebbe essere necessario inviare questi file a un BizTalk Server tecnico di supporto.

Prossima

Vedere anche

Impostazioni di SQL Server non modificabili