January 5, 2013 at 12:41 am
Comments posted to this topic are about the item What Counts for a DBA: Amnesia
January 6, 2013 at 9:41 am
Bravo Louis!
I will share this with my team. I currently practice a valuable piece of information you gave me years ago. You said don't design based on how much work its going to take to complete the solution. This post is an excellent approach to that philosophy. Focusing on the original problem and selectively ignoring things that don't work is the way to maintaining sanity.
So many of the problems that exist are the result of improvisation that didn't really solve the original problem on a long term basis. Thanks for your leadership!
January 6, 2013 at 10:26 am
Good article. The DBA job is significantly easier in the long run , if discipline and sound priniples are applied.
Many DBAs are pragmatic - i.e they work in a resource constrained environment - with the number one priority being to keep Production systems alive.
This leads to short cuts and sometime pain the future
Jack Vamvas
sqlserver-dba.com
January 6, 2013 at 2:16 pm
Jack Vamvas (1/6/2013)
Good article. The DBA job is significantly easier in the long run , if discipline and sound priniples are applied.Many DBAs are pragmatic - i.e they work in a resource constrained environment - with the number one priority being to keep Production systems alive.
This leads to short cuts and sometime pain the future
How do you figure that trying to keep Production systems alive "leads to short cuts"?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 6, 2013 at 2:41 pm
What I've found is that a DBA is usually the voice-of-one against many and that the DBA is usually the only one with a mind out for silly little things like performance, scalability, useablility, archivability, and ease of modification. I certainly can't speak for all DBAs but thank goodness I don't actually have amnesia so that I can remember all of the seemingly little stupid things that have caused huge pains in the future. You know... little things we've suggested like "No. Loan Number from a bank isn't good enough to be a Primary Key" or "No. No permutation of first and last name is good enough to be a Primary Key" or "No. Storing multiple addresses and phone numbers on a single row in the Customer table is a really bad idea".
I think that any DBA that has developed a sense of amnesia has yet another hard lesson to learn. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 6, 2013 at 11:45 pm
Nice article Louis
January 6, 2013 at 11:52 pm
@jeff - "short cuts" , in this context means : a) Increasing time pressure on the Production DBA with limited time to plan and apply principles adequately. b) Many DBAs I know , are frustrated by increased responsibilities but with insufficient increased resources to tackle these responsibilities.
Maintaining Production environments in a complex , constantly changing environment , with SAN , network, VM - upgrades, fixpacks - creates extra workload for the DBA - regarding troubleshooting , capacity planning etc. As a result , developers in lower environments don't receive the necessary attention from the DBAs.
Jack Vamvas
sqlserver-dba.com
January 7, 2013 at 7:31 am
Jeff Moden (1/6/2013)
What I've found is that a DBA is usually the voice-of-one against many and that the DBA is usually the only one with a mind out for silly little things like performance, scalability, useablility, archivability, and ease of modification.
I can definitely agree with this. Many times, we are the only voice of reason that protects the integrity of the production databases which we are the caretakers of. Managers, developers, BI folks, etc tend to want what they want when they want it. I have a big sign over my desk for all to see that states: "This is NOT Burger King. You can't always get it your way.":-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
January 7, 2013 at 8:32 am
@jeff moden,
So, I should note that I don't indicate that you should forget everything you know 🙂 Just that "we have to forget the pain of past failures".
If you are a sports fan, you can think of it just like a receiver. They have a difficult job in that they have to concentrate on the ball coming to them and protecting it once they catch it, but "forget" that they are about to be hit by a small freight train sized opponent, and that the last time they did it hurt really so bad they dropped the ball and lost the game.
They still should remember the lesson of that failure (that they have to protect the ball), but not dwell on the failure or they will do everything they can to not be in the position to even catch the ball so they won't get hurt.
Failure is a big part of the educational process (http://www.simple-talk.com/blogs/2011/04/16/what-counts-for-a-dba-failure/) but failure can lead you in two ways and fear will hopefully not be the one you choose.
January 7, 2013 at 10:17 am
Jeff Moden (1/6/2013)
What I've found is that a DBA is usually the voice-of-one against many and that the DBA is usually the only one with a mind out for silly little things like performance, scalability, useablility, archivability, and ease of modification.
+1
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 7, 2013 at 11:35 am
Thanks for the great post, Louis!
January 7, 2013 at 3:52 pm
Fabulous post and way too close to home. I don’t know of a developer, dba, or support staff that couldn’t relate. The most effective ones (unfortunately) are those that have been around a given product long enough to be aware of the past failures and factor them into their problem solving. So often the genie is out of the lamp (forgive the cliché) and so long gone that remedies are not even considered.
January 7, 2013 at 3:59 pm
Louis Davidson (@drsql) (1/7/2013)
@jeff moden,So, I should note that I don't indicate that you should forget everything you know 🙂 Just that "we have to forget the pain of past failures".
If you are a sports fan, you can think of it just like a receiver. They have a difficult job in that they have to concentrate on the ball coming to them and protecting it once they catch it, but "forget" that they are about to be hit by a small freight train sized opponent, and that the last time they did it hurt really so bad they dropped the ball and lost the game.
They still should remember the lesson of that failure (that they have to protect the ball), but not dwell on the failure or they will do everything they can to not be in the position to even catch the ball so they won't get hurt.
Failure is a big part of the educational process (http://www.simple-talk.com/blogs/2011/04/16/what-counts-for-a-dba-failure/) but failure can lead you in two ways and fear will hopefully not be the one you choose.
I'm suggesting two things, Louis. Perhaps we're actually "in step" but just saying it differently.
1) that you never forget the pains that you've experienced lest you experience them again and 2) do not confuse such pain with simple fear. The only thing that a DBA has in common with getting whacked by an incoming ball is that knowledge in both areas will keep you and your data from being hurt again. Forgetting the pain of either "adventure" may cost you dearly. Being fearful means that you have felt pain but haven't yet figured out "why" or "where" the pain came from and certainly not what to do about it. If you don't have the knowledge and practice, the pain should be good incentive to get it. If you don't have the knowledge or the practice and it happens again, then the fear you feel [font="Arial Black"]should [/font]act as a "Spider Sense" and you should proceed only with great caution.
Such knowledge, caution, and even fear will appear to be a weakness to outsiders and people who don't truly understand what being a DBA is all about. Patently, it is quite the opposite and people need to stop browbeating DBAs into submission and threatening them with their jobs for doing their jobs correctly instead of the way management wants them to do their jobs.
Also, you spell your name as a properly capitalized entity for a reason. So do I. I'd appreciate the same from you in the future. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 7, 2013 at 4:11 pm
@jeff Moden, (and I don't really care if my name is capitalized, but I am sorry if I offended you)
We are saying pretty much the same thing. The difference is that you are focussing on the pain as the thing to be fix, and for me, the task and the pain are seperate. The task is that you have to fix some data, or restore a data. This is my analogy to the catching the ball. The pain is that you have to be careful to make sure you don't delete the entire table (oops, did I forget to back up before I fixed that data?), or you have to spend 100 hours fighting for what is right in a meeting instead of just letting poor code/designs reign. The work/meetings/etc are in many ways worse than the pain of getting flattened by a linebacker, (which is over in a microsecond and a few good nights of sleep).
But that time when you didn't highlight the entire delete statement and deleted all of the order data for the day and didn't even back up first? (or dropped a db, most dba's have some memory of that sort of a thing) Yeah, you certainly don't want to forget that and just do the same thing.
That is what I am saying is like a new year's resolution. Didn't lose weight last year? You can either forget the pain you are going to have exercising and just do it daily, or give up because you know it is going to be difficult. Database is filled with junk? Bah, then who cares if we end up with more junk in the next change?
January 7, 2013 at 4:23 pm
Ah... now I understand what you're trying to say. If someone has the wrong attitude about it, they'll consider it the "pain of learning". If someone has the correct attitude about the job, they'll call it the "joy of learning". IMHO, attitude is one of those major qualities that seperate the really good DBAs from the mundane whether the particular job is mundane or not.
"To try and fail is a learning event". Whether you learn something from it or not is up to you.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply