Each work day, you have responsibilities as a Database Administrator (DBA). Those responsibilities vary, based on the type of business, type of administrator, and type of databases. Generally speaking, there are specific responsibilities that you should include in your daily activities, which you can customize to your specific environment.
1. Checking on Servers
Whether you’re responsible for the hardware or not, there are plenty of things you’ll want to do to check on your servers each day. Checking Windows Event, SQL Server Logs, and reviewing the SQL Server Agent are daily activities:
- DBAs and the SQL Server Agent
- DBAs and SQL Server Logs
- DBAs and Windows Event Logs (not always accessible to you as a DBA)
In some environments as a DBA you may not have enough time to review details for every server every day. If so, set up a schedule where you make sure to keep looking at your most important (most mission critical) servers daily and then cycle through them daily or weekly, with reviews of non-essential servers based on priority, etc.
Performance tuning and throughput will typically be part of your world as a DBA. Without performance baselines and other throughput benchmarks to compare current activity against, you’ll quickly find that you’re unsure of what is normal performance and what is a performance issue. Happily, baselines are pretty easy to set up.
3. Testing and Validating Backups AND Restores
Absolutely everything you do (short of security) takes a back seat behind this major concern. If you’re not regularly testing your backups to make sure you can restore them (under a variety of different scenarios or simulated emergencies) then you’re not building the skills necessary to respond to a disaster and running the risk that a change somewhere within your environment has ruined your ability to either get complete backups or destroyed your ability to restore the data in the event they are needed. Moreover, regular testing helps you verify that you’re staying within your SLAs by helping ensure that you’re able to meet your required RPO and RTO.
4. Performance Analysis and Tuning
With baselines and a sense of what your current workloads are, you’ll be able to spot when, where, and how problems occur. From there, you’ll typically spend a decent amount of your time as a DBA tuning those operations (and working carefully against production data in some cases) to consume fewer resources. As a DBA performance isn’t exactly your primary concern—scalability is. And scalability (or the ability to handle more load) is enabled when you don’t have slow running queries and operations capitalizing hardware resources on your server. Tuning and tweaking and ensuring proper indexes and the rest is what you do as a DBA in almost all database environments.
5. Coordinating Data Pushes and Changes
Depending upon your role, your environment, and your data you might be periodically helping to push application changes and upgrades (with corresponding tweaks to schema and code) or regularly ensuring that data pushes from staging to production and the like are operating efficiently.
6. Patch Management
This is something you’ll commonly need to schedule, address, and coordinate as well. You must keep your systems updated with the latest vendor updates and security patches.
7. Code Reviews and Interactions with Developers
Some people feel this is their favorite things to do as a DBA—to help developers improve their skills, better understand SQL Server and internals, and reinforce the idea that we’re all working on the same team. Teaching other people what you know can be rewarding, and you just might learn something from them in the process.
To address differences of opinion and focus between developers, DBAs, and management. You’ll find you spend too much time in meetings.
9. Capital Improvements and Initiatives
Throughout the year you’ll probably be involved in various initiatives or capital improvements—like making one of your key databases/servers more highly-available by throwing in Clustering, Mirroring, or AlwaysOn Availabililty Groups into the mix—or improving backups, bolstering security, and so on.
Finally, while you will have some long days and even longer nights as a DBA, there will likely be times during the year when you could probably, realistically, get everything you truly need to do done in about 3-4 hours per day on-premises at work. Only, while management will patently expect that you’re simply available and on-call late nights when problems happen or when code changes are being pushed or for longer hours when working on various initiatives, you typically won’t run into many organizations that let their DBAs (or other IT folks/developers) have any of that time back when things start to get slow. You could fill your slower times with training, reading, and trying new skills or techniques. Make sure you ask for and get the formal training you need to keep your skills updated.