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 123»»»

The On-call Demands Expand / Collapse
Author
Message
Posted Thursday, April 05, 2012 9:29 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
Comments posted to this topic are about the item The On-call Demands






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1279305
Posted Friday, April 06, 2012 5:14 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, November 21, 2013 2:25 PM
Points: 1, Visits: 80
Being a DBA has changed my mind about IT. I am on call as probably most 24/7. I maintain 39 SQL servers. I am lucky however so far I have yet had an evening disturbed by a phone call, email that one of my servers has an issue. I am the only DBA. We have a lot of Exchange personnel and a couple of Enterprise Vault guys. It seems they are constantly being called in to fix this a or multiple problems after hours, don't get me wrong I have my fair share of issues, but I contribute a lot of my success to my father, he taught long ago to do a job right. I don't make a guess or let me see what this does. I want it done right before I turn a product out or leave for the day. So I feel lucky that even though after hours the clock ticks on down but because I try to be proactive while I am at work, my family time doesn't suffer. I also know eventually there are potential issues that will arise and the midnight hour will come and go where I will have to go in and fix this or that issue.
Post #1279410
Posted Friday, April 06, 2012 6:23 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, March 27, 2014 9:49 AM
Points: 18, Visits: 100
Depending on departmental churn rate and courtesy swaps, my on-call period falls on every 20-32 weeks. Where call frequency is concerned, we've managed to hire strong skillsets recently for 3rd shift so it's rare that we get more than 2 calls during the week, usually falling on the slot where there's no shift coverage (Sunday late PM). It's gotten a lot better, so no complaints.
Post #1279447
Posted Friday, April 06, 2012 6:31 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: 2 days ago @ 9:48 AM
Points: 70, Visits: 280
Our 8 DBAs take turns, a week at a time. We have a mix of RDBMS species, so if we handle an after-hours call on a system we don't understand, we will bring another DBA into the conversation.

I'd say we handle around 3-5 after-hour calls a week. At this point, 95% of the issues are NOT MS-SQL :)
Post #1279450
Posted Friday, April 06, 2012 6:47 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
Grubb (4/6/2012)

I'd say we handle around 3-5 after-hour calls a week. At this point, 95% of the issues are NOT MS-SQL :)


That's always fun. I used to work on a mixed team (DB, AD, Exchange, etc) and most of my calls were non-SQL Server. Always interesting to learn something new, frustrating when it's under pressure.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1279461
Posted Friday, April 06, 2012 7:16 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 1:14 PM
Points: 10,910, Visits: 12,547
At my current company call is about every 10 weeks. The only calls I've gotten are for batch processes that aren't automated and have regular problems for which there are standard fix scripts. Don't ask why the regular problems haven't been fixed . That's only 5 times a week and at hours you are normally awake anyway.

At the last company I had call duties for we started with 9 in the IT department and ended up with 5 before my position was eliminated. We were on call for everything IT, from PC to network to Exchange to SQL Server. 99% of the calls were non-SQL related and had documented solutions. It still sucked at 3am. Averaged maybe 4-5 calls a week.




Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #1279475
Posted Friday, April 06, 2012 7:45 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 06, 2014 1:05 PM
Points: 1,334, Visits: 3,068
2 DBA's, and we are on call every other month. The key to on-call is proactive automation and monitoring. Once you get that set up on all your db servers, you are emailed issues before they become major issues and you can deal with them during regular hours, thus preventing those late night calls like a T-Log that finally filled up a disk in the middle of the night. It doesn't prevent all of them mind you, but it does cut the volume down considerably. Also, having a well trained help-desk staff that can ferret out silly non-issues and simple connectivity issues before they get to you can help out considerably as well. If you have that all setup first then being on call is not such a nightmare. I have often found over the years through sheer experience that alot of after hours issues could have been caught during business hours if the checks and monitoring were already in place. There will always be issues in SQL Server that crop up quite suddenly and you must deal with them as they occur. However, I have found that 95% of most issues in SQL Server are as the result of accumulation. In other words they develop over time. This is where monitoring and automation come in.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1279490
Posted Friday, April 06, 2012 9:05 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 3:45 PM
Points: 130, Visits: 280
We have a team of 4 DBAs who are more or less on-call 24/7. As the team lead I usually get the first calls and will route them to the proper DBA as necessary. We average about 2-3 after-hours calls a week. About 40% of the time it is an actual database or SQL Server issue. That's what happens when you have 10 times as many developers as DBAs and the DEVELOPERS are the ones writing all stored procedures and creating/modifying tables and databases without DBA consultation or interaction.
Yes, you read that correctly. Welcome to my hell.

We also currently do not have ANY real monitoring and alerting in place except for what we have been able to slap together in between projects and emergencies. It is improving, however, since we will be bringing on one of the industry's leading SQL monitoring tools in the next few weeks. Then once we have everything dialed in we should have more time to prevent help the developers from destroying architect the databases.
Post #1279537
Posted Friday, April 06, 2012 9:28 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
bclyde-1080677 (4/6/2012)

... Then once we have everything dialed in we should have more time to prevent help the developers from destroying architect the databases.









Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1279546
Posted Friday, April 06, 2012 12:04 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 06, 2014 1:05 PM
Points: 1,334, Visits: 3,068
That's what happens when you have 10 times as many developers as DBAs and the DEVELOPERS are the ones writing all stored procedures and creating/modifying tables and databases without DBA consultation or interaction.
Yes, you read that correctly. Welcome to my hell.



I feel your pain. I can tell you though at my shop one of the first things I convinced my manager of is that we do not just hit F5 on any SQL code coming into our QA environment. We review all incoming SQL code for standards and performance metrics and if ANY developer code fails that review, then that code is returned to development for retooling. Period. There are no exceptions to this rule and we got managment buy in on it as well. Without management buy-in its useless. The code does not rollout unless the DBA group bless it, period. Some see this as a bottleneck, sure, but let a developer lock up an important production database with a badly coded stored procedure and the phones start lighting up, then managment sees the light real fast.


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1279614
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse