1. we run Vssadmin list writers command and sqlserverwriter is missing and 

2. Also, there is no error message in Application event logs and

3. Also, SQLserver VSS writer service is running

Here are the steps you need to follow to resolve such issues.

1. First of all we need to check if there are any spaces in the databases names. please run the query :

select '#' + name +'#'  from sys.databases 

if you notice any space in database names e.g. #test  # , we need to make sure we remove the space from the database name. 

Please follow this article to rename the database name : - https://msdn.microsoft.com/en-us/library/ms345378.aspx

once you remove the space in the database name, then issue vssadmin list writers command and check if the SQLwriter is there or not

2. If still SQLwriter is not there then: 

please check the service logon which is mostly Nt authority/system or any user which you have mentioned as service logon, is added in SQL server as sysadmin privileges or not. If it's not there then please make it as syadmin. Run the VSSadmin list writers command. 

Please feel free to post a question if the issue still persists.

The scope of these issues is very wide but I would discuss about the approach which I follow to resolve these issues. I have resolved more than 50% of the cases by using this approach without even looking at profiler traces. I hope this will help you troubleshooting issues in your environment.

It’s specific to SQL server 2008 – 64 bit environments but could be tried on 32 bit environments too.

Let’s discuss about how to start it step by step.

Step 1: - When you see high CPU utilization on the server check in task manager, which process is consuming high CPU. If it’s SQL server then open perfmon and add the counter for Processor: % Privileged time, % Processor time and %user time

If you see the %privileged time to be high like hovering around 40% and above then it could be some driver issue. To troubleshoot these kinds of issues you could try:

Using Xperf: - https://blogs.msdn.com/b/ntdebugging/archive/2010/03/22/using-xperf-to-root-cause-cpu-consumption.aspx -- Video; https://msdn.microsoft.com/en-us/performance/cc709422

If it’s user time which is high then the below steps will be applicable for troubleshooting:

Step 2: - First and very important one is to know what’s the architecture i.e. 64 bit (X64 or IA 64) or 32 bit(x86):

Check the configuration using command: - Xp_msver

In this blog I will talk specifically about SQL server 2008 64-bit.

Step 3: - Check if there are any trace flags enabled:

dbcc tracestatus (-1); It’s always good to check the reason of enabling the trace flags, if enabled.

Step 4: - Check the below mentioned SQL parameters

sp_configure 'advanced',1

go

reconfigure with override

go

sp_configure

go

1. Priority Boost: - it’s not recommended to be enabled as it can cause high CPU utilization. If it’s enabled (value =1) please disable(set value to 0) it - it’s a static parameter which needs SQL restart
2. Max degree of parallelism: - Although this parameter doesn’t make much of a difference but sometimes I have seen SPID stuck in ACCESS_METHODS_SCAN_RANGE_GENERATOR, cxpacket or other parallel waittypes. If you see any such waits when you run this query :

Select a.session_id, a.wait_type, a.wait_time, a.* from sys.dm_exec_requests a, sys.dm_exec_sessions b

where a.session_id=b.session_id and b.is_user_process=1

If in your case waittypes to be any of related to parallelism and the waittime is more than 20 ms reduce the parallelism to e.g. if 8 then to 4 and so on unless the waits go away.

Note: - If you have more than 8 processors, please make sure the max degree of parallelism parameter is 8 or below 8.

1. Ensure that you have set max server memory by leaving minimum 3-4 GB for the OS

Step 4: - Run dbcc memorystatus and check for the USERSTORE_TOKENPERM memory clerk. If the value is high say above 400 MB then follow the article: - https://support.microsoft.com/kb/927396

Step 5: - If everything mentioned above is alright then next thing we have to check is compilations and recompilations :

1. Open perfmon and add the counters: -

MSSQL: SQL statistics à Batch requests/s, compilations/s and recompilations/s.

If you notice compilations/sec are greater than 20% then there is definitely fair amount of chances for Procedure cache pollution. To confirm that please run the query:

