SQL Serverデータベースがまだ使用されているかどうかを確認するにはどうすればよいですか？

いくつかのデータベースがまだ残っているSQL Serverインスタンスの使用停止を検討しています。

それらがまだユーザーまたはWebアプリケーションによって使用されているかどうかを確認するにはどうすればよいですか？

最終クエリの日付を取得するために実行できるT-SQLクエリを含むフォーラムスレッドを見つけました。動作しているようですが、この情報がデータベースを削除するのに十分かどうかを知りたいです。それは...ですか？

同様に役立つ代替方法がある場合。

キャッシュから削除されて見逃したアイテムや、使用頻度の低いデータベースを考慮する必要があります。

データベースを手動でドロップするのではなく、データベースをドロップせずにオフラインにするか、アクセスを制限するRESTRICTED_USERモードにします。これを行うと、それらを1か月または2か月その状態のままにして、時々使用されるかどうかを確認できます。

また、そのデータベースでサーバー側プロファイラートレースフィルタリングを使用することもできます。

これらは私が過去に使用した方法です：

1. データベースをオフラインにする/切り離す
2. ユーザー/ログインアクセスを拒否する
3. プロファイラートレース

問題はこれです：誰もデータにアクセスしないと確信するまで、どれくらいの時間待ちますか？財務データの場合、一部のアイテムは毎日、毎週、毎月、四半期ごと、半年ごと、年ごとに実行されます。しかし、1年で十分ですか？また、データを少なくとも7年間利用できるようにする要求を見てきました。あるケースでは、1つのシステムのデータは、誰も使用していなくても永遠に存在する必要があると言われました。

最善のアドバイスは次のとおりです。アクセスをオフにするために何をするにしても、すぐにオンに戻すことができることを確認してください。これには、分離が最も効果的であることがわかりました。再アタッチをスクリプトで記述し、「どこにいるのかと尋ねられたら、このスクリプトを実行してください」とチームに指示します。それにより、できるだけ早く物を戻す最高のチャンスが得られました。

ニックのアドバイスに同意します。確認する必要がある場合は、SQLクエリの一部がキャッシュされないか、何らかの理由でプロシージャキャッシュがパージされる可能性があるため、プロファイラー（サービス側トレース）を使用する必要があります。

通常、仮想ファイルの統計情報もチェックして、OSファイルレベルで読み取りまたは書き込みが発生しているかどうかを確認します。データベースがアクティブではない場合でも、ログバックアップ、フルバックアップなどを行っている場合、小さな読み取り/書き込みが表示されますが、そのデータベースでの読み取り/書き込みアクティビティのアイデアも得られます。

データベースを削除する前に、少なくとも2つまたは3つの読み取り可能なバックアップ（テスト）を別々の場所に置いてください。いつ必要になるかわかりません。

次のクエリは、インデックス（およびヒープ）に対するユーザーIOを示しているため、キャッシュに保持されているクエリプランに依存することなく、最後の再起動以降使用されていないDBを示しています。これは、仮想ファイルの統計情報を使用するのと同じようなものですが、ここで使用されるDMVはIOアクティビティをバックアップから除外します。プロファイラーのトレースを実行し続ける必要はありません。トリガーや監査は必要ありません。もちろん、SQLサーバーを頻繁に再起動する（またはデータベースを頻繁にアタッチ/シャットダウンする）場合、これは進むべき方法ではないかもしれません:-)

それを言っても、まだこのクエリはDBは、落下させることができることを確認すると思われる場合でも、ということに同意間違いなく OFFLINE /デタッチを行うか、いくつかの時間のためのユーザーのアクセスを拒否し、プラスの前に実際に落下周り尋ねるのいずれかのデューディリジェンス！

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月末までしか実行されませんでした）。

行われたのは、次の組み合わせです：
*すべての開発者にデータベースを使用しているか、他のデータベースを使用しているかを尋ねます（これらの電子メールは毎月送信されるか、バックアップに時間がかかりすぎます）。
*データベースをオフラインにして、苦情を申し立てている人を確認します。
*文句を言う人を見るためにサーバーの名前を変更します。

先のとがった髪のボスだけが「完全かつ完全な」ドキュメントを許可することを望んでいたので、ウィキは明示的に禁止され、スタッフの削減は標準を満たすドキュメントの劇的な減少につながります。

私次第であれば、各データベースの連絡先名（およびデータベースの目的の簡単な説明）が記載されたWikiページがサーバーごとにあります。wikiに文書化されていないデータベースは、削除するのに公平なゲームです。

2009年にはまだSQL Server 2000を使用していた大規模な金融クライアントが1台あったため、そのクライアントが最終的にSQL Server 2005に移行するまで1つのSQL Server 2000インスタンスを実行し続ける必要がありました。

別の2つの選択肢は次のとおりです。

1. アクティビティを通知する（またはテーブルに保存する）トリガーをDB上に作成します。

2. DBで監査を有効にします。

   • DBのバージョンに依存します。

次のソリューションでは、インスタンスの下にある特定のデータベースの一時的な合計ページ、クリーンページ、ダーティページを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