Cada empresa es un mundo, lo sabemos, los escenarios de uso raramente son iguales aunque se utilicen las mismas bases tecnológicas. En este caso una PYME con gran número de bases de datos en su servidor local con SQL Server notaba ciertos problemas de rendimiento en horarios determinados…
Monitorizando en detalle los recursos disponibles en torno a más de 200 base de datos en activo en un único servidor virtualizado, el acceso a disco se veía afectado… bastante afectado, tanto que repercutía en otras máquinas virtuales.
Se valoraron opciones de ampliación y separación de discos, RAID… discos NVMe, controladora, caché… pero antes de realizar cualquier inversión en hardware adicional, decidimos revisar la aplicación que utilizaban.
Aunque el número de bases de datos era mayor al habitual su uso no era intensivo… aquí empezamos con las pruebas y el refinamiento tanto de las tablas, índices, relaciones (hasta donde podíamos sin comprometer el funcionamiento/estructura previos) y la configuración propia del servidor SQL.
Por defecto, la opción de cierre automático («autoclose») esta habilitada, después de que el último usuario se desconecta, la base de datos se cierra.
No parece malo para ahorrar recursos, si no lo usas lo cierras… debemos tener en cuenta que cuando establece una conexión de nuevo, se inicia, se leen los archivos de la bases de datos, se asigna memoria… también puede suponer cierto retraso dependiendo del tamaño o complejidad.
Además al cerrar la base de datos se borran los planes de ejecución en caché y se generan varias entradas en el registro de transacciones, log de uso… todo ello conlleva una mayor actividad de los discos duros…
En este caso el coste de rendimiento es mucho mayor que los posibles ahorros de recursos en el servidor, con solo cambiar una opción predeterminada. ¿te ha pasado algo similar en producción? Contacta con nosotros y revisamos tu caso.