WITH cached_plans (cacheobjtype, objtype, usecounts, size_in_bytes, dbid, objectid, short_qry_text) AS(

SELECT p.cacheobjtype, p.objtype, p.usecounts, size_in_bytes, s.dbid, s.objectid,

CONVERT (nvarchar(100), REPLACE (REPLACE (

CASE

-- Special cases: handle NULL s.[text] and 'SET NOEXEC'

WHEN s.[text] IS NULL THEN NULL

WHEN CHARINDEX ('noexec', SUBSTRING (s.[text], 1, 200)) > 0 THEN SUBSTRING (s.[text], 1, 40)

-- CASE #1: sp_executesql (query text passed in as 1st parameter)

WHEN (CHARINDEX ('sp_executesql', SUBSTRING (s.[text], 1, 200)) > 0)

THEN SUBSTRING (s.[text], CHARINDEX ('exec', SUBSTRING (s.[text], 1, 200)), 60)

-- CASE #3: any other stored proc -- strip off any parameters

WHEN CHARINDEX ('exec ', SUBSTRING (s.[text], 1, 200)) > 0

THEN SUBSTRING (s.[text], CHARINDEX ('exec', SUBSTRING (s.[text], 1, 4000)),

CHARINDEX (' ', SUBSTRING (SUBSTRING (s.[text], 1, 200) + ' ', CHARINDEX ('exec', SUBSTRING (s.[text], 1, 500)), 200), 9) )

-- CASE #4: stored proc that starts with common prefix 'sp%' instead of 'exec'

WHEN SUBSTRING (s.[text], 1, 2) IN ('sp', 'xp', 'usp')

THEN SUBSTRING (s.[text], 1, CHARINDEX (' ', SUBSTRING (s.[text], 1, 200) + ' '))

-- CASE #5: ad hoc UPD/INS/DEL query (on average, updates/inserts/deletes usually

-- need a shorter substring to avoid hitting parameters)

WHEN SUBSTRING (s.[text], 1, 30) LIKE '%UPDATE %' OR SUBSTRING (s.[text], 1, 30) LIKE '%INSERT %'

OR SUBSTRING (s.[text], 1, 30) LIKE '%DELETE %'

THEN SUBSTRING (s.[text], 1, 30)

-- CASE #6: other ad hoc query

ELSE SUBSTRING (s.[text], 1, 45)

END

, CHAR (10), ' '), CHAR (13), ' ')) AS short_qry_text

FROM sys.dm_exec_cached_plans p

CROSS APPLY sys.dm_exec_sql_text (p.plan_handle) s

)

SELECT COUNT(*) AS plan_count, SUM (size_in_bytes) AS total_size_in_bytes,

cacheobjtype, objtype, usecounts, dbid, objectid, short_qry_text

FROM cached_plans

GROUP BY cacheobjtype, objtype, usecounts, dbid, objectid, short_qry_text

HAVING COUNT(*) > 100

ORDER BY COUNT(*) DESC

RAISERROR ('', 0, 1) WITH NOWAIT

In the output you will need check:

Plan_count : - number of times the similar plan was found in the procedure cache

use count : - How many times the plan was reused and in the output of this query you will see the use_count = 1 most of the times which will tell that the query was not being reused.

Total_size_in_bytes: - It’s the memory consumed by the execution plans of the similar kinds.

For the description of the counters please check: - https://msdn.microsoft.com/en-us/library/aa173933(v=sql.80).aspx

In many cases you will find this to be the problem.

If you see the procedure cache pollution then you need to check the memory clerk: CACHESTORE_SQLCP in “dbcc memorystatus” command output (run in query analyzer).

In 64 bit system I have seen this memory to grow up to 8GB or more which is sign of excessive compilation. After you confirm this, there can be two possibilities

1. Memory pressure which can cause cleanup of the execution plans and make SQL to compile the plan and in this case there will be no procedure cache pollution.
2. There are excessive Ad-hoc queries which are causing this compilation and you will see high pollution in the queries.

For point number 2, there are steps which could be followed:

