Diagnosticar y resolver errores de servidor

Transcripción

1 Diagnosticar y resolver errores de servidor SQL Server registra determinados eventos del sistema y definidos por el usuario en el registro de errores de SQL Server y en el registro de aplicación de Windows. Ambos registros marcan automáticamente la fecha y hora de todos los eventos registrados. Debemos utilizar la información del registro de errores de SQL Server para solucionar problemas relacionados con el motor de base de datos. El registro de aplicación de Windows nos proporciona una visión global de los eventos que tienen lugar en el sistema operativo, así como de los eventos de SQL Server y del Agente de SQL Server. Esta herramienta nos permitirá filtrar la información, como eventos de información, advertencia, error, auditoría de éxito o auditoría de error. Podemos utilizar tanto el registro de errores de SQL Server como el registro de aplicación de Windows para identificar la causa de cualquier problema de nuestro servidor de base de datos. Por ejemplo, mientras estamos supervisando el registro de errores de SQL Server, podemos encontrar mensajes de error que no tienen información sobre su causa. Podemos acotar la lista de causas probables si se comparan las fechas y horas de los eventos en ambos registros. El Visor de archivo de registros del Management Studio nos permite integrar los registros de SQL Server, el Agente de SQL Server y el registro de Windows en una única lista, facilitándonos el análisis de los eventos de servidor y los eventos de SQL Server relacionados.

2 Despliegue y Mantenimiento de Bases de datos con SQL Server 2008 Alhambra Eidos Registro de SQL Server El registro de errores de SQL Server nos permite comprobar el estado de todos los procesos. A través de él podemos ver el estado de los procesos completados, y así comprobar si estos se han completado con éxito, como por ejemplo operaciones de copia de seguridad y restauración, comandos de un proceso por lotes u otras secuencias de comandos o procesos. Esto nos puede resultar muy útil para detectar áreas con problemas actuales o posibles, incluido los mensajes de recuperación automática, mensajes del núcleo, etc. Para ver el registro de errores de SQL Server podemos utilizar el SQL Server Management Studio o cualquier otra herramienta de proceso de textos. De manera predeterminada, el registro de errores está ubicado en los archivos de la instancia de SQL Server, en la carpeta LOG. Cada vez que se inicia una instancia de SQL Server se crea un registro de errores, pero se puede utilizar el procedimiento almacenado sp_cycle_errorlog para reciclar archivos de registro de errores sin tener que reiniciar la instancia de SQL Server. Normalmente, SQL Server conserva copias de seguridad de los últimos seis registros y asigna a la copia de seguridad del registro más reciente la extensión.1, a la segunda la extensión.2, y así sucesivamente. El registro de errores actual no tiene ninguna extensión. Figura 1 Para ver el registro de errores desde el Management Studio, debemos expandir árbol del nodo Administración en el Explorador de objetos, y a continuación expandir el nodo Registros de SQL Server (Figura 1). En ese elemento veremos los siete archivos de registro de SLQ Server. Para abrir el visor del archivo de registro sólo tenemos que hacer click derecho sobre cualquiera de los archivos de registro de SQL Server y escoger la opción Visor del archivo de registros (Figura 2). El visor es una herramienta muy sencilla de utilizar. En la parte izquierda tenemos el panel Seleccionar registros. En ese panel tenemos la posibilidad de visualizar los registros del Motor de base de datos, los registros del Correo electrónico de base de datos y los registros del Agente de SQL Server. En el panel central podemos ver todos los registros. Para cada registro podremos ver la fecha de suceso, el identificador de proceso que lo originó, y el mensaje asociado al evento. Este panel nos permite exportar los registros, buscar o filtrar registros. Para el filtro, podemos utilizar parámetros como el nombre de usuario, el nombre del equipo, o fecha de inicio y fin del suceso, entre otros. También tenemos un comando que nos permite cargar registros. Esta característica nos servirá para cargar en este visor los registros de eventos de Windows, con el fin de agruparlos con los registros de errores de SQL Server y facilitar su análisis (Figura 3). Para poder realizar esta tarea, debemos utilizar el comando Guardar registros como del menú Acción del visor de sucesos de Windows, y guardaremos los registros de aplicación como un archivo con formato.csv (Figura 4). 2

