Condividi tramite


Elenco di controllo: Configurazione di SQL Server

Procedura da seguire per la preparazione di SQL Server per l'uso in un ambiente di produzione BizTalk Server.

Configurazione di SQL Server

Fasi Riferimenti
Monitorare e ridurre il conflitto di I/O nei file di database di BizTalk Server. - È consigliabile monitorare in modo proattivo l'utilizzo di I/O del disco per i dischi che ospitano i file di dati e di log delle transazioni.
- È consigliabile che i file di dati e i file di log delle transazioni per ognuno di questi vengano inseriti in unità dedicate per ridurre la probabilità che la contesa di I/O del disco diventi un problema.
- È possibile ridurre la contesa di I/O del disco separando i database MessageBox e Tracking (DTA) e separando i file di database e i file di log delle transazioni in dischi fisici diversi.

Per altre informazioni, vedere Monitoraggio e riduzione della contesa di I/O del database
Verificare che SQL Server sia configurato in partizioni del disco allineate correttamente Le partizioni del disco correttamente allineate potrebbero comportare una diminuzione significativa della latenza, migliorando così le prestazioni di SQL Server, migliorando a sua volta le prestazioni di BizTalk Server. Al contrario, le partizioni disco non allineate possono influire negativamente sulle prestazioni di I/O, riducendo così le prestazioni di SQL Server e BizTalk Server.

Per altre informazioni sul modo in cui le partizioni del disco allineate correttamente possono influire negativamente sulle prestazioni, vedere Procedure consigliate per l'allineamento delle partizioni del disco per SQL Server.
Mantenere gli eventi monitorati con SQL Server Profiler Usare SQL Server Profiler per eseguire unicamente il monitoraggio degli eventi di interesse. Se le tracce diventano troppo grandi, è possibile filtrarle in base alle informazioni desiderate, in modo che venga raccolto solo un subset dei dati dell'evento. Il monitoraggio di un numero troppo elevato di eventi comporta un overhead aggiuntivo per il server e il processo di monitoraggio e pertanto potrebbe aumentare in modo considerevole le dimensioni del file o della tabella di traccia, in particolare se il processo di monitoraggio viene prolungato nel tempo.
Monitorare e ridurre la contesa di I/O dei file di log DTC. Monitoraggio e riduzione della contesa di I/O dei file di log DTC
Offrire disponibilità elevata per i database di SQL Server. Pianificazione della disponibilità del database
Esaminare la configurazione del cluster di SQL Server attivo/attivo per gli scenari di failover. Revisione e test della configurazione del cluster SQL Server per scenari di failover
Usare le impostazioni di configurazione predefinite per:

- Massimo Grado di Parallelismo (MDOP).
- Statistiche di SQL Server nel database MessageBox di BizTalk Server.
- Ricompila e deframmenta l'indice del database di SQL Server.
Impostazioni di SQL Server che non devono essere modificate
Abilitare il flag di traccia 1118 (TF1118) come parametro di avvio per tutte le istanze di SQL Server. L'implementazione di TF1118 consente di ridurre i conflitti tra le istanze di SQL Server rimuovendo quasi tutte le allocazioni di pagine singole. Per altre informazioni, vedere l'articolo della Microsoft Knowledge Base Miglioramenti della concorrenza per il database tempdb.