1. Identify the text and database of the query which is being compiled in the output of the above mentioned query and set parameterization to forced
2. Parameterize the ad-hoc query :- https://msdn.microsoft.com/en-us/library/ee343986(v=sql.100).aspx

If you see high re-compilations then check the article : - https://msdn.microsoft.com/en-us/library/ee343986(v=sql.100).aspx .

Also, make sure statistics of the tables are updated with fullscan. To check the statistics updated date, run the query:

EXEC sp_msforeachtable 'select object_name(object_id) tablename,name as index_name,stats_date(object_id,index_id) as statistics_update_date from sys.indexes where Object_id=object_id("?")'

If after implementing the above action plans issue doesn’t resolve then:

Check for the hashing and sorting in SQL server:

Open perfmon and add the counters: - MSSQL: memory manager (Granted workspace area) or check the output of the query:

select * from sys.dm_os_memory_clerks where type='MEMORYCLERK_SQLQERESERVATIONS'

If the value is very high e.g. more than like 3-4 GB and I have seen this value to go till 10 GB in high memory machines. It’s a clear sign of big hash tables /huge sorting being done.

Then run the query (only for sql server 2008) : -

1. Run the query :

print '-- query and plan hash capture --'

print '-- query and plan hash capture --'

print '-- top 10 CPU by query_hash --'

select getdate() as runtime, *  --into tbl_QueryHashByCPU

from

(

SELECT TOP 10 query_hash, COUNT (distinct query_plan_hash) as 'distinctquery_plan_hash count',

sum(execution_count) as 'execution_count',

       sum(total_worker_time) as 'total_worker_time',

       SUM(total_elapsed_time) as 'total_elapsed_time',

       SUM (total_logical_reads) as 'total_logical_reads',

    max(REPLACE (REPLACE (SUBSTRING (st.[text], qs.statement_start_offset/2 + 1,

      CASE WHEN qs.statement_end_offset = -1 THEN LEN (CONVERT(nvarchar(max), st.[text]))

        ELSE qs.statement_end_offset/2 - qs.statement_start_offset/2 + 1

      END), CHAR(13), ' '), CHAR(10), ' '))  AS sample_statement_text

FROM sys.dm_exec_query_stats AS qs

CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st

group by query_hash

ORDER BY sum(total_worker_time) DESC

) t

go

Find out which one is on the TOP and then run the below query to find the missing indexes:

DECLARE @runtime datetime

DECLARE @cpu_time_start bigint, @cpu_time bigint, @elapsed_time_start bigint, @rowcount bigint

DECLARE @queryduration int, @qrydurationwarnthreshold int

DECLARE @querystarttime datetime

SET @runtime = GETDATE()

SET @qrydurationwarnthreshold = 5000

PRINT ''

PRINT '==============================================================================================='

PRINT 'Missing Indexes: '

PRINT 'The "improvement_measure" column is an indicator of the (estimated) improvement that might '

PRINT 'be seen if the index was created. This is a unitless number, and has meaning only relative '

PRINT 'the same number for other indexes. The measure is a combination of the avg_total_user_cost, '

PRINT 'avg_user_impact, user_seeks, and user_scans columns in sys.dm_db_missing_index_group_stats.'

PRINT ''

PRINT '-- Missing Indexes --'

SELECT CONVERT (varchar, @runtime, 126) AS runtime,

mig.index_group_handle, mid.index_handle,

CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans)) AS improvement_measure,

'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle)

+ ' ON ' + mid.statement

+ ' (' + ISNULL (mid.equality_columns,'')

+ CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')

+ ')'

+ ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,

migs.*, mid.database_id, mid.[object_id]

FROM sys.dm_db_missing_index_groups mig

INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle

INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle

WHERE CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans)) > 10

ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

PRINT ''

GO

For information on the DMV’s used in the query, please check https://msdn.microsoft.com/en-us/library/ms345421.aspx

You will definitely find some index recommendations for the TOP queries. Create the indexes and see if that makes the difference.

