Comments
Sort by recent activity
Could I ask what version of SQL Server you are using?
SQL Response checks the log file looking for DBCC CHECKDB lines. There was an issue with SP2 of Sql Server 2005 that meant that when using maintainance plans it would lose the database context and run the check on the default database. If this happens the log shows
DBCC CHECKDB (mssqlsystemresource) WITH no_infomsgs ((etc.))
rather the name of the DB it was meant to check. The information can be found here http://support.microsoft.com/kb/934459/ which as I read it meant that the maintainance plans weren't actually checking the DB.
I tried this locally on a test box and adding the fix from that link fixed it here.
Reading this http://blogs.msdn.com/psssql/archive/20 ... ained.aspx it looks like there were multiple issues with SP2 that needed patching (indeed they re-released SP2 after a while it seems) / comments
Could I ask what version of SQL Server you are using?
SQL Response checks the log file looking for DBCC CHECKDB lines. There was an issue with SP2 of Sql Server 2005 that meant that when using mai...
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...