November 18, 2008 at 9:50 am
jeffrey yao (11/18/2008)
Good article to read, and I'd especially echo this:"The scary part about being a new DBA is that you don't know the extent of what you don't know".
In reality, I believe this also applies to quite a few experienced DBAs.
I loved that line, it's as applicable to DBA as to life
- We don't know what we don't know, BUT we are willing to know
- DBA's learn from mistakes and trial and errors just like everybody else
November 18, 2008 at 11:18 am
Excellent article that should be read by all DBAs! It highlights a problem I've seen in my own organization: documentation and knowledge transfer are often given very low priorities. Some managers would rather take the easy route and assign to the "hero" DBA, rather than mitigate the risk by giving other team members the opportunity to learn the process or interact with the customer.
November 18, 2008 at 2:17 pm
Great post.
This reminds me of the good old days about .... "oops, I for got to highlight the 'where' clause"
* Noel
November 18, 2008 at 8:12 pm
Great article!
November 19, 2008 at 4:19 am
Great Article especially as I'm an aspiring DBA...slowly getting there.
About Heroes:
I have experienced may instances of contractors and consultants creating a hero persona so that their services can be extended ...for a fee.
They never revel the full deck of cards and always have a ace up their sleeves. (The manager is made to look like a joker.) 😛
Permanent staff can also create the Hero persona to secure the job position, and bolster their Ego. 😀
November 19, 2008 at 5:02 am
If I sound harsh in this post, thats is because I am. One of your first comments is about something that I feel is deeply wrong with the role of IT in organizations and you seem to glorify it in the comment!
IMPORTANT:
Reading the article several times more I DO reallize that this particular comment does not fit in with the rest of the article which is by the way very sound! I just got tripped over by this one simple comment.
Please realize this when reading on (I left my original reply essentially unchanged)!
The comment:
The CEO doesn't really care HOW it happens, whether its transaction log backups, and XML indexes or whizbang fiber-optic laser beam assemblers. He wants his data when he wants it, where he wants it and has to be 100% reliable. THAT is our purpose. Adjust your focus if you don't see it that way; CIA is what you need to be concentrating on
So we have to deliver what someone asks, no matter what and how. Great, but I think you just wrote one of the dumbest line in IT that I must have read for like 10 years! This is because if you as you say have so much experience, you ought to know more about people and organizations. You also should know about the effects past implementations to such requests have been both for your IT department and the organization as a whole.
Now to the why it is wrong part...
Yes everyone in an organization has a function and a focus, but we should not operate completely isolated and thus not use that mindset you just so horribly displayed. It is bad when the left hand does not know what the right hand does, everyone knows absurd examples of that. And believe me that having a "head" figure at a distance above micromanaging everything doesn't work so well either!
Back to your CEO example...
In practice it is not just the CEO that has a wish list, but many more people do and much of those will end up on the IT/dba department. Those requests did not pop-up in existence out of nowhere, and instead of just implementing them one by one in blind obedience and following CIA it stands to reason to dig deeper before even start implementing!
For one, people made the requests and people if anything cannot be trusted to have all the data, operate unbiased or even understand their work or data. What might be useful on the short term to meet a goal that benefits the organization (or just what a requesting individual think it will), might end up a headache for the IT department for decades to come. Thus you definatly need to have your own nontechnical/ethical standards too! Say NO from time to time and make requesting parties think harder about other solutions then just dumping it onto the 'IT solves all' bandwagon.
Island thinking - the disease no 1.
Organizational islands are the biggest corporate illness around! It leads to rule clutter, inefficiency, unsatisfied customers, counter productive actions and even corruption. Someone from island A that can gain a short term benefit by requesting a change (and get rewarded), not knowing the long term health of island B is negatively affected. Unortunatly and contrary to theory, the top of an organization is just another "island", not the guiding head of all islands when it comes to shared data.
If all cross-island data decisions would end up on this "CEO island", then everything would grind to a halt, they are simply not qualified for that (it requirers a different mindset). And whatever they would decide, it they would not be the ones implementing it, so the coupling between power and responsibility is not right. The IT department however CAN make such calls as it DOES have the knowhow and IS responsible for the implementation.
Thus instead of being the low end slave in the corporate hierarchy the IT department actually is when properly managed the heart and (data) head of a company. So you should act like it and not be like a "yes sir, right away" critter.
IT, the path of lowest resistance - the disease no 2.
People with an agenda behave "'like water" and flow the way of least resistance to accomplish that agenda. As IT is the most flexible part in an organization a lot of their (nontechnical) issues end up on the platter of the IT department in one form or another and "solutions" subsequently turn up in the form of software.
Thus instead of streamlining the organization, business model or procedures, you see often IT is deployed to make bad procedures manageable (for now) and then it becomes entrenched. It all happens just because the path to IT does offer so little resistance. Naturally decision makers opt for IT rather quickly without making a proper cost/benefit analysis involving other solutions. Ask a developer if something can be done, you will always hear an answer like: "everything can be done....sir, yes sir" and then it stops any rational thinking in the decission maker! Not surprisingly most IT projects never make the deadline (not the 2nd nor 5th for that matter). Think first, be conservative, be very conservative!
If you do not put up an argument and implement requests that are not sustainable over time, you will be the one feeling the pain years from now! More procedures, a bigger IT department to keep things going would be the result of the escalating complexity and data/software dependencies. You create a web of pain that you don't want as you want to sleep at night like a normal person (free interpretation here). And sadly no documentation in the world can counter this, it would just add yet another data dependancy.
* Keep things simple!
* Understand the effect of a change over time
* Say NO sometimes
* Put the pain where it belongs (do not solve non-technical problems by technical means)
Numbers are like statistics - the disease no 3.
It is easy to store an every increasing amount of data and as IT can deliver that, decision makers will ask for it and invent ever more complex "solutions" to mundane problems. In effect we created the demand, not the decision makers, and it is like a drug. A decision maker will think more numbers is better, as he "feels less unsure" and can put something forward as an argument. But in practice numbers and statistics based on them cloud sound reasoning and common sense, something which a decision maker must use over likely tained data.
Yes tainted data....someone not under control of common sense without real purpose in life entered that number at 6pm just after he hung up his phone where his wife told him to come home or his balls will be bust. Errors will creep in, more numbers, means more people, means less significance, means more errors!
Thus instead of doing the organization a service by recording everything (a common request), you should try to record only essentials that can be used to form meaningful trends. The quality of data must be kept high, do not accept data where you can assume its is not reliable enough. Just say NO in those cases!
That said:
Documentation of a sound system is sound.
Procedures for maintaining a sound system is sound.
But:
Documentation of an unsound solution is not sound. Its makes the headache just worse as you have to keep the documentation up to date as well. As you try to fix the "unsoundnes", errors will creep in and nothing is as bad as unreliable documentation! Better to have none in such a case, just as is the case with unreliable data. You in fact already lost grip of the situation and its time to cut the losses!
November 19, 2008 at 12:53 pm
Good article.
As Database Administrators we are paid to maintain three things:
* Confidentiality of data
* Integrity of data
* Availability of data
The CIA triangle of Information Security fame...
I've never heard of this CIA triangle but I wrote something very similar a few weeks back outlining the top 3 responsibilities of the DBA:
1. Database Availability - Keep the database available and performant.
2. Database Integrity - Secure the database against corruption or data loss.
3. Database Security - Secure the database against unauthorized access.
Ref: http://www.robsymonds.com/the-top-3-responsibilities-of-a-dba/[/url]
November 19, 2008 at 1:47 pm
As a new DBA, I think this article is great. Looking forward to the next section.
November 19, 2008 at 2:47 pm
Peter,
I think you'll like the next article which is about knowing what is the DBA's responsibility and saying "NO!" to what's contradicts CIA and the systems you have designed to uphold it... and even those gray areas that crop up.
I appreciate your comments; Stay tuned.
~BOT
Craig Outcalt
November 19, 2008 at 7:56 pm
SQLBOT (11/19/2008)
Peter,I think you'll like the next article which is about knowing what is the DBA's responsibility and saying "NO!" to what's contradicts CIA and the systems you have designed to uphold it... and even those gray areas that crop up.
I appreciate your comments; Stay tuned.
~BOT
Heh... you packin' porkchops, too? 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2008 at 3:19 am
Heh,
As I said, that one comment that got me going beserk was not in line with the rest, and yes, I am indeed looking forward to the follow ups!
January 6, 2009 at 4:57 am
Hi everyone,
I am sql developer. I studied ur article which is very nice but i would like to know the basics things to become a DBA. I have a chance to attend the interview next week but i dont have much knowledge about DBA side. What should i know before i could attend the interview. If anyone suggest its appreciated.
Thanks in advance
Prasanna
January 6, 2009 at 5:01 am
Hi,
your comments seems that, you were wellversed in DBA. Could you guide me from where i start to become a DBA. I studied lot of topics but i dont know how to implement. I expect reply soon
Thanks in advance
Prasanna
January 6, 2009 at 5:09 am
There is a book I bought SQL DBA 2005 Street Smarts by Joseph Jorden which has all the practical tasks that a DBA is required to do in the form of scenarios and exercises that follow. This is great for practising DBA skill and good to have as a reference. It will give you the DBA knowledge you require. 😎
I'm studying to move from Support to a DBA role and fine that this book gives you the exercise and experience to do the job, where other books just give you the theory and knowledge.
Knowledge is useless with out experience.
January 7, 2009 at 10:32 am
Having been the Hero DBA I will agree it most heartily sucks. The biggest problem is that the lack of documentation that surrounds the Hero DBA is probably not his fault. More often then not I have found lip service for documentation and then not getting the support or help to do it. I have pushed for documentation and then found myself getting the tools I need in place to do the documentation and then having the help to do it pull so dramatically from me that I nearly quit. A Hero DBA gets into that position where he is filling the role of a DBA team for corprate culture that does not want to spend the money to develop a good and reliable team. Being at the center of the storm means that more often then not you are just there to keep the ship moving forward bailing water as fast as you can and adressing major issues and letting the bevy of minor ones fall by the wayside.
Viewing 15 posts - 16 through 30 (of 65 total)
You must be logged in to reply to this topic. Login to reply