If creating the indexes doesn’t help then you will have to find the execution plan of the Top in the Top CPU query and try to tune it.

I was answering to the questions on Social.msdn.microsoft.com forum site, Someone posted the question :

 How to see the standby file path when we restore the database in standby mode:

 I checked lots of DMVs e.g. msdb..restorefile, msdb..restorehistory etc. but couldn't find any place to get the standby file name. I Spent around 1-2 hours to find out the path. The answer, really awesome, was provided by someone else on the forums. I decided to blog this so that in future if someone wants to know about it, it's easier to find the answer.

Just a little background for what happens when we restore the database in standby mode:

When we restore the database with recovery, it rolls back all the uncommitted transactions and bring the database online. And, when we restore the database with standby it leaves the database in read-only mode. Undo uncommitted transactions, but save the undo actions in a standby file so that recovery effects can be reverted.

 Here is how we can find the name of the .tuf,.Bak file which is created when we restore database in standby mode.

** Please create a folder temp in C drive.

** Below script create the database,stop and read the log file to find the tuf filepath.

/* create test database */

CREATE DATABASE [DELETEME] ON

                PRIMARY (NAME = N'DELETEME_data', FILENAME = N'C:\Temp\DELETEME_data.mdf')

                LOG ON (NAME = N'DELETEME_log', FILENAME = N'C:\Temp\DELETEME_log.ldf');

GO

BACKUP DATABASE [DELETEME] TO DISK = N'C:\Temp\deleteme.bak';

GO

BACKUP LOG [DELETEME] TO DISK = N'C:\Temp\deleteme.trn' WITH NORECOVERY;

GO

RESTORE DATABASE [DELETEME] FROM DISK = N'C:\Temp\deleteme.bak' WITH STANDBY = N'C:\Temp\DELETEME.TUF';

GO

/* run script to find undo file location

/* then run this cleanup */

DROP DATABASE [DELETEME];

EXEC xp_cmdshell 'DEL C:\Temp\deleteme.*', no_output

*/

/* ******************************** */

/* retrieve undo filepath from tlog */

/* ******************************** */

DECLARE @DATABASE SYSNAME;

SET @DATABASE = 'DELETEME';

declare @tlog varchar(260);

declare @undo varchar(520);

declare @cmd varchar(1000);

set @tlog =

(

                select

                                sys.sysaltfiles.filename

                from

                                sys.sysaltfiles

                left join

                                sys.sysdatabases

                                on sys.sysdatabases.dbid = sys.sysaltfiles.dbid

                                and sys.sysdatabases.filename = sys.sysaltfiles.filename

                where

                                sys.sysaltfiles.dbid = db_id(@DATABASE)

                and

                                sys.sysdatabases.filename is null

);

create table #file (id int identity(1,1) primary key clustered, line varchar(255) null, wrap varchar(510) null);

set @cmd = 'sqlcmd -S' + @@servername + ' -Q"alter database ' + @DATABASE + ' set offline with rollback immediate"';

exec xp_cmdshell @cmd, no_output;

set @cmd = 'type "' + @tlog + '"';

insert into #file (line)

exec xp_cmdshell @cmd;

set @cmd = 'sqlcmd -S' + @@servername + ' -Q"alter database ' + @DATABASE + ' set online with rollback immediate"';

exec xp_cmdshell @cmd, no_output;

update here

set wrap = here.line + isnull(there.line, '')

from #file as here

left join #file there on there.id = here.id + 1;

set @undo = (

                select distinct substring(wrap, patindex('%_[a-z]_:_\_%_._[a-z]_[a-z]_[a-z]_%', wrap), charindex('.', wrap, patindex('%_[a-z]_:_\_%_._[a-z]_[a-z]_[a-z]_%', wrap)) - patindex('%_[a-z]_:_\_%_._[a-z]_[a-z]_[a-z]_%', wrap) + 8)

                from #file

                where wrap like '%_[a-z]_:_\_%_._[a-z]_[a-z]_[a-z]_%'

);

