Post-configurazione per le ottimizzazioni del database BizTalk Server

Oltre a seguire le indicazioni 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 la configurazione dei database BizTalk Server. In questo argomento viene fornito un elenco di queste ottimizzazioni.

Pre-allocare spazio per i database BizTalk Server e definire le impostazioni di aumento automatico per i database BizTalk Server a un valore fisso anziché un valore percentuale

• L'aumento automatico del database di SQL Server è un'operazione di blocco che impedisce le prestazioni del database BizTalk Server. È 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 caso di aumento automatico, in modo misurato che riduce la probabilità di un aumento eccessivo del database. L'incremento della crescita non deve in genere essere maggiore di 100 MB (per file di grandi dimensioni), 10 MB (per file di medie dimensioni) o 1 MB (per file di piccole dimensioni).

• Quando SQL Server aumenta le dimensioni di un file, è necessario inizializzare il nuovo spazio prima di poterlo usare. Si tratta di un'operazione di blocco che comporta il riempimento del nuovo spazio con pagine vuote. SQL Server 2005 in esecuzione in Windows Server 2003 o versione successiva 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 Inizializzazione dei file di database di SQL Server 2008. In questo argomento vengono illustrati 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 del Backup di BizTalk Server (backup completo e del log) nel LUN dedicato. Modificare i passaggi 1 e 2 del processo di Backup di BizTalk Server [BizTalkMgmtDb] per inserire un nuovo percorso di output. 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 è in esecuzione scrivendo in un disco diverso da quello da cui sta leggendo il processo.

Verificare che i processi di SQL Agent di BizTalk Server siano in esecuzione

BizTalk Server include diversi processi di 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 di problemi di prestazioni in BizTalk Server è che i processi di SQL Agent non vengono eseguiti, il che a sua volta può causare l'aumento incontrollato dei database MessageBox e Tracking. Seguire questa procedura per assicurarsi che i processi di SQL Agent di BizTalk Server siano in esecuzione senza problemi:

Una delle cause più comuni dei problemi di prestazioni in BizTalk Server è che i job di SQL Agent di BizTalk Server non sono in esecuzione, il che a sua volta può causare la crescita incontrollata dei database MessageBox e Tracking. Seguire questa procedura per assicurarsi che i processi di SQL Agent di BizTalk Server siano in esecuzione senza problemi:

• Verificare che il servizio SQL Server Agent sia in esecuzione.

• Verificare che i processi di SQL Server Agent installati da BizTalk Server siano abilitati ed eseguiti correttamente.

  I processi di SQL Server Agent di BizTalk Server sono fondamentali, se non sono in esecuzione, le prestazioni del sistema peggiorano nel tempo.

• Verificare che le operazioni di SQL Server Agent di BizTalk Server siano completate in modo tempestivo.

  Configurare Microsoft Operations Manager (MOM) 2005 o Microsoft System Center Operations Manager 2007 per monitorare i processi.

  È necessario tenere presente le pianificazioni specifiche per determinati processi:

  • Il processo MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb viene eseguito continuamente per impostazione predefinita. Il software di monitoraggio deve tenere conto di questa pianificazione e non generare avvisi.

  • Il processo MessageBox_Message_Cleanup_BizTalkMsgBoxDb non è abilitato o pianificato, ma viene avviato dal processo 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 and Archive sia configurato, abilitato e completato correttamente. Per altre informazioni, vedere Configurare il processo di eliminazione e archiviazione DTA.

• Assicurati che il job possa eliminare i dati di tracciamento con la stessa rapidità con cui vengono generati i dati di tracciamento in ingresso. Per altre informazioni, vedere Misurazione della velocità effettiva massima di rilevamento sostenibile.

• Esaminare i parametri soft purge e hard purge per assicurarsi di mantenere i dati per un periodo di tempo ottimale. Per altre informazioni, vedere Archiviare ed eliminare il database di rilevamento BizTalk.

• Se è sufficiente eliminare i vecchi dati senza la necessità di archiviarli prima, modificare il processo di lavoro di SQL Agent per chiamare la stored procedure denominata dtasp_PurgeTrackingDatabase. Per altre informazioni, vedere Ripulire i dati dal database di rilevamento BizTalk.

Monitorare e ridurre la contesa di I/O dei file di log DTC

Il file di log di Microsoft Distributed Transaction Coordinator (MS DTC) può diventare un collo di bottiglia di I/O su disco in ambienti a elevato utilizzo di transazioni. Ciò vale soprattutto quando si usano adattatori che supportano transazioni, ad esempio SQL Server, MSMQ o MQSeries o in un ambiente multi-MessageBox. Gli adattatori transazionali usano transazioni DTC e 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 su disco, è necessario monitorare l'utilizzo di I/O del disco per il disco in cui si trova il file di log DTC nei server di database di SQL Server. Se l'utilizzo di I/O del disco per il disco in cui si trova 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 è in clustering, questo non è un problema perché il file di log sarà già su un'unità condivisa, che probabilmente sarà un'unità SAN veloce con più dischi. È comunque 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 su disco, è necessario monitorare l'utilizzo di I/O del disco per il disco in cui si trova il file di log DTC nei server di database di 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 è in cluster, questo non è una preoccupazione perché il file di log sarà già su un'unità condivisa, che probabilmente sarà un'unità SAN veloce con più piatti. È comunque 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 Tracking

Poiché i database BizTalk MessageBox e BizTalk Tracking sono i più attivi, è consigliabile inserire i file di dati e i file di log delle transazioni per ognuno di questi in unità dedicate per ridurre la probabilità di problemi con la 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 di Monitoraggio BizTalk (DTA)

• File di log delle transazioni per il tracciamento di BizTalk (DTA)

  La separazione dei database BizTalk MessageBox e bizTalk Tracking e la separazione dei file di database e dei file di log delle transazioni in dischi fisici diversi sono considerate procedure consigliate per ridurre la contesa di I/O del disco. Cercare di distribuire l'I/O del disco tra il massimo numero possibile di piatti fisici. È anche possibile ridurre la contesa di I/O del disco inserendo il database di rilevamento BizTalk in un'istanza di SQL Server dedicata, tuttavia, è comunque consigliabile seguire le procedure descritte in precedenza per quanto riguarda la separazione dei file di dati e dei file di log delle transazioni.

Ottimizzare i filegroup per i database BizTalk Server

Seguire la procedura descritta in Ottimizzazione dei filegroup per Database1 e il white paper su "Ottimizzazione dei database di BizTalk Server" per creare filegroup aggiuntivi e file aggiuntivi per i database di BizTalk Server. Ciò aumenterà notevolmente le prestazioni dei database BizTalk Server da una configurazione a disco singolo.