З чого почати розуміти невідому базу даних

Отже, назва підсумовує це.

У мене є база даних SQL Server з 28 таблицями та 86 збереженими процедурами, які мають бути реверсивними. Я майже впевнений, що деякі таблиці ніколи не використовуються і що не всі програми також використовуються.

Найбільша проблема полягає в тому, що всі служби Windows, які були створені для використання з цією БД, і вся документація на програмне забезпечення та базу даних втрачаються, а людини, яка спроектувала всю систему, ніде не знайдено.

Мені вже вдалося створити ER-діаграму, щоб допомогти мені зрозуміти відносини, але, оскільки я не досвідчений в управлінні базами даних, я не маю уявлення, з чого слід почати.

Також пробачте, якщо тут не потрібно задавати подібне запитання.

Три дуже швидкі кроки для початку роботи:

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

Скаже вам, коли останній раз використовувався кожен індекс, включаючи кластерний індекс. Тож принаймні дайте вам смак, для якого таблиці отримують доступ (а які ні.)

2) Увімкніть розширений сеанс подій (або слід Profiler на стороні сервера, якщо ви працюєте до SQL 2012) протягом години або близько того, поки додаток використовується. Ви також можете попросити користувача виконати різні дії в додатку в певному порядку, щоб ви могли співвіднести це з слідом / сеансом.

Корисна пропозиція: якщо ви можете змінити рядок з'єднання, яку додаток взагалі використовує, додайте "; ім'я програми = AppNameGoesHere", щоб ви могли запустити фільтрацію слідів у цій конкретній назві програми. Гарна практика все одно.

3) Отримайте версію програми, що працює на невиробничому сервері. Розробіть список тестів, орієнтованих на поведінку для програми ("Коли користувач натискає кнопку" Новий елемент ", він створює новий елемент для цього користувача" і т. Д.). Почніть м'яке видалення об'єктів, які не відчувають жодного відношення до тестів, перейменуючи їх (Я використовую такий формат, як objectName_DEPRECATED_YYYYMMDD - датою є день, коли я планую його фактично видалити.) Перевірте всі свої тести.

За допомогою комбінації сеансу розширених подій, використання індексу DMV та м'якого видалення ви зможете визначити основні об’єкти, які використовує додаток, та добрий загальний консенсус щодо того, який об’єкт робить що.

Удачі!

Найкраще почати документувати свою базу даних за допомогою SQL Power Doc

Документація на SQL Server та Windows за допомогою Windows PowerShell

SQL Power Doc - це сукупність скриптів і модулів Windows PowerShell, які виявляють, документують та діагностують екземпляри SQL Server та їх основні конфігурації ОС Windows та машини. SQL Power Doc працює з усіма версіями SQL Server від SQL Server 2000 до 2014 року, а також всі версії Windows Server та споживчих операційних систем Windows з Windows 2000 та Windows XP через Windows Server 2012 R2 та Windows 8. SQL Power Doc також може документування баз даних SQL Windows Azure.

Примітка: я використав це, і це дасть вам справді хороший початок із документування та розуміння екземпляра сервера баз даних.

Оскільки я колись був у подібній ситуації, я можу вам сказати, що це буде важка і неможлива робота. У мене був тільки вихідний код (> 100k рядків коду), запущена служба, запущена база даних (~ 50 таблиць) і жодна документація, і про неї ніхто не запитувати, окрім користувача цієї програми та копії бази даних та служб, що працюють у тестове середовище (яке попереду було на кілька номерів версій, але без вихідного коду). Ще одна вимога полягала в тому, що послуги повинні працювати 24/7, оскільки вони є зовнішніми для споживачів. Ситуація виникла через те, що більшість співробітників виїхали приблизно в один і той же час, включаючи розробників і документацію, зникло в хаосі. Щоб отримати приблизний огляд / документацію, мені знадобилося більше 6 місяців. Було багато таблиць і функцій, які не мали ніякого ефекту, оскільки вони були для подальшого використання або ніколи не були повністю реалізовані, несправні або застарілі або невипущені функції. Через 6 місяців мені довелося переписати документацію, оскільки я виявив нові речі або стосунки між речами, і раніше у мене були неправильні припущення.

Чому я це кажу? Тому що іноді в такій ситуації легше і дешевше почати з нуля і написати нову заявку, що повністю заповнить вимоги старої (або нової, якщо вони змінилися з часом або ви хочете новий великий реліз). Або сказати тобі, що доведеться чекати.

Якщо ви дійсно хочете змінити інженер, я рекомендую наступні кроки:

• Зробіть резервну копію всієї системи! (По-перше: ви ніколи не дізнаєтесь, коли вам це знадобиться. По-друге: вам це потрібно для наступного кроку)
• відтворіть копію системи (служб та бази даних) для роботи та запишіть, як її створити, тому що вам, безумовно, доведеться це робити кілька разів у наступні місяці, тому що ви будете переплутати її кілька разів під час зворотної інженерії
• створити ER-діаграму із залежностями між таблицями
• переглядати та документувати залежності кожної таблиці, що зберігається процедури, ... тому що вони здебільшого не включаються до ER-діаграм
• зрозуміти, що програмне забезпечення має робити, запитуючи користувачів та використовуючи його (найкраще це зробити в тестовій системі)
• Якщо вихідний код послуг доступний: огляньте його та зателефонуйте до БД та задокументуйте його (doxygen - це гарний інструмент для отримання грубої документації з ієрархіями викликів функцій)
• спробуйте отримати приблизний огляд БД, переглянувши назви таблиць та їх стовпців
• дивіться базу даних під час її використання
• за допомогою попередніх 4 кроків розділіть таблиці на 3 категорії (можуть відрізнятися для вас залежно від вашої програми): статичні дані (дані, які не змінюються під час роботи сервера, як серверна конфігурація, перераховують обмежувати дійсні значення в інших таблицях, використовуючи для цього зовнішні ключі , ...), конфігураційні дані (дані, які рідко змінюються, як налаштування користувачів, ...) і дані OLTP (повідомлення користувачів на сервері чату, повідомлення на форумі, значення вимірювання в системі управління машиною, битви в онлайн-грі, ...)
• повторюйте попередні 5 кроків, поки ви не задоволені або не відмовитеся
• Документ та код так, ніби хлопець, який закінчив підтримувати ВАШ код / ​​систему / базу даних, буде жорстоким психопатом, який знає, де ви живете.

Бажаю тобі удачі ;)

У мене недостатньо респондентів, щоб розмістити коментар, але я хотів допомогти у вашому питанні

getting the SQL Power Doc to work.

Якщо ви дотримуєтесь кроків на сторінці їх документації, це буде працювати досить легко. Просто почніть з верху.

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