drop table #file;

select @undo = replace(@undo, LEFT(@undo, 1), '');

select convert(varchar(260), @undo) as undo_filename

 You will get the output as the .tuf filename along with path.

Kind regards

Harsh Chawla

Recently I was working on a scenario in which we were not able to see any perfmon counters for newly added database. Evertytime we had to rebuild all the perfmon counters for sql server to get the perfmon counters of new database. It was just a workaround but we wanted to have a permanent resolution.

To find the cause of the problem, i checked the application logs and found the error:

The configuration information of the performance library ""C:\WINDOWS\system32\sqlctr90.dll"" for the ""MSSQLSERVER"" service does not match the trusted performance library information stored in the registry. The functions in this library will not be treated as trusted.

Then I checked the method which was being followed to rebuild the counters and found:

1. Change the path to the BINN directory of the SQL Server instance you desire to correct.   (Ex: C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\Binn)
   
2. Unload the counters:

For a default instance of SQL Server run this command:
unlodctr MSSQLSERVER

3.  Check the .ini files by running a command on command prompt: - dir *.ini

 4. Execute lodctr /R:sqlctr.ini  

**    LODCTR /R  rebuild the perf registry strings and info from scratch based on the current

5. Restart the remote registry and then open perfmon and check if the missing counters are back otherwise restart the machine.

 To resolve the error :

The configuration information of the performance library ""C:\WINDOWS\system32\sqlctr90.dll"" for the ""MSSQLSERVER"" service does not match the trusted performance library information stored in the registry. The functions in this library will not be treated as trusted.

I had to just change the switch to /T

1. Change the path to the BINN directory of the SQL Server instance you desire to correct

.   (Ex: C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\Binn)

2. Unload the counters:

For a default instance of SQL Server run this command:

unlodctr MSSQLSERVER

3.  Check the .ini files by running a command on command prompt: - dir *.ini

4. Execute lodctr /T:sqlctr.ini 

** LODCTR /T:<Service-Name>  set the performance counter service as trusted.

5. Restart the remote registry and then open perfmon and check if the missing counters are back otherwise restart the machine.

After the above action plan the issue was resolved permanently

A very good blog on related issues : - https://blogs.msdn.com/b/psssql/archive/2009/03/03/troubleshooting-sql-server-2005-2008-performance-counter-collection-problems.aspx

Kind regards

Harsh Chawla

We usually tend to see Activity monitor for a quick understanding of SQL health and resource consumption. Here is a scenario very close to Network IO in Activity monitor.

Below is the screen shot depicting Network IO operation in one of my SQL Server troubleshooting cases.

Here we observe that there are some waits happening on NetworkIO and this data is collected internally using sys.dm_os_wait_stats DMV’s view.

Let me take you further into this, how we can establish the correlation between SQL Activity monitor and DMV which we can use in our normal administration work with SQL Server Network IO troubleshooting.

Looking at the above Activity monitor, SQL Administrator have a general perception that network IO mean something to do only with Network Lines, however its more than that. Activity monitor represents Network I/O as waits on OLEDB, MSQL_DQ, DTC_STATE, DBMIRROR_SEND and ASYNC_NETWORK_IO.

In this scenario customer was running SQL Server profiler trace on the SQL server capturing data and we could observe Network I/O in activity monitor.

Checked sys.dm_os_waiting_tasks and found that there was a task waiting on oledb and Found that session was executing stored procedure to gather the profiler data (dbcc inputbuffer(<session_id>)):

(@P1 int) exec sp_trace_getdata @P1, 0

Checked sys.dm_os_wait_stats view and found some waits on oledb also checked sys.dm_exec_requests view and found that the session was waiting on oledb.

In the above scenario it was clear that the issue was oledb waits which are quite normal when we capture profiler traces.

We can reproduce the same scenario on our box using below steps.

1. Start a normal profiler trace.

2. Run the activity monitor and see the waits.

3. Query the view: sys.dm_os_waiting_tasks and check the Session id waiting on oledb.

