Як я можу визначити, чи все ще використовується база даних SQL Server?

Ми хочемо вивести з експлуатації екземпляр SQL Server, який має ще пару баз даних.

Як я можу дізнатися, чи ними користуються користувачі чи веб-додаток?

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

Якщо у вас є альтернативні методи, які також допоможуть.

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

Замість того, щоб випадати бази даних з рук, поставте їх або ВІДКЛЮЧЕНО для запобігання доступу без їх випадання, або в режимі RESTRICTED_USER для обмеження доступу. Виконуючи це, ви можете залишити їх у такому стані на місяць-два, щоб перевірити і перевірити, чи є випадкові користування.

Ви також можете використати фільтрування слідів профілера на базі сервера на цій базі даних.

Це методи, якими я користувався в минулому:

1. Візьміть базу даних в режимі офлайн / Очистити
2. ДЕНІ користувач / доступ для входу
3. Профілерний слід

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

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

Я погоджуюся з Ніком з його порадою. Якщо вам потрібно бути впевненим, вам доведеться скористатися програмою Profiler (службовий слід), тому що деякі запити SQL не будуть кешовані або з будь-якої причини кеш процедури може бути очищений.

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

Перш ніж викинути будь-яку базу даних, я переконайтеся, що у вас є принаймні 2 чи 3 читання резервних копій (тестуйте їх) в окремих місцях. Ви ніколи не знаєте, коли вони вам потрібні.

Наступний запит показує БД, які не використовувались з моменту останнього перезавантаження, не покладаючись на плани запитів, що зберігаються в кеш-пам'яті, оскільки він показує IO користувача проти індексів (і купи). Це на зразок використання статистики віртуальних файлів, але DMV, що використовується тут, виключає активність вводу-виводу з резервного копіювання. Не потрібно тримати слід провідника, не потрібні тригери чи аудит. Звичайно, якщо ви часто перезапускаєте свій SQL-сервер (або часто додаєте / відключаєте бази даних), це може бути не так :-)

Сказавши це, все-таки погоджуйтеся, що навіть якщо цей запит, здається, підтверджує, що БД може бути скинутий, обов'язково зробіть ОФЛАЙН / відключити або заборонити користувачеві доступ на деякий час, плюс будь-яка ретельність запитання, перш ніж насправді випаде!

select [name] from sys.databases 
where database_id > 4
AND [name] NOT IN 
(select DB_NAME(database_id) 
from sys.dm_db_index_usage_stats
where coalesce(last_user_seek, last_user_scan, last_user_lookup,'1/1/1970') > 
(select login_time from sys.sysprocesses where spid = 1))

Я працював у місці, де було велика кількість осиротілих та напівсирілих баз даних. Важко було сказати, чи справді вони осиротіли, оскільки багато завдань були сезонними чи щорічними - так що веб-сайт працює лише 3-4 місяці на рік (як приклад, форми W2 потрібно подавати в електронному вигляді 1/31, тому обробка веб-сайту вони тривали лише з середини січня до кінця квітня).

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

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

Якби я не залежав від цього, існувала б сторінка вікі на сервері з іменами контактів для кожної бази даних (і, можливо, короткий опис того, для чого потрібна база даних). Будь-яка база даних, недокументована на wiki, була б чесною грою для видалення.

У нас був один великий фінансовий клієнт, який ще використовував SQL Server 2000 ще в 2009 році, тому нам довелося тримати один екземпляр SQL Server 2000, поки цей клієнт нарешті не перейшов на SQL Server 2005.

Ще дві альтернативи:

1. Створіть в БД тригери, які будуть повідомляти вас (або зберігати в таблицях) про будь-яку діяльність.

2. Увімкнути аудит у БД.

   • Залежить від вашої версії БД.

Наступне рішення показує тимчасові загальні, чисті та брудні сторінки в МБ для конкретних баз даних у вашому екземплярі (знайдені в Інтернеті та трохи змінені):

SELECT
    (CASE WHEN ([database_id] = 32767) THEN 'Resource Database' ELSE DB_NAME (database_id) END) AS 'Database Name',
    COUNT(*) *8/1024 AS [TotalPages in MB],
    SUM(CASE WHEN ([is_modified] = 1) THEN 0 ELSE 1 END) *8/1024 AS [CleanPages in MB],
    SUM(CASE WHEN ([is_modified] = 1) THEN 1 ELSE 0 END) *8/1024 AS [DirtyPages in MB]
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY DB_NAME(database_id)

або

select value [DBid],attribute, last_execution_time ,text
from
sys.dm_exec_query_stats
cross apply
sys.dm_exec_plan_attributes(plan_handle)
cross apply
sys.dm_exec_sql_text(plan_handle)
where  attribute = 'dbid' 
order by last_execution_time desc

або

select value [DBid],attribute, last_execution_time ,text
from
sys.dm_exec_query_stats
cross apply
sys.dm_exec_plan_attributes(plan_handle)
cross apply
sys.dm_exec_sql_text(plan_handle)
--where dbid=8
where 
      text like '%idAdministrator%' and
      attribute = 'dbid' 
      and value>= 5 -- dbid >=5 for user databases but include resource database which
                     --you can exclude by its numer I don't remember at the moment
order by last_execution_time desc