Як я можу відстежувати залежності бази даних?

Оскільки внутрішні додатки розвиваються протягом кількох років, ви час від часу виявляєте, що існує ряд таблиць, які люди вважають, що вони більше не актуальні і хочуть скоротити їх. Які практичні методи ідентифікації залежностей від бази даних як у середовищі SQL, так і, можливо, далі в таких речах, як SSIS?

Я працював у місцях, де були прийняті досить жорстокі варіанти, такі як:

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

Я розумію, що SQL Server постачає інструменти для відстеження залежностей у цьому екземплярі, але, здається, вони мають труднощі, якщо у вас є бази даних для різних примірників. Чи є варіанти, які полегшують запити залежностей, можливо, відповідаючи на запитання типу "Де використовується цей стовпець?" з відповідями на кшталт "На цьому іншому сервері в цій збереженій процедурі" або "Над цим пакетом SSIS"?

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

1. Шукати код для використання з sys.sql_modules.definition: на нього посилається? Потім...
2. Перевірте дозволи: який код клієнта може викликати? Потім...
3. Профілер

Таким чином:

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

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

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

Дуже важко відстежувати залежності, коли весь код, який може потрапити в базу даних, не знаходиться в базі даних, тобто випадкові клієнти, які запитують базу даних.

EDIT: Для вирішення питання, що таблиця не може мати тригери 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
• Я навіть скріплюю всі об'єкти бази даних у сховищі.

У мене це ще не налаштовано, але врешті-решт я хочу реалізувати якийсь механізм пошуку індексу / центрального пошуку, який я міг би використати для пошуку конкретних таблиць, проростів тощо. . Тож старі об'єкти SQL ще не є великою проблемою, але я планую на майбутнє.

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

Існують різноманітні інструменти та методики для відстеження залежностей, які включають:

Інструменти, які я знаю:

• Переглядач залежності SQL Server (але може виникнути проблеми, якщо sp за допомогою таблиці створено до створення таблиці)
• Redgate SQL Deckerpender Tracker (через відповідь @Eric Хамфрі)
• 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 з _toBeDropped) і стежте за помилками
• Змініть дозволи та стежте за помилками
• Киньте предмет і моліться

Кілька років тому я намагався створити інструмент для перевірки подібних речей. Відповідь TL; DR полягає в тому, що я вважав, що неможливо зробити доступні ресурси на той час.

Де використовується цей стовпець?

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

Не оброблятиме посилання на SQL, але ви можете перевірити SQL Deckerpender Tracker Redgate . Це приємний інструмент візуалізації.

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

Звичайно, SSIS зазвичай підключатиметься безпосередньо до таблиць, тому, мабуть, це не дуже допоможе вашим потребам. Але коли розробники підключаються до вашої бази даних і скаржаться на необхідність чекати на вас (або той, хто виконує функції DBA), щоб зробити потрібні перегляди та проростки, ви можете сказати їм: "Будь-яку таблицю чи стовпець можна видалити чи перейменувати. Я" м зобов’язаний лише інформувати вас про зміни в поглядах і проростанні ". І їм потрібно лише зробити регресійне тестування на ці конкретні зміни.

TSQL: sys.dm_sql_referencing_entities або sys.sql_expression_dependitions може використовуватися наступне

Крім того, такі інструменти, як SQL Negotiator Pro, Redgate тощо, можуть візуально створювати це для вас, використовуючи графічний інтерфейс