4. Run dbcc inputbuffer(<session_id>), you will see the query text: -“exec  sp_trace_getdata”

5. Stop the trace and the waits will not be there

In the above scenario we had visibility of waits in the sys.dm_exec_requests view and sys.dm_os_wait_stats DMV as well as in activity monitor.

But what if, there are no waits observed in sys.dm_exec_requests DMV for any resource but in activity monitor and sys.dm_os_wait_stats view.

Here is another case study where we see waits in activity monitor and sys.dm_os_wait_stats but no wait in sys.dm_exec_requests.

Step 1: open activity monitor and check resource waits.

Step 2: Run a select statement which returns more than 1000 rows

    e.g.   select * from <Table Name>

Step 3: Now you will see the network waits in activity monitor.

Step 4: Query the sys.dm_exec_requests view and there will be no waits by that session.

Step 5: select * from sys.dm_os_wait_stats where wait_type='async_network_io'

Step 6: Run the query in step 2 and then repeat step 5

You will see the increase in async_network_io waits.

Hence we need to look at the DMV’s  before we draw any conclusion on the basis of activity monitor. It’s also a best approach to correlate the data with Perfmon counters to reach a conclusion.

Below is the memory error, we observed in SQL Server error log followed by DBCC MEMORYSTATUS output.

You will see below error messages in SQL Server error log:

2010-02-17 07:28:43.06 Server       Failed allocate pages: FAIL_PAGE_ALLOCATION 1

2010-02-17 07:28:43.06 spid14s     Error: 701, Severity: 17, State: 123.

2010-02-17 07:28:43.06 spid14s     There is insufficient system memory to run this query.

2010-02-17 07:28:43.06 spid12s     Error: 802, Severity: 17, State: 11.

2010-02-17 07:28:43.06 spid12s     There is insufficient memory available in the buffer pool.

In DBCC MEMORYSTATUS we find:

Memory Manager

VM Reserved = 1650436 KB

VM Committed = 1649556 KB

AWE Allocated = 0 KB

Reserved Memory = 1024 KB

Reserved Memory In Use = 0 KB

MEMORYCLERK_SQLBUFFERPOOL (Total)

VM Reserved = 1632340 KB

VM Committed = 1632340 KB

AWE Allocated = 0 KB

SM Reserved = 0 KB

SM Committed = 0 KB

SinglePage Allocator = 0 KB

MultiPage Allocator = 400 KB

OBJECTSTORE_SERVICE_BROKER  (Total)

VM Reserved = 0 KB

VM Committed = 0 KB

AWE Allocated = 0 KB

SM Reserved = 0 KB

SM Committed = 0 KB

SinglePage Allocator = 1523880 KB  -->Consuming most of the memory

MultiPage Allocator = 0 KB

The Single Page allocator value for OBJECTSTORE_SERVICE_BROKER object looks interesting and uncommon causing BPOOL exhaustion consuming almost 1.5 GB.

This hints problem towards service broker. Further to go indepth in troubleshooting service broker gathered the information from the view:

select state,COUNT(*) from sys.conversation_endpoints group by state

There were millions of conversations in the view:

count    

--------

20930578

“90% of the conversation was in conversing state”

Was checking the service broker configurations and observed that initiator and target was configured on the same database. The service broker was configured to temporarily save the application messages to improve application performance.

The queue was set in auto mode i.e. the procedure at the target would be called automatically to pick up the message from the target queue.  Checked the profiler traces and found that there was no call to the target procedure and that seemed to be the cause of the problem.

Further dived deeper into this issue and was successful in reproducing the issue using the steps below:

Repro steps

===========

Note: Intent of the below mentioned repro is just to show that when the stored procedure at the target gets invalidated then the messages get stuck in the queue causing OBJECTSTORE_SERVICE_BROKER object to keep growing.

ALTER DATABASE DBName SET ENABLE_BROKER

create message type req1 AUTHORIZATION dbo validation= None

create message type req2 AUTHORIZATION dbo validation= None

