During my tenure at my first job as a DBA, my day-to-day break down looked something like this:

 

A Breakdown of how Database Administrators spend their time

 

This was due to me being the latest in a long line of primarily self-taught DBAs. I spent about half my day responding to issues caused at least in part by our lack of maintenance plan, and 15% of my day trying to play catch up, as a 1 man operation (there was a second DBA, but they primarily had him on dev projects) trying to get a bulky legacy system up to some kind of recent standard.

 

 

 

For DBAs we work with, the break down in the rare healthy systems seems to look a bit like this:

 

Meetings 15%

Maintenance 10%

Tuning   10%

Backups/Testing 10%

Responding to Alerts 10%

System/process improvements 35%

Prod deployments 10%

 

These systems have far fewer fires, much better up time, and DR events, when they do happen, result in far less data loss. Prod deployments generally occur on a specific day/cycle with occasional necessary hotfixes just after, and occasional emergency release type situations.

 

After we give them the use of our flight monitoring tool it looks more like this:

How DBAs spend their time with proper monitoring

This may not look significantly different, but the index automated index suggestions improve the efficacy of the tuning efforts, and allow the DBA to put additional focus on query performance. The maintenance performed using our automated health check allows twice the servers to be checked and have their issues addressed in half the time, resulting in fewer alerts, and finally the backup monitoring and organized maintenance schedules, and the ability to track regular failures easily allows the user to spend less time fighting with backup schedules leaving only the regular DR tests. This allows the DBA to focus half of their working hours on initiatives to improve the system. Commonly these days the initiatives include: addressing scaling issues, moving to the cloud, implementing and improving security, moving from SSIS to azure devops, identifying antiquated products and processes that can be removed, saving budget directly or reducing unnecessary load on servers.