Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Debido al rol fundamental que desempeña SQL Server en cualquier entorno de BizTalk Server, es de suma importancia que SQL Server se configure o ajuste para lograr 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 deben seguirse 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 unidad de asignación NTFS en 64 KB, tal 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 características diferentes 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 alojar la base de datos de MessageBox en una versión SQL Server de 64 bits si experimenta errores de "falta de bloqueo" en el entorno de pruebas. El número de bloqueos disponibles es significativamente mayor 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 que requieren compatibilidad con la agrupación en clústeres, compatibilidad con el trasvase de registros de BizTalk Server o compatibilidad con Analysis Services, necesita SQL Server Enterprise Edition para hospedar las bases de datos de SQL Server.
Para obtener una lista completa de las características compatibles con las ediciones de SQL Server, vea Ediciones de SQL Server y características admitidas.
Consideraciones de planeación de bases de datos
Se recomienda hospedar las bases de datos de SQL Server en 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 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 los valores predeterminados pueden ser insuficientes 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.
Instalación del Service Pack más reciente y actualizaciones acumulativas para SQL Server
Instale los service packs más recientes y las actualizaciones acumulativas más recientes de SQL Server, así como los service packs de .NET Framework más recientes.
Instalación de SQL Service Packs y actualizaciones acumulativas en BizTalk Server y SQL Server
Al instalar Service Packs o actualizaciones acumulativas para SQL Server, instale también el Service Pack o la actualización acumulativa en el equipo de BizTalk Server. BizTalk Server usa componentes de cliente SQL actualizados por service packs de SQL Server y actualizaciones acumulativas.
Considere la posibilidad de usar una unidad de estado sólido (SSD) rápida para hospedar el tembdb de SQL Server
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 de SQL Server, especialmente cuando se ejecutan aplicaciones empresariales para las que el rendimiento de SQL Server es crítico.
Considere la posibilidad de implementar el recopilador de datos de SQL Server 2008 R2 y el almacenamiento de datos de administración
SQL Server 2008 R2 admite el uso del nuevo recopilador de datos y almacenamiento de datos de administración 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 almacén de administración de datos especificado. Aunque esto no es una optimización del rendimiento, esto será útil para el análisis de cualquier problema de rendimiento.
Conceder a la cuenta que se usa para SQL Server el privilegio "Bloquear páginas en memoria" de Windows
Conceda el privilegio Bloquear páginas en memoria de Windows a la cuenta de servicio de SQL Server. Esto debe hacerse para evitar que el sistema operativo Windows pagine la memoria del grupo de búferes del proceso de SQL Server fijando 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. Vea lo siguiente:
Conceder 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 tiene 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 garantiza un rendimiento óptimo si una base de datos tiene que crecer automáticamente.
Establecer memoria mínima y máxima del servidor
Los equipos que ejecutan SQL Server que hospedan las bases de datos de BizTalk Server deben estar dedicados a ejecutar SQL Server. Cuando los equipos que ejecutan SQL Server que hospedan las bases de datos de BizTalk Server están dedicados 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 estén establecidas 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 usará SQL Server). Esto reducirá la sobrecarga que SQL Server consumiría al administrar estos valores dinámicamente. 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 hay suficiente memoria disponible para ejecutar el servicio Enterprise Single Sign-On. No es infrecuente 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 Maestro de Secretos. 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 crítico 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 desiguales, 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 anula 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 visto en tempdb. Como regla general general, el número de archivos de datos debe ser igual al número de núcleos de procesador o CPU donde el número de CPU es 8 o menos. En el caso de los servidores con más de 8 CPUs, cree archivos de datos para la mitad de las CPUs (de nuevo, solo si tiene contención de bloqueos).
En nuestro entorno de laboratorio, usamos el siguiente script 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 de demostración o educativos, y se va a 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
Utilice el Monitor de actividad de SQL Server 2008 o los informes del Panel de rendimiento de SQL Server 2005 descritos en Supervisión del rendimiento de SQL Server para identificar problemas con la contención de pestillos.
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 donde hay competencia por las tablas compartidas en la base de datos MessageBox. Dado que los equipos de 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 comandos siguientes 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.
Habilitar la marca de seguimiento T1118 como parámetro de inicio para todas las instancias de SQL Server
La implementación del indicador de seguimiento –T1118 ayuda a reducir la contención en las instancias de SQL Server al eliminar casi todas las asignaciones de páginas únicas. Para obtener 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, estadísticas de SQL Server o recompilaciones y desfragmentación de índices de base de datos
Si una instancia de SQL Server hospedará bases de datos de BizTalk Server, hay cierta configuración de SQL Server que no se debe cambiar. En concreto, el grado máximo de paralelismo de SQL Server, 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 base de datos no deben modificarse. Consulte Configuración de SQL Server que no se debe cambiar.