El proveedor desea ejecutar el trabajo de MSDB cada 5 minutos para la aplicación comercial

Tenemos un proveedor externo que intenta integrar 2 aplicaciones diferentes donde ambas bases de datos residen en nuestra instancia de SQL Server con más de 150 bases de datos y desean crear un trabajo de MSDB para "sincronizar" las 2 aplicaciones diferentes cada 5 minutos (al principio quería ejecutarlo cada minuto).

Mi presentimiento inicial es que deberían hacer esto de alguna manera en el nivel de Aplicación con un trabajo programado de Windows, o tal vez incluso un temido desencadenante (que generalmente recurrimos en situaciones como esta).

Prefiero mantener los trabajos de MSDB reservados para las tareas de DBA tanto como sea posible para reducir el desorden allí, y también me he encontrado con consultas lentas de MSDB al ver historiales de trabajos con trabajos súper activos como este (que también ahogan y eliminan los historiales de trabajo importantes de cosas más importantes como historiales de respaldo). Pero, de nuevo, tal vez mis preferencias son incorrectas y necesito hacer un poco de espacio para el nivel de aplicación en MSDB y arremangarme y arreglar los problemas de los historiales de trabajo que tardan una eternidad en cargarse cuando necesito retener muchas más entradas del historial para capturar el cosas importantes como copias de seguridad (o purgar las entradas de trabajo hiperactivas).

Otro problema que tengo es que ahora tengo que otorgarle a este vendedor derechos de "administrador de sistemas" en lugar de solo derechos de "dbo" solo en sus bases de datos cuando realizan sus actualizaciones a través de su GUI y espero que no exploten la instancia donde mi misión es crítica Los DB son (uno de los inconvenientes de la consolidación).

Supongo que puedo ponerlos en otra instancia "aislada" donde ponemos a todos los proveedores que no juegan bien, pero luego necesitamos reconfigurar las aplicaciones para que apunten a la nueva instancia de SQL ( desafortunadamente, el suspiro no es trivial en este caso).

El vendedor ya rechazó mis inquietudes al hablar sobre cuán malos son los desencadenantes. Entonces, "busqué en Google" un poco esto y salí vacío. ¿Alguien ha visto algún enlace "con autoridad" que indique que es una mala idea y que puedo referirlo? ¿O debería abrazar su enfoque?

No creo que haya publicado nunca en un foro SQL antes de pedir ayuda, así que espero que mi consulta esté correctamente enmarcada.

EDITAR: Estamos ejecutando SQL Server 2008 Enterprise R2 x64 SP1 (¡Gracias por señalar que olvidé mencionar la versión!). Hmmm, espero que no necesiten cambiar sus scripts de actualización de MSDB cuando vamos a una versión más nueva.

¡Gracias por tu tiempo! Rico

OMI, su proveedor está realmente en el camino correcto.

Un trabajo de capa de aplicación requeriría que rehaga muchas características de Agente SQL listas para usar (por ejemplo, lógica para no ejecutar un trabajo que ya se está ejecutando, proponer una solución de almacenamiento de credenciales y seguridad, integrar los resultados del trabajo con informe de errores y seguimiento de resultados en SQL, etc., etc., etc.). Y, lo más importante, proporcione una solución de respaldo / HA / DC para la programación. No desea que su historia de recuperación de desastres sea "y después de que termine de recuperar el servidor en espera, cree estas 50 tareas del planificador NT". Entonces tiene razón al rechazar el uso del planificador del sistema, no tiene nada de las características y capacidades que tiene el Agente.

Está aún más en lo correcto al rechazar los disparadores. Reemplazar un trabajo periódico con un desencadenador síncrono aumenta la latencia de la solicitud, aumenta la cohesión y el acoplamiento (piense en los cambios de esquema ...), aumenta el riesgo de tiempo de inactividad debido a problemas de sincronización (error de activación-> error de la aplicación frente a error del trabajo-> corregir y volver a intentar más tarde) , aumenta drásticamente los problemas de punto muerto (debido a actualizaciones cruzadas entre rastreados / trackee) y tiene muchos más problemas.

La solución más fácil es, de hecho, un trabajo de Agente, y msdbde ninguna manera está reservado para los DBA. Una solución más sofisticada sería usar temporizadores de conversación y activación interna , lo que tendría algunas ventajas sobre los trabajos del Agente, principalmente debido a la contención (todo está dentro de la base de datos de la aplicación, piense en reflejar escenarios de conmutación por error), pero puedo entender totalmente si su proveedor es reacio a probar algo que requiere un conocimiento muy específico. Por cierto, espero que no se refiera a un trabajo cada 5 minutos por DB .

En cuanto a los permisos de administrador de sistemas: el nombre del juego es la firma de código . Puede otorgar cualquier permiso para procedimientos específicos, inspeccionados y validados por usted, firmando con su certificado privado.

Mi preferencia personal sería usar disparadores para manejar al menos una parte de la sincronización. No me interesa particularmente la sincronización de sondeo programada, ya que tiene que lidiar con posibles conflictos, datos obsoletos, impacto en el rendimiento del trabajo repetido, etc. Si quieren hacerlo de forma tan agresiva como 1 a 5 minutos, supongo es para mitigar conflictos y estancamiento, y la inmediatez de un desencadenante abordaría eso.

Si todo sucede dentro del mismo servidor, probablemente esté bien poner el código de sincronización dentro de los disparadores, o hacer que los disparadores llamen a un procedimiento almacenado que sincroniza cada registro afectado. Si la sincronización abarca servidores, o si desea asegurarse de que tener una base de datos fuera de línea no evitará que la otra base de datos sea utilizable, considere usar Service Broker para manejar actualizaciones asincrónicas. He hecho esto para sincronizar las cifras de entrada de ventas con datos CRM entre dos servidores diferentes, al tiempo que permite que cualquiera de los servidores se desconecte sin afectar a la otra aplicación. Una vez que vuelve a funcionar, Service Broker entrega los mensajes y actualiza los datos en el servidor remoto.

Y realmente no hay nada inherentemente malo en los desencadenantes, pero como la mayoría de los aspectos de T-SQL, es muy posible escribir código que tenga un rendimiento horrible. Escribí un artículo sobre las trampas comunes de los desencadenantes, si eso ayuda.

Escribir desencadenantes bien comportados