create queue senderqueue

create queue receiverqueue

create contract testcontract (req1 sent by initiator, req2 sent by target)

create service sendreqservice on queue senderqueue(testcontract)

create service receivereqservice on queue receiverqueue(testcontract)

select name,service_broker_GUID from sys.databases where is_broker_enabled=1

create route testroute with service_Name='sendreqservice', broker_instance='CB496106-EC67-41A9-8F01-3EDFE58FB01B', address='TCP://localhost:1433'

create table temp_table (message char(10))

create procedure sp_processqueue

as

begin

Declare @message char(20)

declare @message_type_name varchar(20)

declare @conversationhandle uniqueidentifier

begin

receive top(1)

@conversationhandle =conversation_handle,

@message_type_name=message_type_name,

@message=message_body

from dbo.receiverqueue

if @message_type_name='req1'

begin

insert into temp_table values(@message);

end

--end conversation @conversationhandle with cleanup;

end

end

Alter queue receiverqueue  with activation(status=ON,procedure_name = SP_processqueue,execute as owner)

Declare @message char(10);

declare @conversationhandle uniqueidentifier

set @message='hi'

begin dialog conversation @conversationhandle

from service sendreqservice

to service 'receivereqservice'

on contract testcontract

with encryption =off;

send on conversation @conversationhandle

message type req1

(@message);

--end conversation @conversationhandle

Now let’s invalidate the procedure to create the problem:

1. Change the procedure code somewhere and make it invalid:

alter procedure sp_processqueue

as

begin

Declare @message char(20)

declare @message_type_name varchar(20)

declare @conversationhandle uniqueidentifier

begin

receive top(1)

@conversationhandle =conversation_handle,

@message_type_name=message_type_name,

@message=message_body

from dbo.receiverqu --> changed the name to invalid table_name

if @message_type_name='req1'

begin

insert into temp_table values(@message);

end

--end conversation @conversationhandle with cleanup;

end

end

2. Now again run the code to queue a message.

Declare @message char(10);

declare @conversationhandle uniqueidentifier

set @message='hi'

begin dialog conversation @conversationhandle

from service sendreqservice

to service 'receivereqservice'

on contract testcontract

with encryption =off;

send on conversation @conversationhandle

message type req1

(@message);

--end conversation @conversationhandle

select * from temp_table 

select * from sys.conversation_endpoints

You will see that the status in the sys.conversation_endpoints is again "CONVERSING". Which is same as the successful execution but the difference is that the message is not processed, you can also check in the profiler trace that we called the stored procedure to process the message but it failed to execute as it was invalid.

1. Now correct the stored procedure:

alter procedure sp_processqueue

as

begin

Declare @message char(20)

declare @message_type_name varchar(20)

declare @conversationhandle uniqueidentifier

begin

receive top(1)

@conversationhandle =conversation_handle,

@message_type_name=message_type_name,

@message=message_body

from dbo.receiverqueue -->changed the name to valid table_name

if @message_type_name='req1'

begin

insert into temp_table values(@message);

end

--end conversation @conversationhandle with cleanup;

end

end

2. Again run the below code to enqueue the message:

Declare @message char(10);

declare @conversationhandle uniqueidentifier

set @message='hi'

begin dialog conversation @conversationhandle

from service sendreqservice

to service 'receivereqservice'

on contract testcontract

with encryption =off;

send on conversation @conversationhandle

message type req1

(@message);

If you see in the profiler trace, there will be no call to the stored procedure at target. Hence the message don’t get processed as its still considered as invalid until we run manually at least once.

To sort out the problem, run the stored procedure manually:

exec sp_processqueue

After this you will find the messages being processed, run the below query to confirm the same.

select * from temp_table 

Resolution

==========

1. You will need to run the target procedure manually.

It will deliver the messages to the target and release the space from the  OBJECTSTORE_SERVICE_BROKER  objectstore.

2. But to clear the messages from the service_endpoints view you will have to  change the procedure code to end the conversations (with cleanup).