Comments
Sort by recent activity
Hi
Sorry for the late reply. I've looked into this and cannot see any reason our WMI calls should be failing in this way.
We do set the authentication level to Pkt_Privacy as suggested by this MS help page http://technet.microsoft.com/en-us/libr ... 27103.aspx
I've raised a bug (reference: SRP-3222) to investigate this issue in more depth. Hopefully it's an issue that we'll be able to fix for a future release.
Regards
Chris / comments
Hi
Sorry for the late reply. I've looked into this and cannot see any reason our WMI calls should be failing in this way.
We do set the authentication level to Pkt_Privacy as suggested by this MS h...
Hi
Are you using SQL Server Express Edition for the data repository by any chance? If you are then you will probably see errors like this quite often as some older versions are limited to 4GB per database.
I believe that the SQL Server 2008 R2 Express allows up to 10GB of storage but even this would only hold a day or two of data.
Regards
Chris / comments
Hi
Are you using SQL Server Express Edition for the data repository by any chance? If you are then you will probably see errors like this quite often as some older versions are limited to 4GB per d...
cehottle wrote:
I had the same issue several weeks ago and, although I received no explanation from support as to the why, restarting the SQL Monitor service resolved it and it hasn't occurred since.
If restarting the service resolves the issue then my best guess is that it must be being caused by something other than clockskew. If you see this issue again, it would help us if you could zip up and send the log files to chris.spencer@red-gate.com.
The log files can be found at C:\ProgramData\Red Gate\Logs\SQL Monitor 2 or C:\Documents and Settings\All Users\Application Data\Red Gate\Logs\SQL Monitor).
Regards
Chris / comments
cehottle wrote:
I had the same issue several weeks ago and, although I received no explanation from support as to the why, restarting the SQL Monitor service resolved it and it hasn't occurred s...
Hi Rakesh
Hopefully the modified regEx will work for you too.
I've raised an enhancement request (reference SRP-3406) to get a history of SQL Process fragments listed on the Long Running Query alert details page. This should make diagnosis far easier in future.
Many Thanks
Chris / comments
Hi Rakesh
Hopefully the modified regEx will work for you too.
I've raised an enhancement request (reference SRP-3406) to get a history of SQL Process fragments listed on the Long Running Query aler...
Also changing the regEx to BACKUP|CHECKDB|BlobEater seemed to do the trick and correctly filter out the alerts.
Regards
Chris / comments
Also changing the regEx to BACKUP|CHECKDB|BlobEater seemed to do the trick and correctly filter out the alerts.
Regards
Chris
patelrk wrote:
exec sp_reset_connection -- network protocol: LPC
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
USE [JustisDataStore]
DBCC CHECKDB(N'DATABASE_NAME') WITH NO_INFOMSGS
I still haven't been able to reproduce this internally. Is the above code in a stored procedure at all?
Regards
Chris / comments
patelrk wrote:
exec sp_reset_connection -- network protocol: LPC
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on...
Hi Rakesh
Sorry they are OR'd. I was just treating each one on an individual basis in my last reponse. The process name (i.e. Microsoft Office 2003) won't work but the T-SQL filtering (BACKUP|CHECKUP) should. Therefore overall it should be filtering out the sql fragment shown.
I'll continue my investigation anyway.
Regards
Chris / comments
Hi Rakesh
Sorry they are OR'd. I was just treating each one on an individual basis in my last reponse. The process name (i.e. Microsoft Office 2003) won't work but the T-SQL filtering (BACKUP|CHECK...
Hi Rakesh
Thank you for testing that. I'm glad to hear that the Backup filtering is working at least.
I'm still attempting to reproduce the issue with CHECKDB. I haven't been able to get an alert through where the sql fragment actually contains the CHECKDB command. I tend to see code internal to CHECKDB instead. But I'll keep working on it.
Regards
Chris / comments
Hi Rakesh
Thank you for testing that. I'm glad to hear that the Backup filtering is working at least.
I'm still attempting to reproduce the issue with CHECKDB. I haven't been able to get an alert t...
Hi
I don't think Microsoft Office 2003 would filter out this alert as the SQL Process name is .Net SqlClient Data Provider. Putting ".Net SqlClient Data Provider" in the SQL process name regEx box should filter out this alert without the need for any T-SQL Matching. However, it would filter out all other alerts with that process name which may not be ideal. I believe that ".Net SqlClient Data Provider" is the default process name if the Application Name setting is not explicitly specified in the connection string.
As far as I can see BACKUP|CHECKDB should be filtering out this alert. I'm currently attempting to reproduce this issue internally. Do alerts for sql containing BACKUP get correctly filtered out?
Regards
Chris / comments
Hi
I don't think Microsoft Office 2003 would filter out this alert as the SQL Process name is .Net SqlClient Data Provider. Putting ".Net SqlClient Data Provider" in the SQL process name regEx box ...