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

Monitoring for Non Existent Events Expand / Collapse
Author
Message
Posted Wednesday, July 30, 2014 9:58 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,204, Visits: 15,649
Comments posted to this topic are about the item Monitoring for Non Existent Events






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1598081
Posted Thursday, July 31, 2014 3:02 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:12 AM
Points: 5,626, Visits: 3,507
See as so many of us will have studied state machines in one way or another, it remains astounding that so many of us, so many times do not setup monitoring to cater for all states. This is rather lax of us and very remiss. It is hardly surprising when not enough consideration is paid to instrumentation in general.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1598145
Posted Thursday, July 31, 2014 6:31 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 1:41 PM
Points: 1,623, Visits: 1,966
It takes a little more time, but changing the exception handling process for a job from "wait for users to notify the right person" to "have SQL Server notify the right person" is definitely worthwhile.

I have checks for jobs that haven't run or haven't finished in a reasonable period of time but we can always use more. It's the irregular processes that run once a month that are hard to pin down.
Post #1598221
Posted Thursday, July 31, 2014 6:32 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 6:05 AM
Points: 40,258, Visits: 36,681
That's one of the points in my DB corruption presentation. Don't assume everything's OK. Don't assume that the backups are succeeding just because you're not getting backup failure messages.


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1598223
Posted Thursday, July 31, 2014 7:36 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, October 9, 2014 1:19 PM
Points: 327, Visits: 587
Thanks to SQL Sentry we have built on to our job step -- alert-- and can now check for jobs that run too long. But I do see one more hole... jobs calling code that is not well built, and it completes with out error, but does not do what you expected... I have had this come up from time to time.. the latest issue was bad data flowing into the database and was not picked up until the weekly maint schedule found that the data did not match the data type. One other time we had a trigger that got turned off.. and not turned back on...

David
Post #1598260
Posted Thursday, July 31, 2014 9:04 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, October 27, 2014 2:35 PM
Points: 214, Visits: 621
"A job that runs long or doesn't run at all can sting just as bad as one that fails."

What's the difference?

There is no difference.
Post #1598320
Posted Thursday, July 31, 2014 9:40 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:50 PM
Points: 2,414, Visits: 1,493
Developers have in the past cursed bean counters for various reasons. However there are reasons for counting and tracking. Maybe we need to regularly check and see if we have the appropriate beans.


Not all gray hairs are Dinosaurs!
Post #1598338
Posted Thursday, July 31, 2014 10:42 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,204, Visits: 15,649
GoofyGuy (7/31/2014)
"A job that runs long or doesn't run at all can sting just as bad as one that fails."

What's the difference?

There is no difference.


Sure there is. A long running job might be stuck, but it's done some work. If you clear the issue, it may run quicker. Depending on the job, ETL or some check, it might not affect your day to day operations.

One that doesn't run is bad because you might not realize the event hasn't occurred. If there is no issue, like a corruption check, then it might not affect you, but certainly it could in the future. A failure of the same job would be indicative of a problem, at least it's likely.

These all can cause problems, but there certainly is a difference in many cases. Not all, but many.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1598380
Posted Thursday, July 31, 2014 10:45 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, October 27, 2014 2:35 PM
Points: 214, Visits: 621
Steve Jones - SSC Editor (7/31/2014)
GoofyGuy (7/31/2014)
"A job that runs long or doesn't run at all can sting just as bad as one that fails."

What's the difference?

There is no difference.


Sure there is. A long running job might be stuck, but it's done some work. If you clear the issue, it may run quicker. Depending on the job, ETL or some check, it might not affect your day to day operations.

One that doesn't run is bad because you might not realize the event hasn't occurred. If there is no issue, like a corruption check, then it might not affect you, but certainly it could in the future. A failure of the same job would be indicative of a problem, at least it's likely.

These all can cause problems, but there certainly is a difference in many cases. Not all, but many.


All three cases represent failure to design and test properly. There is no difference, in my mind, from that perspective.
Post #1598382
Posted Thursday, July 31, 2014 10:52 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 7:40 AM
Points: 17,843, Visits: 15,788
Miles Neale (7/31/2014)
Developers have in the past cursed bean counters for various reasons. However there are reasons for counting and tracking. Maybe we need to regularly check and see if we have the appropriate beans.


Cool beans.

If the bean counter is our check and balance, maybe that is an indicator we haven't been doing enough testing and verification on our part.




Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #1598386
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse