Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQL Server 2005 » Administering » Career growth - Production Support SQL Server...
Add to briefcase
19 posts, Page 2 of 2
««12

Career growth - Production Support SQL Server DBA Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
samir-847608
Posted Thursday, January 28, 2010 9:28 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, September 05, 2012 9:07 AM
Points: 46, Visits: 98
Interesting thread.

I have done both and continue to do both in some sense.

I think which one is for you depends on what you like to do.

Production Support DBA can be ugly. Users can blast a table where a restore is required...unfortunately because you cannot restore just a table from a backup, well...you have to restore a database on a server which has enough space...and then bcp out the data.

While this seems easy -- you'll just have people calling you left and right wondering when it will get done.

Performance and Tuning can all of a sudden become a big issue on a given day. You have to grudgingly hack through bad code and determine why some sproc that ran "well" is taking a hit all of a sudden.

...on the bright side, doing this kind of prod support makes you into a better "developer DBA" -- you'll know for your app what tables to "backup" through BCP cause you'll understand how long a restore can take.

You'll write better sprocs, and more importantly create better indexes after having gone through tuning somebody else's bad sproc.


Personally - I prefer being a dev DBA because I like seeing the data -- and understanding how it can tell a story. Understand the data, and you can create a good db structure. Also - while you may encounter similar thing as a Prod DBA...for a dev dba...well...different types of data kind of make your job more interesting.

my two rupees :)
Post #855396
rudy - Doctor "X"
Posted Friday, January 29, 2010 10:52 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, May 17, 2013 2:11 PM
Points: 3,108, Visits: 2,114
Being a production support DBA is like any other 'niche' title/occupation within IT. There are always tradeoffs in salary, working hours and benefits both within a given company and between your company and others.

I personally have been a DBA for 28+ years, all but 5 of them as a 'pure' production support DBA. My limited development DBA time was rewarding but was too political and schedule driven basically leading to tremendous swings in stress based on where things were in relation to the project life cycle. As a production support DBA things are actually more predictable. Sure there are cycles related to business activities, scheduled maintenance and upgrades. Needles to say the potentially ever present, all important issue of dealing with outages that can crop up at any time. But how is that different from issues that a development DBA faces ? Sure, both have 'expenses' associated with them for the company's bottom line. In production, outages cost revenue. In development bad queries, tuning and other issues cost developer/development time which is also money. Missed deadlines, over scheduling and long hours during 'project cram time' also ramp up the 'cost' paid by the company. Oh, did I mention that 'stress' is a given no matter what since you are the DBA.

The real question to ask is 'Will this role be fulfilling for me ?'

Above all, 'Know Thyself' !



Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #856270
SQLRNNR
Posted Friday, January 29, 2010 12:12 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Monday, May 20, 2013 1:07 PM
Points: 18,733, Visits: 12,332
It depends on where you are a Production DBA. Production DBA is not the same thing from company to company. The depends part, comes down to how well you like it at the company where you are a Production DBA.

Is it a worthwhile career choice - IMHO - yes.


Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #856327
TheSQLGuru
Posted Friday, January 29, 2010 2:12 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 6:54 PM
Points: 3,578, Visits: 5,120
I know a production DBA who just moved to a new job because he had gotten his former company so stable and everything running so routinely that he became bored and unchallenged.

Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #856409
sona.akhi
Posted Sunday, September 02, 2012 3:03 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, February 12, 2013 1:26 PM
Points: 2, Visits: 149
..
Post #1353281
Jeffrey Williams 3188
Posted Sunday, September 02, 2012 8:10 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Friday, May 17, 2013 11:21 AM
Points: 4,317, Visits: 9,216
TheSQLGuru (1/29/2010)
I know a production DBA who just moved to a new job because he had gotten his former company so stable and everything running so routinely that he became bored and unchallenged.


Nothing wrong with that - but, it would tell me that company isn't growing and expanding. A company that is growing and expanding will be bringing in new systems, new applications, building out their DR site, etc...

In fact, a growing and expanding company would definitely have lots of opportunities for growth - especially in the areas of system integration, data warehouse, reporting and other BI related processes.

And just about the time you get caught up with all of that, is the time you start rolling out the old hardware and building out the replacement systems where you have the opportunity to take what you have learned over the past 3-5 years and apply that to the new systems.

Now, if you are really stuck in a 'Production Support DBA' role - where you cannot even think about working in any of the other areas then I would say he did the right thing. That can become very boring - very quickly...

Jeffrey Williams
Problems are opportunites brilliantly disguised as insurmountable obstacles.

How to post questions to get better answers faster
Managing Transaction Logs
Post #1353309
Indianrock
Posted Monday, September 03, 2012 4:24 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 5:25 AM
Points: 564, Visits: 1,457
As far as Systems Admins taking over sql server support duties, I think that can work as far as infrastructure and backups ( where backups are handled by something other than native sql tools ).

We've gone down that road twice, due to decisions being made by IT managers in the absence of any DBAs or DBA managers. The first time native sql backups and log shipping were replaced by Commvault backups administered by Systems Admins. This time we're headed towards Netapp snap backup and its not clear yet if the DBAs we now have will be involved in that or not.

Our System Admins have so far steadfastly refused to get involved in the nuts and bolts of sql server which means they could not manage maintenance like reindexing and update statistics in any reasonable way.


Post #1353645
Jeff Moden
Posted Monday, September 03, 2012 8:01 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 5:13 AM
Points: 32,906, Visits: 26,793
Indianrock (9/3/2012)
As far as Systems Admins taking over sql server support duties, I think that can work as far as infrastructure and backups ( where backups are handled by something other than native sql tools ).

We've gone down that road twice, due to decisions being made by IT managers in the absence of any DBAs or DBA managers. The first time native sql backups and log shipping were replaced by Commvault backups administered by Systems Admins. This time we're headed towards Netapp snap backup and its not clear yet if the DBAs we now have will be involved in that or not.

Our System Admins have so far steadfastly refused to get involved in the nuts and bolts of sql server which means they could not manage maintenance like reindexing and update statistics in any reasonable way.


Have they ever tried doing a restore to make sure it all works as advertised? Any DR drills to make sure DR is actually working?

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1353673
Indianrock
Posted Monday, September 03, 2012 9:07 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 5:25 AM
Points: 564, Visits: 1,457
If you're referring to the Netapp snap manager for sql stuff, no we haven't instituted it yet. As a production DBA I was all set to take some training and/or do extensive reading to get familiar with the software, but now I'm hearing my manager say he doesn't want his DBAs involved in backups and restore -- he views that as infrastructure team duties -- at least in our environments with large sql databases.

So we're at a bit of a standoff, Systems Admins wanting to do netapp snaps for everything except databases and DBAs being told not to get involved.


Post #1353685
« Prev Topic | Next Topic »

Add to briefcase
19 posts, Page 2 of 2
««12

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.