SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The On-call Demands


The On-call Demands

Author
Message
IowaTechBear
IowaTechBear
Valued Member
Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)

Group: General Forum Members
Points: 72 Visits: 111
When I started at my current company I was the 3rd DBA so I was on call every third week. Before I joined the two DBAs would alternate, one would take day call the other would take night call and then switch back and forth every other week. Now we have 5 DBAs so I am on call every 5th week.

When we are on call it is 24/7. The night time calls are rare, maybe once a week or less on average, but an average is just that. We can go a week without night time calls and a week when the service center calls with a problem after midnight 3 or 4 times in the same week. (Sleep, what is sleep?) Hehe

We strictly handle SQL Server support. No Access, no applications, just SQL Server. We have well over 100 instances of SQL Server to administrate spread throughout the state of Iowa.

Our manager wants whoever is on call to do just that - take care of issues as they happen through the day, freeing up the other DBAs to do their project work. It also frees the on call person from project work and allows them to do things that usually get pushed to the side such as documentation. :-D

This is the first time where I am part of a team of DBAs and I like it. There can be more stress, but it is a stress that I can deal with rather than at smaller companies where I would have to be DBA, Developer, Analyst, and have non SQL Server problems shoved in my direction and they want all problems solved at the same time. w00t

I just plan my schedule around the on-call week. No trips, no outings, nothing that would keep me from responding to a call within 20 minutes.

So it is a planned stress vs. a chaotic stress. Cool

-----------------
Larry
(What color is your database?)
cjones 47715
cjones 47715
Grasshopper
Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)

Group: General Forum Members
Points: 12 Visits: 45
How funny, I got called this morning! I seem to get 2-3 calls a month. We have 200+ employees and a call center. I'm our software dev, so if something happens with the database it tends to affect my applications. So I get called on every glitch to either help troubleshoot the issue, fix it, or make the data right if our dialer didn't get loaded properly.

It never fails though, Mondays and Fridays are rip call days and always when on vacations.
TravisDBA
TravisDBA
SSCrazy
SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)

Group: General Forum Members
Points: 2012 Visits: 3069

We strictly handle SQL Server support. No Access, no applications, just SQL Server. We have well over 100 instances of SQL Server to administrate spread throughout the state of Iowa.



I totally agree with most of what you say. However, the problem is with the above, is the people reporting the issue(error), as well as HelpDesk personnel on duty many times cannot always determine if the issue is database related, network related, or application(even Access) related. In many companies the Help Desk department has a constant turnover of people, so seasoned individuals that have the experience to detect the difference have often moved on or left. So, as a result, many times a DBA will get called for a wild goose chase anyway. Fortunately, in my company the Help desk people have been around for awhile and can usually ferret this out before the call is made. :-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"
Lynn Pettis
Lynn Pettis
SSC-Dedicated
SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)

Group: General Forum Members
Points: 39852 Visits: 38563
TravisDBA (4/6/2012)

We strictly handle SQL Server support. No Access, no applications, just SQL Server. We have well over 100 instances of SQL Server to administrate spread throughout the state of Iowa.



I totally agree with most of what you say. However, the problem is with that, is the people reporting the issue(error), as well as HelpDesk personnel on duty many times cannot always determine if the issue is database related, network related, or application(even Access) related. In many companies the Help Desk department has a constant turnover of people, so seasoned individuals that have the experience to detect the difference have often moved on or left. So, as a result, many times a DBA will get called for a wild goose chase anyway. Fortunately, in my company the Help desk people have been around for awhile and can usually ferret this out before the call is made. :-D


My experience has been it is ALWAYS a database issue until proven otherwise beyond any reasonable doubt.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
TravisDBA
TravisDBA
SSCrazy
SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)

Group: General Forum Members
Points: 2012 Visits: 3069
Exactly my point, we get called on a lot of wild goose chases that had nothing to do with the database.:-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"
IowaTechBear
IowaTechBear
Valued Member
Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)Valued Member (72 reputation)

