¿Cómo puedo rastrear las dependencias de la base de datos?

A medida que las aplicaciones internas evolucionan a lo largo de varios años, ocasionalmente encuentra que hay una serie de tablas que las personas creen que ya no son relevantes y quieren eliminar. ¿Cuáles son los métodos prácticos para identificar las dependencias de la base de datos, tanto dentro del entorno SQL, y tal vez hacia adelante en cosas como SSIS?

He trabajado en lugares donde se han tomado opciones bastante brutales como:

• Suelte primero, haga preguntas más tarde (puede eliminar una compilación del almacén de datos si intenta extraer una tabla que ya no existe)
• Elimine primero los permisos y espere a que se informen los errores (puede causar errores silenciosos, si la falla no se maneja correctamente)

Aprecio que SQL Server venga con herramientas para rastrear dependencias dentro de esa instancia, pero estas parecen tener dificultades si tiene bases de datos en diferentes instancias. ¿Existen opciones que faciliten la consulta de dependencias, tal vez respondiendo preguntas como "¿Dónde se usa esta columna?" con respuestas como "Más en este otro servidor en este procedimiento almacenado" o "Más en este paquete SSIS"?

No hay una manera fácil de hacer esto. Los disparadores no funcionan, como si seleccionas de una tabla no se dispara ningún disparador. La mejor forma en que he encontrado para hacer esto es hacer que los desarrolladores rastreen lo que usan. Cuando se vaya a descartar algo, consulte con todos los equipos de desarrollo y, después de que todos cierren la sesión, cambie el nombre del objeto. Entonces no se rompe nada durante un mes o más, el objeto se puede soltar de forma segura.

1. Código de búsqueda para uso con sys.sql_modules.definition: ¿se hace referencia a él? Luego...
2. Verificar permisos: ¿qué código de cliente puede llamarlo? Luego...
3. Profiler

Así:

• Para una tabla sin referencia y sin permisos, no se está utilizando.
• Sin referencias y algunos permisos, ejecute profiler para ver el uso
• Sin permisos y referencias, agregue el registro de uso

Lo que he hecho antes es hacer que la tabla sea una vista que enmascara la tabla y luego hacer que la vista funcione mal: (combinación cruzada, distinta). En realidad, no lo elimina, pero genera tiempos de espera o quejas de clientes ...

Una forma rápida que he usado en el pasado (y realmente depende del tamaño de las tablas, el número de índices de rendimiento, etc.), es agregar un activador, que registra una marca de tiempo cuando se realiza una acción en la tabla. Como he dicho, esto puede tener problemas de rendimiento, por lo que debe tratarse con precaución; también observe que su tabla de registro no usa campos de identidad, ya que esto puede arruinar algún código antiguo que usa @@ IDENTITY. Por supuesto, puede mostrar que una característica de una aplicación no se ha utilizado en algún momento.

Es muy difícil rastrear dependencias cuando todo el código que puede afectar a la base de datos no está en la base de datos, es decir, clientes aleatorios que consultan la base de datos.

EDITAR: para abordar el punto de que una tabla no puede tener disparadores SELECT, aquí hay otra opción que debería funcionar asumiendo que sus tablas tienen índices (probado en 2008 solamente).

SELECT          
    last_user_seek,
    last_user_scan,
    last_user_lookup,
    last_user_update
FROM
    sys.dm_db_index_usage_stats AS usage_stats
INNER JOIN
sys.tables AS tables ON tables.object_id = usage_stats.object_id
WHERE
    database_id = DB_ID() AND
    tables.name = 'mytable' 

pero tenga en cuenta que la tabla de estadísticas de uso se borra cuando se reinicia el servidor, se desconecta, etc. Por lo tanto, deberá configurar un trabajo para recopilar los datos. Un poco pirata, lo sé.

Una forma que usé en el pasado fue establecer una lista de candidatos para eliminar las tablas y luego cambiarles el nombre y buscar fallas.

Cómo establecí la lista fue:

1. ver qué tablas no están en uso en los procedimientos almacenados actuales, disparadores y funciones

2. tablas vacías (cero registros);

3. tablas no referenciadas (tablas que no tienen ninguna relación);

4. ver qué tablas no estaban en uso desde que se inició el servidor DB (DMV)

Después de construir la lista en un archivo de texto, hice un script por lotes que analizaría nuestros archivos .cs (solo tenemos proyectos .net) de la carpeta de control de versiones local asignada y veré si esas tablas se usan en los archivos .cs ( no debería suceder, pero bueno ... he tenido sorpresas). Si no, entonces está claro, si es así, entonces construimos una lista y se la damos a los desarrolladores para verificar si ese módulo todavía está en uso.

En resumen, los muchachos anteriores tienen razón, no hay bala de plata.

La política que estoy implementando en mi empresa es poner todo lo que toca SQL Server bajo control de origen, en una ubicación central.

