The Role Of The DBA
June 17, 2013 8 Comments
I’m back at work today after a week’s travelling around Europe followed by a week’s holiday sailing around the Ionian Sea. I have to say that I’d rather still be on holiday. It’s not that I don’t enjoy my job (I love it) but… Today, I need to install some database software – and it appears that in the last two weeks I forgot what a royal pain in the backside this process is. Either that or I left my brain in Greece…
It seems to me that the role of the DBA is to provide a bridge between the expectation and reality of database software. On the one side we have the marketing hype from the vendor promising an ideal scenario in which stuff just works (hey it’s “unbreakable!”), while on the other side is a set of business requirements defining what needs to be in place. The two seem to fit, yet in between is a yawning chasm – at the bottom of which lies a bubbling and hissing pool of error messages, patching requirements and workarounds; a lake of fire and confusion. The DBA is supposed to make this mess disappear, or at least shield the users from it, but the truth is that the gap feels like it’s getting wider. Some users are going to fall in, while others are blessedly ignorant of just how frail their support structure actually is.
There Is An Alternative…
Ok enough of the metaphors, time to offer some sort of solution. I propose that we automate some of the more mundane tasks of the DBA. Oh I know that some database vendors think they’ve already done this with their installation wizards and “one command” solutions, but we all know that these regularly fall over unless every single thing is *exactly* in the right place and the wind is blowing in the right direction.
No, I’m talking about automating the role of the DBA – the person who has to manually run the automation scripts. Yes, automate the automation. And I’ve begun already, by writing a script to perform a generic database software install. Ok so it’s only in pseudo-code so far, but it’s open sources so perhaps one of you clever people out there could build on it and credit me in the header?
So here we go. I present to you version 0.1 of the AutomaDBA solution’s Database Installation subroutine:
# Subroutine for handling installation of database software on a new host # Part of class defining the role of the Database Administrator (DBA) declare NUMBER_OF_ATTEMPTS := 0; begin let NUMBER_OF_ATTEMPTS := NUMBER_OF_ATTEMPTS + 1; if NUMBER_OF_ATTEMPTS >= 2 then prepare_host(); let ERRORS := install_database_software(PRODUCT, VERSION); while ERRORS > 0; loop # Check error message on Support Portal if (check_errors_on_metalink == FOUND) then case SOLUTION in "WORKAROUND") implement_workaround(); ;; "PATCH" apply_patch(PATCH_NUMBER); ;; end case; # Check error message on Google else if (check_errors_on_google == FOUND) then case SOLUTION in "WORKAROUND") implement_workaround(); ;; "PATCH" apply_patch(PATCH_NUMBER); ;; end case; # Ask anyone and everyone if they know the answer else if (ask_other_people_for_help == SENSIBLE_ANSWER) then attempt_desperate_solution(SUGGESTION); else report "Failed to install"||PRODUCT||" "||VERSION; # Start again or give up? if NUMBER_OF_ATTEMPTS < PATIENCE_THRESHOLD then deinstall_database_software(PRODUCT, VERSION); retry_install; else exit INSTALL_FAILED; end if; end if; end loop; # document_successful_installation(PRODUCT, VERSION); -- REMOVED DUE TO TIME CONSTRAINTS exit INSTALL_SUCCEEDED; exception when others then prepare_resume; end;
looks like you got lots of frustration when installing your database software 🙂 which issue did you encounter ?
It wasn’t anything specific, just that I’d forgotten how much the DBA is expected to find workarounds and patches in order to do even the most basic task. It’s a classic case of two steps forward, one step back.
It’s compounded by the fact that I no longer really work as a DBA, but occasionally have to do DBA-type activities. When you do it every day I think maybe you become more immune to it?
It’s a real failure how so many companies end up with such detailed documentation written and organized in a purely reference style, rather than task oriented. Everything you need is there, but finding it means going through hours of reading that you don’t need. Oracle is guilty of this, but not quite so bad as SAP.
When your documentation is in third normal form it’s miserably hard to use.
I bought a roof-box for my car recently. It came in two parts – the box itself and the rails to support it – and with each part came an instruction manual. As is often the case, these manuals contained no words, only drawings illustrating the actions I needed to take. The first manual I opened told me to do a load of stuff that didn’t appear possible, using parts that didn’t appear to fit. In confusion I tried the second manual… and the very first page was a picture of the first manual being scrunched up and placed in a bin.
I think Oracle should adopt this method of explaining how to follow workarounds for installation issues…
Hum, i’ve worked 6 years as Oracle EBS dba, and i can still feel the patching pain …. 🙂
That is classic.
Just need to paste a MOS window into the screen on this stock photo for step 1: http://comp.webstockpro.com/corbis2/42-18578828.jpg
All your database are belong to us.
True say my friend.