Comments
Sort by recent activity
I presume you've tried something like ^[Ww]omaster ?
If you have and it's not working for you then I'll do some investigation to see if we have any issues in this area.
Thanks
Chris / comments
I presume you've tried something like ^[Ww]omaster ?
If you have and it's not working for you then I'll do some investigation to see if we have any issues in this area.
Thanks
Chris
Hi
We now list the relevant port numbers on the online documentation. http://www.red-gate.com/supportcenter/C ... %20Monitor
Hope this helps
Chris / comments
Hi
We now list the relevant port numbers on the online documentation.http://www.red-gate.com/supportcenter/C ... %20Monitor
Hope this helps
Chris
Hi Adam
We are currently investigating an issue where the base monitor machine will suddenly start using large amounts of memory. We believe it's being caused by a combination of trace being enabled for the monitored server and the number of alerts being generated. As each alert is generated we query the server for the relevant trace data for that point in time. We are currently looking to see if there is any inefficiency in the way we do this.
Some more details about your problem could be very useful to us
1. Whilst the memory issue was happening, how many alerts were you getting for the monitored server that had trace enabled?
2. Does the memory issue occur when trace is enabled but the most commonly occurring alerts have been disabled or had their thresholds reduced so as not to be triggered as often?
3. Was the monitored server under stress at the time and likely to be generating huge amounts of trace?
In the meantime I can only suggest that SQL Monitor's trace option is used purely as a diagnostic measure and not turned on permanently.
Many Thanks
Chris / comments
Hi Adam
We are currently investigating an issue where the base monitor machine will suddenly start using large amounts of memory. We believe it's being caused by a combination of trace being enable...
Hi Adam
Well that's good news that the base monitor memory usage has stabilised at a more acceptable level but we appreciate that it seems to be down to trace now being disabled.
Issues of this nature are notoriously difficult to diagnose but it's possible the SQL Monitor log files could contain information. On Server 2008 they would be located at "C:\ProgramData\Red Gate\Logs\SQL Monitor 2". Only log files generated whilst the memory usage was high would be likely to contain useful relevant information however.
If you experience this issue again then we'd be interested to know the number of handles RedGate.Response.Engine.Alerting.Base.Service is using. This can be viewed in Task Manager (the column isn't visible by default but can be added using View > Select Columns > check Handles). If time allows then the sysinternals tool "handle.exe" (very small download from http://technet.microsoft.com/en-us/sysi ... 96655.aspx) logs very useful information about performance. It's a command line tool that can be ran as follows:-
handle.exe -p RedGate.Response.Engine.Alerting.Base.Service > handleinfo.txt
handle.exe -p RedGate.Response.Engine.Alerting.Base.Service -a > detailedhandleinfo.txt
Again this would only be useful to us if the service is performing badly at the time.
Any files (log file or handle.exe output) can be zipped up and sent to me at chris.spencer@red-gate.com.
Many Thanks
Chris / comments
Hi Adam
Well that's good news that the base monitor memory usage has stabilised at a more acceptable level but we appreciate that it seems to be down to trace now being disabled.
Issues of this nat...
Great news that it's working for you.
Be assured that the IIS documentation is under constant review and we will respond to user feedback in order to make it more complete.
Many Thanks
Chris / comments
Great news that it's working for you.
Be assured that the IIS documentation is under constant review and we will respond to user feedback in order to make it more complete.
Many Thanks
Chris
Apologies if you've already tried this but I just need to make sure that you've done the wildcard mapping required to get MVC applications working on IIS6. The process is as follows:
SQL Monitor is an ASP.NET MVC application that uses URLs without extensions, so you will need to use wildcard mapping:
- Right-click the Monitor website you just created and click Properties.
- In the Properties dialog, go to the Home Directory page and click Configuration. (If you have set SQL Monitor to be a virtual directory beneath an existing website, then go to the Virtual Directory page).
- Under Wildcard application maps, click Insert.
- In the Add/Edit Application Extension Mapping dialog, type the path to the aspnet.isapi.dll file in the Executable box. This should be mapped to C:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll or, for 64 bit Windows, to C:\windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll.
- Ensure that Verify that file exists is not checked.
- Reload the SQL Monitor page to check that it displays correctly
(sourced from our online documention found at http://www.red-gate.com/supportcenter/C ... 126997.htm)
If you've already done this and still have the issue then we'd probably have to look through any log files (location mentioned in my previous post).
Thanks
Chris / comments
Apologies if you've already tried this but I just need to make sure that you've done the wildcard mapping required to get MVC applications working on IIS6. The process is as follows:
SQL Monitor is...
Apologies for the issues you're having. We've not seen any issues internally where the website fails due to a file being in use and you definitely shouldn't need .NET 4.0 in order to get it working. The installer checks for the presence of .NET 3.5 SP1 and that should be enough.
What browser are you using to view the website out of interest? If it's Internet Explorer then it could be an issue we've seen internally where the URL needs to be added as a trusted site. http://www.red-gate.com/supportcenter/C ... 269935.htm
If it's not that then would you be able to give us some more details of your IIS setup (especially the IIS version) and any screenshots of errors received could be valuable.
Also we write to log files that are by default (on Vista and later) located at C:\ProgramData\Red Gate\Logs\SQL Monitor 2. If you can zip up the contents of this directory and email to chris.spencer@red-gate.com, I could check these and see if anything unexpected is occurring.
Thanks
Chris / comments
Apologies for the issues you're having. We've not seen any issues internally where the website fails due to a file being in use and you definitely shouldn't need .NET 4.0 in order to get it working...
Suggestion noted. Support for cell phones and other mobile devices is something we're taking very seriously and any ideas posted on these forums will be considered for future versions.
Thanks again
Chris / comments
Suggestion noted. Support for cell phones and other mobile devices is something we're taking very seriously and any ideas posted on these forums will be considered for future versions.
Thanks again...
We're planning some improvements to the email format but adding the job name in the case of a Job Failed alert is technically more difficult than it really should be.
However, we do take note of all user feedback and will prioritise product enhancements accordingly.
Thanks for the feedback
Chris / comments
We're planning some improvements to the email format but adding the job name in the case of a Job Failed alert is technically more difficult than it really should be.
However, we do take note of al...
This is being fixed for the next point release of SQL Monitor (release date unknown at present). We will use the host name for any (local) instances.
Thanks for the feedback
Chris / comments
This is being fixed for the next point release of SQL Monitor (release date unknown at present). We will use the host name for any (local) instances.
Thanks for the feedback
Chris