3 Alhambra Eidos 9. Diagnosticar y resolver errores de servidor Figura 2 Cada sesión de SQL Server escribe sucesos nuevos en el registro de aplicación de Windows. A diferencia del registro de errores de SQL Server, no se crea un nuevo registro de aplicación cada vez que se inicia una instancia de SQL Server. Con el visor de sucesos de Windows podemos ver tres tipos de registros: Registro del sistema: registra los sucesos emitidos por los componentes del sistema operativo, como por ejemplo el error al cargar un controlador u otro componente del sistema durante el inicio. Registro de seguridad: registra sucesos de seguridad, como los errores en intentos de inicios de sesión. Esto ayuda a realizar un seguimiento de los cambios en el sistema de seguridad, y a identificar las posibles infracciones en la seguridad. Registro de la aplicación: graba los sucesos registrados por las aplicaciones, como por ejemplo errores de SQL Server. 3

4 Despliegue y Mantenimiento de Bases de datos con SQL Server 2008 Alhambra Eidos Figura 3 Con estas herramientas podremos diagnosticar los errores de aplicación del motor de base de datos, y obtener información sobre cómo resolverlos. Figura 4 Conexión a un servidor que no responde utilizando DAC La utilidad en línea de comandos de SQL Server se utiliza para establecer una conexión a SQL Server y enviar instrucciones TSQL y otros comandos al servidor. También podemos ejecutar archivos de script, consultar variables de sistema, o conectarnos con el servidor SQL Server utilizando la Conexión Dedicada del Administrador (DAC). Esta herramienta se llama SQLCMD.exe, y sustituye a las anteriores OSQL e ISQL, aunque la primera de ellas se sigue manteniendo en SQL Server 2008 por compatibilidad con versiones anteriores. La 4

5 Alhambra Eidos 9. Diagnosticar y resolver errores de servidor utilidad en línea de comandos utiliza un proveedor OLE DB para establecer la conexión con el servidor, lo que le permite establecer múltiples conexiones a diferentes servidores dentro del mismo script. Para establecer comunicación con el servidor utilizando la herramienta en línea de comando de SQL Server, debemos utilizar el parámetro A. Únicamente los miembros de la función fija de servidor sysadmin pueden conectarse al servidor usando la Conexión dedicada del administrador. Además, debemos tener en cuenta que la opción de usar la conexión dedicada del administrador debe estar habilitada en la herramienta de Configuración de Superficie. Para conectarnos debemos ejecutar el siguiente comando: C:\ sqlcmd A d master Aunque teóricamente es posible ejecutar cualquier instrucción Transact-SQL que no se tenga que ejecutar en paralelo en la DAC, debemos limitar su uso a los siguientes comandos de diagnóstico y solución de problemas: Consultas en Vistas de administración dinámica para diagnósticos básicos como sys.dm_tran_locks para el estado de bloqueo, sys.dm_os_memory_cache_counters para comprobar el estado de las cachés y sys.dm_exec_requests y sys.dm_exec_sessions para solicitudes y sesiones activas. Evitaremos las Vistas de administración dinámica que consumen muchos recursos (por ejemplo, sys.dm_tran_version_store recorre el almacén de versiones completo y puede causar numerosas E/S) o que utilizan combinaciones complejas. Consultas en vistas de catálogo. Comandos DBCC básicos, como por ejemplo DBCC FREEPROCCACHE, DBCC FREESYSTEMCACHE, DBCC DROPCLEANBUFFERS, y DBCC SQLPERF. No debemos ejecutar comandos que consumen muchos recursos, como DBCC CHECKDB, DBCC DBREINDEX o DBCC SHRINKDATABASE. Comando Transact-SQL KILL <spid>. Dependiendo del estado de SQL Server, es posible que el comando KILL no siempre se ejecute correctamente; entonces la única opción puede ser reiniciar SQL Server. Éstas son algunas directrices generales: Comprobaremos que realmente se ha eliminado SPID con la consulta select * from sys.dm_exec_sessions where session_id = <spid>. Si no devuelve ninguna fila, significa que la sesión se ha eliminado. Si la sesión todavía existe, comprobaremos si hay tareas asignadas a esta sesión ejecutando la consulta select * from sys.dm_os_tasks where session_id = <spid>. Si vemos la tarea, lo más probable es que se esté eliminando la sesión ahora. Debemos tener en cuenta que es posible que esto tarde bastante tiempo y que no salga correctamente. Si no hay ninguna tarea en sys.dm_os_tasks asociada a esta sesión, pero la sesión permanece en sys.dm_exec_sessions tras ejecutar el comando KILL, significa que no tiene ningún trabajo disponible. Seleccionaremos una de las tareas que se están ejecutando (una tarea que aparece en la vista sys.dm_os_tasks con sessions_id <> NULL), y eliminaremos la sesión que tiene asociada para liberar el trabajo. Puede que no sea suficiente eliminar una sola sesión: posiblemente tendremos que eliminar varias. 5

6

7