Как я могу отслеживать зависимости базы данных?

Поскольку внутренние приложения развиваются в течение ряда лет, вы время от времени обнаруживаете, что существует ряд таблиц, которые, по мнению людей, больше не актуальны и которые нужно отбирать. Каковы практические методы для определения зависимостей базы данных, как в среде SQL, так и, возможно, в таких вещах, как SSIS?

Я работал в местах, где были приняты довольно жестокие варианты, такие как:

• Отбросьте сначала, задавайте вопросы позже (может убить сборку хранилища данных, если она попытается извлечь таблицу, которая больше не существует)
• Сначала удалите разрешения и дождитесь сообщений об ошибках (может привести к тихим ошибкам, если сбои обработаны неправильно)

Я ценю, что SQL Server поставляется с инструментами для отслеживания зависимостей в этом экземпляре, но, похоже, они не справляются, если у вас есть базы данных в разных экземплярах. Существуют ли варианты, облегчающие запрос зависимостей, например, ответы на вопросы типа «Где используется этот столбец?» с такими ответами, как «На этом другом сервере в этой хранимой процедуре» или «В этом пакете служб SSIS»?

Нет простого способа сделать это. Триггеры не работают, как будто вы выбираете из таблицы, триггер не срабатывает. Лучший способ сделать это - заставить разработчиков отслеживать, что они используют. Когда что-то будет отброшено, сверьтесь со всеми командами разработчиков, и после того, как все подпишутся, переименуйте объект. Тогда ничто не сломается в течение месяца или до, объект может быть безопасно отброшен.

1. Поиск кода для использования с sys.sql_modules.definition: на него ссылаются? Затем...
2. Проверьте права доступа: какой код клиента может вызвать это? Затем...
3. Profiler

Таким образом:

• Для таблицы без ссылки и без разрешений она не используется.
• Без ссылок и некоторых разрешений, запустите профилировщик, чтобы увидеть использование
• Без разрешений и ссылок, добавьте регистрацию использования

То, что я сделал раньше, - это сделал таблицу представлением, маскирующим таблицу, а затем заставив представление работать плохо: (само по себе перекрестное соединение). Вы фактически не удаляете это, но вы действительно генерируете тайм-ауты клиента или жалобы ...

Один быстрый способ, который я использовал в прошлом (и он действительно зависит от размера таблиц, количества индексов и т. Д.), - это добавить триггер, который регистрирует метку времени при выполнении действия над таблицей. Как я уже сказал, это может привести к проблемам с производительностью, поэтому необходимо соблюдать осторожность - также следите за тем, чтобы ваша таблица журналов не использовала идентифицирующие поля, поскольку это может испортить некоторый старый код, использующий @@ IDENTITY. Конечно, это может просто показать, что функция в приложении некоторое время не использовалась.

Очень трудно отслеживать зависимости, когда весь код, который может попасть в базу данных, отсутствует в базе данных, т.е. случайные клиенты, запрашивающие базу данных.

РЕДАКТИРОВАТЬ: для решения вопроса о том, что таблица не может иметь триггеры SELECT, вот еще один вариант, который должен работать, если ваши таблицы имеют индексы (проверено только в 2008 году).

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' 

но учтите, что таблица статистики использования очищается при перезапуске, отключении и т. д. сервера, поэтому вам необходимо настроить задание для сбора данных. Немного взлома, я знаю.

Один из способов, который я использовал в прошлом, заключался в создании списка кандидатов для удаления, а затем переименования их и поиска сбоев.

Как я установил список был:

1. увидеть, какие таблицы не используются в текущих хранимых процедурах, триггерах и функциях

2. пустые таблицы (ноль записей);

3. таблицы без ссылок (таблицы, которые не имеют каких-либо связей);

4. узнать, какие таблицы не использовались с момента запуска сервера БД (DMV)

После построения списка в текстовом файле я создал пакетный скрипт, который будет анализировать наши файлы .cs (у нас есть только проекты .net) из локальной сопоставленной папки контроля версий и посмотреть, используются ли эти таблицы в файлах .cs ( не должно было случиться, но эй .. у меня были сюрпризы). Если нет, тогда понятно, если да, то мы строим список и даем разработчикам проверить, что этот модуль все еще используется.