• proyectos asp.net
• Proyectos SSRS
• Proyectos SSIS
• Incluso escribo todos los objetos de la base de datos en una especie de repositorio.

Todavía no lo tengo configurado, pero eventualmente quiero implementar algún tipo de mecanismo de búsqueda de índice / central que pueda usar para buscar tablas, sprocs, etc. específicos. De hecho, somos una nueva tienda de SQL Server: conversión de FoxPro . Entonces, los viejos objetos SQL no son un gran problema todavía, pero estoy planeando para el futuro.

El problema que veo con el enfoque de cambio de nombre / rastreo es que algunas cosas solo se ejecutan anualmente, y ni siquiera todos los años. Sin mencionar las diversas cosas ad-hoc que la gente te pide que escribas, y luego piden nuevamente meses o años después.

Hay una variedad de herramientas y técnicas para usar en el seguimiento de dependencias, que incluyen:

Herramientas que conozco:

• Visor de dependencia de SQL Server (pero puede tener problemas si se creó sp usando table antes de crear la tabla)
• Redgate SQL Dependency Tracker (a través de la respuesta de @Eric Humphrey)
• Resharper (herramienta .net que se puede usar para ver las rutas de llamadas, creo que se puede usar para rastrear dónde se usan las llamadas SQL clave)

Métodos

• El código busca el uso de objetos SQL (aunque replica algunas de las herramientas anteriores)

• Mire las estadísticas de uso (es decir: cuándo se llamó por última vez un objeto SQL), uso el siguiente SQL:

  SELECT 
      last_execution_time,   
      (SELECT TOP 1 
          SUBSTRING(s2.text,statement_start_offset / 2+1 , 
              ((CASE WHEN statement_end_offset = -1 THEN 
                  (LEN(CONVERT(nvarchar(max),s2.text)) * 2) 
              ELSE statement_end_offset END) - statement_start_offset) / 2+1)
      )  AS sql_statement,
      execution_count
  FROM sys.dm_exec_query_stats AS s1 
  CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
  WHERE 
      s2.text like '%[OBJECT NAME]%' 
      and last_execution_time > [DATE YOU CARE ABOUT]
  ORDER BY last_execution_time desc

Nota : La tabla de estadísticas de uso se borra cuando se reinicia el servidor, se desconecta, etc. Por lo tanto, deberá configurar un trabajo para recopilar los datos. Un poco pirata, lo sé. (de @Miles D)

Tecnicas

• Busque el último uso (consulte las estadísticas de uso anteriores)
• Busque dónde se usa (ver herramientas)
• Revise el uso del código con los desarrolladores (a través de @MrDenny)
• Cambie el nombre del objeto (es decir: post / prefijo con _toBeDropped) y observe si hay errores
• Cambiar permisos y estar atento a errores
• Suelta el objeto y reza

Hace varios años, intenté crear una herramienta para verificar cosas similares. La respuesta de TL; DR es que no encontré que fuera posible hacer con los recursos disponibles en ese momento.

¿Dónde se usa esta columna?

Esta pregunta se vuelve más complicada cuando te das cuenta de que una serie de consultas, vistas y procedimientos almacenados se usan select *en la tabla en la que reside la columna. Luego, debes mirar los programas que usan esos resultados, por lo que necesitas un poco de escáner / indexador / analizador capaz de leer el código fuente que puede ser C #, Delphi, Java, VB, ASP (clásico), etc., solo para intentar buscar cada referencia a esa columna. Luego, debe analizar esos programas para intentar identificar si ese código ya se está llamando.

No manejará las referencias SQL, pero es posible que desee consultar el Rastreador de dependencias SQL de Redgate . Es una buena herramienta de visualización.

Esta no es realmente una respuesta a su pregunta, pero creo que vale la pena mencionar: esta es una razón por la cual todos los sistemas fuera de su base de datos deberían comunicarse a través de vistas y sprocs . Tiene los scripts de compilación para estos en archivos .sql de búsqueda, por lo que puede ver fácilmente si una tabla o columna en particular se está utilizando externamente.

Por supuesto, SSIS normalmente se conectará directamente a las tablas, por lo que probablemente no sea de gran ayuda para su necesidad en este momento. Pero cuando los desarrolladores se conectan a su base de datos y se quejan de tener que esperarle (o quien sea que esté sirviendo como DBA) para hacer las vistas y los sprocs que necesitan, puede decirles: "Cualquier tabla o columna puede ser eliminada o renombrada. solo estoy obligado a mantenerlo informado sobre los cambios en las vistas y los sprocs ". Y solo tienen que hacer pruebas de regresión para estos cambios específicos.

TSQL se puede usar lo siguiente sys.dm_sql_referencing_entities o sys.sql_expression_dependencies

Alternativamente, herramientas como SQL Negotiator Pro, Redgate, etc. pueden generar esto visualmente para usted utilizando una GUI