Comments
Sort by recent activity
Hi Chris,
Thanks for that. Is there currently any workaround for this bug?
Regards,
Avinash / comments
Hi Chris,
Thanks for that. Is there currently any workaround for this bug?
Regards,
Avinash
Hi Chris,
Thanks for your response. I have just emailed support@red-gate.com with the attached log files.
Regards,
Avinash / comments
Hi Chris,
Thanks for your response. I have just emailed support@red-gate.com with the attached log files.
Regards,
Avinash
Hi Chris,
Thanks for your response. I received your email a few hours ago and have carried out the changes that you suggested.
However, performing those changes entirely disables the data collection for those types of metrics. After performing the change there is no data displayed under Top 10 Waits" or "Top 10 Queries" which is not really what we want.
Even though the data collection is disabled, this does not prevent that query (in the initial post) from executing. It just means that the query runs in practically no time with extremely low resource consumption due to there being no data present for the period run for.
Thanks and Regards,
Avinash / comments
Hi Chris,
Thanks for your response. I received your email a few hours ago and have carried out the changes that you suggested.
However, performing those changes entirely disables the data collectio...
I have not heard back yet regarding this issue. Is there a resolution to the problem?
Thanks,
Avinash / comments
I have not heard back yet regarding this issue. Is there a resolution to the problem?
Thanks,
Avinash
Hi Chris,
I have reduced the data purge window for the "Performance diagnostics data" and "SQL process data" to 3 days.
However, this does not seem to have solved the issue stated initially.
Regards,
Avinash / comments
Hi Chris,
I have reduced the data purge window for the "Performance diagnostics data" and "SQL process data" to 3 days.
However, this does not seem to have solved the issue stated initially.
Regard...
Hi Chris,
Thanks for your response.
The database RedGateMonitor used as the SQL Monitor 4 data repository is already in a maintenance plan and the indexes are reorganized or rebuilt on a daily basis based on their fragmentation level.
Our current purge window for the Performance diagnostics data is 1 week. I will try reducing the purge window to 3 days to see if this helps. Just wanted to point out that in your product documentation it states that the default purge window for this type of data is 1 month (http://documentation.red-gate.com/display/SM4/Purging+SQL+Monitor+data) so was just wondering what the impact would have been if we were storing 1 months worth of that type of data.
This issue was not present in SQL Monitor v3.5 though.
Thank you for your help in this matter.
Regards,
Avinash / comments
Hi Chris,
Thanks for your response.
The database RedGateMonitor used as the SQL Monitor 4 data repository is already in a maintenance plan and the indexes are reorganized or rebuilt on a daily basi...
Funnily enough the disk read/write time stats on the drives in my cluster started getting populated again. Not all at once though. They came trickling in; one day the Disk Avg. Read time for one drive started getting populated, few days later the Disk Avg. Write time for another drive and so on so forth until all drive statistics were back.
No guarantee it's going to stay the same the next time we perform a cluster failover though! / comments
Funnily enough the disk read/write time stats on the drives in my cluster started getting populated again. Not all at once though. They came trickling in; one day the Disk Avg. Read time for one dr...
Apparently this is a known bug (SRP-9314) in SQL Monitor. The response I got from Red Gate in ticket "Unable to get Disk avg. read/write time for certain drives" was that they are aware of the bug but cannot say when it will be looked at. / comments
Apparently this is a known bug (SRP-9314) in SQL Monitor. The response I got from Red Gate in ticket "Unable to get Disk avg. read/write time for certain drives" was that they are aware of the bug ...
No, I have not tried that yet. Could you let me know if that works out for you. Thanks. / comments
No, I have not tried that yet. Could you let me know if that works out for you. Thanks.
Has there been any resolution for this issue? I am experiencing a similar issue on our SQL cluster / comments
Has there been any resolution for this issue? I am experiencing a similar issue on our SQL cluster