Condividi tramite

Ottimizzazioni del database di post-configurazione

  • Articolo

Oltre a seguire le raccomandazioni riportate in Ottimizzazioni di database preconfigurazione2, è 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.

È consigliabile impostare l'opzione di tabella 'text in row' in tabelle di database MessageBox specifiche

SQL Server fornisce un'opzione di tabella denominata testo in riga per dichiarare che i contenuti dei campi di testo, ntext o dati dell'immagine le cui dimensioni sono inferiori a quelle di una pagina dati (8 Kb) devono essere archiviate in una riga di dati. Impostando questa opzione nelle tabelle BizTalkMsgBoxDb (tabella parti, tabella Spool e tabelle DynamicStateInfo), è possibile aumentare la velocità effettiva dei messaggi quando si utilizzano messaggi di piccole dimensioni che dispongono di un contesto e di orchestrazioni di piccole dimensioni che hanno dimensioni di persistenza ridotte.

  • Tabella parti: quando le dimensioni del messaggio sono inferiori alle dimensioni di una pagina dati di 8 kb, l'applicazione del testo nella tabella righe nella tabella Parti può causare BizTalk Server miglioramento delle prestazioni. La tabella Parti contiene i campi seguenti:

    • ImgPart: contiene una parte del messaggio o un frammento di parte del messaggio.

    • ImgPropBag: contiene il contenitore delle proprietà della parte del messaggio.

      In questo modo, quando si esegue il ciclo su MessageBox, l'agente messaggi in esecuzione all'interno di un host BizTalk può recuperare un batch di messaggi dalla tabella Parti leggendo una piccola quantità di pagine. A seconda dello scenario e della configurazione hardware specifici, questa tecnica può ridurre l'utilizzo della CPU sia sul SQL Server che sulla BizTalk Server e fornire un miglioramento significativo in termini di latenza e velocità effettiva.

  • Tabella Spool: quando le dimensioni medie del contesto del messaggio sono inferiori a 8 kb, l'abilitazione dell'opzione testo nella tabella di riga nella tabella Spool consente di ridurre il numero di accessi durante la lettura di messaggi da MessageBox insieme al relativo contesto. Per applicare questa opzione alla tabella Spool, è necessario eliminare le proprietà del contesto non necessarie e i campi distinti per ridurre le dimensioni del contesto di messaggio inferiori a 8 Kb.

  • Tabelle DynamicStateInfo Queste tabelle, una per ogni host, contengono un campo di immagine di tipo denominata imgData che contiene lo stato di orchestrazione serializzata binaria quando incontrano un punto di persistenza durante l'esecuzione. Quando lo stato interno delle orchestrazioni all'interno di un host HostA è così piccolo che le dimensioni una volta serializzate sono inferiori a 8 kb, il testo nella tecnica di riga può essere applicato correttamente alla tabella DynamicStateInfo_HostA. È pertanto consigliabile mantenere lo stato interno delle orchestrazioni il più piccolo possibile. Questa tecnica può ridurre significativamente il tempo trascorso dal motore XLANG per serializzare, rendere persistente, de serializzare e ripristinare lo stato interno di un'orchestrazione in caso di punto di persistenza.

    Sono stati usate le impostazioni seguenti nei test del lab:

  • EXEC sp_tableoption N'Spool', 'text in row', '6000'

  • EXEC sp_tableoption N'Part', 'text in row', '6000'

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 che, se si verifica la crescita automatica, ciò avviene in modo misurato. Ciò riduce la probabilità di una crescita eccessiva del database. L'incremento della crescita per i database BizTalk Server deve in genere essere inferiore a 100 MB.

Dimensioni predefinite BizTalk Server database con dimensioni appropriate con più file di dati

Quando SQL Server aumenta le dimensioni di un file, deve prima inizializzare il nuovo spazio prima di poterlo usare. Si tratta di un'operazione di blocco che implica il riempimento del nuovo spazio con pagine vuote. SQL Server 2005 o versioni successive in esecuzione in Windows Server 2003 o versioni successive supporta l'inizializzazione immediata dei file. Questa funzionalità può ridurre notevolmente l'impatto sulle prestazioni di un'operazione di crescita dei file. Per altre informazioni, vedere Inizializzazione dei file istantanei del database, che fornisce passaggi per abilitare l'inizializzazione immediata dei file.

