Stored Procedures No Documentados en SQL Server 2008

Introducción

Hola a todos, hace algunos días reflexionaba que pese al uso común que personalmente hago del stored procedure xp_readerrorlog (o bien sp_readerrorlog) para revisar el log de errores de SQL Server, si realizamos una búsqueda del comando en la ayuda de SQL Server no encontraríamos referencias al mismo. Así como este stored hay varios más que no están documentados en la ayuda de SQL Server pero que en un momento dado nos pueden ser útiles para revisar información que necesitemos conocer.

En esta entrada al blog platico un poco acerca de estos “undocumented stored procedures” y presento una lista de algunos que pueden ayudarnos en nuestras actividades diarias.

¿Por qué existen stored procedures no documentados?

Algunos autores opinan que en muchos casos no hay una razón importante para que Microsoft no libere documentación acerca de algunos de estos stored procedures con el objetivo de que los administradores y usuarios de SQL Server pudieran utilizarlos sin problemas, o bien, que en todo caso, ninguno de ellos debería estar accesible para su ejecución por parte de los administradores de los sistemas.

La posición anterior, si bien tiene un poco de lógica desde la perspectiva de usuario final, me parece que no es del todo correcta, según lo que he podido investigar muchos de estos stored procedures, y en general otras herramientas no documentadas disponibles en SQL Server (comandos DBCC, Funciones, Trace Flags y Startup Options) pudieron ser utilizados para propósitos de “testing” durante el desarrollo del Producto o bien fueron creados con propósitos de “deep debuggin” para Soporte del mismo.

¿Es bueno utilizar stored procedures no documentados?

Creo que no es casualidad u olvido (como algún otro autor opina) que las herramientas mencionadas no estén documentadas, muchas de ellas pueden llegar a ser “peligrosas” en su utilización, el que no estén documentadas también nos advierte del hecho que en cualquier momento (con la liberación de algún hotfix, parche de seguridad, service pack o bien una nueva versión del producto) puede ser cambiada su funcionalidad, el comportamiento de su ejecución o definitivamente ser eliminadas, es también muy probable que la funcionalidad de cada uno de ellos no este revisada con exhaustivos casos de prueba, así que definitivamente no es recomendable su utilización por parte de usuarios finales en sus aplicaciones (no deben incluirse referencias a ellos en el código), tampoco debe hacerse dependiente algún proceso de su ejecución.

Para poner un ejemplo de que tan real es el riesgo al que se expone alguno de nuestros clientes que implemente dentro de su código llamadas a alguno de estos procedimientos, basta mencionar que mientras preparaba esta entrada al blog, me enteré de que el uso de procesador de un server se iba a rangos del 100%, en tal servidor está instalada una instancia de SQL Server 2005 SP3, y en dicha instancia se estaba ejecutando un proceso del cliente que hace una llamada al xp_readerrorlog precisamente, es muy probable, de acuerdo al escenario que se presenta, que la causa raíz del problema sea un bug relacionado a la ejecución del extended stored procedure mencionado (https://support.microsoft.com/kb/973524).

Por tanto debe entenderse que, el posible uso que hagamos de cada uno de los stored procedures no documentados, es bajo nuestro propio riesgo, sin embargo como ya he mencionado antes, algunos de ellos pueden ser altamente útiles en nuestras actividades diarias.

Algunos útiles.

A continuación menciono algunos procedimientos no documentados que nos pueden ser de utilidad:

1. 1.        xp_dirtree

La ejecución de este extended stored procedure nos da como resultado una lista de todas las sub-carpetas de una carpeta especificada como parámetro de entrada:

EXECUTE master.sys.xp_dirtree '<path>'

Existe otro extended stored procedure (xp_subdirs) que sólo nos regresa las sub-carpetas del primer nivel, es decir, es el resultado de xp_dirtree con la condición depth = 1.

1. 2.        xp_enum_oledb_providers

El resultado de su ejecución es la lista de todos los proveedores de OLE DB disponibles para SQL Server:

EXEC master.sys.xp_enum_oledb_providers

1. 3.        xp_enumerrorlogs

Su ejecución nos regresa una lista de todos los archivos de log de SQL Server (error logs) con su última fecha de modificación:

EXECUTE master.sys.xp_enumerrorlogs

1. 4.        xp_enumgroups

Al ejecutarse regresa a lista de los grupos de Windows y su descripción:

EXECUTE master.sys.xp_enumgroups

1. 5.        xp_fixeddrives

Regresa una lista de todos los discos (drives) y el monto de espacio libre (en MB) para cada uno de ellos:

EXEC master.sys.xp_fixeddrives

1. 6.        xp_readerrorlog

Para terminar, como ya había mencionado, uno de los que más uso. Regresa el contenido de los archivos de log de errores de SQL Server, me parece muy útil así cuando buscamos errores que están ocurriendo en las instancias:

EXEC master.sys.xp_readerrorlog

Puede recibir hasta siete parámetros:

                                                         i.            Valor del archivo de log de errores que deseas leer: 0 = actual, 1 = Archivo #1, 2 = Archivo #2, etc…

                                                        ii.            Tipo de archivo de log de errores que quieres leer: 1 or NULL = Error Log, 2= SQL Agent Log

                                                      iii.            Cadena de búsqueda 1: Cadena de caracteres para condicionar los resultados mostrados, es decir un “string” que estés buscando.

                                                      iv.            Cadena de búsqueda 2: Cadena de caracteres secundaria para realizar una búsqueda mucho más precisa.

                                                        v.            Fecha/Hora de inicio de la búsqueda: Se buscará a partir de la fecha y hora indicada en este parámetro.

                                                      vi.            Fecha/Hora de fin de la búsqueda: Se buscará y desplegarán resultados (si los hubiera) hasta la fecha y hora especificadas en este parámetro.

                                                     vii.            Ordenamiento para los resultados: N'asc' = ascendente, N'desc' = descendente.

El stored procedure master.sys.sp_readerrorlog hace una llamada a xp_readerrorlog pero a diferencia de éste sólo puede recibir los primeros cuatro parámetros mencionados.

Para finalizar.

Como pudimos darnos cuenta, los stored procedures que presento como ejemplo son extended estored procedures, recordemos que éstos son una ejecución de una “dynamic link library” que corre directamente dentro de SQL Server, en la mayoría de los casos estos extended stored procedures sólo pueden ser ejecutados por usuarios con privilegios de sysadmin.

Existen más stored procedures no documentados en SQL Server 2008, si se desea obtener la información de los stored procedures disponibles en nuestra instancia de SQL Server 2008 y de allí buscar cuales aparecen en la ayuda y documentación del producto y cuáles no, podemos usar la siguiente consulta:

SELECT OBJECT_NAME(c.id), c.*

FROM master..syscomments c JOIN master..sysobjects o ON c.id = o.id

WHERE o.type in('X', 'P')

ORDER by 1, 4

*Como curiosidad: La herramienta de IntelliSense (nueva para SQL Server 2008) puede llegar a presentar información de algunos stored procedures no documentados (también de algunas funciones), como ejemplo puede probar escribiendo:

EXECUTE master.sys.sp_re

verá que IntelliSense ubica el stored sp_readerrorlog (aunque no aparece referencia a éste en la ayuda de SQL Server 2008) y te da información acerca del número de parámetros que puede recibir

“Las opiniones e ideas expresadas en este blog son las de los Autores y no necesariamente declaran o reflejan la opinión de Microsoft”

Este material tambien lo podras acceder en https://blogs.technet.com/b/sql_pfe_latam/