Group: General Forum Members
Points: 72 Visits: 111
Lynn Pettis (4/6/2012)
TravisDBA (4/6/2012)

We strictly handle SQL Server support. No Access, no applications, just SQL Server. We have well over 100 instances of SQL Server to administrate spread throughout the state of Iowa.



I totally agree with most of what you say. However, the problem is with that, is the people reporting the issue(error), as well as HelpDesk personnel on duty many times cannot always determine if the issue is database related, network related, or application(even Access) related. In many companies the Help Desk department has a constant turnover of people, so seasoned individuals that have the experience to detect the difference have often moved on or left. So, as a result, many times a DBA will get called for a wild goose chase anyway. Fortunately, in my company the Help desk people have been around for awhile and can usually ferret this out before the call is made. :-D


My experience has been it is ALWAYS a database issue until proven otherwise beyond any reasonable doubt.


I agree. I don't want to give the impression that we only receive pages or calls about SQL Server. But we are third level support; a problem has to pass through two other levels before we are paged. Doze

Usually the service desk does what they can to help. If necessary it gets passed along to the application analyst on call who is responsible for the specific application. If the application analyst runs into problem then they contact our layer and the analyst are pretty good at notifying the teams that they think would be the most likely to help such as networking, server, application or client device people. Cool;-) Hehe

Our service center does a pretty good job of working out who to contact for a problem, which for SQL Server issues is about 95%+ of the time. The other 5% we scratch our head and wonder why it was sent to us.Crazy

-----------------
Larry
(What color is your database?)
phegedusich
phegedusich
SSC-Enthusiastic
SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)SSC-Enthusiastic (152 reputation)

Group: General Forum Members
Points: 152 Visits: 531
I'm not an enterprise DBA, but I support a couple of applications with off-farm SQL instances. SQL has been rock-solid for the duration of my tenure; most middle-of-the-night calls result from application snafus.

I have to give a huge "THIS" to proper development and code promotion procedures. SQL isn't excused. Adopt a strong test and promotion methodology, and stick to it. At my current job, this isn't an option and is mandated by regulation, so you can be sure it's followed without exception.

If your company doesn't have controls and your cowboy developers can run roughshod over the production environment, become a champion for controls and methods. Do it now.
JP Dakota, PRC
JP Dakota, PRC
SSC Veteran
SSC Veteran (284 reputation)SSC Veteran (284 reputation)SSC Veteran (284 reputation)SSC Veteran (284 reputation)SSC Veteran (284 reputation)SSC Veteran (284 reputation)SSC Veteran (284 reputation)SSC Veteran (284 reputation)

Group: General Forum Members
Points: 284 Visits: 563
I am never on call. I made it a condition of employment. Been there, done that, got the t-shirt a long time ago. My work is highly specialized, so I do get called occasionally when an issue is very complicated or a DBA is stuck trying to figure something out. By occasionally I mean a couple of times a year. We have a very proficient technical staff where I work, and there are firm controls in place to prevent "accidental code" from assaulting production.
TravisDBA
TravisDBA
SSCrazy
SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)

Group: General Forum Members
Points: 2012 Visits: 3069
If your company doesn't have controls and your cowboy developers can run roughshod over the production environment, become a champion for controls and methods. Do it now.


This makes me remember an interview I once had where the interviewer started out the interview with "All my developers have sysadmin access to the production environment, Do you have a problem with that?" My immediate return question was "Who restores the production database back to point in time if they screw it up. His answer was "Well..... the DBA, of course." That pretty much terminated the interview for me right there. You can champion all you want, but if management doesn't back your controls and methods, you are pretty much left in the ditch, and it is time to just move on. :-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"
TravisDBA
TravisDBA
SSCrazy
SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)SSCrazy (2K reputation)

Group: General Forum Members
Points: 2012 Visits: 3069
JP Dakota (4/9/2012)
I am never on call. I made it a condition of employment.


I am glad for you, but in reality, most DBA's would not get the job in the first place if they made this a condition up front. It's just part of the job for most DBA's.:-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"
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search