Comments
Sort by recent activity
One instance. When I restarted the service yesterday, the memory stayed at around 200 - 300 MB. Most of the day. It appears that it swelled again last night and the service stopped completely at some point overnight and my connection to the repository was broken.
So something appears to be swelling it's footprint then shutting down the service when it runs out of memory. The repository is on a production build of a SQL Server 2005 box that has yet to be placed into be deployed, so it's not doing any work other than backing up the system databases every night via an SSIS package scheduled via a SQL Agent job.
Let me know if you need any additional information.
Thanks! / comments
One instance. When I restarted the service yesterday, the memory stayed at around 200 - 300 MB. Most of the day. It appears that it swelled again last night and the service stopped completely at...
I'm wondering if it could be as simple as associating a comment to the cleared alert is was associated to when it was made. Maybe a hyperlink in the comment to the cleared alert it's associated to.
Just a thought...you may already have the bases covered on this enhancement so just ignore me if you do.
Thanks! / comments
I'm wondering if it could be as simple as associating a comment to the cleared alert is was associated to when it was made. Maybe a hyperlink in the comment to the cleared alert it's associated to...
I sent my info to your email last night as well...let us know if you need any additional info. Thanks! / comments
I sent my info to your email last night as well...let us know if you need any additional info. Thanks!
Same here. "Reasons Unknown" in the details pane. / comments
Same here. "Reasons Unknown" in the details pane.
It looks like mine are also frequently running jobs. Every minute, every 15 minutes etc.. Perhaps that's the place to start. / comments
It looks like mine are also frequently running jobs. Every minute, every 15 minutes etc.. Perhaps that's the place to start.
Hello...
A little bit of an different issue. Actually two of them:
1) I am receiving job durations in the baseline history window in the negative. For instance, I have one that shows an historical run of -184 seconds.
2) I have an example of the "usual duration" alert detail information showing over 4200 seconds whereas all of the historical durations are no more than 200 seconds.
I can provide Job History detail, a snapshot of the SQLResponse screen and log files if needed.
Thanks! / comments
Hello...
A little bit of an different issue. Actually two of them:
1) I am receiving job durations in the baseline history window in the negative. For instance, I have one that shows an historical...
Just a quick enhancement request to the details section of this alert. It would be extremely helpful to know the database context of the query being executed.
Thanks! / comments
Just a quick enhancement request to the details section of this alert. It would be extremely helpful to know the database context of the query being executed.
Thanks!
priyasinha wrote:
nuberfin wrote:
The Redgate Monitor database is 45 GB now, I switched data purge from 6 months to 1 month about 4 hours ago but it's not changing the size (I even attampted a SHRINKFILE).
7 Machines/8 Instances
Trace is turned on in all instances.
Please let us know once a fix/workaround is in place. I'm going to have to shut down monitoring as it is affecting my other databases disk space availablility.
Hi,
Apologies for the error. Firstly, I would turn trace off on all SQL Server. Trace generates a lot of data and should be used very cautiously for only investigation purpose for short period of time.
The bug being discussed in this thread doesn't affect everyone. This is happening in very rare cases where purge is not able to delete few tables. You might be having a completely different issue with purge in your environment. Could you please send log file from base monitor machine so that we can investigate your issue? Please email to priya.sinha@red-gate.com. The location is C:\ProgramData\Red Gate\Logs\SQL Monitor 2 or C:\Documents and Settings\All Users\Application Data\Red Gate\Logs\SQL Monitor.
Thanks,
Priya
There are 91 log files in this directory. I'm assuming you want the ones that being with "Base Deployment...". Can you specify which ones and how far back you need? / comments
priyasinha wrote:
nuberfin wrote:
The Redgate Monitor database is 45 GB now, I switched data purge from 6 months to 1 month about 4 hours ago but it's not changing the size (I even attampted ...
The Redgate Monitor database is 45 GB now, I switched data purge from 6 months to 1 month about 4 hours ago but it's not changing the size (I even attampted a SHRINKFILE).
7 Machines/8 Instances
Trace is turned on in all instances.
Please let us know once a fix/workaround is in place. I'm going to have to shut down monitoring as it is affecting my other databases disk space availablility. / comments
The Redgate Monitor database is 45 GB now, I switched data purge from 6 months to 1 month about 4 hours ago but it's not changing the size (I even attampted a SHRINKFILE).
7 Machines/8 Instances
Tr...
Agreed...this is a huge pain and added steps for most. I used to be able to just send the html, now I have to zip up images too and it's a much bigger production. / comments
Agreed...this is a huge pain and added steps for most. I used to be able to just send the html, now I have to zip up images too and it's a much bigger production.