¡Hola estimados lectores! Llevo un tiempo pensando en escribir este post sobre SQL Server; aunque, en realidad, no tiene porqué tratar de SQL Server, se puede extrapolar a cualquier otra aplicación y/o entorno.


Hoy os voy a hablar de algo muy importante y muy básico a la vez: mantener un entorno SQL Server y la importancia para los usuarios y los técnicos (para evitar problemas).

 

Un entorno tan crítico, como es el de las bases de datos, dónde reside información muy importante para uso interno, por ejemplo, el control de stock de una fábrica, y para uso externo de la empresa, por ejemplo, la venta online, es algo que tenemos que cuidar y mantener lo mejor posible.

 

Primero, ante todo, hay que destacar que a veces los problemas que nos encontramos vienen «heredados» desde el principio. Una mala instalación del tipo «siguiente, siguiente, acepto, fin» es mucho más peligrosa de lo que a veces somos conscientes; pero no hay que ser alarmistas, con un mantenimiento del entorno y de las BBDD podemos paliar muchos de los errores y quejas de los usuarios, provocados por un funcionamiento deficiente del entorno.

 

Me gustaría separar los errores que me encuentro en dos categorías, los errores «visibles» y los que son peores, aunque a veces no los veamos. ?

 

En la primera categoría, podemos encontrarnos que tenemos un entorno el cual nos puede proporcionar multitud de problemas: desde un error total y perdida de información (problemas con los backups), pasando por la lentitud de las aplicaciones (este es un error que me encuentro a menudo y al que mayor solución se le puede dar), errores en el funcionamiento de las aplicaciones, por ejemplo, una aplicación como SharePoint, que da problemas de timeout, puede venir provocado por una mala configuración de las bases de datos.

 

Estos son los problemas de los que, normalmente, nos pueden ir informando/quejándose los usuarios de nuestra empresa, lo cual resulta útil, pero no grato. Hay toda una serie de buenas prácticas como puede ser: separar ficheros de datos y de logs, modificar configuraciones de los ficheros, crear planes de mantenimiento, etc.

 

Ahora, si pasamos a los problemas no tan visibles a simple vista, pero, al final, más catastróficos; me encuentro muchos entornos sin estar actualizados. Sabemos que Microsoft tiene una política de soporte y, como en todos sus productos, tiene marcada unas fechas de caducidad de soporte.

 

Me gustaría hacer un recordatorio del año pasado en el que informamos que SQL 2005 dejaba de tener soporte. ➤ Noticia

 

¿Esto que quiere decir? Os pongo un ejemplo: Tenemos una aplicación de terceros montada en un entorno RTM (sin ninguna actualización), tenemos un problema grave y necesitamos soporte externo y lo solicitamos. Primera pregunta: ¿Qué versión de SQL Server se dispone? Si está fuera de soporte la contestación seguramente sea: Primero actualice. Con lo cual, estamos alargando el problema ya que, para dar una solución, primero tenemos que actualizar. No es lo mismo, realizar una actualización programada dentro de una ventana consensuada en la cual realizar el mantenimiento (en el cual hemos revisado el entorno, los prerrequisitos, procedimiento de movimiento del rol en un clúster, etc.) que actualizar con el entorno caído. Es posible que, después de la actualización, el error o errores que teníamos queden resueltos; un CU o un SP resuelve errores tanto de performance, como de seguridad, estabilidad, etc.

 

Dando un paso más allá que el de actualizar; migrar de versión, siempre que sea posible, nos puede aportar novedades y mejoras muy interesantes (como comentaré en futuros posts que haré de SQL Server 2017).

 

¡Mirad como ha mejorado la velocidad en realizar los backups!


SQL-Server-la-importancia-de-un-buen-mantenimiento

 

Por otro lado, dentro del tipo de errores comunes no visibles encontramos: La gestión de los permisos. Muchas veces, por desconocimiento, me encuentro con barra libre de permisos; cualquier usuario es propietario de la base de datos con el consiguiente problema, un usuario sin saberlo puede borrar información o sobre escribirla, pues le hemos dado los permisos para ello. Esto nos puede provocar errores inesperados y, para solucionarlos, casi seguro que tendremos que utilizar backup. Backup que, si no tenemos con una buena política de backups, puede no estar disponible o que sea de hace una semana perdiendo horas de trabajo.

 

En definitiva, un entorno SQL Server es robusto, mucho, pero también necesita una revisión tanto del entorno como de las bases de datos (índices, fragmentación, etc.).

 

Espero que os haya gustado el post.

Y recordad, disponemos de bolsas de horas y de un servicio de mantenimiento. ?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Post Relacionados: