Preguntas y respuestas acerca de SQLConfiguración de la memoria, elaboración de perfiles de rendimiento, configuración del factor de relleno y mucho más

Editado por Nancy Michell

Configuración de la memoria

Sugerencia: Elaboración de perfiles más sencilla

¿Sabía que es posible ahora correlacionar PerfMon con el Analizador de SQL Server 2005?

Quizás haya advertido incrementos bruscos de uso de la CPU, un consumo de memoria excesivo, un rendimiento general lento en el monitor de rendimiento de su equipo de SQL Server y se ha preguntado qué ha provocado estas anomalías de rendimiento. Antes de SQL Server 2005, tenía que usar el Analizador para capturar una traza, después observar los procesos de sistema en Enterprise Manager y por último capturar los registros de rendimiento (que, por supuesto, le obligaban a iniciar PerfMon). A pesar de todo este trabajo con todas estas herramientas, necesitaba reconciliar de manera manual eventos entre las herramientas para averiguar por qué el rendimiento se había visto afectado. Y esto implicaba avanzar muy lentamente a través de cada uno de los registros. No era en absoluto divertido, pero si necesario si deseaba llegar hasta el fondo de sus problemas de rendimiento.

Con SQL Server 2005, sigue siendo necesario capturar una traza y examinar los registros de PerfMon, pero ahora el Analizador le permite adjuntarlos. Puede desplazarse por las instrucciones de T-SQL y el Analizador le mostrará automáticamente, de manera gráfica, lo que ha ocurrido. Si hace clic en la interfaz de usuario del monitor de rendimiento en el Analizador, pasará a la instrucción que se correlaciona con esa marca de hora. Esto ahorra grandes cantidades de tiempo en la solución de problemas en su entorno de SQL Server.

Veamos ahora cómo adjuntar registros de PerfMon al Analizador:

1. Inicie el monitor de rendimiento y comience a capturar información del servidor de la base de datos.
2. Cree un nuevo registro del contador en Registros y alertas de rendimiento y escriba un nombre para su nuevo registro.
3. Agregue nuevos contadores, como % de tiempo de procesador. Deseará igualmente configurar su registro para que se inicie manualmente o según un programa mediante la ficha Programación.
4. Haga clic en Aceptar y, si ha elegido la opción manual, asegúrese de iniciar el registro.
5. Configure una traza en SQL Server a través del Analizador. Puede hacerlo haciendo clic en Nueva traza en el menú Archivo. Asegúrese de incluir la Hora de inicio y la Hora de finalización en la traza, a continuación, dé un nombre a la traza y configúrela para guardarla en un archivo. En último lugar, debe poner en funcionamiento el servidor para simular cierta actividad de transacción, a continuación, deje de capturar tanto el monitor de rendimiento como los datos del Analizador.
6. En el Analizador, seleccione Importar datos de rendimiento en el menú Archivo. A continuación, escoja la ubicación en la que almacenó su registro de PerfMon y seleccione Archivo | Abrir | Traza. Finalmente, seleccione la ubicación en la que almacenó la traza del Analizador.

Cuando esté listo, verá lo sencillo que es averiguar qué efecto particular han tenido las instrucciones SQL en el tiempo de procesamiento.

P Intento averiguar la mejor configuración de memoria para mis cuadros de SQL Server™. El administrador anterior configuró Boot.ini para cada equipo con 12 GB de RAM en un clúster de dos nodos de SQL Server 2000 de la siguiente manera: Yes /PAE NO /3GB (Sin AWE configurado para SQL Server). Con 12 GB de RAM disponibles, ¿debo quitar el conmutador /3GB de Boot.ini, activar AWE y dar a SQL Server unos 10 GB de los 12 GB? No hay nada más en los equipos que ejecutan SQL Server, por lo que ninguna otra aplicación necesita memoria.

R Sí, debe activar las direcciones de ventana de dirección (AWE) y asignar previamente un límite superior de RAM para SQL Server, 10 GB está bien para un cuadro dedicado de SQL Server de 12 GB. (Tenga en cuenta que la asignación previa sólo es válida para SQL Server 2000. El inicio con SQL Server 2005, mediante AWE, ya no es estático y puede cambiarse sobre la marcha.) Siempre ha habido un gran debate en cuanto a si usar los conmutadores /3GB y /PAE simultáneamente o sólo el conmutador /PAE. Aunque sólo necesita configurar el conmutador /PAE y tener activada la AWE, le sugiero que use ambos conmutadores; sin embargo, hay algunos factores de debe considerar.

