Optimizaciones de base de datos previas a la configuración
Debido al papel fundamental que desempeña SQL Server en cualquier entorno de BizTalk Server, es de suma importancia que SQL Server configurar o ajustar para un rendimiento óptimo. Si SQL Server no está optimizado para funcionar bien, las bases de datos usadas por BizTalk Server se convertirán en un cuello de botella y el rendimiento general del entorno de BizTalk Server sufrirá. En este tema se describen varias optimizaciones de rendimiento de SQL Server que se deben seguir antes de instalar BizTalk Server y configurar las bases de datos de BizTalk Server.
Establecer unidad de asignación de archivos NTFS
SQL Server almacena sus datos en Extensiones, que son colecciones de ocho páginas físicamente contiguas de 8K o 64 KB. Por lo tanto, para optimizar el rendimiento del disco, establezca el tamaño de la unidad de asignación NTFS en 64 KB, tal y como se describe en "Procedimientos recomendados de configuración de disco" en Procedimientos recomendados de E/S de implementación previa.
Consideraciones para la versión y edición de SQL Server
Varias versiones y ediciones de SQL Server proporcionan diferentes características que pueden afectar al rendimiento de su entorno de BizTalk Server. Por ejemplo, en condiciones de alta carga, es posible que se supere el número de bloqueos de base de datos disponibles para la versión de 32 bits de SQL Server, lo que es perjudicial para el rendimiento de la solución de BizTalk. Considere la posibilidad de hospedar la base de datos de Cuadro de mensajes en una versión de 64 bits de SQL Server si experimenta errores de "bloqueo insuficiente" en el entorno de prueba. El número de bloqueos disponible es significativamente superior en la versión de 64 bits de SQL Server.
Tenga en cuenta la tabla siguiente al decidir las características del motor de base de datos que necesitará para su entorno de BizTalk. Para soluciones a gran escala y de nivel empresarial que requieren compatibilidad con la agrupación en clústeres, BizTalk Server compatibilidad con el trasvase de registros o compatibilidad con Analysis Services, necesita SQL Server Enterprise Edition para hospedar las bases de datos SQL Server.
Para obtener una lista completa de las características admitidas por las ediciones SQL Server, consulte SQL Server Ediciones y características admitidas.
Consideraciones sobre el planeamiento de bases de datos
Se recomienda hospedar las bases de datos de SQL Server en un almacenamiento rápido (por ejemplo, discos SAN rápidos o discos SCSI rápidos). Se recomienda RAID 10 (1+0) en lugar de RAID 5, ya que el raid 5 es más lento al escribir. Los discos SAN más recientes tienen cachés de memoria muy grandes, por lo que, en estos casos, la selección de raid no es tan importante. Para aumentar el rendimiento, las bases de datos y sus archivos de registro pueden residir en discos físicos diferentes.
Considere también la posibilidad de ajustar la profundidad de la cola del adaptador de bus host (HBA) si usa una red de área de almacenamiento (SAN). Esto puede afectar significativamente al rendimiento de E/S y a los valores predefinidos puede ser insuficiente para SQL Server. Las pruebas son necesarias para determinar el valor óptimo, aunque la profundidad de la cola de 64 se acepta generalmente como un buen punto de partida en ausencia de recomendaciones específicas del proveedor.
Instale el Service Pack más reciente y las actualizaciones acumulativas para SQL Server
Instale los Service Pack más recientes y las actualizaciones acumulativas más recientes para SQL Server, así como los Service Pack de .NET Framework más recientes.
Instalación de SQL Service Pack y actualizaciones acumulativas en BizTalk Server y SQL Server
Al instalar Service Pack o actualizaciones acumulativas para SQL Server, instale también el Service Pack o la actualización acumulativa en el equipo BizTalk Server. BizTalk Server usa componentes de sql Client que actualizan SQL Server Service Packs y actualizaciones acumulativas.
Considere la posibilidad de usar una unidad de estado sólido (SSD) rápida para alojar la SQL Server tembdb
Considere la posibilidad de usar una o varias unidades de disco de estado sólido (SSD) para hospedar TempDB. Las unidades SSD ofrecen importantes ventajas de rendimiento sobre las unidades de disco duro tradicionales y están disminuyendo rápidamente el precio a medida que entran en los mercados estándar. Dado que el rendimiento de TempDB suele ser un factor clave para el rendimiento general de SQL Server, el costo inicial agregado de las unidades a menudo se recuperará rápidamente por el aumento general del rendimiento SQL Server, especialmente cuando se ejecutan aplicaciones empresariales para las que el rendimiento de SQL Server es fundamental.
Considere la posibilidad de implementar la Data Warehouse de recopilación y administración de datos de SQL Server 2008 R2
SQL Server 2008 R2 admite el uso del nuevo Data Warehouse data collector and Management para recopilar datos relacionados con el rendimiento de la base de datos o el entorno para el análisis de pruebas y tendencias. El recopilador de datos conserva todos los datos recopilados en el Data Warehouse de administración especificado. Aunque esto no es una optimización del rendimiento, esto será útil para el análisis de cualquier problema de rendimiento.
Conceda a la cuenta que se usa para SQL Server el privilegio De bloqueo de páginas en memoria de Windows
Conceda el privilegio Windows Lock Pages in Memory a la cuenta de servicio SQL Server. Esto debe hacerse para evitar que el sistema operativo Windows pagina la memoria del grupo de búferes del proceso de SQL Server bloqueando la memoria asignada para el grupo de búferes en memoria física.
En nuestro entorno de laboratorio, la opción Bloquear páginas en memoria de la directiva de Windows se ha habilitado de forma predeterminada. Consulte Habilitar la opción Bloquear páginas en memoria.
Importante
Se aplican ciertas limitaciones al conceder a la cuenta de servicio de SQL Server el privilegio Páginas de bloqueo de Windows en memoria. Consulte lo siguiente:
Conceda al SE_MANAGE_VOLUME_NAME derecho a la cuenta de servicio de SQL Server
Asegúrese de que la cuenta que ejecuta el servicio SQL Server tenga el privilegio de Windows "Realizar tareas de mantenimiento de volumen" o asegúrese de que pertenece a un grupo que sí lo hace. Esto permitirá la inicialización instantánea de archivos, lo que garantizará un rendimiento óptimo si una base de datos tiene que crecer automáticamente.
Establecer memoria de servidor mínima y máxima
Los equipos que ejecutan SQL Server que hospedan las bases de datos de BizTalk Server deben dedicarse a ejecutar SQL Server. Cuando los equipos que ejecutan SQL Server que hospedan las bases de datos de BizTalk Server se dedican a ejecutar SQL Server, se recomienda que las opciones "memoria mínima del servidor" y "memoria máxima del servidor" en cada instancia de SQL Server se establezcan para especificar la cantidad fija de memoria que se va a asignar a SQL Server. En este caso, debe establecer "memoria mínima del servidor" y "memoria máxima del servidor" en el mismo valor (igual a la cantidad máxima de memoria física que SQL Server usará). Esto reducirá la sobrecarga que, de lo contrario, usaría SQL Server administrar dinámicamente estos valores. Ejecute los siguientes comandos de T-SQL en cada equipo que ejecute SQL Server para especificar la cantidad fija de memoria que se va a asignar a SQL Server:
sp_configure ‘Max Server memory (MB)’,(max size in MB)
sp_configure ‘Min Server memory (MB)’,(min size in MB)
Antes de establecer la cantidad de memoria para SQL Server, determine la configuración de memoria adecuada restando la memoria necesaria para Windows Server de la memoria física total. Esta es la cantidad máxima de memoria que puede asignar a SQL Server.
Nota
Si los equipos que ejecutan SQL Server que hospedan las bases de datos de BizTalk Server también hospedan enterprise Single Sign-On Master Secret Server, es posible que tenga que ajustar este valor para asegurarse de que haya suficiente memoria disponible para ejecutar enterprise Single Sign-On Service. No es raro ejecutar una instancia en clúster del servicio Enterprise Single Sign-On en un clúster de SQL Server para proporcionar alta disponibilidad para el servidor secreto maestro. Consulte Agrupación en clústeres del servidor secreto maestro.
Dividir la base de datos tempdb en varios archivos de datos de igual tamaño en cada instancia de SQL Server usada por BizTalk Server
Asegurarse de que los archivos de datos usados para tempdb tienen un tamaño igual es fundamental porque el algoritmo de relleno proporcional usado por SQL Server se basa en el tamaño de los archivos de datos. Si los archivos de datos se crean con tamaños diferentes, el algoritmo de relleno proporcional usará el archivo más grande para las asignaciones de GAM en lugar de distribuir las asignaciones entre todos los archivos, lo que anulará el propósito de crear varios archivos de datos. El número óptimo de archivos de datos tempdb depende del grado de contención de bloqueo temporal que se ve en tempdb. Como regla general, el número de archivos de datos debe ser igual al número de núcleos o CPU del procesador donde el número de CPU es 8 o menos. En el caso de los servidores con más de 8 CPU, cree archivos de datos para la mitad del número de CPU (de nuevo, solo tiene contención de bloqueo temporal).
En nuestro entorno de laboratorio, usamos el script siguiente para crear 8 archivos de datos TempDB cada uno de los cuales tenía un tamaño de archivo de 1024 MB con un crecimiento de 100 MB y un archivo de registro de 512 MB con un crecimiento de 100 MB. Los archivos de datos se mueven a la unidad H: y el archivo de registro se mueven a la unidad I:.
Importante
Este script se proporciona "tal cual", está pensado solo para fines educativos o de demostración, y se usará en su propio riesgo. Microsoft no admite el uso de este script y Microsoft no garantiza la idoneidad de este script.
--<<<<<<<<<<----------------------------------------------------------------->>>>>>>>>>--
-- 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
Use el Monitor de actividad de SQL Server 2008 o los informes del panel de rendimiento de SQL Server 2005 descritos en Supervisión SQL Server rendimiento para identificar problemas con la contención de bloqueos temporales.
Establecer manualmente la afinidad de proceso de SQL Server
La opción Afinidad de proceso puede proporcionar mejoras de rendimiento en entornos de SQL Server de alto nivel empresarial que se ejecutan en equipos que no son NUMA con 16 CPU o más. Esto es especialmente cierto en entornos de BizTalk de alto rendimiento en los que tiene contención en tablas compartidas en la base de datos MessageBox. Dado que los equipos SQL Server que se usaron en nuestro entorno de laboratorio no estaban habilitados para NUMA y tenían 16 núcleos, para optimizar el rendimiento, usamos los siguientes comandos para establecer la afinidad de proceso:
Para establecer manualmente la afinidad de proceso de SQL Server de 0 a 15
ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 to 15
Para obtener más información, vea ALTER SERVER CONFIGURATION (Transact-SQL).
Configuración de MSDTC
Para facilitar las transacciones entre SQL Server y BizTalk Server, debe habilitar el Coordinador de transacciones distribuidas de Microsoft (MS DTC). Para configurar MSDTC en SQL Server, consulte el tema Directrices generales para mejorar el rendimiento del sistema operativo.
Habilite la marca de seguimiento T1118 como parámetro de inicio para todas las instancias de SQL Server
La implementación de la marca de seguimiento –T1118 ayuda a reducir la contención en las instancias de SQL Server mediante la eliminación de casi todas las asignaciones de página única. Para más información, consulte KB 328551: PRB: Mejoras de simultaneidad para la base de datos tempdb.
No cambie la configuración predeterminada de SQL Server para el grado máximo de paralelismo, las estadísticas de SQL Server ni las recompilaciones y la desfragmentación del índice de base de datos.
Si una instancia de SQL Server hospedará bases de datos BizTalk Server, hay ciertas configuraciones de SQL Server que no deben cambiarse. En concreto, el SQL Server grado máximo de paralelismo, las estadísticas de SQL Server en la base de datos messageBox y la configuración de la recompilación y desfragmentación del índice de la base de datos no deben modificarse. Consulte SQL Server configuración que no se debe cambiar.
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de