Por dónde empezar a entender una base de datos desconocida

Entonces, el título lo resume.

Tengo una base de datos de SQL Server con 28 tablas y 86 procedimientos almacenados que deben ser de ingeniería inversa. Estoy bastante seguro de que algunas tablas nunca se usan y que no todos los procesos también se usan.

El mayor problema es que todos los Servicios de Windows que se crearon para usarse con este DB y toda la documentación del software y la base de datos se pierden, y la persona que diseñó todo el sistema no se encuentra en ningún lado.

Ya he logrado crear un diagrama ER para ayudarme a comprender las relaciones, pero como no tengo experiencia en la administración de bases de datos, no tengo idea de por dónde empezar.

También lo siento si este tipo de preguntas no están destinadas a hacerse aquí.

Tres pasos muy rápidos para comenzar:

1)

USE DatabaseName

SELECT    [TableName] = OBJECT_NAME(object_id),
last_user_update, last_user_seek, last_user_scan, last_user_lookup
FROM    sys.dm_db_index_usage_stats
WHERE    database_id = DB_ID('DatabaseName')

Le indicará la última vez que se utilizó cada índice, incluido el índice agrupado. Por lo tanto, al menos dé una idea de a qué tablas se accede (y cuáles no)

2) Active una sesión de eventos extendidos (o el rastreo de Profiler del lado del servidor si está ejecutando pre-SQL 2012) durante aproximadamente una hora mientras se usa la aplicación. También puede pedirle a un usuario que realice varias acciones en la aplicación en un orden específico para que pueda correlacionarlo con el seguimiento / sesión.

Una sugerencia útil: si puede modificar la cadena de conexión que usa la aplicación, agregue "; Nombre de la aplicación = AppNameGoesHere" para que pueda ejecutar un filtrado de rastreo en ese Nombre de aplicación en particular. Buena práctica de todos modos.

3) Obtenga una versión de la aplicación que funcione en un servidor que no sea de producción. Desarrolle una lista de pruebas basadas en el comportamiento para la aplicación ("Cuando el usuario hace clic en el botón Nuevo elemento, crea un nuevo elemento para ese usuario", etc.) Comience a eliminar los objetos que considera que no tienen relación con las pruebas al cambiarles el nombre. (Uso un formato como objectName_DEPRECATED_YYYYMMDD, siendo la fecha el día que planeo eliminarlo). Vuelva a verificar todas sus pruebas.

Mediante una combinación de la sesión de Eventos extendidos, el DMV de uso del índice y su eliminación suave, debería poder identificar los objetos principales que utiliza la aplicación y un buen consenso general sobre qué objeto hace qué.

¡Buena suerte!

Su mejor apuesta para comenzar es documentar su base de datos usando SQL Power Doc

Documentación de SQL Server y Windows con Windows PowerShell

SQL Power Doc es una colección de scripts y módulos de Windows PowerShell que descubren, documentan y diagnostican instancias de SQL Server y sus configuraciones de máquina y SO Windows subyacentes. SQL Power Doc funciona con todas las versiones de SQL Server desde SQL Server 2000 hasta 2014, y todas las versiones de Windows Server y sistemas operativos Windows de consumo desde Windows 2000 y Windows XP hasta Windows Server 2012 R2 y Windows 8. SQL Power Doc también es capaz de documentando las bases de datos SQL de Windows Azure.

Nota: Lo he usado y le dará un buen comienzo para documentar y comprender su instancia de servidor de base de datos.

Como una vez estuve en una situación similar, puedo decirte que este será un trabajo difícil o imposible. Solo tenía código fuente (> 100k líneas de código), el servicio en ejecución, la base de datos en ejecución (~ 50 tablas) y ninguna documentación y nadie para preguntar al respecto, excepto un usuario de esta aplicación y una copia de la base de datos y servicios que se ejecutan en un entorno de prueba (que tenía algunos números de versión por delante pero sin código fuente). Otro requisito era que los servicios debían ejecutarse las 24 horas, los 7 días de la semana, porque eran externos a los clientes. La situación surgió porque la mayoría del personal se fue aproximadamente al mismo tiempo, incluidos los desarrolladores, y la documentación desapareció en el caos. Me llevó más de 6 meses obtener una descripción / documentación aproximada. Había muchas tablas y funciones que no tenían efecto porque eran para uso futuro o nunca se implementaron por completo, características defectuosas o en desuso o inéditas. Después de los 6 meses tuve que reescribir la documentación porque descubrí cosas nuevas o relaciones entre cosas y tenía suposiciones erróneas antes.

¿Por qué estoy diciendo esto? Porque a veces, en tal situación, es más fácil y económico comenzar desde cero y escribir una nueva aplicación que cumpla con los requisitos de la anterior (o nuevas si cambiaron con el tiempo o si desea una nueva versión importante). O para decirte lo que tendrás que esperar.

Si realmente desea realizar ingeniería inversa, le recomendaría los siguientes pasos:

• ¡Haga una copia de seguridad de todo el sistema! (Primero: nunca sabrá cuándo lo necesitará. Segundo: lo necesitará para el siguiente paso)
• recrear una copia del sistema (servicios y base de datos) para trabajar y escribir cómo crearlo porque seguramente tendrá que hacerlo varias veces en los próximos meses porque lo estropeará varias veces mientras realiza ingeniería inversa
• crear un diagrama ER con las dependencias entre las tablas
• ver y documentar las dependencias de cada tabla, procedimiento almacenado, ... porque en su mayoría no se incluyen en los diagramas ER
• Comprenda qué debe hacer el software preguntando a los usuarios y usándolo por sí mismo (mejor hacerlo en el sistema de prueba)
• Si el código fuente de los servicios está disponible: obtenga una descripción general y llame al DB y documente (doxygen es una buena herramienta para obtener una documentación aproximada con jerarquías de llamadas a funciones)
• intente obtener una visión general aproximada de la base de datos mirando los nombres de las tablas y sus columnas
• mire la base de datos mientras la usa
• con los 4 pasos anteriores, divida las tablas en 3 categorías (pueden diferir para usted según su aplicación): datos estáticos (datos que no cambian mientras se ejecuta el servidor como la configuración del servidor, enumeraciones para restringir valores válidos en otras tablas mediante el uso de claves externas para ello , ...), datos de configuración (datos que rara vez cambian, como la configuración del usuario, ...) y datos OLTP (mensajes de usuario en el servidor de chat, publicaciones en un foro, valores de medición en un sistema de control de máquina, batallas en un juego en línea, ...)
• repita los 5 pasos anteriores hasta que esté satisfecho o se dé por vencido
• Documente y codifique como si el tipo que termina manteniendo SU código / sistema / base de datos sea un psicópata violento que sabe dónde vive.

Te deseo buena suerte ;)

No tengo suficiente representante para publicar un comentario, pero quería ayudarte con tu pregunta sobre

getting the SQL Power Doc to work.

Si sigue los pasos en su página de documentación, funcionará con bastante facilidad. Solo comienza desde arriba.

https://sqlpowerdoc.codeplex.com/wikipage?title=Guide%20For%20PowerShell%20Beginners