How can I tell if a SQL Server database is still being used?

You would have to be concerned with items that have been purged from the cache and that you have missed, or for databases that have infrequent usage.

Rather than dropping the databases out of hand put them either OFFLINE to prevent access without dropping them or in RESTRICTED_USER mode to limit access. Doing this you can leave them in that state for a month or two to check and see if there is occasional usage.

You could also look to use a server side profiler trace filtering on that database.


These are the methods I have used in the past:

  1. Take database offline/ Detach
  2. DENY user/login access
  3. Profiler trace

The trouble is this: how long do you wait before you are certain that nobody is going to access the data? For financial data, you have some items run daily, weekly, monthly, quarterly, semi-annual, and annual. But is a year long enough? I have also seen requests to have data kept available for at least 7 years, and in one case I was told that the data in one system needed to be there forever, even though nobody was using it.

The best advice is this: whatever you do to turn off access, make sure you can turn it back on immediately. I found that the detatch worked best for this. I would simply script out the reattach and instruct my team "if anyone ever asks where it is, run this script". That gave us the best chance to put things back as quickly as possible.


I agree with Nic with his advice. If you need to be sure, then you would have to go with Profiler (Service side trace) because some of the SQL queries won't be cached or for any reason the procedure cache could be purged.

I would normally check the virtual file stats information also to see if there are any reads or writes happening at the OS file level. Even if the database is NOT active you will still see a small reads/writes if you are taking log backups, full backups etc... but that will also give you an idea of read/write activity on that database.

Before dropping any database, I would make sure you have at-least 2 or 3 readable backups (test them) in separate locations. You never know when you need them.