Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Career growth - Production Support SQL Server DBA Expand / Collapse
Author
Message
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 5, 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
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, October 17, 2014 10:29 AM
Points: 3,214, Visits: 2,343
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
Posted Friday, January 29, 2010 12:12 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 9:24 PM
Points: 17,807, Visits: 15,728
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, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #856327
Posted Friday, January 29, 2010 2:12 PM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 6:56 PM
Points: 4,400, Visits: 6,257
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
Posted Sunday, September 2, 2012 3:03 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Today @ 9:41 AM
Points: 2, Visits: 369
..
Post #1353281
Posted Sunday, September 2, 2012 8:10 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Thursday, October 2, 2014 12:09 PM
Points: 4,358, Visits: 9,538
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
Posted Monday, September 3, 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 @ 8:52 AM
Points: 599, Visits: 1,711
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
Posted Monday, September 3, 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 @ 9:36 PM
Points: 35,347, Visits: 31,885
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1353673
Posted Monday, September 3, 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 @ 8:52 AM
Points: 599, Visits: 1,711
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
Posted Thursday, October 24, 2013 11:49 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, October 24, 2013 11:46 AM
Points: 1, Visits: 0
I've seen some of the responses to this topic and I want to provide a bit more of a balanced response. There will always be demand for both Support and Dev guys. There's money in both. How much you get depends on the amount of expertise you build and where you want to take your career. If what you're trying to do is become a great Production Support guy, then you're probably on the right track. If what you're trying to do is launch a Development career, the answer is more like "maybe."

From experience running Production Support teams, the best Support folks come with good Development backgrounds and the converse isn't necessarily true (you won't become a great Developer by doing Prod Support, though you might be more conscientious about the SQL you write). Sure, there is something to be learned for Developers in Support. For example, you'll have a better view of how systems are structured and will have some insight into the environments where applications run, but unless you're doing something like Level 3 Support (bug-fixes), don't expect to be able to code elegant solutions. Even with Level 3 Support, the design decisions are already made for you. I would say, if you want to launch a Dev career, get a Dev position. There's plenty of them out there.

Prod Support has processes and a discipline of its own. These are complementary, at best, with what you'd learn when doing Development. For example, in Support, you won't really learn how to put together code in an Agile process, but you will learn how to effectively manage incidents and restore service quickly.

If you'd like to learn more about Production Support, check out http://www.prodsupportblog.com.
Post #1508198
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse