답변:
캐시에서 제거되었거나 누락 된 항목 또는 자주 사용하지 않는 데이터베이스에 대해 걱정해야합니다.
데이터베이스를 수동으로 삭제하지 않고 데이터베이스를 삭제하지 않고 액세스를 방지하기 위해 OFFLINE 또는 액세스를 제한하기 위해 RESTRICTED_USER 모드에 놓으십시오. 이렇게하면 한두 달 동안 해당 상태로 두어 가끔 사용되는지 확인하고 확인할 수 있습니다.
해당 데이터베이스에서 서버 측 프로파일 러 추적 필터링을 사용할 수도 있습니다.
다음은 내가 과거에 사용한 방법입니다.
문제는 이것입니다. 아무도 데이터에 액세스하지 않을 것이라고 확신하기 전에 얼마나 기다려야합니까? 재무 데이터의 경우 일부 항목이 매일, 매주, 매월, 분기 별, 반기 별 및 연간 실행됩니다. 그러나 1 년이면 충분합니까? 또한 데이터를 최소 7 년 동안 사용할 수 있도록 요청하는 것을 보았으며, 어떤 경우에도 아무도 사용하지 않더라도 한 시스템의 데이터가 영원히 있어야한다고 들었습니다.
최선의 조언은 다음과 같습니다. 액세스를 해제하기 위해 무엇을 하든지 즉시 다시 켤 수 있는지 확인하십시오. 나는 분리가 가장 잘 작동한다는 것을 알았습니다. 나는 단순히 다시 첨부를 스크립트로 작성하고 "누군가가 어디에 있는지 묻는다면이 스크립트를 실행하십시오"라고 팀에 지시합니다. 그것은 우리에게 가능한 한 빨리 물건을 되돌릴 수있는 최고의 기회를 주었다.
나는 그의 조언으로 Nic에 동의합니다. 확실해야하는 경우 일부 SQL 쿼리가 캐시되지 않거나 어떤 이유로 든 프로 시저 캐시를 제거 할 수 있기 때문에 프로파일 러 (서비스 측 추적)를 사용해야합니다.
일반적으로 가상 파일 통계 정보를 확인하여 OS 파일 수준에서 발생하는 읽기 또는 쓰기가 있는지 확인합니다. 데이터베이스가 활성화되지 않은 경우에도 로그 백업, 전체 백업 등을 수행하는 경우에도 작은 읽기 / 쓰기가 표시되지만 해당 데이터베이스에 대한 읽기 / 쓰기 작업에 대한 아이디어도 제공됩니다.
데이터베이스를 삭제하기 전에 별도의 위치에 최소한 2 또는 3 개의 읽기 가능한 백업 (테스트)이 있는지 확인하십시오. 필요할 때 알 수 없습니다.
다음 쿼리는 인덱스 (및 힙)에 대한 사용자 IO를 표시하므로 캐시에 보유 된 쿼리 계획에 의존하지 않고 마지막 재시작 이후 사용되지 않은 DB를 보여줍니다. 이것은 가상 파일 통계를 사용하는 것과 비슷하지만 여기서 사용 된 DMV는 IO 활동을 백업에서 제외합니다. 프로파일 러 추적을 계속 실행할 필요가 없으며 트리거 또는 감사가 필요하지 않습니다. 물론 SQL 서버를 자주 다시 시작하거나 데이터베이스를 자주 연결 / 종료하는 경우에는 갈 수 없습니다. :-)
아직이 쿼리는 DB 드롭 할 수 있음을 확인 보인다하더라도 그 동의 그런 말로 미루어 보아, 확실히 오프라인 / 분리 할 또는 약간의 시간에 대한 사용자 액세스를 거부 플러스 전에 실제로 주위에 물어 하락의 실사!
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로 전자식으로 제출해야하므로 웹 사이트 처리) 1 월 중순부터 4 월 말까지만 운영되었습니다).
수행 된 작업은 다음과 같은 조합입니다.
* 모든 개발자에게 데이터베이스 또는 다른 데이터베이스를 사용 중인지 묻습니다 (이 이메일은 월별 또는 백업 시간이 너무 오래 걸릴 때마다 전송 됨).
* 데이터베이스를 오프라인으로 전환하여 누가 불만을하는지 확인하십시오.
누가 불만을 보도록 서버 이름을 바꿉니다.
뾰족한 머리 보스는 "완전하고 완전한"문서를 기꺼이 허용하기 때문에 위키는 명시 적으로 금지되었으며 직원 축소는 표준을 충족시키는 문서의 급격한 감소로 이어졌습니다.
그것이 나에게 달려 있다면, 각 데이터베이스에 대한 연락처 이름을 가진 서버 당 위키 페이지가있을 것입니다 (그리고 데이터베이스의 내용에 대한 간단한 설명). 위키에 문서화되지 않은 데이터베이스는 삭제하기에 적합합니다.
2009 년까지 SQL Server 2000을 계속 사용하고있는 하나의 대규모 금융 클라이언트가 있었으므로 해당 클라이언트가 최종적으로 SQL Server 2005로 이동할 때까지 하나의 SQL Server 2000 인스턴스를 계속 실행해야했습니다.
다음 솔루션은 인스턴스의 특정 데이터베이스 (인터넷에서 발견되고 약간 수정 됨)에 대한 임시 총계의 깨끗하고 더러운 페이지 (MB)를 보여줍니다.
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