DBA priorities

- [Instructor] In my role as an architect, I've always found it helpful in trying to bridge relationships between various technology groups with different perspectives to try and get both sides to think of the priorities and motivations of the other group as it's important to understand how those priorities and frequently impact mutual goals. The thing you always have to remember, especially in larger organizations is, every team is motivated by their management set objectives. And these typically these may go counter to working with other teams which can be problematic.

One thing to think about is how your database administration team has to wear a lot of hats. They're frequently involved with the management of both infrastructure, things like storage, virtual machines, containers, as well as the application side that you manage as a developer. This keeps the DBAs extremely busy and in a lot of meetings. While a developer might need to spend more time with their business users that they support, the DBA has the balance the needs of those business users and those applications with infrastructure needs as well as data security.

The acronym default blame acceptor has been tossed around for DBA as, instead of database administrator, and it's quite reasonable because they cover so much. The database gets blamed for a lot of things. The other important thing to note, and this is going to lead to our next slide, is that production DBAs frequently have on-call duty for all the databases in the company. This means that if there's a problem with any database in the organization, they get paged. It seems in the law of getting paged, you never get paged at, y'know, 8 o'clock on a Wednesday.

It's always 2 AM on Friday night, it's never a good time. Given that the DBA is on call for everything, that means the number one priority of the database administrator and the database administrator team is not to get paged. No one likes that 2 AM wake up call and getting up and having to fix things. So the mission of that team becomes stability. And to minimize things that can happen that 'causes the team to get paged. We see this manifest itself sometimes by DBAs having a reputation of always wanting to say no.

Like for example, limiting access to databases, so unauthorized or unpredictable changes can't be made. It also means that DBAs are also responsible for a lot of things. In this list, that's on this slide, is somewhat prioritized. So backup and recovery is always their number one job 'cause they don't want to lose data. High availability is another thing that's important and initiates the whole not getting paged thing. If we have a highly available environment, if something goes down, we can sustain it and not get paged. They also have to patch databases, sometimes they have to patch servers.

They're responsible for keeping the lights on in their environment in general. Security. As important as data security is in a lot of organizations, it falls well below keeping the lights on. That's another thing that's problematic. And finally below that, they're responsible for your application's database. And after that, they might have some time to deal with performance. It's not that the DBA team doesn't care about your application, it's just at the bottom of things they have time to work on. Different organizational structures like positioning a DBA in a development team can help with this, but in general and in most large corporations, the DBA team is busy with a lot of things, and doesn't get to prioritize apps with that other outside influences like manager, director, or even CIO level pressure.

So what you DBA wants. The biggest thing they would like from your application is stability. Make your changes in your change window and having changes that you can roll back. A DBA doesn't want to get paged because your application rollout went poorly and they have to restore your two terabyte database. That'll take all day. They would like you to just be able to simply roll back your changes. While that's not always possible, you learn more about how to do that in a later video in this course. Your DBA would also like to help you with your application's performance.

Performance tuning is fun, and frankly the average production DBA is so busy with keeping the lights on, they don't have a lot of time to do performance tuning. So if you have a problematic query, don't be afraid to ask for help in making it run faster. But while you're at the DBA's office, please don't ask for SysAdmin rights. You can have that in your local instance, but the DBA would really like you to learn how to run your application with low privileges because they also have to deal with audits, and if you SA for your application, those audits aren't going to go well.

So security is another thing that you have to kind of understand and worry about.