El uso del conmutador /3GB se reduce a si es necesario en su situación particular. ¿Se está quedando sin las áreas de memoria MemToLeave que deben estar en los primeros 2 ó 3 GB del espacio de direcciones virtual? Si habilita el conmutador, ¿está privando de memoria el sistema operativo? (Para obtener más información consulte support.microsoft.com/kb/316739). Si está trabajando en un clúster, podría configurar /3GB en un nodo en particular. De ese modo, si está realizando pruebas con /3GB y está teniendo problemas, puede conmutar la instancia por error en otro nodo muy rápidamente. Tenga en cuenta que si tiene más de 16 GB de RAM, el conmutador /3GB no es compatible.

Mediante /3GB, aumenta el espacio de direcciones virtual (VAS) en un 50%, así que las aplicaciones que colocan la demanda de memoria en VAS y no sólo en la memoria caché de datos se benefician ampliamente. Afortunadamente, los servidores de 64 bits, tanto IA64 como x64, eliminan ese factor mal comprendido. Las inquietudes que surgen de privar de recursos al SO no son aplicables si el equipo está dedicado a SQL Server. Dejar tan sólo 2 GB para el sistema operativo es un poco excesivo; si este servidor está dedicado a SQL Server con sólo los servicios mínimos estándar de sistema operativo en ejecución, observará que hay unos 1,3 GB de memoria libre en el servidor, por lo que puede permitir a SQL Server usar el GB extra. Comience con 10 GB, use PerfMon para supervisar la memoria disponible durante un período largo para consultar el tiempo de inactividad y, a continuación, realizar el ajuste correspondiente. Recuerde que provocará intercambios si realiza confirmaciones en exceso en SQL Server 2000, puesto que AWE no es en este caso tan dinámica como lo es con SQL Server 2005. La clave para decidir si usar el conmutador /3GB es probarlo en su entorno específico.

Nombres de instancia para la réplica

P ¿Puedo usar ahora la dirección IP de mi servidor en la réplica de SQL Server 2005 para indicar qué instancia replicar? En SQL Server 2000, según "Cómo realizar réplicas entre equipos que ejecutan SQL Server en dominios no confiables o a través de Internet" (support.microsoft.com/kb/321822), el hacerlo provocará errores, pero no sé con seguridad si sigue siendo cierto.

R Al especificar las instancias de servidor para participar en la réplica, debe suministrar el nombre de instancia registrado de SQL Server. Por ejemplo, debe usar el nombre de instancia de SQL Server al especificar los parámetros Publisher o Subscriber para los procedimientos de réplica almacenados o para la configuración de la conexión del agente de réplica en la línea de comandos. Si el nombre de red para la instancia de SQL Server difiere del nombre de instancia registrado, las conexiones de réplica por agentes tendrán errores.

Si el nombre de red de la instancia y el nombre de instancia de SQL Server difiere, considere agregar el nombre de instancia de SQL Server como un nombre válido de red. Una manera de configurar un nombre de red alternativo es agregarlo al archivo host local. El archivo host local se ubica de manera predeterminada en WINDOWS\system32\drivers\etc o WINNT\system32\drivers\etc. Por ejemplo, si el nombre del equipo es comp1, el equipo tiene una dirección IP 10.193.17.129 y el nombre de la instancia es inst1/instname, agregue la entrada siguiente al archivo host:

10.193.17.129 inst1

SQL Server Integration Services

P Estoy instalando un clúster activo/activo para SQL Server 2005 (Enterprise Edition 64 bit con dos servidores) y tendré un total de cuatro instancias de SQL Server 2005. SQL Server Integration Services (SSIS) será necesario para todas las instancias. ¿Qué me puede decir acerca de la agrupación de SSIS y el efecto en los planes de mantenimiento?

R Aunque puede agrupar el servicio SSIS, no es necesario hacerlo pues podría encontrar gran cantidad de problemas, incluidos una falta de compatibilidad para la delegación (consulte msdn2.microsoft.com/aa337083) y que no tiene varias instancias, sólo es posible ejecutar una instancia en un nodo al mismo tiempo.

Anteriormente, era necesario instalar SSIS, no ejecutarlo, sólo instalarlo, para que se ejecutara el Asistente para planes de mantenimiento. Sin embargo, éste no es el caso en SQL Server 2005 SP1. Si SSIS no se ejecuta, los planes de mantenimiento pueden ejecutarse gracias al Agente SQL Server.

