August 2, 2014 at 1:52 am
Comments posted to this topic are about the item A DBA at the Opera
August 4, 2014 at 2:31 am
What is the old saying? "A stitch in time saves nine!!!"
There is no reason for computing to be any different to anything else. I cannot remember the number of times when I have said "I don't have to do it yet but I'll start in now and get it out of the way" only to find that my personal deadline has come and gone because of one issue or another.
I guess that no matter how much effort we put in to avoid the drama it will come anyway. However, as professionals we should be ensure that any drama remains that and doesn't end up being a crisis.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 4, 2014 at 8:47 am
Gary Varga (8/4/2014)
What is the old saying? "A stitch in time saves nine!!!"There is no reason for computing to be any different to anything else. I cannot remember the number of times when I have said "I don't have to do it yet but I'll start in now and get it out of the way" only to find that my personal deadline has come and gone because of one issue or another.
I guess that no matter how much effort we put in to avoid the drama it will come anyway. However, as professionals we should be ensure that any drama remains that and doesn't end up being a crisis.
Here Here!!
+1
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 4, 2014 at 8:56 am
Oh geez. I feel quite operatic in the sense of this article lately 😛
The sysadmin here decided a few weeks back that the CPU usage of the SQL Server was just too high after midnight, which just so happens to be the time when things like full backups, DBCC checks, statistics updates, and index rebuilds are done. Without informing he, he started restarting the server at around 1:00 A.M., right in the middle of all the maintenance work.
Today, he calls me and tells me about the problems, and says the maintenance stuff is making the CPU too high. I question why that's a problem, since everyone's off-premises, and the jobs finish by 7:00 A.M., and work for the day starts at 9:30 A.M. Plenty of leeway. "Well, the CPU is just too high! It's bad for the server!" Alright, well, the CPU will come down eventually, especially if you stop restarting the server every day, which forces recompilation on everything- "No! That's not it! There must be something on the SQL side of things messing it all up!" Well, technically, yes, if there wasn't interference with the processes meant to control that, and also, we don't have backups anymore since they haven't been allowed to run- "It's better this way!" ... *Sigh*.
I'm not looking forward to the final act, which will probably involve corruption and a few dead databases :hehe:
- 😀
August 4, 2014 at 9:02 am
Andrew Kernodle (8/4/2014)
Oh geez. I feel quite operatic in the sense of this article lately 😛The sysadmin here decided a few weeks back that the CPU usage of the SQL Server was just too high after midnight, which just so happens to be the time when things like full backups, DBCC checks, statistics updates, and index rebuilds are done. Without informing he, he started restarting the server at around 1:00 A.M., right in the middle of all the maintenance work.
Today, he calls me and tells me about the problems, and says the maintenance stuff is making the CPU too high. I question why that's a problem, since everyone's off-premises, and the jobs finish by 7:00 A.M., and work for the day starts at 9:30 A.M. Plenty of leeway. "Well, the CPU is just too high! It's bad for the server!" Alright, well, the CPU will come down eventually, especially if you stop restarting the server every day, which forces recompilation on everything- "No! That's not it! There must be something on the SQL side of things messing it all up!" Well, technically, yes, if there wasn't interference with the processes meant to control that, and also, we don't have backups anymore since they haven't been allowed to run- "It's better this way!" ... *Sigh*.
I'm not looking forward to the final act, which will probably involve corruption and a few dead databases :hehe:
ROFLMAO
Amazing how stubborn sysadmins can get sometimes when they don't understand.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 4, 2014 at 9:11 am
Andrew Kernodle (8/4/2014)
Oh geez. I feel quite operatic in the sense of this article lately 😛The sysadmin here decided a few weeks back that the CPU usage of the SQL Server was just too high after midnight, which just so happens to be the time when things like full backups, DBCC checks, statistics updates, and index rebuilds are done. Without informing he, he started restarting the server at around 1:00 A.M., right in the middle of all the maintenance work.
Today, he calls me and tells me about the problems, and says the maintenance stuff is making the CPU too high. I question why that's a problem, since everyone's off-premises, and the jobs finish by 7:00 A.M., and work for the day starts at 9:30 A.M. Plenty of leeway. "Well, the CPU is just too high! It's bad for the server!" Alright, well, the CPU will come down eventually, especially if you stop restarting the server every day, which forces recompilation on everything- "No! That's not it! There must be something on the SQL side of things messing it all up!" Well, technically, yes, if there wasn't interference with the processes meant to control that, and also, we don't have backups anymore since they haven't been allowed to run- "It's better this way!" ... *Sigh*.
I'm not looking forward to the final act, which will probably involve corruption and a few dead databases :hehe:
Are you in a Jim Henson Production??? 😛
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 4, 2014 at 9:13 am
... You know, now that I think about it... 😛
But eh, frustrating though it may be, I'll just have to get some climbing gear out and start scaling the cliff wall of management. Provided nothing too nonsensical happens, I should be able to get everything sorted out. Still, it's a little unnerving that a problem like this can just dive-bomb onto me when I thought I had everything on the server running quite well :crazy:
- 😀
August 4, 2014 at 9:20 am
Andrew Kernodle (8/4/2014)
... You know, now that I think about it... 😛But eh, frustrating though it may be, I'll just have to get some climbing gear out and start scaling the cliff wall of management. Provided nothing too nonsensical happens, I should be able to get everything sorted out. Still, it's a little unnerving that a problem like this can just dive-bomb onto me when I thought I had everything on the server running quite well :crazy:
That's the beauty of IT. We can implement process to control most events that are computer related. Sadly we can't account for all of the possible stupid things other humans will do that will undo everything we have tried to accomplish.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 4, 2014 at 9:27 am
Wow. I couldn't make up a story so excellent as that one.
Louis
August 4, 2014 at 9:29 am
...and for once it is not a "Stupid Developer" tale!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 4, 2014 at 9:46 am
Louis Davidson wrote:
Tragedies are very much part of IT ... occasionally, you, as a DBA, will face one of those decisions that really matter, and which has the possibility to greatly affect your future ...
Absolutely true, and not only for DBAs, but for developers as well. I try very hard to follow some basic rules to avoid tragedy (which I've experienced at least once in my own career):
1. Always 'go the extra mile'. If a problem crops up five minutes before you're due to walk out the door for a long holiday, solve the problem first, even if it chews into your time off a bit.
2. 'Good enough' isn't. Sometimes in the crush of work, it's tempting to leave out an error trap or to omit some testing, which later turns out to be a critical mistake. Although perfection is something to which we might only aspire, quality workmanship is wholly achievable.
3. Teamwork counts. Bring in the people around you to help solve the problem, if your lack the time and/or expertise to do so on your own. There is nothing heroic about letting one's ego get in the way of a good solution.
The analogy between the drama found in opera and that encountered in IT is a good one, but it only goes so far. Unlike 'rescue operas' like Beethoven's Fidelio and Schumann's Genoveva - in which a hero swoops in from the outside to set matters to rights - we must solve our IT problems amongst ourselves; else tragedy may well swallow us up.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply