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 Friday, April 6, 2012 12:54 PM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 10:36 AM
Points: 22, Visits: 102
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?)

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.

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.

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.



-----------------
Larry
(What color is your database?)
Post #1279642
Posted Friday, April 6, 2012 1:01 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, May 12, 2014 2:20 PM
Points: 5, Visits: 35
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.
Post #1279650
Posted Friday, April 6, 2012 1:05 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068

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.


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1279654
Posted Friday, April 6, 2012 1:08 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 8:53 AM
Points: 23,033, Visits: 31,556
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.


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



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)
Post #1279656
Posted Friday, April 6, 2012 1:10 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
Exactly my point, we get called on a lot of wild goose chases that had nothing to do with the database.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1279658
Posted Friday, April 6, 2012 2:57 PM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 10:36 AM
Points: 22, Visits: 102
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.


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.

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.

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.



-----------------
Larry
(What color is your database?)
Post #1279704
Posted Friday, April 6, 2012 7:37 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: 2 days ago @ 3:30 AM
Points: 53, Visits: 401
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.
Post #1279769
Posted Monday, April 9, 2012 8:26 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 10:44 AM
Points: 213, Visits: 517
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.
Post #1280164
Posted Monday, April 9, 2012 10:00 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
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.


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1280232
Posted Monday, April 9, 2012 10:11 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
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.


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

Add to briefcase ««123»»

Permissions Expand / Collapse