On call support experience

Question

On call support experience

sqluser52

Grasshopper

Points: 21
More actions
May 25, 2011 at 10:21 am

#250798

Can anyone share their on-call support experience. Problem u might have faced and steps for resolution and how long it took. Want to gather some BP or lesson learned.

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply

Chirag Roy SSChasing Mays Points: 622 More actions · Answer 1

There is plenty of information out there with regards to troubleshooting scenarios and each person's on-call experience will differ from another based on the environment, SLA's, business stake holder relationship, processes, company politics, etc. to name a few factors.

sqlstrater SSC Veteran Points: 257 More actions · Answer 2

sqlstrater

SSC Veteran

Points: 257

May 25, 2011 at 3:51 pm

#1330007

Can you plz point out few links.

Thanks

Grant Fritchey SSC Guru Points: 398882 More actions · Answer 3

Not so much a how to, but I recently posted this article on how to prepare[/url] for being the on call person.

For what it's worth, there is no average on-call response. I've had calls that took me about 30 seconds to fix (after waking up and logging on and connecting to the server) to calls that took 3 days. You have to expect them all.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

MysteryJimbo SSC-Insane Points: 24203 More actions · Answer 4

I'm on call right now!

Nothing can replace experience and documentation of the environment you are working in. Its also essential to have an escalation protocol and list of "points of contact".

Never panic, keep a cool head, and if its something you dont think you can tackle on your own or complete within SLA admit it to yourself and escalate straight away. Doing this wrong can and does cost people their jobs and their employers money.

Jeff Moden SSC Guru Points: 1004318 More actions · Answer 5

{EDIT} Terrible post from a seriously caffeine deprived day removed. My apologies.

--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.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

rfr.ferrari SSCertifiable Points: 6879 More actions · Answer 6

searching is that you learn!!!!!

[font="Times New Roman"]rfr.ferrari[/font]
DBA - SQL Server 2008
MCITP | MCTS

remember is live or suffer twice!
the period you fastest growing is the most difficult period of your life!

colin.Leversuch-Roberts SSC Guru Points: 52643 More actions · Answer 7

there's no way anyone could answer such a question because all our experiences would be different. You do the same stuff on call as you do in your working day with regard to issues ( except perhaps remotely ) if a server crashes the process is the same regardless.

I might suggest you keep a "when it goes wrong" manual, I keep a record of every issue I've ever encountered as a DBA, this includes issues with switches, hba's sans, storage, firewalls, app and web tier etc. etc. If something affected the availability of the application my database(s)/server(s) support I need to know so in the future if it happens again I might save myself ( and maybe client ) a "headless chicken" period!!

[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/

Marios Philippopoulos SSC Guru Points: 57190 More actions · Answer 8

I hate being on call! :w00t:

When I'm on call, I want to retire early.

When not on call, I feel I want to work with SQL to the grave.

But, aside from the silliness, to me on call-support experience is something you get immersed in; there is no way to prepare for it.

However, a good documentation ethic in the team really helps;

having some sort of knowledgebase on how to tackle common issues can especially help team members who may not be as senior or experienced in the day-to-day work or even those of us who may not have had experience with a certain issue. After all, no one knows everything...

In the vast number of cases, call issues will be simple. It's those once-in-a-blue-moon crises though that raise the hair at the back of my neck.

It's no fun having to call Microsoft in the middle of the night because of a server crash. :w00t:

__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]

barsuk SSChampion Points: 12280 More actions · Answer 9

You may want to sit with a Senior DBA and discuss all issues (SQL related) that used to happened before you in this organization. And how they were resolved. Make sure to document them. It is very important especially if you are new to that place, don't have much of the experience and especially, if issue happens in the middle of the night.

sujitkmishra Mr or Mrs. 500 Points: 524 More actions · Answer 10

You have already entered a house full of information. Most of the questions asked here are the problems faced or thinking ahead of a problem. Please browse through the posts and you 'll get a lot of information.

colin.Leversuch-Roberts SSC Guru Points: 52643 More actions · Answer 11

never worried about being on call, done that on and off for around 16 odd years. Generally there are not many calls, if there are then you fix the problems so you don't get called .. works well for me < grin >

[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/