Comments
Sort by recent activity
Thanks - but my testers here have already delighted in finding my error locally so hopefully it won't be too long to work it out. / comments
Thanks - but my testers here have already delighted in finding my error locally so hopefully it won't be too long to work it out.
Hi - Thanks for reporting this.
There's an issue we've discovered when servers are in different timezones other than UTC (GMT) in that when we look for the job starting time we internally use UTC and then correct back to the server's correct timezone. However there's an issue once you go past midnight GMT in that it corrects the time and not the date.
I'm working on it... [image] Problem is when I set my time incorrectly to test it the local domain controller won't let me logon so it's proving harder to fix than it should be! / comments
Hi - Thanks for reporting this.
There's an issue we've discovered when servers are in different timezones other than UTC (GMT) in that when we look for the job starting time we internally use UTC a...
It's possible you're behind a firewall that blocks FTP?
We've changed it to a HTTP link on http://www.red-gate.com/products/SQL_Response/index.htm now.
Sorry for the problems / comments
It's possible you're behind a firewall that blocks FTP?
We've changed it to a HTTP link on http://www.red-gate.com/products/SQL_Response/index.htm now.
Sorry for the problems
Hi - could you try right-clicking on the link and "Save link as"? / comments
Hi - could you try right-clicking on the link and "Save link as"?
Hi Phil,
What we give you here is straight out the error log. I'm afraid we've not looked into doing anything with that information.
However this information does give you the SPIDs of the processes involved (in this case 212 and 202). SQL Response may have captured the SQL process information, but as this is done by polling every so often it sadly may not have the exact processes. If you look on the performance tab you may be able to find those ids which will give you a little more information.
It also gives you the input buffer - which can contain the SQL that was executing. In this case however it refers to an RPC event (possibly calling a stored procedure).
I'll take a look tomorrow and see what else I can find out for you. / comments
Hi Phil,
What we give you here is straight out the error log. I'm afraid we've not looked into doing anything with that information.
However this information does give you the SPIDs of the process...
Those incidents are different from the "Job did not start (overrunning)" ones. A job overrun is where a run of a job takes significantly longer than it's average run - so if a job usually completes within a second and then takes 6 we tell you. I think we're planning to make it wait a number of seconds before it starts complaining as jobs that are a few seconds long aren't that accurate with the timings. / comments
Those incidents are different from the "Job did not start (overrunning)" ones. A job overrun is where a run of a job takes significantly longer than it's average run - so if a job usually complete...
It won't complain about overrun the first time (as it has no baseline). After the first run it will note the time taken and each subsequent run recalculate the average, so if the first run was 1 second and the next 5 seconds then that would be overrun. After a few runs it should be more accurate. I think for the final release we'll make it wait a few runs before declaring overruns.
For the did not run issue - could you send me a screen shot of the incidents, and a sample of the job history from sp_help_jobhistory (preferably covering the same time as reported in the incident)? I'll pm you my email. / comments
It won't complain about overrun the first time (as it has no baseline). After the first run it will note the time taken and each subsequent run recalculate the average, so if the first run was 1 se...
PDinCA wrote:
The "Did not run" is definitely a red herring! SSMS Job Monitor happily shows each job ran...
I've realised what you meant here now. The "Did not run" was refering to the job step in the panel below as part of the job overrun incident. As you said this is a red herring. We put all the job information into the tab so that in the case of a failure you can see which steps ran and which didn't. However in a job overrun we don't say which steps have run, and so the UI is displaying it as "did not run" whereas it should say something like "for information"
We're going to try hard and see if we can reproduce an erroneous "job did start" incident today. / comments
PDinCA wrote:
The "Did not run" is definitely a red herring! SSMS Job Monitor happily shows each job ran...
I've realised what you meant here now. The "Did not run" was refering to the job s...
The "job step did not run" in the additional information is just the way the UI is displaying it - i.e. we always show all the job steps, but which ones ran or didn't will only be usefull for a job failure incident - in all others it's there for information.
As for the 1000+ incidents I suspect this is due to the timezone bug that we found which generates false incidents for jobs in the future. We've fixed that. here for next release.
If you think you're getting other erroneous incidents then please do let us know as we'd really like to fix that!
Thanks,
Nigel / comments
The "job step did not run" in the additional information is just the way the UI is displaying it - i.e. we always show all the job steps, but which ones ran or didn't will only be usefull for a job...
Hi,
The job overrun is triggered when the job takes a lot longer than the average time which we track from previous runs.
A job not starting is not the same as a failure (which would be reported as Job Failure). Job did not start means that we found a time when the job should have started, however the job is not currently running and hasn't recently completed (by checking it's last run date).
Note that if a job may not start because it was still completing a previous run, we do try to detect this and report it as "job did not start (overrun)".
If this doesn't help, perhaps you could send me the details of the job schedule and how often it runs, and a sample of the recent job history? You can put that in a pm to me here, or if you like I can pm you my email to send it to.
Thanks,
Nigel / comments
Hi,
The job overrun is triggered when the job takes a lot longer than the average time which we track from previous runs.
A job not starting is not the same as a failure (which would be reported as...