Postconfiguration des optimisations des bases de données
En plus de suivre les recommandations des optimisations de base de données de préconfiguration2, plusieurs étapes doivent être suivies pour optimiser les performances de BizTalk Server base de données sur SQL Server après l’installation de BizTalk Server et la configuration des bases de données BizTalk Server. Cette rubrique fournit une liste de ces optimisations.
Envisagez de définir l’option de table « texte dans la ligne » sur des tables de base de données MessageBox spécifiques
SQL Server fournit une option de table appelée text in row pour déclarer que le contenu des champs de type text, ntext ou image dont les dimensions sont inférieures à celles d’une page de données (8 Ko) doit être stocké dans une ligne de données. En définissant cette option sur les tables BizTalkMsgBoxDb (table Parts, Table Spool et Tables DynamicStateInfo), vous pouvez augmenter le débit des messages lorsque vous travaillez avec de petits messages qui ont un petit contexte et des orchestrations qui ont une petite taille de persistance.
Table de parties : lorsque la taille du message est inférieure aux dimensions d’une page de données qui sont de 8 Ko, l’application de l’option de table texte dans les lignes de la table Parties peut entraîner une amélioration des performances BizTalk Server. La table Parts contient les champs suivants :
ImgPart : contient une partie de message ou un fragment de partie de message.
ImgPropBag : contient le conteneur de propriétés de partie de message.
De cette façon, lors d’une boucle sur messageBox, l’agent de message s’exécutant dans un hôte BizTalk peut récupérer un lot de messages de la table Parts en lisant une petite quantité de pages. En fonction du scénario et de la configuration matérielle spécifiques, cette technique peut réduire l’utilisation du processeur à la fois sur le SQL Server et la BizTalk Server, et apporter une amélioration significative en termes de latence et de débit.
Table Spool : lorsque la taille moyenne du contexte de message est inférieure à 8 Ko, l’activation de l’option de table texte dans les lignes sur la table Spool vous permet de réduire le nombre d’accès lors de la lecture des messages à partir de MessageBox, ainsi que leur contexte. Pour appliquer cette option à la table Spool, vous devez éliminer les propriétés de contexte inutiles et les champs distingués afin de réduire la taille du contexte de message inférieure à 8 Ko.
Tables DynamicStateInfo Ces tables, une pour chaque hôte, contiennent un champ d’image de type appelé imgData qui contient un état d’orchestration sérialisé binaire lorsqu’elles rencontrent un point de persistance pendant leur exécution. Lorsque l’état interne des orchestrations au sein d’un hôte HostA est si petit que sa taille une fois sérialisée est inférieure à 8 Ko, la technique de texte en ligne peut être appliquée avec succès à la table DynamicStateInfo_HostA. Par conséquent, nous vous recommandons de conserver l’état interne des orchestrations aussi petit que possible. Cette technique peut réduire considérablement le temps passé par le moteur XLANG à sérialiser, conserver, désérialiser et restaurer l’état interne d’une orchestration en cas de point de persistance.
Nous avons utilisé les paramètres suivants dans nos tests lab :
EXEC sp_tableoption N’Spool', 'text in row', '6000'
EXEC sp_tableoption N’Parts', 'text in row', '6000'
Définir des paramètres de croissance automatique pour BizTalk Server bases de données à une valeur fixe au lieu d’une valeur de pourcentage
SQL Server croissance automatique de la base de données est une opération bloquante, qui entrave BizTalk Server performances de la base de données. Par conséquent, il est important d’allouer suffisamment d’espace pour les bases de données BizTalk Server à l’avance afin de réduire la croissance automatique de la base de données.
La croissance automatique de la base de données doit être définie sur un nombre fixe de mégaoctets au lieu d’un pourcentage (spécifiez la croissance des fichiers en mégaoctets). Cela devrait être fait de sorte que, si la croissance automatique se produit, elle le fait de manière mesurée. Cela réduit la probabilité d’une croissance excessive de la base de données. L’incrément de croissance des bases de données BizTalk Server ne doit généralement pas être inférieur à 100 Mo.
Prédimensionner BizTalk Server bases de données à une taille appropriée avec plusieurs fichiers de données
Lorsque SQL Server augmente la taille d’un fichier, il doit d’abord initialiser le nouvel espace avant de pouvoir l’utiliser. Il s’agit d’une opération bloquante qui implique de remplir le nouvel espace avec des pages vides. SQL Server version 2005 ou ultérieure s’exécutant sur Windows Server 2003 ou version ultérieure prend en charge l’initialisation instantanée des fichiers. Cette fonctionnalité peut considérablement réduire l’impact sur les performances d’une opération de croissance de fichiers. Pour plus d’informations, consultez Initialisation instantanée de fichier de base de données, qui fournit les étapes d’activation de l’initialisation instantanée des fichiers.
La liste suivante décrit les configurations de base de données BizTalk Server utilisées dans nos tests lab :
BizTalk DTADB (fichiers de base de données de suivi BizTalk) : Fichier de données d’une taille de fichier de 2 048 Mo avec une croissance de 100 Mo et un fichier journal de 1 024 Mo avec une croissance de 100 Mo.
BizTalkMgmtdb (fichiers de base de données de gestion BizTalk) : Fichier de données d’une taille de fichier de 512 Mo avec une croissance de 100 Mo et d’un fichier journal de 512 Mo avec une croissance de 100 Mo.
SSODB : Fichier de données d’une taille de fichier de 512 Mo avec une croissance de 100 Mo et d’un fichier journal de 512 Mo avec une croissance de 100 Mo.
BizTalkMsgBoxDb (bases de données BizTalk MessageBox) : 8 fichiers de données, chacun ayant une taille de fichier de 2 Go avec une croissance de 100 Mo et un fichier journal de 20 Go avec une croissance de 100 Mo. Étant donné que les bases de données MessageBox BizTalk sont les plus actives, nous vous recommandons de placer les fichiers de données et les fichiers journaux des transactions sur des lecteurs dédiés pour réduire la probabilité de problèmes liés à la contention d’E/S de disque. Dans notre environnement lab, nous avons utilisé un lecteur pour chacun des éléments suivants :
Fichiers de données MessageBox
Fichiers journaux des transactions MessageBox
Le script SQL suivant peut être utilisé pour prédimensionner BizTalkMsgBoxDb qui a initialement un fichier de données sur le lecteur J (J :\BizTalkMsgBoxDb.mdf) et un fichier journal sur le lecteur K (K :\BizTalkMsgBoxDb_log. LDF) :
Important
Ce script est fourni « tel quel », est destiné à des fins de démonstration ou d’éducation uniquement, et doit être utilisé à vos propres risques. L’utilisation de ce script n’est pas prise en charge par Microsoft, et Microsoft n’offre aucune garantie quant à l’adéquation de ce 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
Déplacer le répertoire de sortie backup BizTalk Server vers un numéro d’unité logique dédié
Déplacez le répertoire de sortie nommé Sauvegarde BizTalk (sauvegarde complète et sauvegarde du journal) vers un numéro d’unité logique dédié.
Modifiez le travail nommé Backup BizTalk Server pour qu’il pointe vers le numéro d’unité logique dédié.
La première étape réduit la contention d’E/S de disque lorsque le travail est en cours d’exécution en écrivant sur un disque différent de l’emplacement de lecture du travail. Pour plus d’informations, consultez Configurer le travail de BizTalk Server de sauvegarde.
Vérifier que les travaux BizTalk Server SQL Agent sont en cours d’exécution
Dans BizTalk Server, plusieurs travaux SQL Server Agent exécutent des fonctions importantes qui maintiennent vos serveurs opérationnels et sains. Assurez-vous que vous surveillez l’intégrité de ces travaux et qu’ils s’exécutent sans erreurs. L’une des causes courantes des problèmes de performances BizTalk Server est que lorsque les travaux BizTalk Server SQL Agent ne sont pas en cours d’exécution, les bases de données MessageBox et Tracking peuvent croître sans avoir été cochées. Pour vous assurer que les travaux BizTalk Server SQL Agent s’exécutent sans problème, procédez comme suit :
Vérifiez que le service SQL Server Agent est en cours d’exécution.
Vérifiez que les travaux SQL Server Agent installés par BizTalk Server sont activés et s’exécutent correctement. Les BizTalk Server SQL Server Agent travaux sont essentiels : s’ils ne sont pas en cours d’exécution, les performances du système se dégradent au fil du temps.
Vérifiez que les travaux BizTalk Server SQL Server Agent se terminent en temps opportun. Configurez la version la plus récente de Microsoft System Center Operations Manager pour surveiller les travaux. Vous devez connaître les planifications qui sont spécifiques à certains travaux :
Le travail MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb s’exécute en continu par défaut. Les logiciels de surveillance doivent prendre en compte cette planification et ne pas générer d’avertissements.
Le travail MessageBox_Message_Cleanup_BizTalkMsgBoxDb n’est pas activé ou planifié, mais il est démarré par le MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb travail toutes les 10 secondes. Par conséquent, ce travail ne doit pas être activé, planifié ou démarré manuellement.
Vérifiez que le type de démarrage du service SQL Server Agent est correctement configuré. Vérifiez que le service SQL Server Agent est configuré avec le type de démarrageAutomatique, sauf si le service SQL Server Agent est configuré en tant que ressource de cluster sur un cluster Windows Server. Si le service SQL Server Agent est configuré en tant que ressource de cluster, vous devez configurer le type de démarragemanuel, car le service sera géré par le service cluster.
Configurer le vidage et l’archivage des données de suivi
Pour vous assurer que vous configurez correctement le vidage et l’archivage des données de suivi, procédez comme suit :
Assurez-vous que le travail sql Agent nommé Purge et archivage DTA est correctement configuré, activé et terminé correctement.
Pour plus d’informations, consultez Configurer le travail de vidage et d’archivage DTA.
Assurez-vous que le travail peut vider les données de suivi aussi rapidement que les données de suivi entrantes sont générées.
Pour plus d’informations, consultez Mesure du débit maximal de suivi durable.
Passez en revue les paramètres de vidage réversible et de vidage dur pour vous assurer que vous conservez les données pendant la durée optimale.
Pour plus d’informations, consultez Archiver et vider la base de données de suivi BizTalk.
Si vous avez seulement besoin de vider les anciennes données et que vous n’avez pas besoin d’archiver d’abord, modifiez le travail SQL Agent pour appeler la procédure stockée nommée dtasp_PurgeTrackingDatabase.
Pour plus d’informations, consultez Vider les données de la base de données de suivi BizTalk.
Surveiller et réduire la contention d’E/S du disque de fichier journal DTC
Le fichier journal DTC (Distributed Transaction Coordinator) peut devenir un goulot d’étranglement d’E/S disque dans les environnements gourmands en transactions. Cela est particulièrement vrai lorsque vous utilisez des adaptateurs qui prennent en charge des transactions, telles que SQL Server, MSMQ ou MQSeries, ou dans un environnement multi-MessageBox. Les adaptateurs transactionnels utilisent des transactions DTC, et les environnements multi-MessageBox utilisent largement les transactions DTC. Pour vous assurer que le fichier journal DTC ne devient pas un goulot d’étranglement des E/S de disque, vous devez surveiller l’utilisation des E/S de disque pour le disque où le fichier journal DTC réside sur les serveurs de base de données SQL Server. Si l’utilisation des E/S de disque pour le disque où réside le fichier journal DTC devient excessive, envisagez de déplacer le fichier journal DTC vers un disque plus rapide. Dans un environnement où SQL Server est en cluster, ce n’est pas autant un problème, car le fichier journal se trouve déjà sur un lecteur partagé, qui sera probablement un lecteur SAN rapide avec plusieurs broches. Vous devez néanmoins toujours surveiller l’utilisation des E/S du disque. En effet, il peut devenir un goulot d’étranglement dans les environnements non cluster ou lorsque le fichier journal DTC se trouve sur un disque partagé avec d’autres fichiers gourmands en disque.
Séparer les bases de données MessageBox et Tracking
Étant donné que les bases de données BizTalk MessageBox et BizTalk Tracking sont les plus actives, nous vous recommandons de placer les fichiers de données et les fichiers journaux des transactions pour chacun d’entre eux sur des lecteurs dédiés afin de réduire la probabilité de problèmes liés à la contention d’E/S de disque. Par exemple, vous avez besoin de quatre lecteurs pour les fichiers de base de données MessageBox et BizTalk Tracking, un lecteur pour chacun des éléments suivants :
Fichiers de données MessageBox
Fichiers journaux des transactions MessageBox
Fichiers de données de suivi BizTalk (DTA)
Fichiers journaux des transactions BizTalk Tracking (DTA)
La séparation des bases de données BizTalk MessageBox et BizTalk Tracking et la séparation des fichiers de base de données et des fichiers journaux des transactions sur différents disques physiques sont considérées comme des meilleures pratiques pour réduire la contention d’E/S de disque. Essayez de répartir les E/S du disque sur autant de broches physiques que possible. Vous pouvez également réduire la contention d’E/S disque en plaçant la base de données BizTalk Tracking sur un SQL Server dédié. Toutefois, vous devez toujours suivre les pratiques ci-dessus en ce qui concerne la séparation des fichiers de données et des fichiers journaux des transactions.
Optimiser les groupes de fichiers pour les bases de données BizTalk Server
Suivez les étapes décrites dans Optimisation des groupes de fichiers pour les bases de données2 et Optimisation des performances des bases de données pour créer des groupes de fichiers et des fichiers supplémentaires pour les bases de données BizTalk Server. Cela augmentera considérablement les performances des bases de données BizTalk Server à partir d’une configuration de disque unique.