1. Managing the mystery database
Dustin Dorsey
Managing the mystery database

2. Who am I?
Managing Database Engineer for Lifepoint Health (Fortune 500 company) -
LinkedIn – linkedin.com/in/dustindorsey
Twitter
Blog -
I have been working with SQL Server for over a decade in development and administration
Active speaker and blogger

3. Thank you for being my friend!
And thank you to all the other sponsors and organizers!!!

4. Evaluations!

5. Agenda What are mystery databases? Talk about why we even care
Discuss the challenges and cost implications associated with mystery databases
Look at things you can do to figure out what these databases are used for

6. What is a mystery database?
A database that you are responsible for supporting, but have no idea what it is

7. Some cost implications
(Licensing)
(Resources)
(Storage)
(People)

8. Other implications (Upgrades) (Migrations) (Troubleshooting)
(Scheduling)
(Decommissions)

9. We need to investigate!
WHO, WHAT, WHEN, WHERE, WHY, HOW

10. Shut it off and see who screams!

11. No perfect solution

12. Non-technical list Ask around… Someone may know something
Look for documentation
Look for old support requests

13. Who is using this database?
Check to see who is actively connecting to the database
Check to see who has access
Tracking connection activity over time
Sp_whoisactive, sp_blitzwho, sp_who, etc.
Look at users who have access to the server… Check database permissions that indicate permissions where explicitly granted
Start tracking connections over time
Benefits:
Know distinctly which databases are getting connected to and how often
Tracking for what accounts are being used… helpful for cleanup of old accounts
Understanding of what hosts connections are coming from, this is useful when you need to know where the apps are located
See specifically what is accessing a database… and avoid false positives such as maintenance scripts\backups\monitoring\etc
Decommissions
What programs are connecting?

14. Database properties
Information from sys.databases
Extended properties

15. Track database growth
Check the size of your backups to see if they are growing
Check to see if the transaction log is growing

16. Database usage Look for plans in the plan cache
Review index usage stats (read\writes)
View Transactions\sec perfmon counters
Use extended events\profiler
Plan cache – Good indicator but may not catch everything due to memory pressure or RECOMPILE hints

17. Database design Review the database design Profile the data
By carefully naming objects, you can perform a lot of self-documentation

18. Where can I start… Run periodic self-audits
Start by looking at places with the most impact
Largest databases
Databases with the least resource consumption
Old versions of SQL

19. Questions? Problems with connection tracking:
* You are tracking connections on an interval
* Logins may not be connecting to the database they are querying
* Sysprocesses can only indicate one database. Sometimes multiple databases run across multiple servers