Как узнать, используется ли база данных SQL Server?


33

Мы собираемся списать экземпляр SQL Server, на котором еще есть несколько баз данных.

Как я могу определить, используются ли они пользователями или веб-приложением?

Я нашел ветку форума с запросом T-SQL, который вы можете запустить, чтобы получить дату последнего запроса. Кажется, это работает, но я хочу знать, достаточно ли эта информация для удаления баз данных. Это?

Если у вас есть альтернативные методы, это также поможет.


1
Много отличного обсуждения ниже, но также смотрите этот пост в блоге .
Аарон Бертран

Ответы:


29

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

Вместо того, чтобы удалять базы данных из-под контроля, поместите их в положение OFFLINE, чтобы запретить доступ без их удаления, или в режиме RESTRICTED_USER, чтобы ограничить доступ. Делая это, вы можете оставить их в этом состоянии на месяц или два, чтобы проверить и посмотреть, есть ли случайное использование.

Вы также можете использовать фильтрацию трассировки профилировщика на стороне сервера в этой базе данных.


24
Правило № 1 быть администратором базы данных: никогда не вносите никаких изменений, от которых вы не сможете быстро отказаться, если это необходимо.
Гай

14

Вот методы, которые я использовал в прошлом:

  1. Отключить базу данных / отключить
  2. DENY пользователь / доступ для входа
  3. Профилирование трассировки

Проблема в следующем: как долго вы ждете, чтобы убедиться, что никто не собирается получить доступ к данным? Для финансовых данных у вас есть некоторые элементы, выполняемые ежедневно, еженедельно, ежемесячно, ежеквартально, полугодово и ежегодно. Но достаточно ли одного года? Я также видел запросы на то, чтобы данные оставались доступными не менее 7 лет, и в одном случае мне сказали, что данные в одной системе должны быть там всегда, даже если никто не использовал их.

Лучший совет заключается в следующем: что бы вы ни делали, чтобы отключить доступ, убедитесь, что вы можете включить его немедленно. Я обнаружил, что для этого лучше всего работал детатч. Я просто написал бы сценарий присоединения и дал указание моей команде «если кто-нибудь спросит, где он, запустите этот сценарий». Это дало нам лучший шанс вернуть вещи как можно быстрее.


Я думал об этом, достаточно ли времени для мониторинга использования базы данных. Вы просто взяли природу SQL Server и сделали это суждение?
Джсауни

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

13

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

Я бы обычно проверял информацию о статистике виртуальных файлов, чтобы узнать, происходит ли чтение или запись на уровне файла ОС. Даже если база данных НЕ активна, вы все равно увидите небольшие операции чтения / записи, если вы делаете резервные копии журналов, полные резервные копии и т. Д. ... но это также даст вам представление об активности чтения / записи в этой базе данных.

Прежде чем удалять любую базу данных, я должен убедиться, что у вас есть как минимум 2 или 3 читаемых резервных копии (проверьте их) в разных местах. Вы никогда не знаете, когда они вам нужны.


8

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

Это очень здорово, если работает хорошо. Могу я спросить, почему вы берете объединение и сравниваете с login_time? И почему вы не включили last_user_update? Является ли это умной попыткой увидеть, получает ли база данных INSERTS, но никто никогда не запрашивает ее? Или это DMV может включать все метки времени NULL?
Джейсон

2

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

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

Поскольку заостренный босс был готов разрешить «полную и полную» документацию, вики была категорически запрещена, а сокращение персонала привело к резкому сокращению документации, соответствующей стандарту.

Если бы это зависело от меня, на каждом сервере была бы вики-страница с именами контактов для каждой базы данных (и, возможно, краткое описание того, для чего эта база данных). Любая база данных, недокументированная в вики, будет честной игрой для удаления.

У нас был один крупный финансовый клиент, который все еще использовал SQL Server 2000 еще в 2009 году, поэтому нам нужно было поддерживать один экземпляр SQL Server 2000 до тех пор, пока этот клиент окончательно не перешел на SQL Server 2005.


2

Еще две альтернативы:

  1. Создайте в БД триггеры, которые будут уведомлять вас (или сохранять в таблицах) о любых действиях.
  2. Включить аудит на БД.

    • Зависит от вашей версии БД.

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

2
Не могли бы вы уточнить, как это решает исходную проблему?
Дезсо
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.