Блог

Я читал на различных страницах MSDN и в блогах SQL Server, что «обычно» в базе данных Service Broker требуется главный ключ.

Действительно, при попытке ПОЛУЧИТЬ сообщения я получаю следующее сообщение журнала событий приложения:

Service Broker необходимо получить доступ к главному ключу в базе данных ‘MDR_REPLICATION_Z’. Код ошибки: 26. Главный ключ должен существовать, и требуется шифрование главного ключа службы.

Что меня смущает, так это то, почему это происходит, когда все мои разговоры имеют ENCRYPTION = OFF.

Есть ли способ использовать Service Broker внутри одной базы данных, где ШИФРОВАНИЕ ОТКЛЮЧЕНО, без необходимости создания главного ключа базы данных?

Из диалогового окна Service Broker Безопасность:

Безопасность диалога Service Broker позволяет вашему приложению использовать аутентификацию, авторизацию или шифрование для отдельного диалогового окна (или dialog). По умолчанию во всех диалоговых беседах используется безопасность диалога. Когда вы начинаете диалог, вы можете явно разрешить продолжение диалога без защиты диалога, включив предложение ENCRYPTION = OFF в инструкцию BEGIN DIALOG CONVERSATION. Однако, если для службы, на которую нацелен диалог, существует привязка к удаленной службе, в диалоговом окне используется защита, даже если ШИФРОВАНИЕ = ВЫКЛЮЧЕНО.

Другими словами, убедитесь, что у вас нет подходящих привязок к удаленной службе.

Альтернативой было бы создание главного ключа для service broker.

Сначала проверьте свою очередь service Broker, щелкнув правой кнопкой мыши очередь и просмотрев очередь передачи, или просто используйте этот запрос

 SELECT  *, casted_message_body = CASE message_type_name WHEN 'X' 
    THEN CAST(message_body AS NVARCHAR(MAX)) 
    ELSE message_body 
END 
FROM [DATABASE_NAME].[sys].[transmission_queue]
  

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

Если брокер не выполняет свою роль, я бы создал NEW_BROKER со следующим запросом

 USE [master] 
ALTER DATABASE [DATABASE_NAME] SET NEW_BROKER
  

Затем включите брокер с НАДЕЖНЫМ значением ON

 ALTER DATABASE DATABASE_NAME SET ENABLE_BROKER;
ALTER DATABASE DATABASE_NAME SET TRUSTWORTHY ON;
  

Наконец, удаление главного ключа и создание нового главного ключа и шифрование новым паролем:

 ALTER AUTHORIZATION ON DATABASE::DATABASE_NAME TO [SA];
DROP MASTER KEY
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '79HGKJ67ghjgk^amp;*^fgj'
GO
  

Пароль может представлять собой определенную пользователем смесь буквенно-цифровых символов.

Если выполнение любого из вышеперечисленных шагов занимает больше времени, я бы посоветовал вам остановить запрос, повторно открыть SQL Manager и повторить попытку. Он должен работать хорошо!!

Я нашел решение.

Даже несмотря на то, что целевая служба, указанная в моем диалоговом окне «НАЧАТЬ«, содержится в той же базе данных, мне нужно было четко указать на тот факт, что целевая служба находится в той же базе данных.

Это делается путем добавления необязательного CURRENT DATABASE при указании целевой службы:

 BEGIN DIALOG @dlg_handle 
FROM SERVICE CheckpointAndLogInitiatorService 
TO
SERVICE 'CheckpointAndLogTargetService', 'CURRENT DATABASE'
ON CONTRACT
CheckpointStart_CheckpointStartReply
WITH ENCRYPTION = OFF;