Nota: Per altre informazioni su TF1118, vedere Errori relativi a TF1118. Si noti che il contenuto in questo collegamento non è di proprietà di Microsoft e Microsoft non garantisce l'accuratezza del contenuto.
Suddividere il database tempdb in più file di dati di dimensioni uguali in ogni istanza di SQL Server usata da BizTalk Server. Assicurarsi che i file di dati usati per tempdb siano di dimensioni uguali. Ciò è fondamentale perché l'algoritmo di riempimento proporzionale usato da SQL Server si basa sulle dimensioni dei file di dati. Se i file di dati vengono creati con dimensioni diverse, l'algoritmo di riempimento proporzionale userà il file più grande per le allocazioni GAM (Global Allocation Map) invece di distribuire le allocazioni tra tutti i file, sconfiggendo così lo scopo di creare più file di dati. Come linea guida generale, creare un file di dati per ogni CPU nel server e quindi regolare il numero di file verso l'alto o verso il basso in base alle esigenze. Si noti che una CPU dual-core viene considerata come due CPU. In ogni caso, il numero di file di dati non deve essere maggiore di 8, indipendentemente dal numero di core aggiuntivi disponibili nel computer. Per altre informazioni sui file tempdb, vedere Ottimizzazione delle prestazioni di tempdb.
Impostare la memoria minima e massima del server sugli stessi valori nelle istanze di SQL Server che ospitano i database BizTalk Server. I computer che eseguono SQL Server che ospitano i database BizTalk Server devono essere dedicati all'esecuzione di SQL Server. Quando i computer che eseguono SQL Server che ospitano i database BizTalk Server sono dedicati all'esecuzione di SQL Server, è consigliabile impostare le opzioni "min server memory" e "max server memory" in ogni istanza di SQL Server per specificare la quantità fissa di memoria da allocare a SQL Server. In questo caso, è necessario impostare "min server memory" e "max server memory" sullo stesso valore (uguale alla quantità massima di memoria fisica usata da SQL Server). In questo modo si ridurrà il sovraccarico che altrimenti verrebbe usato da SQL Server per la gestione dinamica di questi valori. Eseguire i comandi T-SQL seguenti in ogni computer che esegue SQL Server per specificare la quantità fissa di memoria da allocare a SQL Server:

sp_configure 'Memoria massima server (MB)', (dimensione massima in MB) sp_configure 'Memoria minima server (MB)', (dimensione minima in MB)

Prima di impostare la quantità di memoria per SQL Server, determinare l'impostazione di memoria appropriata sottraendo la memoria necessaria per Windows Server dalla memoria fisica totale. Si tratta della quantità massima di memoria che è possibile assegnare a SQL Server. Nota: Se i computer che eseguono SQL Server che ospitano i database BizTalk Server ospitano anche Enterprise Single Sign-On master secret come descritto nell'argomento Clustering the Master Secret Server , potrebbe essere necessario modificare questo valore per assicurarsi che sia disponibile memoria sufficiente per eseguire il servizio Enterprise Single Sign-On Service.
Tenere conto delle dimensioni del database di rilevamento BizTalk - Quando si determinano le dimensioni dei messaggi nel database di rilevamento BizTalk (DTA), aggiungere la dimensione media del contesto del messaggio alla dimensione del messaggio se è significativa rispetto alle dimensioni del messaggio.
- Per limitare le dimensioni dei messaggi nel database di rilevamento di BizTalk, limitare il numero di proprietà promosse.
- Se l'opzione del debugger di orchestrazione è abilitata, tenere presente che lo stato di ogni forma nell'orchestrazione viene salvato nel database di rilevamento BizTalk.

Esecuzione di procedure di manutenzione di SQL Server

Fasi Riferimenti
Definire le impostazioni di aumento automatico per i database BizTalk Server. - L'aumento automatico del database deve essere impostato su un numero fisso di megabyte anziché su una percentuale, in particolare per i database MessageBox e Tracking. A seconda dell'applicazione BizTalk Server e della velocità effettiva, i database MessageBox e Tracking possono ottenere dimensioni molto elevate. Se la crescita automatica è impostata su una percentuale, la crescita automatica può anche essere sostanziale.
- L'inizializzazione immediata dei file può ridurre notevolmente l'impatto sulle prestazioni di un'operazione di crescita dei file.
- Idealmente, le dimensioni dei file che supportano i gruppi di file devono essere preallocate e, se possibile, impostare su una dimensione statica.

Per altre informazioni, vedere Definizione delle impostazioni di aumento automatico per i database.
Eseguire il backup dei database BizTalk Server - È consigliabile eseguire il processo di backup di BizTalk Server per impedire che i log delle transazioni del database BizTalk Server aumentino in modo non associato.
- È consigliabile ripristinare regolarmente l'intero ambiente BizTalk Server e documentare attentamente il processo.
- È consigliabile archiviare i file di backup precedenti.

