Post-configurazione per le ottimizzazioni del database BizTalk Server
Oltre a seguire le raccomandazioni riportate in Ottimizzazioni del database di preconfigurazione, è necessario seguire diversi passaggi per ottimizzare le prestazioni del database BizTalk Server in SQL Server dopo l'installazione di BizTalk Server e i database BizTalk Server sono stati configurati. Questo argomento fornisce un elenco di queste ottimizzazioni.
Spazio pre-allocato per i database BizTalk Server e definire le impostazioni di crescita automatica per i database BizTalk Server in un valore fisso anziché un valore percentuale
SQL Server la crescita automatica del database è un'operazione di blocco che impedisce BizTalk Server prestazioni del database. È quindi importante allocare spazio sufficiente per i database BizTalk Server in anticipo per ridurre al minimo l'occorrenza della crescita automatica del database.
La crescita automatica del database deve essere impostata su un numero fisso di megabyte anziché su una percentuale (specificare la crescita dei file In Megabyte). Questa operazione deve essere eseguita in modo da ridurre la probabilità di una crescita eccessiva del database. L'incremento della crescita deve in genere non essere superiore a 100 MB (per file di grandi dimensioni), 10 MB (per file di dimensioni medie) o 1 MB (per file di piccole dimensioni).
Quando SQL Server aumenta le dimensioni di un file, è necessario inizializzare prima di poterlo usare. Si tratta di un'operazione di blocco che implica il riempimento del nuovo spazio con pagine vuote. SQL Server 2005 in esecuzione in Windows Server 2003 o versioni successive supporta l'inizializzazione immediata dei file. Ciò può ridurre notevolmente l'impatto sulle prestazioni di un'operazione di crescita dei file. Per altre informazioni, vedere SQL Server 2008 - Inizializzazione file di database. Questo argomento illustra i passaggi per abilitare l'inizializzazione immediata dei file.
Spostare la directory di output di Backup BizTalk Server in un LUN dedicato
Spostare la directory di output Backup BizTalk Server (backup completo e log) in LUN dedicato, Modificare i passaggi 1 e 2 (inserire il nuovo percorso di output) del processo Backup BizTalk Server [BizTalkMgmtDb]. Lo spostamento della directory di output di Backup BizTalk Server in un LUN dedicato ridurrà la contesa di I/O del disco quando il processo viene eseguito scrivendo in un disco diverso rispetto al processo da cui viene letto.
Verificare che i processi di SQL Agent BizTalk Server siano in esecuzione
BizTalk Server include diversi processi SQL Server Agent che eseguono funzioni importanti per mantenere operativi e integri i server. È consigliabile monitorare l'integrità di questi processi e assicurarsi che siano in esecuzione senza errori. Una delle cause più comuni dei problemi di prestazioni in BizTalk Server è che i processi di SQL Agent BizTalk Server non sono in esecuzione, che a sua volta possono causare l'aumento deselezionato dei database MessageBox e Rilevamento. Seguire questa procedura per assicurarsi che i processi di SQL Agent BizTalk Server vengano eseguiti senza problemi:
Una delle cause più comuni dei problemi di prestazioni in BizTalk Server è che i processi di SQL Agent BizTalk Server non sono in esecuzione, che a sua volta possono causare l'aumento deselezionato dei database MessageBox e Rilevamento. Seguire questa procedura per assicurarsi che i processi di SQL Agent BizTalk Server vengano eseguiti senza problemi:
Verificare che il servizio SQL Server Agent sia in esecuzione.
Verificare che i processi SQL Server Agent installati da BizTalk Server siano abilitati ed in esecuzione correttamente.
I processi di BizTalk Server SQL Server Agent sono cruciali, se non sono in esecuzione, le prestazioni del sistema degraderanno nel tempo.
Verificare che i processi di BizTalk Server SQL Server Agent vengano completati in modo tempestivo.
Configurare Microsoft Operations Manager (MOM) 2005 o Microsoft System Center Operations Manager 2007 per monitorare i processi.
È consigliabile tenere presente le pianificazioni specifiche per determinati processi:
Il processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb viene eseguito continuamente per impostazione predefinita. Il software di monitoraggio deve prendere in considerazione questa pianificazione e non produrre avvisi.
Il processo MessageBox_Message_Cleanup_BizTalkMsgBoxDb non è abilitato o pianificato, ma viene avviato dal processo di MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb ogni 10 secondi. Pertanto, questo processo non deve essere abilitato, pianificato o avviato manualmente.
Verificare che il tipo di avvio del servizio SQL Server Agent sia configurato correttamente.
Verificare che il servizio SQL Server Agent sia configurato con un tipo di avvioautomatico a meno che il servizio SQL Server Agent non sia configurato come risorsa cluster in un cluster Windows Server. Se il servizio SQL Server Agent è configurato come risorsa cluster, è necessario configurare il tipo di avvio come Manuale perché il servizio verrà gestito dal servizio cluster.
Configurare l'eliminazione e l'archiviazione dei dati di rilevamento
Seguire questa procedura per assicurarsi che l'eliminazione e l'archiviazione dei dati di rilevamento siano configurati correttamente:
Assicurarsi che il processo di SQL Agent denominato DTA Purge e Archive sia configurato correttamente, abilitato e completato correttamente. Per altre informazioni, vedere Configurare il processo di eliminazione e archiviazione DTA.
Assicurarsi che il processo possa eliminare i dati di rilevamento più velocemente quando vengono generati i dati di rilevamento in ingresso. Per altre informazioni, vedere Misurazione massima velocità effettiva di rilevamento sostenibile.
Esaminare i parametri di eliminazione temporanea e di eliminazione dura per assicurarsi di mantenere i dati per la durata ottimale. Per altre informazioni, vedere Archivio ed eliminazione del database di rilevamento BizTalk.
Se è necessario eliminare solo i dati precedenti e non è necessario archiviare prima di tutto, modificare il processo di SQL Agent per chiamare la stored procedure denominata dtasp_PurgeTrackingDatabase. Per altre informazioni, vedere Eliminare i dati dal database di rilevamento BizTalk.
Monitorare e ridurre la contesa dei file di log DTC
Il file di log microsoft Distributed Transaction Coordinator (MS DTC) può diventare un collo di bottiglia di I/O su disco negli ambienti a elevato utilizzo delle transazioni. Ciò è particolarmente vero quando si usano schede che supportano transazioni, ad esempio SQL Server, MSMQ o MQSeries o in un ambiente multi-MessageBox. Le schede transazionali usano transazioni DTC e gli ambienti multi-MessageBox usano ampiamente le transazioni DTC. Per assicurarsi che il file di log DTC non diventi un collo di bottiglia di I/O disco, è necessario monitorare l'utilizzo di I/O del disco per il disco in cui risiede il file di log DTC nel server di database SQL Server. Se l'utilizzo di I/O del disco per il disco in cui risiede il file di log DTC diventa eccessivo, prendere in considerazione lo spostamento del file di log DTC in un disco più veloce. In un ambiente in cui SQL Server è cluster, questo non è un problema perché il file di log sarà già in un'unità condivisa, che probabilmente sarà un'unità SAN veloce con più spinde. È tuttavia consigliabile monitorare l'utilizzo di I/O del disco perché può diventare un collo di bottiglia in ambienti non cluster o quando il file di log DTC si trova in un disco condiviso con altri file a elevato utilizzo di disco.
Per assicurarsi che il file di log DTC non diventi un collo di bottiglia di I/O disco, è necessario monitorare l'utilizzo di I/O del disco per il disco in cui risiede il file di log DTC nel server di database SQL Server. Se l'utilizzo di I/O del disco per il disco in cui risiede il file di log DTC diventa eccessivo, è consigliabile spostare il file di log DTC in un disco più veloce.
In un ambiente in cui SQL Server è cluster, questo non è un problema perché il file di log sarà già in un'unità condivisa, che probabilmente sarà un'unità SAN veloce con più spinde. È tuttavia consigliabile monitorare l'utilizzo di I/O del disco perché può diventare un collo di bottiglia in ambienti non cluster o quando il file di log DTC si trova in un disco condiviso con altri file a elevato utilizzo di disco.
Separare i database MessageBox e rilevamento
Poiché i database BizTalk MessageBox e BizTalk Tracking sono i più attivi, è consigliabile posizionare i file di dati e i file di log delle transazioni per ognuno di questi in unità dedicate per ridurre la probabilità di problemi relativi alla contesa di I/O del disco. Ad esempio, sono necessarie quattro unità per i file di database MessageBox e BizTalk Tracking, un'unità per ognuna delle seguenti:
File di dati MessageBox
File di log delle transazioni MessageBox
File di dati bizTalk Tracking (DTA)
File di log delle transazioni BizTalk Tracking (DTA)
La separazione dei database BizTalk MessageBox e BizTalk Tracking e la separazione dei file di log delle transazioni e dei file di database in dischi fisici diversi sono considerate procedure consigliate per ridurre la contesa di I/O del disco. Provare a distribuire l'I/O del disco tra il maggior numero possibile di spindles fisici. È anche possibile ridurre la contesa di I/O del disco inserendo il database di rilevamento BizTalk in un SQL Server dedicato, tuttavia, è comunque consigliabile seguire le procedure precedenti per quanto riguarda la separazione dei file di dati e dei file di log delle transazioni.
Ottimizzare i filegroup per i database di BizTalk Server
Seguire la procedura descritta nell'Ottimizzazione dei filegroup per database1 e nel white paper "Ottimizzazione database BizTalk Server" per creare filegroup e file aggiuntivi per i database BizTalk Server. Ciò aumenterà notevolmente le prestazioni dei database BizTalk Server da una singola configurazione del disco.