Очередь останавливается (отключается) без каких-либо ядовитых сообщений - PullRequest
Новая
       15

Очередь останавливается (отключается) без каких-либо ядовитых сообщений

1 голос
/ 26 января 2011

У меня есть очередь, которая останавливается без видимой причины, в этой очереди я реализовал обработку сообщений posion . А во время обработки записывает и отбрасывает любые ядовитые сообщения.

Он работал нормально более года без остановки. Но недавно (проблема началась четыре недели назад), она останавливается один или два раза в неделю. И только на этой неделе он остановился дважды.

А когда я проверяю таблицу с новыми отравленными сообщениями, ее нет !! И когда я включаю очередь, обработка возобновляется успешно, а ситуация с «ядовитым сообщением» не воспроизводится.

О задании очереди: Получает около 2-3000 сообщений в день. Он используется для запуска хранимых процедур вне транзакции. Каждое сообщение может обрабатываться немного (делать много операций выбора, вставки, обновления).

Позвольте мне объяснить этот момент: в базе данных есть триггеры, которые запускаются внутри транзакции, триггер отправляет сообщение для запуска некоторого кода вне триггера. Асинхронное поведение предотвращает снижение производительности базы данных.

Я обнаружил, что даже при возникновении взаимоблокировки при обработке сообщений очередь обрабатывает сообщение как отравленное. Так что в принципе это не должно быть проблемой производительности. Но может ли это быть? Может быть, база данных растет и длится слишком долго, чтобы обрабатывать сообщения?

Но как я могу это выяснить, если он не обнаружен как положенный?
Почему по другой причине очередь останавливается?
Как сохранить, когда и с каким сообщением очередь отключена?
Кто-нибудь знает, как я могу провести какой-либо судебный анализ?
Есть идеи?

<ч /> ОБНОВЛЕНИЕ ОБСЛУЖИВАНИЯ ПСЕВДО-РЕШЕНИЯ:
Согласно сообщению Ремуса, я пытался использовать уведомление о событии, чтобы получить точный момент, когда очередь останавливается. 

CREATE EVENT NOTIFICATION [QueueDisabledEN]
  ON QUEUE [dbo].[ProcessQueue]
  FOR BROKER_QUEUE_DISABLED
  TO SERVICE 'Queue Watch Service', 'current database';

И затем проверка журнала событий: 

select * from sys.event_notificiation

Но так как трудно узнать среду, в которой произошло событие (что еще происходило на моменте?), Криминалистический анализ на этом заканчивается. К счастью, моя реализация службы брокера хранит сообщения с датой отгрузки, датой получения, датой обработки ... Это помогло мне обнаружить, что в течение 3 секунд очередь заполняется сотнями сообщений, обработка которых занимает слишком много времени. .

Хотя я нахожу реальное решение, единственное временное решение - проверять с помощью задания агента каждые x минут состояние очереди и включать его: 

IF (EXISTS(SELECT * FROM sys.service_queues WHERE name like 'ProcessQueue' AND (is_receive_enabled = 0 OR is_enqueue_enabled = 0))) BEGIN
    PRINT convert(nvarchar, getdate(), 121)+ ': Activando la cola ProcessQueue'
    ALTER QUEUE ProcessQueue WITH STATUS = ON 
END

Спасибо, Ремус!

1 Ответ

4 голосов
/ 26 января 2011

Когда вы находите очередь в отключенном состоянии и включаете ее обратно, я предполагаю, что обработка возобновляется успешно и ситуация с «ядовитым сообщением» не воспроизводится. Это указывает на то, что причина является временной или временной. Это может быть задание агента SQL, которое выполняется и вызывает взаимные блокировки при обработке очереди, что приводит к откату обработки очереди. По моему опыту, тупики являются наиболее типичной причиной сообщения об отравлении. Ваш лучший инструмент для анализа - это журнал системных событий, так как активированная процедура выводит ошибки в ERRORLOG и, следовательно, в системный журнал событий.

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

Как примечание: у вас никогда не будет настоящей «обработки ядовитых сообщений». Всякий раз, когда вы улучшаете обработку для обработки некоторых случаев ошибок, определение «ядовитого сообщения» меняется на сообщение, способное отключить новую обработку ошибок .

...