Короче, предыдущие парни правы, серебряной пули нет.

Политика, которую я реализую в своей компании, заключается в том, чтобы все, что касается SQL Server, находилось под централизованным контролем.

• проекты asp.net
• Проекты SSRS
• Проекты SSIS
• Я даже записываю все объекты базы данных в своеобразный репозиторий.

У меня его еще нет, но в итоге я хочу реализовать какой-то механизм индексного / центрального поиска, который я мог бы использовать для поиска определенных таблиц, sprocs и т. Д. Мы на самом деле новый SQL Server Shop - преобразование из FoxPro , Так что старые объекты SQL пока не представляют большой проблемы, но я планирую на будущее.

Проблема, которую я вижу с подходом переименования / отслеживания, состоит в том, что некоторые вещи выполняются только раз в год, а не каждый год. Не говоря уже о различных специальных вещах, которые люди просят вас написать, а затем просят снова месяцы или годы спустя.

Существуют различные инструменты и методы для отслеживания зависимостей, в том числе:

Инструменты, которые я знаю:

• Средство просмотра зависимостей SQL Server (но могут возникнуть проблемы, если sp с использованием таблицы был создан до ее создания)
• Redgate SQL Dependency Tracker (через ответ Эрика Хамфри)
• Resharper (инструмент .net, который можно использовать для просмотра путей вызова, я думаю, его можно использовать для отслеживания использования ключевых вызовов SQL)

методы

• Код ищет использование объектов SQL (хотя дублирует некоторые из инструментов выше)

• Посмотрите статистику использования (то есть: когда последний раз вызывался объект SQL), я использую приведенный ниже 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

Примечание . Таблица статистики использования очищается при перезапуске, отключении и т. Д. Сервера, поэтому вам необходимо настроить задание для сбора данных. Немного взлома, я знаю. (из @Miles D)

методы

• Поиск последнего использования (см. Выше статистику использования)
• Поиск, где он используется (см. Инструменты)
• Обзор использования кода с разработчиками (через @MrDenny)
• Переименуйте объект (то есть: post / prefix with _toBeDropped) и следите за ошибками
• Измените разрешения и следите за ошибками
• Бросай объект и молись

Несколько лет назад я пытался создать инструмент для проверки подобных вещей. Ответ TL; DR заключается в том, что в то время я не мог делать с доступными ресурсами.

Где используется этот столбец?

Этот вопрос усложняется, когда вы понимаете, что select *из таблицы, в которой находится столбец , используется ряд запросов, представлений и хранимых процедур . Затем вам нужно взглянуть на программы, использующие эти результаты - поэтому вам нужен сканер / индексатор / анализатор способен читать исходный код, который может быть C #, Delphi, Java, VB, ASP (классический) и т. д., чтобы попытаться найти каждую ссылку на этот столбец. Затем вам нужно проанализировать эти программы, чтобы попытаться определить, вызывается ли этот код.

Не обрабатывает ссылки на SQL, но вы можете проверить отслеживание зависимостей SQL от Redgate . Это хороший инструмент визуализации.

Это не совсем ответ на ваш вопрос, но я думаю, что стоит упомянуть: это одна из причин, почему все системы за пределами вашей базы данных должны взаимодействовать через представления и следы . У вас есть сценарии сборки для них в доступных для поиска файлах .sql, так что вы можете легко увидеть, используется ли определенная таблица или столбец извне.

Конечно, SSIS обычно подключается напрямую к таблицам, так что это, вероятно, не сильно поможет вашим потребностям прямо сейчас. Но когда разработчики подключаются к вашей базе данных и жалуются на необходимость ждать, пока вы (или кто-либо, выступающий в роли администратора БД) создаст нужные им представления и sprocs, вы можете сказать им: «Любая таблица или столбец может быть удалена или переименована. Я» Я только обязан держать вас в курсе изменений в представлениях и sprocs. " И они должны только сделать регрессионное тестирование для этих конкретных изменений.

TSQL следующие могут быть использованы sys.dm_sql_referencing_entities или sys.sql_expression_dependencies

В качестве альтернативы такие инструменты, как SQL Negotiator Pro, Redgate и т. Д., Могут генерировать это визуально для вас с помощью графического интерфейса.