The situation is closely related to SQL Service Broker - communication scenario - migration from SQL 2008 R2 to SQL 2014 and to SQL Service Broker -- one central SQL and more satelite SQL... beginner wants to understand details.
After migration from SQL Server 2008 R2 Standard Ed. to SQL Server 2014 Standard Ed., the same code does not work. The firewall was set to allow the communication.
The sys.transmission_queue
(on both sender and receiver servers) keeps empty, and the GenericQueue
(my identifier for the queue) receives the messages. However, the procedure attached by (to the receiving SQL server):
ALTER QUEUE [GenericQueue]
WITH ACTIVATION (
STATUS = ON,
MAX_QUEUE_READERS = 1,
PROCEDURE_NAME = [usp_CentralActivation],
EXECUTE AS OWNER);
is not activated. I have put the log message inside to have the tangible proof -- the procedure is not called.
I do not observe any error message or indication -- or I do not know where to look for the indication. How can I find what is the problem? What information should I post here to help to find the reason?
The code that installs the service broker is generated from templates, and besides the machine identification (IP address as a string) the exact same code worked nicely on SQL Server 2008 R2.
Could the EXECUTE AS OWNER
be the reason? Who is the OWNER
?
A shot in the dark. Try running this:
EXECUTE AS USER = 'dbo';
If this fails, then the database owner SID is invalid locally (happens frequently after a restore or file copy). The solution is trivial:
ALTER AUTHORIZATION ON DATABASE::<dbname> TO [sa];
If you still have problems then have a look at Understanding Queue Monitors. Look in sys.dm_broker_queue_monitors
and see that 1) the queue is present and 2) the status is RECEIVES_OCCURING
来源:https://stackoverflow.com/questions/31825844/sql-server-2014-service-broker-does-not-activate-the-procedure-that-receives-mes