С чего начать разбираться в неизвестной базе данных

Итак, название подводит итог.

У меня есть база данных 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) Включите сеанс расширенных событий (или трассировку профилировщика на стороне сервера, если вы используете pre-SQL 2012) примерно на час во время использования приложения. Вы также можете попросить пользователя выполнить различные действия в приложении в определенном порядке, чтобы вы могли соотнести его с трассировкой / сеансом.

Полезное предложение: если вы можете вообще изменить строку подключения, используемую приложением, добавьте «; Application Name = 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 также поддерживает документирование баз данных Windows Azure SQL.

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

Поскольку я когда-то был в подобной ситуации, я могу сказать вам, что это будет трудная или невозможная работа. У меня был только исходный код (> 100 тыс. Строк кода), работающий сервис, работающая база данных (~ 50 таблиц) и никакой документации, и никто не спросил об этом, кроме пользователя этого приложения и копии базы данных и сервисов, работающих в тестовая среда (которая была на несколько номеров впереди, но без исходного кода). Еще одним требованием было то, что сервисы должны были работать круглосуточно, потому что они были внешними по отношению к клиентам. Ситуация возникла потому, что большинство сотрудников ушли примерно в одно и то же время, в том числе разработчики и документация исчезли в хаосе. Мне потребовалось более 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