Comments
Sort by recent activity
Hi,
The server cloumn is there beacuse you can select the groups as well which would show all incidents for servers in that group. / comments
Hi,
The server cloumn is there beacuse you can select the groups as well which would show all incidents for servers in that group.
Hi,
The incident you're getting is outright job failure correct? This comes directly from the job history logs so should match with that. I'll send you a PM with my email asking for more information. / comments
Hi,
The incident you're getting is outright job failure correct? This comes directly from the job history logs so should match with that. I'll send you a PM with my email asking for more informat...
Hi Bill,
Great stuff - Thanks for taking the time to put all that down, I can assure you we'll take it into account.
I just picked up on one thing in particular I'd like to check with you:
preachuk wrote:
6. One of the Recommendations was 'DB needs Integrity check,' but we are in fact doing a DBCC in SQL 2005 Maintenance plan using the default wizard. it does a 'DBCC CHECKDB with NO_INFOMSGS' so I am guessing this is a false-positive.
We use SQL Server's error log to detect DBCC CHECKDB runs which should still show, for instance if I run the same command on the Adventure Works database then my error log has something like: DBCC CHECKDB (AdventureWorks) WITH no_infomsgs executed by MYDOMAIN\nigel.morse found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 10 seconds.
Now there was an issue here with the original beta (Data base need integrity check) but I think that made the new updated beta build 520 available here so if you're not using that you might like to see if that one works, and if you are already using it then please let me know as we may need to look at it again!
Thanks,
Nigel / comments
Hi Bill,
Great stuff - Thanks for taking the time to put all that down, I can assure you we'll take it into account.
I just picked up on one thing in particular I'd like to check with you:
preachu...
I suspect the "block" is correct as that comes direct from the sysprocesses table, but it does look like the SQL we report as applying to it may be incorrect (as per http://www.red-gate.com/MessageBoard/vi ... php?t=6507 [image] )
We've got this logged as a bug and are looking to fix it. / comments
I suspect the "block" is correct as that comes direct from the sysprocesses table, but it does look like the SQL we report as applying to it may be incorrect (as per http://www.red-gate.com/Message...
Hi,
The Incident Repository is monitoring all the time and stores the incidents locally to itself. When you open the client it then asks the repository for the incidents/recomendations. The speed here depends on mainly incidents/recomendations you have and how fast the machine with incident repository is. (It will also depend on many servers it's monitoring and how busy those servers are). Having lots of tables shouldn't be a problem - it might take a while for some recomendations to be checked (indices being a good example)
When you say "initial" tasks do you find it runs ok after it has done the first load of incidents when starting the client? / comments
Hi,
The Incident Repository is monitoring all the time and stores the incidents locally to itself. When you open the client it then asks the repository for the incidents/recomendations. The speed...
Thanks for looking at getting me the values.
As for your question the short answer is that no, we don't allow for any changes.
However as I understand it the 2005 algorithm is simply more accurate in it's calculations of fragmentation when pages are in different extents, which means it may report higher, but more "accurate" values.
So if my understanding is correct then perhaps we should use a lower threshold for 2000 rather than a higher one for 2005? / comments
Thanks for looking at getting me the values.
As for your question the short answer is that no, we don't allow for any changes.
However as I understand it the 2005 algorithm is simply more accurate ...
Hi - sorry to take so long to get back to you.
Could you possibly send me the output of the DBCC SHOWCONTIG for the table or indicies in question please?
Also could you let me know what you used to rebuild the indices?
Thanks,
Nigel / comments
Hi - sorry to take so long to get back to you.
Could you possibly send me the output of the DBCC SHOWCONTIG for the table or indicies in question please?
Also could you let me know what you used to...
Hi Mark,
SQL Response currently uses a DBCC SHOWCONTIG (DBCC SHOWCONTIG WITH TABLERESULTS, ALL_INDEXES, FAST to be exact) and we then look at the logical scan fragmentation and use that to send a recomendation if an index or table is above a certain size and the fragmenation is "too high".
(Note that query can create locks on SQL Server 2000 which can cause blocks so we'll be modifying it slightly for final release to one that won't) / comments
Hi Mark,
SQL Response currently uses a DBCC SHOWCONTIG (DBCC SHOWCONTIG WITH TABLERESULTS, ALL_INDEXES, FAST to be exact) and we then look at the logical scan fragmentation and use that to send a ...
Hi,
Is the date correct at least now? the problem before was the date of the Job Did Not Start was in the future - I just want to see if this is the same or a new problem.
What we so is to check is the last run date of the job, which if it's showing in the job history then it should have updated.
If you're using Enterprise Manager then when you show the jobs it should have a "last run status (Start Date)" column - which should show when this job last ran and whether it worked or not (this is different from the job history.) Could you possibly check this soon after a "did not start" incident arrives and possibly send me screen shots of that and of SQL Response please?
Thanks,
Nigel / comments
Hi,
Is the date correct at least now? the problem before was the date of the Job Did Not Start was in the future - I just want to see if this is the same or a new problem.
What we so is to check is...
Thanks for reporting this. We're going to switch to using a query that won't cause locks on the indexes which will hopefully fix it for final release / comments
Thanks for reporting this. We're going to switch to using a query that won't cause locks on the indexes which will hopefully fix it for final release