User profile for JoeGT

Thank you @TomW I can confirm I did the update to that version and the issue is now resolved [image] / comments

Thank you @TomW I can confirm I did the update to that version and the issue is now resolved

0 votes

Please note RedGate that I am still seeing this message despite the fact that I have upgraded to SQL Prompt 10. Running SSMS v18.5 and SQL Prompt v 10.1.0.13908 What is my next move here @Sarah B ? Cheers Joe / comments

Please note RedGate that I am still seeing this message despite the fact that I have upgraded to SQL Prompt 10. Running SSMS v18.5 and SQL Prompt v 10.1.0.13908What is my next move here @Sarah B ?...

0 votes

Hi Alex We were on 5.0.1 abd upgrading from that to 5.0.10 We are running SQL 2008 R2 on the clusters where this issues cropped up and the servers are running Windows Server 2008 R2. All configuration settings seem to have come across aside from this Port setting. A screenshot showing the exact location of the missing config value is below (I have to repopulate this manually for clustered SQL instance) [image] Let me know if I can help with any other details. Cheers Joe / comments

Hi Alex We were on 5.0.1 abd upgrading from that to 5.0.10 We are running SQL 2008 R2 on the clusters where this issues cropped up and the servers are running Windows Server 2008 R2. All configurat...

0 votes

I too am having this same issue with SQL 2008 R2 named instances (ie MSSQL$<instance_name> ) and the exact same error message. I can also confirm that I am able to successfully add the Access Method and Buffer Manager counters to a perfmon session running locally on the server Can you please forward on the same instructions by email to myself ? The mere fact that myself and the original poster are able to add the counter locally on the server suggests to me it is not likely that they are corrupted nor disabled and more that the issue is with SQL Monitor attempting to connect to perfmon using the named instance name Another check I did was to look for the existence of the counters (and values for them) from SQL : use master select * from sysperfinfo where object_name like '%Access Methods%' select * from sysperfinfo where object_name like '%Buffer Manager%' This showed that for all of these named instances the counters appeared to be running just fine. / comments

I too am having this same issue with SQL 2008 R2 named instances (ie MSSQL$<instance_name> ) and the exact same error message. I can also confirm that I am able to successfully add the Access Metho...

0 votes

Not to put a dampener on things here but I have a feeling that based on previous experience with this tool, the official RedGate answer is likely to be something along the lines of "we have a custom schema that is forever changing and therefore are not happy to give you information about running queries direct against the repository". I will watch this with interest to see if this is indeed still the case. I too have in the past wanted to be able to mine information such as this direct from the repository. I guess it makes sense - if you allow your users to bypass the UI then the UI becomes potentially less useful and therefore harder to upsell the new features. Sorry for the thread hijack and I hope you get the answer you are looking for. / comments

Not to put a dampener on things here but I have a feeling that based on previous experience with this tool, the official RedGate answer is likely to be something along the lines of "we have a custo...

0 votes

I finally got what I was looking for here off the back off the ticket that was raised in the RedGate system when no-one had replied to this thread. So happy but unhappy all at the same time. The workaround assisted, it was just pretty late in arriving / comments

I finally got what I was looking for here off the back off the ticket that was raised in the RedGate system when no-one had replied to this thread. So happy but unhappy all at the same time. The wo...

0 votes

And now further updates that I believe might be relevant to other users of SQL Monitor. It is possible that the DEADLOCK_ENUM_MUTEX spid referred to above is now causing our SQL instances not to be able to identify real deadlock situations - we have some SPIDs that are in what ought to be a deadlock situation that are not causing a deadlock ie. SPID 170 is blocking SPID 179 SPID 179 is blocking SPID 170 and the pages being waited on are not changing. This to me is a classic deadlock situation and one of these two processes ought to be getting chosen as a victim. I am in a situation where I am likely going to be forced to perform a rollback of the SQL Monitor upgrade as this is the path of least pain : * Rollback SQL MOnitor to v 3.xxx * Roll forward SQL to SQL 2008 R2 SP2 CU5 I would love to hear from RedGate about this one as I believe that there are quite possibly a number of their customers who are keen to get the new Wait Stats functionality available in v4 but who are also not at SQL 2008 R2 SP5 and therefore could be vulnerable to this issue. This is the risk that we take being bleeding edge ie. installing a product update a matter of days after is is released (v4.1 of SQL Monitor was only released on June 13th and we installed on June 16th) Look forward to a reply ASAP. In the meantime I am going to be contacting our RedGate account manager to discuss. / comments

And now further updates that I believe might be relevant to other users of SQL Monitor. It is possible that the DEADLOCK_ENUM_MUTEX spid referred to above is now causing our SQL instances not to be...

0 votes

