We are almost at the end of our journey (and really are just beginning) to becoming the holistic DBA (well my vision of one anyway). We have freed ourselves of the ordinary day to day tasks that can be automated and reported on and now we have time that we can allocate to a number of things. We don’t keep re-inventing the wheel. We have our tools in place and reporting to advise us of any problems. We have also worked on our communications skills. Maybe we have read a book, or just practiced some of the ideas that I presented in my previous post.
One thing to keep in mind is that all of these priorities never really stop. They are iterative in nature. We can’t stop looking for a better tool, or more efficiency. By the same time, we can’t get bogged down in it either.
6. Help users to help themselves
7. Work to understand and correct bad behaviors with respect to the organizations data policies.
8. Work to understand and correct bad behaviors with respect to the organizations data designs.
9. Work to understand and correct bad behaviors with respect to the organizations application designs.
10. As befits the organization, your abilities, and time keep up with current data related technologies.
Number 6 is a particular favorite of mine. This is of the “teach a man to fish rather than fishing for him” kind of thing. How familiar is this to you?
DBA: Yeah? (hey, you’re a little grumpy, you have not really recovered from the weekend yet)
APP Developer: Hey Tiny (you hate when they call you Tiny), I have this SQL code in module 4405 of the zantax application that’s running slow. Can you look at it and fix the database?
DBA: Yeah, sure.
You then proceed to spend quite a bit of time (in between swigs of Mountain Dew Code Red) ferreting out the running code, getting the execution plan, and chasing down the problem.
What’s the problem here? I mean, we are DBA’s. We are the lords of our domain! Right? If we are, let us build a better domain because this one is sick as a dog.
What’s wrong is this is not a scalable operation first of all. I know that there have been many times that I have had several calls at once (particularly after a new application release). There is one of me, thirteen developers and 10 problems all at once. It’s a classic queuing problem, anyway my queue does not process things any faster when they are piling up (in fact, it probably slows down). This is where priority 6 comes into play. It is the DBA being proactive, and teaching the developers (and even damagers) how to do things like bring up execution plans, understand them, figure out what’s wrong, craft a solution and test it before you ever hear about it (you probably already knew about it from OEM reports, but that’s beside the point. Even better, in our previous work perhaps we have arranged for developers to receive Top SQL reports on a daily basis, hmmmmm)?
I thought about adding another item to my list that was “Do everything you can to make your job scalable” or “Do everything you can to get others to do their job, so you can do your job”, but it didn’t quite seem to fit. Helping users and developers to help themselves is the better solution. How do we do that? Well we put on classes, we teach the mysterious dark arts of writing good SQL. We suggest to hiring managers that they might question their prospective hires about SQL and writing efficient SQL code. We need to turn this ship around, we need to change the paradigm such that the people writing the code, are the ones writing the tuned version of the code. We need to put the onus on them.
Your response might be, “Well management does not support that.” Really? Have you talked to management about that? If so how? Did you just walk in and blow up about all the idiots in the development group who could not code themselves out of a box. Did you throw in a lot of hot air or did you offer calm, level headed, solutions. Does your group just grouse about the duh-velopers in meetings, or does someone decide that enough is enough and today things change. Managers – You are expected to be the leaders, it’s you they will look towards for leadership and to follow. I know it can seem overwhelming at first, but just little steps…. Little steps and you can get an awful lot done.
Having completed steps 1 through 6, how much free time do you think you will have on your hands? Will we have freed up 20% of your time? 50% of your time? I suggest to you that if these steps have not freed up at least 50% of your daily workload, then you are not doing something right. You are still out there coding something cool in Java or Perl….maybe you are taking the time to read one of Craig Fergusons books (and I can get behind you on that one!) You still can’t let go of your built in DBA desire to tune SQL code or something else has you not making the most of your newly found free time. That’s where the remaining steps come in.
By moving to these steps we are moving away from being tactical DBA’s and we are moving towards becoming strategic DBA’s. You might fear the notion that I’m trying to push you along this path, making you leave your cherished million lines of perl code behind, the dark nights of overtime while rebuilding some tables in your database and all those fun, cool, technical things that you do that really offer, in the long run, no real value to your employer, and in fact, increase costs, significantly.
I feel like I’m writing a book here. Still, these are just my observations and my view of what will ultimately make for a successful data organization. I still have more to say, but it seems like I have said enough for this post. So, I’ll try to finish my thoughts in the final installment.
No comments:
Post a Comment