¿Alguien está utilizando Service Broker en SQL Server?

Question

Cuando asistí a una presentación de SQL Server 2008 en Microsoft, hicieron un análisis rápido para ver qué características estábamos usando. Resultó que en toda la sala de conferencias, mi compañía era la única que usaba Service Broker. Esto me sorprendió mucho, ya que pensé que más gente lo estaría usando.

Mi experiencia con SB es que funciona bien, pero es bastante difícil de administrar y es difícil obtener una visión general.

¿Ha considerado utilizar Service Broker? ¿Si no, porque no? ¿Fuiste a MSMQ? ¿Hay algo en SQL Server 2008 que lo haga considerar usar Service Broker?

Answer 1

Recientemente consideré usar Service Broker para un proyecto, pero sí, decidí optar por MSMQ.

Nuestra arquitectura constaba de varios servidores (agrupados), cada uno de los cuales necesitaba escribir información en una sola instancia de SQL de forma fiable.

Según tengo entendido, SB solo funciona para la comunicación de SQL a SQL, por lo que habría necesitado una instancia de SQL en cada cuadro agrupado. Sentimos que esto era un poco innecesario, por lo tanto, usando MSMQ

Para ser honesto, no puedo pensar en un escenario en el que usaría SB - Me interesa saber un poco más sobre su escenario, para ver si me estoy perdiendo algo vital.

Answer 2

He estado utilizando SB en 2005 durante aproximadamente dos años con una implementación que maneja varios cientos de miles de mensajes al día. Yo diría que el mayor desafío no ha sido tanto en la arquitectura sino en la comprensión de todos los matices involucrados. La documentación de Microsoft es pobre con muy pocos ejemplos prácticos. Remus Rusanu's blogs han sido realmente útiles para hacer cosas como la reutilización de diálogo y la activación del ajuste de procedimientos almacenados. He descubierto que es REALMENTE importante reutilizar los cuadros de diálogo tanto como sea posible (y trabajar a través de todos los bloqueos asociados con eso), así como manejar múltiples mensajes recibidos como un conjunto en lugar de uno a la vez.

El monitoreo SB puede ser un problema. Básicamente dependes de un conjunto de vistas del sistema para decirte lo que está sucediendo. Los mensajes huérfanos son un dolor. Hay un montón de pequeños problemas que pueden, bueno, obtener.

Aparte de los problemas, y no hay muchos, creo que realmente funcionó mejor de lo que esperaba. Como SB está integrado en la base de datos, no hay colas de mensajes separadas para realizar copias de seguridad fuera de la base de datos. Todo es transaccionalmente consistente. El rendimiento es bueno. Es una gran solución.

Lo volvería a usar y continuaré usándolo.

Answer 3

He estado usando SQL Service Broker desde hace un par de meses después de que se lanzara SQL 2005. Lo usamos sin parar aquí enviando cientos de miles de mensajes a través de él por día.

Lo usamos para cargar datos de tablas intermedias a tablas de producción para que el servicio que carga la tabla provisional no tenga que esperar a que los datos realmente se procesen, puede volver atrás y obtener más datos para cargar.

Lo usamos para poner en cola la eliminación de archivos del sistema de archivos. (Cuando se elimina la fila, también se debe eliminar el archivo).

En compañías anteriores, lo he utilizado para imprimir documentos de préstamos y cheques que se enviaron a los clientes.

Incluso utilicé Service Broker para hacer ETL desde una base de datos OLTP a una base de datos OLAP para informes en tiempo real.

A la mayoría de las personas (especialmente los DBA) no les gusta Service Broker porque no hay ninguna interfaz de usuario para ello. Si desea utilizar Service Broker o ver qué está haciendo, tiene que escribir y ejecutar algo de T/SQL.

Answer 4

En mi empresa actual, nuestro uso de SB es algo diferente al de los otros carteles. Usamos SB en SQL2005 principalmente como una herramienta de gestión. Por ejemplo, lo usamos para administrar actualizaciones en un pequeño conjunto de tablas mutables que están presentes en una gran cantidad de bases de datos inmutables. Todos los mensajes son entre servicios que se ejecutan en la misma instancia y el volumen de mensajes es muy bajo.

Mi experiencia con SB ha sido que puede ser un poco 'complicado' configurar correctamente y, como mencionó en su pregunta, es difícil obtener una visión general del estado de SB porque no hay una sola herramienta de monitoreo .

Sin embargo, hemos encontrado que es muy valioso como una forma de automatizar muchas tareas de administración de bases de datos de una manera confiable y trazable.

Answer 5

Service Broker se puede utilizar en varios casos donde se requiere automatización en la arquitectura distribuida. Tales aplicaciones reciben eventos de varios dispositivos y necesitan un procesamiento confiable. Donde eventos de dispositivos (detección) o sensores se utilizan para procesar la lógica de la automatización. Para hacer intercambio de datos entre múltiples bases de datos o aplicaciones.

espero que la implementación puede ser más asegurado y fiable con el SB