Comments
Sort by recent activity
chriskelly wrote:
You could query the view alert.Alert_Current and filter out the LRQ alerts, where the AlertType = 12. This would get you some of the way there. But this would only work for alert that have not been purged yet. My suspicion is that you will find that the data for your older database has been purged.
Chris,
The data is still there and I was able to do some rough comparisons with the following changes to your suggestion:
SELECT --TOP 1000 *
Count(AlertId),
Left(TargetObject,30)
FROM alert.Alert_Current
where 1 = 1
AND AlertType = 12
AND WorstSeverity = 3
AND TargetObject LIKE'%MyOldDBserver%'
GROUP BY Left(TargetObject,30)
SELECT --TOP 1000 *
Count(AlertId),
Left(TargetObject,30)
FROM alert.Alert_Current
where 1 = 1
AND AlertType = 12
AND WorstSeverity = 3
AND TargetObject LIKE'%MyNewServer%'
GROUP BY Left(TargetObject,30)
I now just need to refine this by Date which will require using a UDF to convert the date values as stored in the DB into something human readable and I can compare the number of HIGH level LRQ alerts between the 2 systems.
Thanks / comments
chriskelly wrote:
You could query the view alert.Alert_Current and filter out the LRQ alerts, where the AlertType = 12. This would get you some of the way there. But this would only work for a...
Thanks for the offer Brian.
What I’d like is a simple aggregation of LRQ's (LONMG RUNNING QUERY's) over 2 time periods (comparing the 2 if possible) to show a drop or an increase in the number of LRQ's between the 2 periods.
In our environment we use an enterprise level accounting software application that has a higher than normal occurrence of LRQ alerts (normal being how many LRQ alerts it would take for most DBA's using SQL Monitor to say "Man that’s a lot of LRQ's") . I'd like to compare the number of LRTQ alerts this past month to the same month last year when we were operating under our old DB server. I can’t do that because there’s no LRQ alert on the Analysis tab.
That said this may all be a moot point as it appears that you can’t access information stored in your Red gate DB for any SQL Server instances you are no longer actively monitoring. When we switched to our new DB server it came with a new name and so we had to switch in SQL Monitor the SQL Server instance we were monitoring. Now that we’ve switched over I can no longer retrieve data on anything captured from the old server e3ven though the info is in my DB (I have never purged the DB).
If you have any suggestion son how I can get some basic counts on LRQ's that would be great but keep in mind it would need to work for a SQL monitor we no longer monitor.
Thanks / comments
Thanks for the offer Brian.
What I’d like is a simple aggregation of LRQ's (LONMG RUNNING QUERY's) over 2 time periods (comparing the 2 if possible) to show a drop or an increase in the number o...
petey wrote:
You will need to use SQL Backup if you want to restore directly from those files.
The alternative is to first convert those files to native SQL Server backup files using the SQBConverterGUI or SQBConverter applications (found in the SQL Backup installation folder), then use SQL Server to restore using those converted files.
Thanks Petey. BTW - I did try and find this info first but could not. Is this restriction mentioned naywhere in the SQL Back documentation? What about any mention of the 2 applications you mentioned, SQBConverterGUI & SQBConverter ? / comments
petey wrote:
You will need to use SQL Backup if you want to restore directly from those files.
The alternative is to first convert those files to native SQL Server backup files using the SQBConv...
eddie davis wrote:
Thank you for your reply and sorry for the delay in replying.
You wrote:
Being that Red-gate develops tools for Sharepoint I would think you'd (or someone in a SP team at Red-gate) have some insight into this.
I am not aware of any tools that Red Gate develops specific for Sharepoint servers. There are a couple of ANTS profiling tools that can profile .NET applications for Sharepoint. There is also a use case with SQL Virtual Restore Sharepoint Object Level recovery with Metalogix Selective Restore Manager.
Are there any other SQL Monitor users monitoring SQL Servers / Sharepoint servers experiencing this problem?
Many Thanks
Eddie
Eddie,
I believe we've tracked down the problem and its a monitoring feature that SharePoint is using/running. I'm not that involved with the Sharepoint administartion so I can't give any more details other then to say the Sharepoint admin is running some kind of monitoring that comes with Sharepoint and they identified it as the cause based on the time this alert atsrts up every day on SQL Monitor. I have another LRQ related issue like this that is not Sharepoint related but will post it in a seperate posting. / comments
eddie davis wrote:
Thank you for your reply and sorry for the delay in replying.
You wrote:
Being that Red-gate develops tools for Sharepoint I would think you'd (or someone in a SP team at Re...
eddie davis wrote:
Hi
Thank you for your forum post.
sp_trace_Getdata is used by SQL Profiler. Do you have the trace feature of SQL Monitor enabled (which is running SQL Profiler to obtain the trace data)?
Or are you or a colleague been running SQL Profiler outside of SQL Monitor to collect information and forgotton to turn off the SQL Profiler?
Many Thanks
Eddie
No we are not using profiler and the 3 instances of this LRQ alert being captured dialy are not the default background trace that SQL Server runs; in other words the id from sys.TRACES is not 1.
I suspected this was asscoaited with tracing. Are no other SQL Monitor users reporting that their SQL monitor is seeing an LRQ alert for this same thing? I'm %99 certain its Sharepoitn specific menaing you have to be monitoringa SQL Server instance that hosts SharePoint DB's. Being that Red-gate develops tools for Sharepoint I would think you'd (or someone in a SP team at Red-gate) have some insight into this.
Thanks / comments
eddie davis wrote:
Hi
Thank you for your forum post.
sp_trace_Getdata is used by SQL Profiler. Do you have the trace feature of SQL Monitor enabled (which is running SQL Profiler to obtain the ...
Brady1408 wrote:
I believe I have found the issue, we are looking at the wrong node, the active node has the correct labels and it is the inactive node that does not.
Thanks,
What do you mean by "inactive node"? I too am now seeing harddiskvolumneXX (where XX changes daily) on Disk Space alerts for our new server and I'd like to know why. Is this some quirk of VMWare? / comments
Brady1408 wrote:
I believe I have found the issue, we are looking at the wrong node, the active node has the correct labels and it is the inactive node that does not.
Thanks,
What do you mean ...
Chris,
FYI - So far the downgrade is working. I have yet to have any probelms or errors and most importanty, I got back my missing SQL Fragment info for LRQ alerts.
I was worried that the info had been permanently lost and not just missing but its still there. I just wish I knew how to get that info directly from the DB.
Thanks / comments
Chris,
FYI - So far the downgrade is working. I have yet to have any probelms or errors and most importanty, I got back my missing SQL Fragment info for LRQ alerts.
I was worried that the info had...
What if we downgrade back to the prior version of 3.0.X we were using, can we get back the misssing SQL Fragment info?
I hope this bug has been given a high level of priorty because the LRQ (long Running Query) alert is just about useless without this key piece of information.
I'm suprised that this is not being fixed till the next release of SQL Monitor. Then again maybe no other user besides myself makes use of the LRQ alert and so this is not a major setback/bug for anyone else.
Thanks / comments
What if we downgrade back to the prior version of 3.0.X we were using, can we get back the misssing SQL Fragment info?
I hope this bug has been given a high level of priorty because the LRQ (long R...
Brian Donahue wrote:
Data files saved to "c:\program files" and "c:\program files (x86)" are automatically redirected to c:\programdata by Windows Vista, 2008, and Windows 7.
Brian,
So then you are confirming my intial posts statement and confirming that the file is where I indicated and that Chris's reply was to state why the file is there instead of the location listed in the RedGate KB article and thats because Windows redirects the files to the progradata directory, correct?
Thanks / comments
Brian Donahue wrote:
Data files saved to "c:\program files" and "c:\program files (x86)" are automatically redirected to c:\programdata by Windows Vista, 2008, and Windows 7.
Brian,
So then yo...
chrisk5 wrote:
Thanks for your post.
While the configuration file "RedGate.Response.Engine.Alerting.Base.Service.exe.config" does contain the location of the configuration file "RedGate.Response.Engine.Alerting.Base.Service.exe.settings.config", it is actually located in the directory C:\Program Files\Red Gate\SQL Monitor 3\BaseMonitor\ which is not the same location at all.
The directory C:\ProgramData\Red Gate\SQL Monitor 3\ is hidden by default on many machines, is slightly different for SQL Monitor 2 (as detailed in the document) and for pre-Win Server 2003 machines it is in the equivalent directory for that older directory structure.
However this is only not true when the user has made changes to the default install locations.
If there are any problems with making this configuration change then users should contact support@red-gate.com
Chris,
Since I did not make any changes from the default during the install of SQL Monitor does this mean I imagined fined the file ine the location I specified ? Just trying to get clarification on the conflicting statements, the differ3ence between where I found these files and where you say they actually were.
Thanks / comments
chrisk5 wrote:
Thanks for your post.
While the configuration file "RedGate.Response.Engine.Alerting.Base.Service.exe.config" does contain the location of the configuration file "RedGate.Response...