Par où commencer pour comprendre une base de données inconnue

12

Donc, le titre le résume.

J'ai une base de données SQL Server avec 28 tables et 86 procédures stockées qui doivent être rétroconçues. Je suis presque sûr que certaines tables ne sont jamais utilisées et que tous les procs ne sont pas utilisés également.

Le plus gros problème est que tous les services Windows créés pour être utilisés avec cette base de données et toute la documentation du logiciel et de la base de données sont perdus, et la personne qui a conçu l'ensemble du système est introuvable.

J'ai déjà réussi à créer un diagramme ER pour m'aider à comprendre les relations, mais comme je n'ai pas d'expérience en administration de base de données, je ne sais pas par où commencer.

Je suis également désolé si ce type de question ne doit pas être posé ici.

sql-server  documentation 
— Humain après tout
source
1
Je ne suis pas. Vous avez un accès complet à la base de données et vous savez que vous disposez de 86 procédures de stockage pour effectuer une rétro-ingénierie. Ce sont donc des procédures stockées cryptées? De quoi avez-vous besoin exactement pour faire de l'ingénierie inverse?
— paparazzo
Oh, c'est vrai. Votre question est logique: la base de données fonctionne, mais c'est un gâchis complet. Mauvais index, mauvais types de données, non normalisés, et tout cela se résume en une mauvaise performance ... Mais cela fonctionne.
— Human_AfterAll
Assurez-vous également d'être émotionnellement préparé. Embrassez et acceptez votre défi. Ne pas le faire entraînera des frictions mentales tout au long de votre voyage.
— Christiaan Westerbeek
Sûr! Merci pour le conseil! La préparation émotionnelle est l'une des étapes les plus importantes (sinon la plus importante).
— Human_AfterAll

Réponses:

5

Trois étapes très rapides pour vous aider à démarrer:

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')

Vous indiquera la dernière fois que chaque index a été utilisé, y compris l'index clusterisé. Donc, donnez-vous au moins une idée des tables auxquelles vous accédez (et de celles qui ne le sont pas).

2) Activez une session d'événements étendus (ou une trace Profiler côté serveur si vous exécutez une version antérieure à SQL 2012) pendant environ une heure pendant que l'application est utilisée. Vous pouvez également demander à un utilisateur d'effectuer diverses actions dans l'application dans un ordre spécifique afin de pouvoir le corréler avec la trace / session.

Une suggestion utile: si vous pouvez modifier la chaîne de connexion que l'application utilise, ajoutez "; Nom de l'application = AppNameGoesHere" afin que vous puissiez exécuter un filtrage de trace sur ce nom d'application particulier. Bonne pratique quand même.

3) Obtenez une version de l'application fonctionnant sur un serveur hors production. Développer une liste de tests comportementaux pour l'application («Lorsque l'utilisateur clique sur le bouton Nouvel élément, il crée un nouvel élément pour cet utilisateur», etc.) (J'utilise un format comme objectName_DEPRECATED_YYYYMMDD - la date étant le jour où j'ai l'intention de le supprimer.) Revérifiez tous vos tests.

Grâce à une combinaison de la session Événements étendus, du DMV d'utilisation de l'index et de votre suppression logicielle, vous devriez être en mesure d'identifier les principaux objets utilisés par l'application et un bon consensus général sur quel objet fait quoi.

Bonne chance!

— Kyle Hale
source
7

Votre meilleur pari pour commencer est de documenter votre base de données à l'aide de SQL Power Doc

Documentation SQL Server et Windows à l'aide de Windows PowerShell

SQL Power Doc est une collection de scripts et de modules Windows PowerShell qui découvrent, documentent et diagnostiquent les instances SQL Server et leurs configurations sous-jacentes de système d'exploitation Windows et de machine. SQL Power Doc fonctionne avec toutes les versions de SQL Server de SQL Server 2000 à 2014, et toutes les versions de Windows Server et des systèmes d'exploitation Windows grand public de Windows 2000 et Windows XP à Windows Server 2012 R2 et Windows 8. SQL Power Doc est également capable de documenter les bases de données Windows Azure SQL.

Remarque: je l'ai utilisé et il vous donnera un très bon départ pour documenter et comprendre votre instance de serveur de base de données.

— Kin Shah
source
Merci. Cela va sûrement ajouter à la série d'étapes que je devrai faire pour comprendre cette maudite DB
— Human_AfterAll
Hey! Je suis vraiment mauvais avec PowerShell et je n'ai pas pu passer cette New-Item -type directory -path "$([Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments))\WindowsPowerShell\Modules"étape sur le SqlServerInventory ReadMe.txtfichier. Je ne sais pas où dois-je insérer le chemin d'accès au dossier nouvellement créé et où dois-je insérer le nom du dossier nouvellement créé.
— Human_AfterAll
3