Nell'elenco seguente vengono descritte le configurazioni di database BizTalk Server usate nei test del lab:

  • BizTalk DTADB (file di database di rilevamento BizTalk): File di dati con dimensioni di file pari a 2048 MB con una crescita di 100 MB e un file di log di 1024 MB con una crescita di 100 MB.

  • BizTalkMgmtdb (file di database BizTalk Management): File di dati con dimensioni di file pari a 512 MB con una crescita di 100 MB e un file di log di 512 MB con una crescita di 100 MB.

  • SSODB: File di dati con dimensioni di file pari a 512 MB con una crescita di 100 MB e un file di log di 512 MB con una crescita di 100 MB.

  • BizTalkMsgBoxDb (database BizTalk MessageBox): 8 file di dati, ognuno con dimensioni di file pari a 2 GB con una crescita di 100 MB e un file di log di 20 GB con una crescita di 100 MB. Poiché i database BizTalk MessageBox sono i più attivi, è consigliabile posizionare i file di dati e i file di log delle transazioni nelle unità dedicate per ridurre la probabilità di problemi con la contesa di I/O del disco. Nell'ambiente lab è stata usata un'unità per ognuna delle operazioni seguenti:

    • File di dati MessageBox

    • File di log delle transazioni MessageBox

    Lo script SQL seguente può essere usato per predimensionare BizTalkMsgBoxDb che inizialmente dispone di un file di dati nell'unità J (J:\BizTalkMsgBoxDb.mdf) e un file di log nell'unità K (K:\BizTalkMsgBoxDb_log. LDF:

Importante

Questo script viene fornito "come è", è destinato solo a scopi demo o educativi e deve essere usato a proprio rischio. L'uso di questo script non è supportato da Microsoft e Microsoft non garantisce alcuna garanzia sull'idoneità di questo script.

EXEC dbo.sp_helpdb BizTalkMsgBoxDb
ALTER DATABASE BizTalkMsgBoxDb MODIFY FILE (NAME = BizTalkMsgBoxDb , FILENAME = 'J:\BizTalkMsgBoxDb.mdf' , SIZE = 2GB , FILEGROWTH = 100MB)
ALTER DATABASE BizTalkMsgBoxDb ADD FILE    (NAME = BizTalkMsgBoxDb_2 , FILENAME = 'J:\BizTalkMsgBoxDb_2.ndf' , SIZE = 2GB , FILEGROWTH = 100MB)
ALTER DATABASE BizTalkMsgBoxDb ADD FILE    (NAME = BizTalkMsgBoxDb_3 , FILENAME = 'J:\BizTalkMsgBoxDb_3.ndf' , SIZE = 2GB , FILEGROWTH = 100MB)
ALTER DATABASE BizTalkMsgBoxDb ADD FILE    (NAME = BizTalkMsgBoxDb_4 , FILENAME = 'J:\BizTalkMsgBoxDb_4.ndf' , SIZE = 2GB , FILEGROWTH = 100MB)
ALTER DATABASE BizTalkMsgBoxDb ADD FILE    (NAME = BizTalkMsgBoxDb_5 , FILENAME = 'J:\BizTalkMsgBoxDb_5.ndf' , SIZE = 2GB , FILEGROWTH = 100MB)
ALTER DATABASE BizTalkMsgBoxDb ADD FILE    (NAME = BizTalkMsgBoxDb_6 , FILENAME = 'J:\BizTalkMsgBoxDb_6.ndf' , SIZE = 2GB , FILEGROWTH = 100MB)
ALTER DATABASE BizTalkMsgBoxDb ADD FILE    (NAME = BizTalkMsgBoxDb_7 , FILENAME = 'J:\BizTalkMsgBoxDb_7.ndf' , SIZE = 2GB , FILEGROWTH = 100MB)
ALTER DATABASE BizTalkMsgBoxDb ADD FILE    (NAME = BizTalkMsgBoxDb_8 , FILENAME = 'J:\BizTalkMsgBoxDb_8.ndf' , SIZE = 2GB , FILEGROWTH = 100MB)
GO
ALTER DATABASE BizTalkMsgBoxDb MODIFY FILE (NAME = BizTalkMsgBoxDb_log , FILENAME = 'K:\BizTalkMsgBoxDb_log.LDF', SIZE =  20GB , FILEGROWTH = 100MB)
GO

Spostare la directory di output di Backup BizTalk Server in un LUN dedicato

  1. Spostare la directory di output denominata Backup BizTalk (backup completo e log) in un LUN dedicato.

  2. Modificare il processo denominato Backup BizTalk Server per puntare al LUN dedicato.

Il primo passaggio riduce la contesa di I/O del disco quando il processo viene eseguito scrivendo in un disco diverso dalla posizione in cui il processo sta leggendo. Per altre informazioni, vedere Configurare il processo di backup BizTalk Server.

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

In BizTalk Server diversi processi SQL Server Agent eseguono funzioni importanti che mantengono operativi e integri i server. Assicurarsi di monitorare l'integrità di questi processi e che vengano eseguiti senza errori. Una causa comune dei problemi di prestazioni BizTalk Server è che quando i processi di SQL Agent BizTalk Server non sono in esecuzione, i database MessageBox e Rilevamento possono crescere senza controllo. Per assicurarsi che i processi di SQL Agent BizTalk Server vengano eseguiti senza problemi, seguire questa procedura:

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

  2. Verificare che i processi di SQL Server Agent installati da BizTalk Server siano abilitati ed in esecuzione correttamente. I processi BizTalk Server SQL Server Agent sono cruciali: se non sono in esecuzione, le prestazioni del sistema degraderanno nel tempo.

  3. Verificare che i processi BizTalk Server SQL Server Agent vengano completati in modo tempestivo. Configurare la versione più recente di Microsoft System Center Operations Manager 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.

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

Per assicurarsi di configurare correttamente l'eliminazione e l'archiviazione dei dati di rilevamento, seguire questa procedura:

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

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

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

  4. 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 DTC (Distributed Transaction Coordinator) può diventare un collo di bottiglia di I/O 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 nei 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. È comunque consigliabile monitorare l'utilizzo di I/O del disco. Ciò avviene perché può diventare un collo di bottiglia negli 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 di Rilevamento BizTalk (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 riportate sopra 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 in Ottimizzazione dei filegroup per database2 e Ottimizzazione delle prestazioni del database 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.

Vedere anche

Ottimizzazione delle prestazioni del database