A menudo veo "problemas" que involucran requisitos para que SQL Server realice "trabajo sucio" como:
- En mi disparador, necesito copiar un archivo hacia/desde la red
- Mi procedimiento almacenado necesita enviar un archivo por FTP
- Después de que finalice la copia de seguridad, necesito SQL Server para comprimirlo, hacer una copia y luego archivarlo
- Cuando se agrega un cliente, quiero crear una nueva base de datos y hacer un montón de cosas en Active Directory
- Mi trabajo del Agente SQL Server necesita escanear un directorio en busca de archivos y realizar inserciones masivas cuando encuentra nuevos
Esta no es una lista exhaustiva; Probablemente podría llenar una página. El punto es que realizar estas tareas desde dentro de SQL Server presenta obstáculos significativos:
Seguridad
Por lo general, para cualquier cosa en la que considere que SQL Server necesita un sistema de archivos u otro acceso a nivel de sistema operativo, (a) otorgará derechos de carta blanca explícitos a la cuenta de servicio de SQL Server (y/o las cuentas del Agente SQL/proxy), o (b) simplemente configure las cuentas de servicio de SQL Server para que se ejecuten como una cuenta de dominio existente que ya tiene todos esos derechos. Esta es la solución "fácil":ahora, en lugar de otorgar acceso individualmente a esta carpeta y a ese recurso compartido y a este otro recurso, simplemente se limpia las manos porque ya son administradores de dominio. A continuación, habilita la configuración a nivel del servidor que está deshabilitada de forma predeterminada pero que se interpone en su camino para realizar una o más de las tareas anteriores (por ejemplo, xp_cmdshell ).
No creo que tenga que explicar el nivel de exposición que estas acciones pueden representar. O qué tipo de problemas pueden ocurrir si se trata de una cuenta de empleado real y ese empleado se va, o determina que está descontento antes de que se vaya. ¡Ay! He visto varios casos en los que se usa una cuenta común para todos los servidores SQL. ¿Adivina qué sucede si necesita cambiar la contraseña de una cuenta de dominio que está siendo utilizada activamente por docenas o cientos de instancias de SQL Server? No importa con qué frecuencia sucederá si no excluye a ese usuario de las políticas de restablecimiento de contraseña.
Rendimiento
Además de los problemas de seguridad, salir del servidor de la base de datos puede generar demoras, mientras que SQL Server depende de algún proceso externo sobre el que no tiene control. ¿La transacción de la base de datos realmente necesita esperar a que se comprima y copie un archivo, a que se complete una transferencia FTP o a que responda el controlador de dominio de respaldo? ¿Cómo se agrava esto cuando varios usuarios realizan tareas similares, todos compitiendo por el mismo ancho de banda y/o cabezas de disco? También debe considerar que una vez que SQL Server le ha dicho a algún archivo por lotes que haga algo, la transacción que lo contiene se revierte, no puede revertir la acción externa.
La respuesta
Bueno, por lo general, y siempre hay excepciones, la respuesta es usar procesos externos para estas tareas que realmente son externas a SQL Server. Use PowerShell, use C#, use archivos por lotes; Diablos, usa VBScript. Piense en cuáles de estas tareas realmente deben manejarse *inmediatamente* y mientras la transacción aún esté activa, sospecho que no muchas. Cree una tabla de cola para estos y escriba en la tabla de cola dentro de la transacción (que se revertirá si la transacción no se realiza correctamente). Luego, tenga una tarea o secuencia de comandos en segundo plano que consuma filas de la tabla de colas, realice las tareas asociadas y elimine o marque cada fila como completada. Bonificación adicional:aquí no se requiere el Agente SQL Server, por lo que puede usar cualquier programador empresarial y la metodología aún funciona con SQL Server Express.
