[powerpress]
Do You Have a Cracked Foundation?
in WOxPod!, episode # 004 – “Do you have a cracked foundation?” we discuss the role of the non-production DBA, and why, if you don’t have one already, you may need one sooner than you know.
Show links:
WaterOx’s Concierge DBA® Services
Transcript
You are listening to WOxPod!, episode # 003 – Do you have a cracked foundation?
Today we discuss the role of the non-production DBA, and why, if you don’t have one already, you may need one sooner than you know.
Hey everyone, Chris Bell here. The WOxPod! podcast is produced for your enjoyment. Show notes can be found at wateroxconsulting.com/podcasts
Come back often feel free to add WOxPod! to your favorite RSS feeds, or subscribe on Android or Itunes using the link below.
You can also follow us on Twitter, Facebook, or LinkedIn, all which are linked through our website: WaterOxConsulting.com
Now let’s get on to the show.
I assume you are using SQL Server in your environment, otherwise it seems a little odd to listen to a SQL Server based podcast. Regardless, here’s a quick question. How many production Database Administrators do you have? 1 or more? Great!
How about development DBA’s? Now, I don’t mean those developers that act as DBAs. I mean actual dedicated DBAs for your development environment? If you have even one; bravo! You are better off than a lot of companies out there.
In most businesses the production SQL Server is the most critical. It is what your business is running on, and holds lots of important information. It is also where a majority of your internal and external customers interact with the data they need. Odds are you have a production DBA that primarily makes sure the database is up, running and available to meet business demands, and secondly helps tune the system to get the best performance from it.
But what about those non-production systems you have. You know, the ones that are used by the developers to, well, develop against? They are the very foundation that your code and production environment are built upon. Don’t let a crack in your foundation, be what causes everything to eventually collapse.
So, on that note, do you have a dedicated SQL Server DBA for those development systems? No? Well, why not?
Your development systems are essentially foundational, production systems, just for a different kind of customer. Your developers and other teams are those customers. You need them to remain productive. What happens if their system goes down?
Most times things slow down and stress builds since project timelines are not likely to change much for an outage in a non-production system. That development productivity may even grind to a halt. Who is responsible for getting that development SQL Server environment back up and running, with minimal code & data loss? Hopefully not your production DBA. They have a lot of other, higher priority things to worry about.
Oh, and don’t forget the ‘good’ code to go to production. It is one thing to have developers write and ‘test’ their SQL code for deployment, then get it deployed. Unless there are strict code review guidelines, with someone who knows what they are doing in SQL Server you may be surprised at how quickly the production DBA suddenly starts spending valuable time answering emails and the phone to deal with customers and other employees when that new code doesn’t scale properly and things get slower in production.
Those of us in the industry joke all the time that the term DBA stands for Default Blame Acceptor. Usually it is the DBAthat is the first ones asked why the systems are being slow. The application was working fine, until suddenly it isn’t. The production DBA then digs into the issue, and if it is a database problem, more often than not it is due to poor coding practices in the SQL Code, or code that can’t scale because it was developed against a much, much smaller set of test data.
Wouldn’t it be nice if your production DBA could focus on keeping the system up and running and not spend a lot of their time working on cleaning up ‘dirty’ code that never should have made it to production?
Welcome to a major advantage of having a Development DBA. The non-production DBA focus is a little different than the production DBA. Yes, they focus on keeping the system up and running and available with backups and restores as needed, but they also focus on making sure the code that is going to production is efficient, clean and will scale properly. The production DBA will focus on keeping things running first, then performance. The development DBA is the opposite. They can focus on making sure the code is efficient and will scale properly, and also help ensure those secondary ‘production’ systems for your teams are up and running.
(Incidentally, If you are using SQL Server, and don’t have any DBAs, you should consider visiting our website and checking out our Concierge DBA® Service. As of recording this podcast we have just a couple of slots left to join in. The link will be in the notes)
And that’s the show! Thanks for listening.
If you have any Questions or suggestions of topics or people to talk to email us at [email protected] or hit me up on twitter at @CBellDBA.
Until next time, keep yourself and your data safe!