Thanks Chris. This is what I was hoping you would be able to offer and yes I am very interested in being able to disable this specific query (happy to lose the functionality in the meantime). We are going down the path of the CU for SQL but it will take some time and in the interim this is a good compromise. Look forward to getting the details from you. Cheers Joe / comments

Thanks Chris. This is what I was hoping you would be able to offer and yes I am very interested in being able to disable this specific query (happy to lose the functionality in the meantime). We ar...

0 votes

A little disappointed here I have to say. Having : * Emailed (and had a response from) our RedGate account manager * Posted a reply in this thread * Private messaged Chris Kelly on this forum * Updated the support ticket that was logged from this post I am yet to have seen the promised workaround to this issue and, sure enough, the issue has caused us further production problems. If there is anyone with access to this workaround reading this message, please forward it on to me ASAP. Cheers Joe / comments

A little disappointed here I have to say. Having : * Emailed (and had a response from) our RedGate account manager * Posted a reply in this thread * Private messaged Chris Kelly on this forum * Upd...

0 votes

As another follow up to this I can confirm that having restarted all of the affected SQL instances (thus removing the DEADLOCK_ENUM_MUTEX SPID), I no longer has SQL Monitor causing blocking events. Since that point however I can see that SQL Monitor itself as now been the cause of another of these DEADLOCK_ENUM_MUTEX SPIDS Capturing the query that is running at the time it is this : <?query -- INSERT INTO [##redgate_sqlmonitor_querywaitstats_xxxxxxx] SELECT database_name , sql_handle , statement_start_offset , statement_end_offset , wait_type , wait_time_delta FROM ( SELECT DB_NAME(er.database_id) [database_name], er.sql_handle, er.statement_start_offset, er.statement_end_offset, ISNULL(wt.wait_type, CASE WHEN er.[status] = 'runnable' then er.last_wait_type ELSE NULL END) [wait_type] , @delta wait_time_delta FROM sys.dm_exec_requests er LEFT JOIN sys.dm_os_waiting_tasks wt ON er.session_id = wt.session_id ) s WHERE s.wait_type IS NOT NULL AND s.sql_handle IS NOT NULL AND s.[wait_type] NOT IN (N'BROKER_EVENTHANDLER',N'BROKER_INIT',N'BROKER_MASTERSTART',N'BROKER_RECEIVE_WAITFOR',N'BROKER_REGISTERALLENDPOINTS', N'BROKER_SERVICE',N'BROKER_SHUTDOWN',N'BROKER_TASK_STOP',N'BROKER_TO_FLUSH',N'BROKER_TRANSMITTER',N'CHECKPOINT_QUEUE',N'CHKPT', N'CLR_AUTO_EVENT',N'CLR_MANUAL_EVENT',N'CLR_SEMAPHORE',N'DIRTY_PAGE_POLL',N'DISPATCHER_QUEUE_SEMAPHORE',N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',N'KSOURCE_WAKEUP',N'LAZYWRITER_SLEEP',N'LOGMGR_QUEUE',N'MISCELLANEOUS', N'OGMGR_QUEUE',N'PARALLEL_BACKUP_QUEUE',N'REQUEST_DISPENSER_PAUSE',N'REQUEST_FOR_DEADLOCK_SEARCH',N'RESOURCE_QUEUE', N'SLEEP_BPOOL_FLUSH',N'SLEEP_DBSTARTUP',N'SLEEP_DCOMSTARTUP',N'SLEEP_MSDBSTARTUP',N'SLEEP_SYSTEMTASK',N'SLEEP_TASK', N'SLEEP_TEMPDBSTARTUP',N'SP_SERVER_DIAGNOSTICS_SLEEP',N'SQLTRACE_BUFFER_FLUSH',N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', N'TRACEWRITE',N'WAITFOR',N'XE_DISPATCHER_JOI',N'XE_DISPATCHER_WAIT',N'XE_TIMER_EVENT') --?> And the result is the the SPID running this query is now showing with a wait (and wait time) of : (184635ms)DEADLOCK_ENUM_MUTEX And is blocking another SQL Monitor Process : <?query -- TRUNCATE TABLE [##redgate_sqlmonitor_querywaitstats_xxxxx] --?> With wait (and wait time) : (1609ms)LCK_M_SCH_M So.. I have kind of answered my own question - I probably need to update to SQL 2008 R2 SP5 to solve the underlying SQL issue. However, as I am not in a position to be able to do this anytime soon, is there any interim solution that RedGate(or someone else enterprising) might be able to offer ? Note: We specifically updated to this version of SQL Monitor to allow us access to the Wait information so not having this feature of the tool functioning correctly is limiting its continued usefulness. Cheers Joe / comments

As another follow up to this I can confirm that having restarted all of the affected SQL instances (thus removing the DEADLOCK_ENUM_MUTEX SPID), I no longer has SQL Monitor causing blocking events...

0 votes

How can we help you today?

JoeGT

Comments