Depuis que j'étais dans une situation similaire, je peux vous dire que ce sera un travail difficile à impossible. Je n'avais que le code source (> 100k lignes de code), le service en cours d'exécution, la base de données en cours d'exécution (~ 50 tables) et aucune documentation et personne à qui demander, sauf un utilisateur de cette application et une copie de la base de données et des services exécutés dans un environnement de test (qui était en avance de quelques numéros de version mais sans code source). Une autre exigence était que les services devaient fonctionner 24h / 24 et 7j / 7 car ils étaient externes aux clients. La situation est survenue parce que la plupart des employés sont partis à peu près au même moment, y compris les développeurs et la documentation a disparu dans le chaos. Il m'a fallu plus de 6 mois pour obtenir un aperçu / une documentation approximative. Il y avait de nombreuses tables et fonctions qui n'avaient aucun effet car elles étaient destinées à une utilisation future ou jamais entièrement implémentées, fonctionnalités défectueuses ou obsolètes ou non publiées. Après les 6 mois, j'ai dû réécrire la documentation parce que j'ai découvert de nouvelles choses ou des relations entre les choses et j'avais des hypothèses erronées auparavant.

Pourquoi je dis ça? Parce que parfois, dans une telle situation, il est plus facile et moins cher de recommencer à zéro et d'écrire une nouvelle application remplissant les exigences de l'ancienne (ou de nouvelles si elles ont changé au fil du temps ou si vous voulez une nouvelle version majeure). Ou pour vous dire à quoi vous devrez vous attendre.

Si vous voulez vraiment le désosser, je recommanderais les étapes suivantes:

  • Faites une sauvegarde de l'ensemble du système! (Premièrement: vous ne saurez jamais quand vous en aurez besoin. Deuxièmement: vous en aurez besoin pour l'étape suivante)
  • recréer une copie du système (services et base de données) pour travailler avec et écrire comment le créer parce que vous devrez sûrement le faire plusieurs fois au cours des prochains mois parce que vous le gâcherez plusieurs fois lors de l'ingénierie inverse
  • créer un diagramme ER avec les dépendances entre les tables
  • afficher et documenter les dépendances de chaque table, procédure stockée, ... car celles-ci ne sont généralement pas incluses dans les diagrammes ER
  • comprendre ce que le logiciel doit faire en demandant aux utilisateurs et en l'utilisant lui-même (mieux le faire sur le système de test)
  • Si le code source des services est disponible: obtenez-en un aperçu et appelez la base de données et documentez-la (doxygen est un bon outil pour obtenir une documentation approximative avec des hiérarchies d'appels de fonctions)
  • essayez d'obtenir un aperçu approximatif de la base de données en regardant les noms de table et leurs colonnes
  • regarder la base de données tout en l'utilisant
  • avec les 4 étapes précédentes, divisez les tables en 3 catégories (peuvent différer pour vous en fonction de votre application): données statiques (données qui ne changent pas lors de l'exécution du serveur comme la configuration de serveur, énumérations pour restreindre les valeurs valides dans d'autres tables en utilisant des clés étrangères. , ...), les données de configuration (données qui changent rarement comme les paramètres utilisateur, ...) et les données OLTP (messages utilisateur dans le serveur de chat, messages dans un forum, valeurs de mesure dans un système de contrôle de machine, batailles dans un jeu en ligne, ...)
  • répétez les 5 étapes précédentes jusqu'à ce que vous soyez satisfait ou que vous abandonniez
  • Documentez et codez comme si le gars qui finit par maintenir VOTRE code / système / base de données sera un psychopathe violent qui sait où vous vivez.

Je vous souhaite bonne chance ;)

— H. Idden
source
1
-1, Quiconque pense qu'il est "plus facile et moins cher de recommencer à zéro et de tout réécrire" d'une grande application n'a jamais eu à le faire. Ceci est un conseil amateur.
— BlueRaja - Danny Pflughoeft
@ BlueRaja-DannyPflughoeft Cela dépend du type, de la taille et de l'état de l'application et de l'exigence de compatibilité descendante. J'ai réécrit une application à partir de zéro avec environ 100k LoC. Il n'était pas nécessaire d'imiter l'original, mais il a été publié en tant que nouvelle version majeure avec de nouvelles fonctions ajoutées, d'anciennes fonctions supprimées, une interface utilisateur modernisée et la possibilité d'utiliser les anciennes données. Le code d'origine était un tel désordre et un désastre de sécurité que nous avons été plus rapides que le temps estimé pour nettoyer l'ancien code.
— H.Idden
Surtout si le code contient de nombreuses solutions de contournement non documentées, il arrivait souvent qu'un petit changement plantait quelque chose de totalement différent. Mais je suis d'accord avec vous, que beaucoup sous-estiment le coût (main-d'œuvre, argent, ..) de le faire à partir de zéro parce qu'ils ne connaissent pas ou ne sous-estiment pas les exigences complètes de l'application, surtout lorsqu'elle a grandi et changé au fil des ans.
— H. Idden
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.