Хранимая процедура завершается со сбоем при вызове из Service Broker, но запускается из SSMS

Мы используем Service Broker в SQL Server 2008R2 в качестве простого планировщика заданий. Мы отправляем сообщение брокеру, и он устанавливает его для обработки в запрошенную дату/время.

У нас есть задание (хранимая процедура), которое автоматически назначается действиями пользователя на сайте Sharepoint, и оно отлично работает уже около года. Эта хранимая процедура создает 2 таблицы, если они не существуют, усекает их, если они существуют, а затем вызывает 2 другие хранимые процедуры (последовательно) для заполнения каждой из таблиц.

Несколько недель назад вторая из двух хранимых процедур начала давать сбой, когда основной процесс «задание» был инициирован SB. Если я захожу в SSMS, я могу выполнить хранимую процедуру «задание», и она выполняется до завершения без проблем (т.е. обе вызываемые хранимые процедуры выполняются без проблем, и обе таблицы заполняются).

Наша компания в своей бесконечной мудрости решила уволить парня, который настроил Service Broker и написал эти хранимые процедуры. Я разбираюсь в хранимых процедурах и начинаю немного разбираться в SB, но я не понимаю, почему вторая хранимая процедура будет выполняться из SSMS, но терпит неудачу при вызове из Service Broker.

Единственное, о чем я могу думать, это то, что Служба была создана с помощью этой команды:

CREATE SERVICE [//ScheduledJobService]
AUTHORIZATION [user ID]
ON QUEUE [dbo].[ScheduledJobQueue] ([//ScheduledJobContract])

и что что-то случилось с его удостоверением личности в тот день, когда оно перестало работать. Однако это не объясняет, почему часть кода будет выполняться и как продолжают выполняться другие задачи в компоненте Service Broker.

Я не знаю, где искать и как это отследить, поэтому буду очень признателен за любые советы по устранению неполадок.


person FreeMan    schedule 29.07.2014    source источник


Ответы (1)


Сервис-брокер, как фоновый процесс, должен запускать что-то от имени определенных пользователей. В моих установках брокера я обычно создавал для этого специального пользователя (то есть Broker_User) с правами на все, что ему нужно выполнить, и ничего больше.

Если авторизующая учетная запись для этой службы или для процедуры активации очереди брокера будет отозвана, ничего не получится.

Чтобы действительно проследить это, нам нужно знать:

  • Детали очереди (оператор создания и т.д.)
  • Детали процедуры активации, упомянутые выше
  • Информация о задействованных счетах

Также возможно, что внутри одного из SP есть код, который использует EXECUTE AS, что вызовет проблему, если учетная запись будет удалена или отозвана.

person JNK    schedule 29.07.2014
comment
CREATE QUEUE [dbo].[ScheduledJobQueue] WITH STATUS = ON , RETENTION = OFF , ACTIVATION ( STATUS = ON , PROCEDURE_NAME = [dbo].[SCHED_RunJob] , MAX_QUEUE_READERS = 20 , EXECUTE AS N'<manager account>' ), POISON_MESSAGE_HANDLING (STATUS = ON) ON [PRIMARY] Менеджер ‹управляющего аккаунта› также больше не работает в компании. Я полностью понимаю, что существует риск отключения/удаления учетных записей, однако Брокер продолжает работать. Более подробная информация в дальнейших комментариях (пожалуйста, дайте мне знать, если это не правильный способ и что это такое). - person FreeMan; 29.07.2014
comment
CREATE CONTRACT [//ScheduledJobContract] AUTHORIZATION [<manager account>] ([http://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer] SENT BY INITIATOR) Это тот же аккаунт администратора, которого больше нет у нас, который использовался для создания очереди. - person FreeMan; 29.07.2014
comment
Является ли эта учетная запись входом в SQL? Возможно, учетная запись все еще существует, но больше не имеет прав. - person JNK; 29.07.2014
comment
У нас есть другие задачи, которые мы используем в Брокере, и все они работают нормально. Я просмотрел все различные хранимые процедуры, которые вызываются основной процедурой (в части, которая дает сбой), и нет операторов Execute as - person FreeMan; 29.07.2014
comment
Да, это логин SQL, привязанный к его сетевому логину. Я полностью согласен с вами, что потеря прав на любой из аккаунтов ‹менеджер› или ‹программист› приведет к сбою. Что меня смущает, так это то, как некоторые из этой SP работают, а другие не работают, и как другие SP выполняются без проблем. - person FreeMan; 29.07.2014
comment
Если он привязан к его сетевому логину, то это не логин SQL, а учетная запись домена Windows. Я спрашивал об этом, потому что возможно, что логин все еще работает, но не имеет прав. Я действительно не могу помочь без более подробной информации о том, что работает / не работает и т. Д. - person JNK; 29.07.2014