December 3, 2017 at 8:44 pm
Comments posted to this topic are about the item Is This Database Being Used?
December 4, 2017 at 2:54 am
Nice article. We used traces on DBs we believed to be inactive. We worried about mystery monthly processes so needed a long running trace to be certain we identified this.
One of the biggest challenges was to get prioritisation agreed to carry out remedial work done to applications to deprecate old DBs once and for all. As far as a DBA is concerned a database is either in use or it is not. If it is in use then it needs backup/archive, suitable HADR, maintenance jobs etc.
As far as a business person is concerned DB usage is shades of grey. The impact (and costs) of their "hardly ever used" DB probably won't be understood and on shared servers difficult to assign a cost.
December 4, 2017 at 5:24 am
great article, getting evidence of things that are NOT in use is lways a complicated matter, mostly because nobody wants to think about that.
does someone have a stored procedure that can capture data from time to time and can share here too?
December 4, 2017 at 5:37 am
No matter which method you use to determine if a database is being used, it's not a good idea to immediately kill the database. To Dave's point, I'll typically take a final backup along with a "Tail Log" backup, which also takes the database offline and then I'll leave it like that for at least two monthly cycles and a quarterly cycle, whichever is the furthest out. And then I guard the final MDF and LDF locally (as well as on tape) until the year end cycle has passed. If we needed to drop the database because of space issues, having the MDF and LDF locally might not be feasible so I'll have a special tape made and keep that locally.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2017 at 7:32 am
Surprised you didn't mention it, but I use an extended events session that I leave running to capture the login and source (among a few others) for a lock_acquired event. I filter by database and I filter out our maintenance and sysadmin accounts.
December 4, 2017 at 7:46 am
To complicate things, there could be legacy jobs or reports that robotically access the database on a schedule, but it's defunct and no end user or business process really depends on it or even looks at it. That's why it's a best practice to state the purpose or business justification for a job within it's description, and also have one or more operators setup for each job, even if there are no routine email notifications. In this case the operators are really business owners who are there in case someone needs an actual human contact to vouch for the purpose or continued need of a process when it comes under scrutiny for some reason.
I'm speaking from the perspective of someone who helps manage a database environment containing 100+ production servers and 1000+ jobs. The first logic branch on my mental flowchart for troubleshooting jobs is: "Who who created this thing?" and the 2nd branch is "Do we actually need it?". Only when those questions are answered can I justify spending any serious time trying to fix or optimize it. Nothing makes me happier than to give the ax to some old resource hog of a job that's wasting server resources in addition to wasting DBA time.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 4, 2017 at 8:19 am
Yuri Padorin - Monday, December 4, 2017 7:32 AMSurprised you didn't mention it, but I use an extended events session that I leave running to capture the login and source (among a few others) for a lock_acquired event. I filter by database and I filter out our maintenance and sysadmin accounts.
If you measure something, it costs in clock cycles and memory used. While people say that EE is more efficient than a server side SQL Profiler Trace, I find there's not really much difference especially if someone forgets to turn the damned thing off. Also, as Eric suggested above, even if something isn't used, there may be some forgotten job somewhere that really serves no purpose. One does require some bit of esoteric knowledge of such things to either prevent something valuable from being turned off or, to reverse it all, something that is being used that actually provides no value from being turned off.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2017 at 12:24 pm
A lot of those counters have values since the last start time of the server. If you can restart the server, then track the database specific counters to see if any don't increase
December 4, 2017 at 2:14 pm
If we are trying to detect activity in a "unused" DB then the overhead of a trace or extended event should not be of concern.
I'd be more worried about the app that doesn't handle faulty connections gracefully
December 5, 2017 at 8:45 am
Just a heads up; some of the techniques discussed can be skewed (in use) by maintenance jobs like re-indexing.
December 5, 2017 at 9:16 am
Bert-701015 - Tuesday, December 5, 2017 8:45 AMJust a heads up; some of the techniques discussed can be skewed (in use) by maintenance jobs like re-indexing.
Which techniques and how are they skewed?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 5, 2017 at 12:21 pm
Jeff Moden - Tuesday, December 5, 2017 9:16 AMBert-701015 - Tuesday, December 5, 2017 8:45 AMJust a heads up; some of the techniques discussed can be skewed (in use) by maintenance jobs like re-indexing.Which techniques and how are they skewed?
I believe he's referring to scheduled index and statistics maintenance jobs performing reads and writes.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 5, 2017 at 12:57 pm
Eric M Russell - Tuesday, December 5, 2017 12:21 PMJeff Moden - Tuesday, December 5, 2017 9:16 AMBert-701015 - Tuesday, December 5, 2017 8:45 AMJust a heads up; some of the techniques discussed can be skewed (in use) by maintenance jobs like re-indexing.Which techniques and how are they skewed?
I believe he's referring to scheduled index and statistics maintenance jobs performing reads and writes.
Yes. And depending on when you run the query, all techniques listed except the dependency tracker could generate a false positive. I haven't found a foolproof way to determine if a database is used. These are all good options. Another option, if it's running, is the built in Data Collection.
December 5, 2017 at 1:11 pm
Bert-701015 - Tuesday, December 5, 2017 12:57 PMEric M Russell - Tuesday, December 5, 2017 12:21 PMJeff Moden - Tuesday, December 5, 2017 9:16 AMBert-701015 - Tuesday, December 5, 2017 8:45 AMJust a heads up; some of the techniques discussed can be skewed (in use) by maintenance jobs like re-indexing.Which techniques and how are they skewed?
I believe he's referring to scheduled index and statistics maintenance jobs performing reads and writes.
Yes. And depending on when you run the query, all techniques listed except the dependency tracker could generate a false positive. I haven't found a foolproof way to determine if a database is used. These are all good options. Another option, if it's running, is the built in Data Collection.
at least with extended events you can exclude events raised by specific logins, i.e. your agent service account or maintenance job proxy.
December 5, 2017 at 1:28 pm
Bert-701015 - Tuesday, December 5, 2017 12:57 PMYes. And depending on when you run the query, all techniques listed except the dependency tracker could generate a false positive. I haven't found a foolproof way to determine if a database is used. These are all good options. Another option, if it's running, is the built in Data Collection.
I don't believe there is a foolproof way. That's why saving the last backup and data, log files off somewhere is a good idea. You need a way to bring it back online if needed. And that can be more than a years time away. There are ways to make guesses if a database is needed but that's about it.
Sue
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply