Subscribe to Blog via Email
Follow me on TwitterMy Tweets
Database Administrators, (DBAs) through their own self-promotion, will tell you they’re the smartest people in the room and being such, will avoid buzzwords that create cataclysmic shifts in technology as DevOps has. One of our main role is to maintain consistent availability, which is always threatened by change and DevOps opposes this with a focus on methodologies like agile, continuous delivery and lean development.
Residing a step or more behind bleeding edge has never phased the DBA. We were the cool kids by being retro, those refusing to fall for the latest trend or the coolest new feature, knowing that with bleeding edge comes risk and that a DBA that takes risks is a DBA out of work. So we put up the barricades and refused the radical claims and cultural shift to DevOps.
As I travel to multiple events focused on numerous platforms the database is crucial to, I’m faced with peers frustrated with DevOps and considerable conversation dedicated to how it’s the end of the database administrator. It may be my imagination, but I’ve been hearing this same story, with the blame assigned elsewhere- either its Agile, DevOps, the Cloud or even a latest release of the actual database platform. The story’s the same- the end of the Database Administrator.
The most alarming and obvious pain point of this, is that in each of these scenarios, the result was the Database Administrator a focal point in the end more so than they were when it began. When it comes to DevOps, the specific challenges of the goal needed the DBA more so than any of these storylines. As development hurdled top speed to deliver what the business required, the DBA and operations as a whole, delivered the security, the stability and the methodologies to build automation at the level that the other groups simply never needed previously.
Powerful DBAs with skills not just in scripting, but in efficiency and logic, were able to take complicated, multi-tier environments and break them down into strategies that could be easily adopted. As they’d overcome the challenges of the database being central and blamed for everything in the IT environment, they were able to dissect and built out complex management and monitoring of end-to-end DevOps. As essential as System, Network and Server Administration was to the Operations group, the Database Administrator possessed advanced skills required, a hybrid of the developer and the operations personnel that make them a natural fit for DevOps.
Thanks to this awesome post from 2012 from Alex Tatiyants which resonated so well with the DBAs I speak to every day, even in 2017.
I’m a Leaf on the Wind, Watch How I Soar.
This is one of my favorite lines from the movie Serenity.
Without Alan Tudyk’s character dying and all at the end of this, (sorry if I ruined the movie for anyone…) this is how a DBA should be in the database environment- skilled, reliable and maybe a little off our rockers. Our job is to protect the data, the database and all of the database.
With that said, I’m going to list my Ten Rules of Database Administration.
Happy Friday Folks!
Happy Birthday to me! So for my birthday, I give a present to you… As I want all DBAs to sleep better at night, here are the top ten features you can use in Enterprise Manager Cloud Control to offer a good night’s rest instead of during the day at your desk… 🙂
Yes, you heard me. I believe you should use them as a starting point or an example, but don’t put them into production. These were examples set by development to see all that you could be notified on, but what you need to be woke up for should be anything mission critical that will SUFFER an outage if you DON’T respond. Anything that can wait till the morning SHOULD wait till the morning.
Make copies of the default rules and disable the originals. Plan on making as many copies and edits as necessary to ensure that you are only being notified on the appropriate targets, life cycle status and line of business that YOU are responsible for ensuring is up and available to the business.
Monitoring templates ensure that you are monitoring each target in the same way and for the same metric thresholds. This ensures you start with metric thresholds that make sense for the target and should be applied to all targets of that target type. Creating monitoring templates are easy when you create one target as an example and use it for the source of your template.
Now this might sound like a complete 180 from #2 on this list, but it’s not. This is just like #1, break down and specialize for unique targets that have unique challenges. This means, if you have a target backup drive that fills up to 97% each night, you shouldn’t be woke up for it. This is expected behavior and you can either set a static threshold specific to this target or an adaptive threshold that won’t be overridden by the monitoring template for this target ONLY.
Administration Groups offer you advanced features and scalability to your Cloud Control environment that standard groups, and to a lesser extent, Dynamic groups, do not. Line of business and life cycle management features that ensure you can break down notification groups, rule sets and other features, along with more advanced features with Database as a Service and other features to allow you to do more with less. The natural life of a database environment is one of growth, so thinking ahead one, five and ten years is a great way to add value to the business as a database administrator.
Enterprise Manager 12c is a self-service product. So often there are unique situations that the business needs monitored for or the DBA notes creates a situation or outage, but isn’t, by default, a metric that comes with EM12c. It’s easy enough to create a metric extension and take the concern and worry out of the situation, creating more value to the business.
Often when, a problem occurs, a DBA has a simple shell script or SQL they run and it corrects the problem. If this is the case, why not have Cloud Control monitor for the issue, create an incident in the Incident Manager, send an email, then run the SQL or script as a Corrective Action? The DBA will still know the problem occurred the next morning, but no one needs to be woke up to do what can be automated in the system.
I understand, really. Something could somehow, somewhere, some rare time go wrong, but the patch plans you can create in Enterprise Manager are surprisingly robust and full featured. If you’re still doing patching the old fashioned way and not patching environments in the more automated and global patch plan way, you’re wasting time and let’s face it- DBAs rarely have time to waste. You are a resource that could be utilized for more important tasks and quarterly PSU patching is just not one of those.
The common environment is structured with multiple DBAs, often with one DBA as primary to a database environment and the others playing catch up to figure out how the primary has the database set up. My favorite DBA to work with once told me, “Kellyn, love your shell scripts. They make the world go ‘round. I just don’t want to try to figure out how you write shell at 3am in the morning or what kind of scheduler is used on all the OS’s you support!” I realized that I owed him to centralize all my environments with an interface that made it easy for ANYONE to manage it. No one had to look at cron, the task scheduler or a third party scheduling tool anymore. Everything was in Enterprise Manager and no matter what operating system, it all looked very similar with the logs in the same place, found in the same tab of the UI. Think about it- this is one you do for the team, move those jobs to inside Enterprise Manager, too…
Compliance is one of those things that seem a mystery to most. I’m often asked why environments really need it and does it make sense. It can seem overwhelming at first, but the idea that you know what database environments, hosts and such are out of compliance helps to distinguish how to get your database environment all set up to ensure that business best practices are in place- You have a baseline of compliance standards for configuration settings, installation and real-time monitoring to view globally via EM12c.
A database is a database or that’s how the business sees it. I have almost as many years in SQL Server as I do in Oracle. I’ve worked in Sybase, Informix, Postgres and MySQL. After being hired for my Oracle DBA skills in every job I’ve held, it never failed- within 6 weeks, a mission critical database environment on a secondary database platform was discovered that a group, often outside of IT had implemented and now needed critical support of. Enterprise Manager offers plug-ins to support all of the above database platforms and more. It offers plug-ins for engineered systems, storage arrays and other hardware that the DBA is now expected to manage, too. Why manage all of this from multiple systems when you can easily create a single pane to ensure you’re covered?
So there you have it, my top ten list. There are, of course, 100’s of other great features in EM12c, but make sure you are taking advantage of these in the list!