April 4, 2009 at 11:04 am
Comments posted to this topic are about the item The Disappearing DBA
April 4, 2009 at 7:11 pm
I generally tend to agree with this, but the disappearing act is more often a detriment to the career of a DBA. Few people remember that the servers ran for 10 months without a hiccup and few people will care that the cause of that one hiccup was bad code released or perhaps a hardware failure. They'll remember that one hiccup if the DBA hasn't done some self-promotion. It's very easy for the DBA to be completely satisfied with being an unknown player and I'll admit that I like that to some extent as well. I just know that if the only time my name tends to come up is when the servers are having trouble, that's a bad thing. Even if I fix the problem quickly and prevent it from happening again, it won't matter as much. Kind of like newspaper stories may tear people down but never follow up when those people are found innocent, or if they do - only in a short corrective article buried somewhere in the paper.
Some good thoughts, but I think career-wise, the DBA should definitely be encourage to do more self-promotion if they're not doing any currently.
April 4, 2009 at 8:24 pm
This is also true of particular types of "systems". For Example, if payroll operates as expected, nobody pats you on the back. BUT if there is an error (especially if it an error affecting a group or everyone), there is a question of "HOW did this happen?".
There are other jobs that also come into this "genre". For example, a Project Manager is most successful when they are nearly invisible. This is not unique to DBAs, but it is noted that the traditional DBA position has become this type of position. If you perform your job well, your are invisible. If you do not, you are front and center (and often not for long).
April 4, 2009 at 8:32 pm
Very well written and oh so true. All too often a company only knows they have a 'good DBA' when the rare occasion arises that he or she was the one to perform that last 'critical' restore to alleviate some major issue (or crisis as it usually is). There are lots of 'good DBAs' out there and even more growing into that role through perseverance, knowledge gathering, and problem solving each and every day. It is almost as if it is our collective career-wise lot is to begin to work ourselves out of a job from the onset of day one. Thankfully this is not usually the case. SQL changes, application technology changes and applications change over time - basically the only constant for a DBA is change.
We need to set our sights much. much higher though. We need to aspire to what was once espoused to me on what a day in the life of a 'great DBA' was.
- get to work
- get coffee, possibly even breakfast
- log in, eat breakfast and start reading emails
- look at the days calendar
- plan or replan the days activities
- deal with the problem tickets from the night before - there should be none
- answer email, read your email monitoring
- attend the daily turnover call
- attend the daily change management call
- replan the days activities
- read about 1/2 the daily morning newspaper
- get more coffee (or the beverage of your choice)
- attend the development related meetings needed
- continue your education through groups like SSC
- get lunch, read the rest of the newspaper
- answer email, read your email monitoring
- replan the days activities
- maybe and development steering committees
- deal with the problem tickets that are application related
- more coffee (or the beverage of your choice)
- an afternoon snack
- answer email, read your email monitoring
- replan the days activities
- finish the daily newspaper - the sports section or reading want-ads
- continue your education through groups like SSC
If you can get to this point career-wise you have almost achieved 'greatness'.
However there are a few more hurdles left before you can claim that accomplishment. If things are running that smoothly not a soul really knows that you even exist - well with the notable exception of your management and those who take you for granted. That is really how it should be. You should be that enigma that HR annually poses the following queries about.
- who is this person ?
- what do they really do ?
- how come we pay them so much ?
- how come we never hear anything about them ?
The final hurdle of achieving this espoused 'greatness' is making sure that your immediate management and all other management groups that affect your career path are aware of exactly what you do and how you get things done. Sounds like quite a paradox, being an unknown enigma and yet one of the enterprise's crucial players. Well, that is where knowing people and politics comes into play. There is really no online reference or book in print that teaches that to you what you need to do - it is basically experience and the mentoring tat you have received.
One might not think that this is possible. Well ... it is definitely achievable.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
April 5, 2009 at 10:31 am
good article with a lot of truths in it. It is also often true that there is more credit to be gained in fixing a high profile incident then preventing it in the first place. thats just a fact of life (and poor management).
Maybe DBAs should occasionally cause problems on purpose, after setting up a cover story and having a quick fix ready to go. Just joking of course.
I don't mind developers being higher profile, as long as they don't make a habit of doing two things:
claim coding is the ONLY skill that matters
claim MY database is slowing down THEIR code.
---------------------------------------------------------------------
April 5, 2009 at 11:02 am
I've often thought the production DBA should be insurance. If he/she's doing the job, you pay him/her, and don't worry about things. That's a big IF, however, and when something breaks (no IF here, it's a WHEN), they have to respond.
Since HR and management don't often see it that way, I would say that you do want to give them some sort of dashboard that shows work being done, and you're on top of things. This doesn't necessarily have to be a "server running at 20% instead of 40% after tuning SQL" report. I'd aim more for the "payroll ran in 20 minutes, instead of 22, with 12 more people added after tuning"
You do want to show your boss that you are providing value. You want to build your brand. And as I've mentioned in the past, if you don't have anything to tell him, perhaps that's a problem.
Nice editorial, Tony.
April 5, 2009 at 11:52 am
Steve Jones - Editor (4/5/2009)
I've often thought the production DBA should be insurance. If he/she's doing the job, you pay him/her, and don't worry about things. That's a big IF, however, and when something breaks (no IF here, it's a WHEN), they have to respond.Since HR and management don't often see it that way, I would say that you do want to give them some sort of dashboard that shows work being done, and you're on top of things. This doesn't necessarily have to be a "server running at 20% instead of 40% after tuning SQL" report. I'd aim more for the "payroll ran in 20 minutes, instead of 22, with 12 more people added after tuning"
You do want to show your boss that you are providing value. You want to build your brand. And as I've mentioned in the past, if you don't have anything to tell him, perhaps that's a problem.
Nice editorial, Tony.
Hi
I'm a developer (sorry for that :Whistling:) but I've been in same situation. Since the new requirements for the software just work fine when it comes to production the customer says "That's just as it has to be so why should we speak about?" but if there are any problems you become pointed by everybody.
Some years a go I had a project manager consultant who taught me "Do good things and speak about". This is just right! It is not naturally that everything runs good! If you do your job good, show it. Populate dashboards, reached milestones, ... .
Greets
Flo
April 5, 2009 at 1:05 pm
Great editorial Tony!
A lot of people managing large corporations (and some managing small ones) do not understand the value database professionals bring. Finding meaningful ways to bridge this gap is worthwhile any time, particularly at review time.
I think the visibility of the production DBA can be mitigated by a good boss. A good boss will be concerned with "telling your story." My current boss does this extremely well, and I try to do this for members of my team.
Regardless of how cool your boss may be, following the personal branding advice Steve Jones offers is a good idea.
:{> Andy
PS - thanks for the link Tony! :{>
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
April 6, 2009 at 1:27 am
One added DBA area for praise is rescuing a bought-in supplier-installed system that you haven't been allowed to touch because "it's been set up by the supplier so it's fine".
Then there's a problem and you are allowed to touch and find the classic Phil Factor's "Pop Rivett and the expanding log" problem caused by the "supplier who knows all" lifting their backup code straight from SQL Server Central, then not implementing it properly, so no log backups on full recovery databases and no system database backups whatsoever!!!
I'm getting really fed up with suppliers who don't seem to know the first thing about SQL Server yet treat the client's experienced staff like idiots :angry:
April 6, 2009 at 2:50 am
This is not the difference between a Developer and a DBA, it is the difference between Developers and Support. Some DBA's do development work, even if most are in a supporting role, while most front-end coders have to do support as well as development.
I am pretty sure that it is this mix that is most important, not the technology.
April 6, 2009 at 3:13 am
Times are changing and the technology with which DBAs have access to and use have improved greatly. Think of the great many monitoring tools out there!
I really think that a DBA who's worth his pay is one that can keep critical systems running efficiently AND help out with developers. This DBA is certainly not one who is unnoticed, but is a valuable resource for developers. These days more and more SQL development work are done by developers with 3GL experience. The DBA must take care to assist as much as possible, particularly where technologies such as LINQ is used.
April 6, 2009 at 10:57 am
With the advent of third-party enterprise-level backup solutions, such as Symantec or CommVault, how justifiable is it to maintain that DBAs should still be the owners of the database-backup/restore process?
Some of these (enterprise) backup tools include the entire O/S system in the backup plan, in addition to database files. In a company using a tool like this, one might argue that the responsibility of database backups and restores should now belong to the system administrators or operations staff or a specially designated backups team. The DBA team might then be shut out of one of the most important roles of the DBA, which is data security and data access management.
What do people think about this? How important is it for DBAs to stay in control of database backups/restores, even if the tools used are third-party tools that do system-level backups?
I'm a DBA BTW... 🙂
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
April 6, 2009 at 11:03 am
Mario,
I'd actually ask you start a new thread for that. It's a great question, and I think it deserves some debate. If you post a URL here to it, I'll answer, and I'm sure others.
April 6, 2009 at 11:09 am
Steve Jones - Editor (4/6/2009)
Mario,I'd actually ask you start a new thread for that. It's a great question, and I think it deserves some debate. If you post a URL here to it, I'll answer, and I'm sure others.
Sounds good, I will post a new thread then and will post the URL here, once created.
Thanks!
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
April 6, 2009 at 11:19 am
I posted the question on http://www.sqlservercentral.com/Forums/Topic691281-361-1.aspx.
Thanks in advance for all the feedback.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply