El caso de sp_depends desde SQL Server 6.5, su legado hasta SQL Server 2005/2008 y un sin sabor hasta la fecha
¿Quién no ha usado sp_depends para recuperar información de dependencias de objetos de bases de datos?, creo que casi toda persona que en algún momento de su vida ha trabajado o trabaja con SQL Server, especialmente en temas de desarrollo o soporte donde es casi frecuente su uso. ¿Quién dice yo no?. El punto es que el procedimiento almacenado del sistema sp_depends no devuelve resultados correctos, no es confiable tanto en SQL Server 2000 como en las versiones 2005 y 2008, el caso es más frecuente para bases de datos que se van migrando en el tiempo. Existen situaciones donde podría funcionar y es cuando creas objetos desde cero en la versión que uses, existen otras que no, simplemente indica que no existe alguna dependencia (después de migraciones).
Y por qué es tán importante que la información de este tipo sea confiable?, pues ayudaría a atender requerimientos como estos:
- Realizar cambios en ciertos objetos de bases de datos(como tablas, columnas) y deseas saber dónde estos objetos están siendo referenciados, y de esta manera reducir el riesgo de desplegar cambios parciales.
- Medir el impacto de nuevos desarrollos que implican cambios en objetos de bases de datos, las cuales deben integrarse a los que ya tenemos en producción, y tal vez también necesitemos programar cargas masivas y evitar problemas de rendimiento y bloqueos.
- Mejorar la rapidez del servicio de soporte, saber en que objetos impactará el cambio, por ejemplo, del tipo de dato de una columna.
A veces incluso, en el caso de procedimientos almacenados de usuario, tenemos que modificarlo moviendo una que otra línea para que las referencias de algunas dependencias se actualicen, y no sabes si va funcionar. En SQL Server 2000 no tienes alternativa para solucionar el tema. En SQL Server 2005 apareció sys.sql_dependencies que en realidad tampoco es confiable porque lee de la misma tabla del que se sirve sp_depends, esta tabla es sysdepends la cual suele andar desactualizada o actualizarse incorrectamente, no sirve. Discúlpenme pero ya hace muchos años atrás que le he pérdido confianza a este señor sp_depends, además ya está depreciada, sin embargo, la solución no es migrar, Microsoft debería hacer algo para mejorar sp_depends en SQL Server 2000 y SQL Server 2005, y sys.sql_dependencies en SQL Server 2005 y SQL Server 2008.
En SQL Server 2008 tenemos alternativas que sí funcionan muchísimo mejor, podría decir que son confiables(aunque tienen su propias odiseas como esta: http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=331830). Las alternativas son sys.dm_sql_referenced_entities y sys.dm_sql_referencing_entities, sql_expression_dependencies y podemos adicionalmente apoyarnos de sys.objects para conseguir cualquier información de dependencia entre objetos de bases de datos. El tema aquí es que estas vistas no leen de sysdepends sino la información de dependencia se consigue bajo demanda, es decir es dinámico. Ahora, por ejemplo, si nosotros deseamos saber cual son las dependencias desactualizadas o incorrectas podriamos conseguirlo con algo sencillo:
SELECT OBJECT_NAME(referencing_id)
FROM sys.sql_expression_dependencies
WHERE referencing_id NOT IN (
SELECT id
FROM sysdepends
)
Cuando realmente es urgente contar con información confiable acerca de dependencias de objetos es donde recién te pones a pensar porque Microsoft no se preocupó mucho antes en mejorar estas funcionalidades en SQL Server 2005 y versiones menores, claro que SQL Server 2008 trabaja bien con estos temas, pero no soluciona los problemas, se tiene que hacer cosas como esto Keeping sysdepends up to date in SQL Server 2008 , lo cual por cierto también es limitado. Es evidente que aún sigo descontento, pero la necesidad de manejar dependencias entre varios miles de objetos, cientos de bases de datos entre muchos servidores, y saber que podría faltar algo actualizado obviamente aún me deja un sin sabor hasta la fecha.
PercyReyes,