Mejor que agrupar SSIS, puede considerar mantenerlo en ejecución como servicio independiente y editar MsDtsSrvr.ini.xml para señalar a cualquier instancia en ejecución. Esto le permite administrar sus paquetes desde cualquier nodo y proporcionar la alta disponibilidad que la mayoría de los clientes están buscando sin ninguno de los problemas asociados con la agrupación del servicio.

Para obtener más información acerca de la creación de planes de mantenimiento con error, asegúrese de consultar el artículo de Knowledge Base en support.microsoft.com/kb/909036.

Tiempo de ejecución extraño

P Durante la prueba de carga en mi cuadro SQL Server 2005 SP1, el Analizador de SQL Server registró muchos valores negativos del tiempo de procedimiento del procedimiento almacenado (SP) y, en algunos casos, el tiempo de ejecución de SP, no coincidió con el resultado de restar la hora de inicio a la hora de finalización.

R Hay una serie de factores que pueden afectar a la generación de informes de la hora de ejecución de SP y otros tiempos de rendimiento en el Analizador de SQL Server. Recuerde, SQL Server 2005 usa milisegundos para contar el tiempo de ejecución y si usa cualquier tecnología que cambie la unidad de medida, sufrirá incoherencias en los tiempos de generación de informes y de ejecución que no se agregan.

Por ejemplo, si usa otras combinaciones de energía, escalonamiento de la CPU o la tecnología AMD Cool'n Quiet, cambia las frecuencias de la CPU, que después no coincidirán con lo que el Analizador de SQL Server espera al calcular el tiempo de ejecución.

Hay un artículo de Knowledge Base en support.microsoft.com/kb/931279 que explica los síntomas, una variedad de causas y algunos remedios.

Sugerencia: Compruebe su factor de relleno

Supongamos que tiene un vaso lleno completamente de agua e intenta poner más agua en ese vaso. ¿Qué sucede? El agua se desborda.

Ocurre lo mismo con SQL Server. Siempre que se agrega una fila a una página de índice completa, SQL Server mueve aproximadamente la mitad de las filas a una nueva página para dejar espacio a una nueva. Esto se denomina división de página. Las divisiones de página dejan espacio a nuevos registros, pero también tardan mucho y consumen muchos recursos. Y pueden provocar fragmentación, lo cual puede afectar de manera negativa a las operaciones de E/S. Así pues, ¿cómo las puede evitar?

Para evitar dichas situaciones, debe determinar de manera proactiva el valor del factor de relleno. Cuando se crea o reconstruye un índice, el valor del factor de relleno determina el porcentaje del espacio en cada página de nivel de hoja que se va a rellenar con datos, conservando el resto para un crecimiento futuro. Por ejemplo, configurar un valor de factor de relleno de 60 significa que el 40% de cada página de nivel de hoja se dejará vacío para facilitar la expansión del índice a medida que se agreguen datos a la tabla subyacente.

El valor predeterminado del factor de relleno es siempre 0, lo cual es correcto para la mayoría de las situaciones. Básicamente, un factor de relleno de 0 implica que el nivel de hoja se rellena casi hasta su capacidad, pero que se deja cierto espacio para al menos una fila de índice adicional. (Tenga en cuenta que un factor de relleno de 0 y 100 es similares.)

Puede configurar el valor del factor de relleno para índices individuales durante una instrucción CREATE INDEX o ALTER INDEX, o puede configurar este valor directamente en el nivel de servidor para que cualquier índice nuevo creado use el valor predeterminado.

El ejemplo siguiente configura el valor del factor de relleno en el nivel del servidor en 70%, lo cual implica que dispone de un 30% de espacio disponible para una futura expansión. Por supuesto, debe probar con cuidado esta opción antes de implementarla en un entorno de producción.

USE Master;
GO
SP_Configure 'show advanced options',1;
GO
SP_Configure 'Fill Factor', 70;
GO
--You must restart SQL Server Engine for changes to take effect.

¿Qué ocurre si desea configurar el factor de relleno en el nivel del índice individual? Asuma que crea la tabla siguiente y que desea crear un índice único en la columna llamada Col_A con un valor de factor de relleno de 70. El comando tendría este aspecto:

--Create an Item table
USE Item_DB;
GO
CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200));
GO;

--Create a unique index on colum Col_A of Item table with a Fill Factor value of 70
CREATE UNIQUE INDEX AK_Index ON Item (Col_A)
WITH (FillFactor = 70);
GO

¿Cómo es posible identificar el factor de relleno de cada índice? Puede consultar los sys.Indexes para obtener el valor del factor de relleno de todos los índices de la base, de este modo:

USE Item_DB;
GO
SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL;
GO

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.