Managing the mystery database Dustin Dorsey Managing the mystery database

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

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

Evaluations!

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

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

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

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

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

Shut it off and see who screams!

No perfect solution

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

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?

Database properties Information from sys.databases Extended properties

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

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

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

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

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