habilitar - ¿Alguien usa Service Broker en SQL Server?
sql service broker tutorial (5)
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 mencionaste en tu 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.
Cuando asistí a una presentación de SQL Server 2008 en Microsoft, hicieron un rápido análisis 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.
Entonces, ¿ha considerado usar Service Broker? ¿Si no, porque no? ¿Fuiste a MSMQ? ¿Hay algo en SQL Server 2008 que lo haga considerar usar Service Broker?
He estado usando SQL Service Broker desde hace un par de meses después de que se lanzó 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 desde tablas de etapas hasta tablas de producción para que el servicio que carga la tabla de etapas no tenga que esperar a que los datos realmente se procesen, puede retroceder 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, el archivo también debe eliminarse).
En compañías anteriores lo he usado para imprimir documentos de préstamos y cheques que fueron enviados 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 a los DBA) no les gusta Service Broker porque no tienen UI. Si desea utilizar Service Broker o ver qué está haciendo, tiene que escribir y ejecutar algo de T / SQL.
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. Los blogs de Remus Rusanu realmente han sido útiles para hacer cosas como la reutilización del 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.
Monitorear SB puede ser un dolor. Básicamente dependes de un conjunto de vistas del sistema para decirte lo que está sucediendo. Los mensajes huérfanos son un dolor. Hay muchos 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 usaría de nuevo y continuaré usándolo.
Recientemente consideré usar Service Broker para un proyecto, pero sí, decidí optar por MSMQ.
Nuestra arquitectura consistía en varios servidores (agrupados), cada uno de los cuales necesitaba escribir información en una sola instancia de SQL de manera confiable.
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 sincero, no puedo pensar en un escenario en el que usaría SB. Me interesa saber un poco más acerca de su escenario, para ver si me estoy perdiendo algo vital.
Service Broker se puede usar en varios casos donde se requiere automatización en la arquitectura distribuida. Tales aplicaciones reciben eventos de varios dispositivos y necesitan que el procesamiento se realice de forma 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 sea más segura y confiable con SB