Per ulteriori informazioni, vedere Creazione di backup dei database.
Monitorare i processi di SQL Agent di BizTalk Server. Monitorare lo stato di salute di questi processi e assicurarsi che siano in esecuzione senza errori. Per altre informazioni, vedere Monitoraggio dei processi di SQL Server Agent.
Abilitare il rilevamento e l'archiviazione di BizTalk Server Il processo di lavoro "Eliminazione e archiviazione DTA" di SQL Agent archivia ed elimina i dati obsoleti dal database di monitoraggio BizTalk, impedendo così che la sua dimensione cresca fuori controllo. Questo è essenziale per un sistema BizTalk Server integro. Per altre informazioni, vedere Eliminazione e archiviazione dei dati di rilevamento.

Processo di backup dei database di BizTalk Server

Fasi Riferimenti
Verificare che il processo di Backup di BizTalk Server SQL Agent sia configurato. Vedere Configurare il processo di Backup di BizTalk Server
Configurare il processo di Backup di BizTalk Server SQL Agent per eliminare i file di backup precedenti al numero di giorni specificato dalla @DaysToKeep variabile. Se i file di backup non vengono eliminati, possono aumentare nel tempo senza vincoli, in modo da riempire i dischi che contengono i file di backup e causare problemi correlati a spazio su disco limitato. Vedere Configurare il processo di Backup di BizTalk Server
Verificare che il processo di Backup di BizTalk Server SQL Agent sia abilitato e in esecuzione. Monitoraggio dei processi di SQL Server Agent

Uso del log shipping di SQL Server per il ripristino di emergenza

Fasi Riferimenti
Verificare che i server di ripristino di emergenza abbiano la capacità di gestire il carico di produzione. Vedere Uso del log shipping di BizTalk Server per il ripristino di emergenza
Assicurarsi che le specifiche della routine di ripristino di emergenza siano ben documentate. Consulta Utilizzo del trasferimento del log di BizTalk Server per il ripristino di emergenza
Nell'ambito dei test regolari, è consigliabile eseguire il failover nel sito di ripristino di emergenza, in particolare quando vengono messe in produzione nuove applicazioni BizTalk. Vedere Uso del log shipping di BizTalk Server per il ripristino di emergenza

Monitoraggio delle attività di SQL Agent di BizTalk Server

Fasi Riferimenti
Verificare che il servizio SQL Server Agent sia in esecuzione. Vedere Monitoraggio dei processi di SQL Server Agent
Verificare che i processi di SQL Server Agent installati da BizTalk Server siano abilitati ed eseguiti correttamente. Vedere Monitoraggio dei processi di SQL Server Agent
Verificare che i processi di SQL Agent di BizTalk Server vengano completati in modo tempestivo. Vedere Monitoraggio dei processi di SQL Server Agent

Eliminazione e archiviazione dei dati di rilevamento

Fasi Riferimenti
Assicurarsi che il processo di SQL Agent "Eliminazione e archiviazione DTA" sia configurato correttamente, abilitato e completato correttamente. Vedere Configurare il processo di eliminazione e archiviazione DTA.
Assicurarsi che l'attività sia in grado di ripulire i dati di rilevamento alla stessa velocità con cui vengono generati i dati di rilevamento in ingresso. Vedere Misurazione della massima capacità di tracciamento sostenibile
Esaminare i parametri soft purge e hard purge per assicurarsi di mantenere i dati per un periodo di tempo ottimale. Vedere Archiviazione ed eliminazione del database di rilevamento BizTalk.
Se è sufficiente eliminare i dati precedenti e non è necessario archiviarli prima, modificare il processo di SQL Agent per chiamare la stored procedure "dtasp_PurgeTrackingDatabase". Consulta Eliminare i dati dal database di rilevamento BizTalk.

Prossimo