Optimierungen der Datenbank vor der Konfiguration
Aufgrund der wichtigen Rolle, die SQL Server in jeder BizTalk Server-Umgebung spielt, ist es von größter Bedeutung, dass SQL Server für eine optimale Leistung konfiguriert/optimiert werden. Wenn SQL Server nicht auf eine gute Leistung optimiert ist, werden die von BizTalk Server verwendeten Datenbanken zu einem Engpass, und die Gesamtleistung der BizTalk Server-Umgebung wird beeinträchtigt. In diesem Thema werden mehrere SQL Server Leistungsoptimierungen beschrieben, die vor der Installation BizTalk Server und der Konfiguration der BizTalk Server-Datenbanken befolgt werden sollten.
Festlegen der NTFS-Dateizuordnungseinheit
SQL Server speichert seine Daten in Blöcken, bei denen es sich um Sammlungen von acht physisch zusammenhängenden 8.000 Seiten oder 64 KB handelt. Legen Sie daher zur Optimierung der Datenträgerleistung die NTFS-Zuordnungseinheitsgröße auf 64 KB fest, wie unter "Bewährte Methoden für die Datenträgerkonfiguration" unter Bewährte Methoden für die Vorabbereitstellung von E/A beschrieben.
Überlegungen zur Version und Edition von SQL Server
Verschiedene Versionen und Editionen von SQL Server bieten unterschiedliche Features, die sich auf die Leistung Ihrer BizTalk Server-Umgebung auswirken können. Beispielsweise kann unter Bedingungen mit hoher Auslastung die Anzahl der Datenbanksperren, die für die 32-Bit-Version von SQL Server verfügbar sind, überschritten werden, was sich negativ auf die Leistung der BizTalk-Lösung auswirkt. Erwägen Sie, Ihre MessageBox-Datenbank in einer 64-Bit-Version von SQL Server zu speichern, wenn in Ihrer Testumgebung Fehler vom Typ "Nicht gesperrt" auftreten. Bei dieser Version von SQL Server steht eine wesentlich höhere Anzahl an Sperren zur Verfügung.
Berücksichtigen Sie die folgende Tabelle bei der Entscheidung über die Datenbank-Engine-Features, die Sie für Ihre BizTalk-Umgebung benötigen. Für umfangreiche Lösungen auf Unternehmensebene, die Clusterunterstützung, BizTalk Server Protokollversandunterstützung oder Analysis Services-Unterstützung erfordern, benötigen Sie SQL Server Enterprise Edition, um die SQL Server Datenbanken zu hosten.
Eine vollständige Liste der Features, die von den SQL Server-Editionen unterstützt werden, finden Sie unter SQL Server Editionen und unterstützten Features.
Überlegungen zur Datenbankplanung
Es wird empfohlen, ihre SQL Server Datenbanken auf schnellem Speicher zu hosten (z. B. schnelle SAN-Datenträger oder schnelle SCSI-Datenträger). Wir empfehlen RAID 10 (1+0) anstelle von RAID 5, da raid 5 beim Schreiben langsamer ist. Neuere SAN-Datenträger verfügen über sehr große Speichercaches, sodass in diesen Fällen die Raidauswahl nicht so wichtig ist. Um die Leistung zu steigern, können sich Datenbanken und ihre Protokolldateien auf unterschiedlichen physischen Datenträgern befinden.
Erwägen Sie auch die Optimierung der Warteschlangentiefe des Host Bus Adapters (HBA), wenn Sie ein Storage Area Network (SAN) verwenden. Dies kann sich erheblich auf den E/A-Durchsatz auswirken, und out-of-the-box-Werte können für SQL Server nicht ausreichen. Tests sind erforderlich, um den optimalen Wert zu ermitteln, obwohl die Warteschlangentiefe von 64 im Allgemeinen als guter Ausgangspunkt akzeptiert wird, wenn keine spezifischen Empfehlungen des Anbieters vorliegen.
Installieren Sie das neueste Service Pack und kumulative Updates für SQL Server
Installieren Sie die neuesten Service Packs und die neuesten kumulativen Updates für SQL Server sowie die neuesten .NET Framework Service Packs.
Installieren von SQL Service Packs und kumulativen Updates auf BizTalk Server und SQL Server
Wenn Sie Service Packs oder kumulative Updates für SQL Server installieren, installieren Sie auch das Service Pack oder kumulative Update auf dem BizTalk Server Computer. BizTalk Server verwendet SQL-Clientkomponenten, die von SQL Server Service Packs und kumulativen Updates aktualisiert werden.
Erwägen Sie die Verwendung eines schnellen SSD-Laufwerks (Solid State Drive), um die SQL Server tembdb zu beherbergen.
Erwägen Sie die Verwendung eines oder mehrerer SSD-Laufwerke (Solid State Disk), um die TempDB zu speichern. SSD-Laufwerke bieten erhebliche Leistungsvorteile gegenüber herkömmlichen Festplatten und fallen schnell im Preis, wenn sie in mainstream-Märkte eintreten. Da die TempDB-Leistung häufig ein wichtiger Faktor für die Gesamtleistung SQL Server ist, werden die zusätzlichen Anfangskosten der Laufwerke häufig schnell durch die insgesamt erhöhte SQL Server Leistung verursacht, insbesondere wenn Unternehmensanwendungen ausgeführt werden, für die SQL Server Leistung entscheidend ist.
Erwägen Sie die Implementierung des SQL Server 2008 R2 Data Collector and Management Data Warehouse
SQL Server 2008 R2 ist die Verwendung des neuen datensammler- und -verwaltungs-Data Warehouse zum Sammeln von Umgebungs-/Datenbankleistungsdaten für Test- und Trendanalysen vorgesehen. Der Datensammler speichert alle gesammelten Daten im angegebenen Verwaltungs-Data Warehouse. Obwohl dies keine Leistungsoptimierung ist, ist dies für die Analyse von Leistungsproblemen nützlich.
Erteilen Des Kontos, das zum SQL Server der Windows-Berechtigung "Seiten im Arbeitsspeicher sperren" verwendet wird
Erteilen Sie dem SQL Server-Dienstkonto die Berechtigung Windows Lock Pages in Memory. Dies sollte verhindert werden, dass das Windows-Betriebssystem den Pufferpoolspeicher des SQL Server Prozesses auslagern kann, indem der für den Pufferpool zugeordnete Arbeitsspeicher im physischen Arbeitsspeicher gesperrt wird.
In unserer Labumgebung war die Option Seiten im Arbeitsspeicher sperren von Windows-Richtlinien standardmäßig aktiviert. Weitere Informationen finden Sie unter Aktivieren der Option Zum Sperren von Seiten im Arbeitsspeicher.
Wichtig
Es gelten bestimmte Einschränkungen, wenn dem SQL Server Dienstkonto die Windows Lock Pages in Memory-Berechtigung gewährt wird. Weitere Informationen finden Sie in den folgenden Themen:
Gewähren des SE_MANAGE_VOLUME_NAME-Rechts für das SQL Server-Dienstkonto
Stellen Sie sicher, dass das Konto, das den SQL Server Dienst ausführt, über die Windows-Berechtigung "Volumewartungsaufgaben ausführen" verfügt, oder stellen Sie sicher, dass es zu einer Gruppe gehört, die dies tut. Dadurch wird eine sofortige Dateiinitialisierung ermöglicht, die eine optimale Leistung gewährleistet, wenn eine Datenbank automatisch vergrößert werden muss.
Festlegen von Min. und Max. Serverarbeitsspeicher
Die Computer, auf denen SQL Server ausgeführt werden, auf denen die BizTalk Server Datenbanken gehostet werden, sollten für die Ausführung SQL Server dediziert werden. Wenn die Computer, auf denen SQL Server ausgeführt werden, auf denen die BizTalk Server Datenbanken gehostet werden, für die Ausführung SQL Server dediziert sind, wird empfohlen, dass die Optionen "Minimaler Serverarbeitsspeicher" und "maximaler Serverarbeitsspeicher" für jeden SQL Server instance festgelegt sind, um die feste Menge an Arbeitsspeicher anzugeben, der zugeordnet werden soll. SQL Server. In diesem Fall sollten Sie die Werte "Min. Serverarbeitsspeicher" und "Max. Serverarbeitsspeicher" auf den gleichen Wert festlegen (entspricht der maximalen Menge an physischem Arbeitsspeicher, die SQL Server verwenden wird). Dadurch wird der Aufwand reduziert, der andernfalls von SQL Server dynamischer Verwaltung dieser Werte verwendet würde. Führen Sie die folgenden T-SQL-Befehle auf jedem Computer aus, auf dem SQL Server ausgeführt wird, um die feste Menge an Arbeitsspeicher anzugeben, die SQL Server zugeordnet werden soll:
sp_configure ‘Max Server memory (MB)’,(max size in MB)
sp_configure ‘Min Server memory (MB)’,(min size in MB)
Bevor Sie die Arbeitsspeichermenge für SQL Server festlegen, bestimmen Sie die entsprechende Arbeitsspeichereinstellung, indem Sie den für Windows Server erforderlichen Arbeitsspeicher vom gesamten physischen Arbeitsspeicher subtrahieren. Dies ist die maximale Arbeitsspeichermenge, die Sie SQL Server zuweisen können.
Hinweis
Wenn die Computer, auf denen SQL Server ausgeführt werden, die die BizTalk Server-Datenbanken hosten, auch den Enterprise Single Sign-On Master Secret Server hosten, müssen Sie diesen Wert möglicherweise anpassen, um sicherzustellen, dass genügend Arbeitsspeicher für die Ausführung des Enterprise Single Sign-On Service verfügbar ist. Es ist keine ungewöhnliche Praxis, eine gruppierte instance des Enterprise Single Sign-On-Diensts in einem SQL Server-Cluster auszuführen, um Hochverfügbarkeit für den Master Secret Server zu gewährleisten. Siehe Clustering the Master Secret Server (Clustering the Master Secret Server)
Aufteilen der tempdb-Datenbank in mehrere Datendateien gleicher Größe auf jeder SQL Server instance, die von BizTalk Server
Es ist wichtig, sicherzustellen, dass die für die tempdb verwendeten Datendateien die gleiche Größe aufweisen, da der proportionale Füllalgorithmus, der von SQL Server verwendet wird, auf der Größe der Datendateien basiert. Wenn Datendateien mit ungleicher Größe erstellt werden, verwendet der proportionale Füllalgorithmus die größte Datei eher für GAM-Zuordnungen, anstatt die Zuordnungen auf alle Dateien zu verteilen, wodurch der Zweck der Erstellung mehrerer Datendateien verfehlt wird. Die optimale Anzahl von tempdb-Datendateien hängt vom Grad des Latchkonflikts in tempdb ab. Als allgemeine Faustregel sollte die Anzahl der Datendateien gleich der Anzahl der Prozessorkerne/CPUs sein, bei denen die Anzahl der CPUs 8 oder weniger beträgt. Erstellen Sie für Server mit mehr als 8 CPUs Datendateien für die Hälfte der Anzahl von CPUs (auch hier haben nur Latchkonflikte).
In unserer Labumgebung haben wir das folgende Skript verwendet, um 8 TempDB-Datendateien zu erstellen, die jeweils eine Dateigröße von 1024 MB mit 100 MB Wachstum und eine Protokolldatei von 512 MB mit 100 MB Wachstum hatten. Die Datendateien werden auf Laufwerk H: und die Protokolldatei auf Laufwerk I:verschoben.
Wichtig
Dieses Skript wird "wie beschaulich" bereitgestellt, ist nur für Demo- oder Bildungszwecke vorgesehen und kann auf eigenes Risiko verwendet werden. Die Verwendung dieses Skripts wird von Microsoft nicht unterstützt, und Microsoft übernimmt keine Garantien für die Eignung dieses Skripts.
--<<<<<<<<<<----------------------------------------------------------------->>>>>>>>>>--
-- Use of included script samples are subject to the terms specified at
-- http://www.microsoft.com/info/cpyright.htm
--<<<<<<<<<<----------------------------------------------------------------->>>>>>>>>>--
--***Instructions***
-- 1. If running the script from a remote server, change the context in SSMS to target instance
-- 2. Enable SQLCMD mode (add & click toolbar button or toggle by clicking Query > SQLCMD Mode)
-- 3. Commence execution of scripts (recommend running statements discretely to more easily remedy potential problems)
-- 4. Examine servername & temp configuration
-- 5. If necessary, 1) Replace instance name in path to reflect target instance *all throughout script*
-- 2) Modify root drives to reflect drives designated for data & log (folder creation *and* ALTER DB statements)
-- 6. Resume script execution
-- 7. If necessary, create new folders
-- 8. Modify/Add data & log files
-- 9. Recycle SQL service using sqlservermanager10.msc
--10. Examine results & if appropriate, delete original tempdb data log files
--(if they were "moved", the original files aren't automatically deleted)
--<<<<<<<<<<----------------------------------------------------------------->>>>>>>>>>--
--1. If running the script from a remote server, change the context in SSMS to target instance
--2. Enable SQLCMD mode (add & click toolbar button or toggle by clicking Query > SQLCMD Mode)
--3. Commence execution of scripts (recommend running statements discretely to more easily remedy potential problems)
--4. Examine servername & temp configuration
SELECT @@SERVERNAME
EXEC dbo.sp_helpdb tempdb
--tempdev 1 C:\tempdb.mdf PRIMARY 8192 KB Unlimited 10% data only
--templog 2 C:\templog.ldf NULL 512 KB Unlimited 10% log only
GO
--5. If necessary, 1) Replace instance name in path to reflect target instance *all throughout script*
-- 2) Modify root drives to reflect drives designated for data & log (folder creation *and* ALTER DB statements)
--6. Resume script execution
--7. If necessary, create new folders
--!!md H:\MSSQL10.<instance>
--!!md H:\MSSQL10.<instance>\MSSQL
--!!md H:\MSSQL10.<instance>\MSSQL\DATA
GO
-- 8. Modify/Add data & log files
--note: even if the out-of-box mdf is already where it needs to be,
--the first command is necessary to modify size & filegrowth
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev , FILENAME = 'H:\tempdb.mdf' , SIZE = 1024MB , FILEGROWTH = 100MB)
ALTER DATABASE tempdb ADD FILE (NAME = tempdat2 , FILENAME = 'H:\tempdat2.ndf' , SIZE = 1024MB , FILEGROWTH = 100MB)
ALTER DATABASE tempdb ADD FILE (NAME = tempdat3 , FILENAME = 'H:\tempdat3.ndf' , SIZE = 1024MB , FILEGROWTH = 100MB)
ALTER DATABASE tempdb ADD FILE (NAME = tempdat4 , FILENAME = 'H:\tempdat4.ndf' , SIZE = 1024MB , FILEGROWTH = 100MB)
ALTER DATABASE tempdb ADD FILE (NAME = tempdat5 , FILENAME = 'H:\tempdat5.ndf' , SIZE = 1024MB , FILEGROWTH = 100MB)
ALTER DATABASE tempdb ADD FILE (NAME = tempdat6 , FILENAME = 'H:\tempdat6.ndf' , SIZE = 1024MB , FILEGROWTH = 100MB)
ALTER DATABASE tempdb ADD FILE (NAME = tempdat7 , FILENAME = 'H:\tempdat7.ndf' , SIZE = 1024MB , FILEGROWTH = 100MB)
ALTER DATABASE tempdb ADD FILE (NAME = tempdat8 , FILENAME = 'H:\tempdat8.ndf' , SIZE = 1024MB , FILEGROWTH = 100MB)
GO
ALTER DATABASE tempdb MODIFY FILE (NAME = templog , FILENAME = 'I:\templog.ldf', SIZE = 512MB , FILEGROWTH = 100MB)
GO
--8b. Modify log file: modify drive & instance name to reflect designated destination for tempdb log
--!!md I:\MSSQL10.<instance>
--!!md I:\MSSQL10.<instance>\MSSQL
--!!md I:\MSSQL10.<instance>\MSSQL\DATA
GO
-- 9. Recycle SQL service in SQL Server Services node of sqlservermanager10.msc
--note, if running script from a UNC share, SSMS will report an error,
--but SQL Server Configuration Manager will open if its location is in %path%
!!sqlservermanager10.msc
--10. Examine results & if appropriate, delete original tempdb data log files
--(if they were "moved", the original files aren't automatically deleted)
EXEC dbo.sp_helpdb tempdb
--!!del C:\tempdb.mdf
--!!del C:\templog.ldf
GO
Verwenden Sie den SQL Server 2008-Aktivitätsmonitor oder die unter Überwachung SQL Server Leistung beschriebenen SQL Server 2005-Leistungsdashboardberichte, um Probleme mit Latchkonflikten zu identifizieren.
Manuelles Festlegen SQL Server Prozessaffinität
Die Option Affinität verarbeiten kann Leistungsverbesserungen in High-End-Umgebungen auf Unternehmensebene SQL Server bereitstellen, die auf Nicht-NUMA-Computern mit 16 oder mehr CPUs ausgeführt werden. Dies gilt insbesondere für BizTalk-Umgebungen mit hohem Durchsatz, in denen Konflikte mit freigegebenen Tabellen in der MessageBox-Datenbank auftreten. Da die SQL Server Computer, die in unserer Laborumgebung verwendet wurden, nicht NUMA-fähig waren und 16 Kerne hatten, haben wir zur Optimierung der Leistung die folgenden Befehle verwendet, um die Prozessaffinität festzulegen:
So legen Sie die SQL Server Prozessaffinität manuell von 0 auf 15 fest
ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 to 15
Weitere Informationen finden Sie unter ALTER SERVER CONFIGURATION (Transact-SQL).
Konfigurieren von MSDTC
Um Transaktionen zwischen SQL Server und BizTalk Server zu erleichtern, müssen Sie Microsoft Distributed Transaction Coordinator (MS DTC) aktivieren. Informationen zum Konfigurieren von MSDTC für SQL Server finden Sie im Thema Allgemeine Richtlinien zur Verbesserung der Betriebssystemleistung.
Aktivieren Sie das Ablaufverfolgungsflag T1118 als Startparameter für alle Instanzen von SQL Server
Die Implementierung des Ablaufverfolgungsflags –T1118 hilft, Konflikte in den SQL Server-Instanzen zu reduzieren, indem fast alle Zuordnungen für einzelne Seiten entfernt werden. Weitere Informationen finden Sie unter KB 328551: PRB: Parallelitätserweiterungen für die tempdb-Datenbank.
Ändern Sie die Standardeinstellungen für SQL Server nicht für den maximalen Grad an Parallelität, SQL Server Statistiken oder Neuerstellung und Defragmentierung von Datenbankindizes.
Wenn ein SQL Server instance BizTalk Server Datenbanken enthält, gibt es bestimmte SQL Server Einstellungen, die nicht geändert werden sollten. Insbesondere sollten die SQL Server maximalen Grad an Parallelität, die SQL Server Statistiken für die MessageBox-Datenbank und die Einstellungen für die Neuerstellung und Defragmentierung des Datenbankindexes nicht geändert werden. Weitere Informationen finden Sie unter SQL Server Einstellungen, die nicht geändert werden sollten.