SQL Server Para Administradores de Bases de Datos


SQL Server Para Administradores de Bases de Datos Accidentales

Recuerdo una noche de otoño del 1993, cuando abrí el manual de SQL Server 4.21A, y me dispuse a instalar SQL Ser por primera vez en mi vida. Hasta ese momento, yo me consideraba un buen programador en varios dialectos de Basic (la ignorancia es muy atrevida), sobre todo Visual Basic, y manejaba decentemente algún sistema de bases de datos como dBase III (y IV), y hasta las primeras versiones de Access. Pero esto de SQL Server era un animal muy distinto. Su proceso de instalación (sobre todo el análisis de requisitos) me recordó la primera vez que instalé Novell en un proyecto en Indonesia.

Para ser sincero, nunca había estudiado nada sobre bases de datos relacionales, y lo poco que sabía de tablas y consultas lo había aprendido con sistemas que en poco se parecían a SQL Server. La primera sensación tras instalar SQL Server fue de una desorientación total. Devices… Segments…

¿y yo para qué necesitaba meterme en esos berenjenales? La verdad es que no tenía más remedio que “subirme” a un gestor de bases de datos “serio” porque, intentando utilizar Access como motor de bases de datos de un gran proyecto, aprendí cuales son esos dos ingredientes que hacen que la estabilidad de un sistema de base de datos peligre: datos y usuarios. Access funcionaba muy bien en mi equipo de desarrollo, pero al llevarlo a producción, añadir la ingente cantidad de datos que el proyecto del gasoducto requería, y los muchos usuarios con sus ingeniosas e inesperadas formas de consultar dichos datos, topé con los límites de esta herramienta, y muy probablemente con mis límites como programador para resolverlos adecuadamente.

Muchos años han pasado desde entonces, y con esos años, muchas versiones de SQL también.

Pero una constante permanece en el mercado: muchos profesionales de diferentes áreas se enfrentan por primera vez a un motor de bases de datos relacional, como SQL Server, sin que nadie se haya preocupado antes de formarles para enfrentarse adecuadamente a este reto, convirtiéndose en DBAs (Administradores de Bases de Datos) accidentales sin quererlo o, al menos, sin tener muy claro qué obligaciones comporta este rol.

El proceso de instalación ha mejorado mucho. Es muy intuitivo, y facilita el trabajo en la gran mayoría de los casos. Sin embargo, una vez instalado, muchos DBAs accidentales siguen experimentando esta desorientación que inundó mis primeras horas con SQL Server

Un motor de bases de datos es una máquina que funciona muy bien cuando está bien engrasada, cuando se observan los niveles periódicamente, se cambian los filtros cuando toca, y se le aplican las rutinas de mantenimiento prescritas por el fabricante y por las buenas prácticas de la industria. Exactamente como cualquier motor. Si además tenemos en cuenta que este motor atesora toda la información de nuestra empresa, y que cuando el motor se para toda nuestra empresa se para, más nos vale aplicar un mantenimiento adecuado. Y no hablamos de un mantenimiento correctivo, sino de un mantenimiento preventivo, que se anticipe a los posibles problemas, y se asegure su máxima disponibilidad, por el bien de nuestro negocio.

Nos seguimos encontrando con bases de datos en producción que carecen de estrategias de prevención de desastres. Ni tan siquiera una copia de seguridad de vez en cuando. Y si disponen de copias de seguridad, éstas no sean comprobado nunca. Recuerdo repetir en los cursos que impartía sobre administración de SQL Server que “una copia de seguridad que no se ha restaurado nunca no es una copia de seguridad, sino un fichero relleno de contenido potencialmente inservible”.

No es culpa del DBA accidental. Es culpa de quien no da suficiente importancia a los posibles desastres que pudieran ocurrir, bien por fallo material o por error humano, que podrían dar al traste con la valiosa información almacenada en la base datos.


Es como conducir un coche sin seguro, pensando que nunca se va a tener un accidente. Toda base de datos, en funcionamiento, sufrirá un desastre tarde o temprano.

El modo en que sepamos prepararnos para prevenir este desastre, dentro de lo posible, y para resolverlo cuando se produzca, será una buena medida de nuestra efectividad como DBAs.

Y no hablemos de las técnicas para mejorar el rendimiento de las bases de datos. Esta es una actividad que siempre me apasionó, y a la que dediqué no pocas horas, días y noches, sábados y domingos, vacaciones y fiestas de guardar. Y es que las técnicas de mejora de rendimiento rozan en algunos casos la categoría de arte, más que de técnica. Al menos eso me parece a mí, cuando veo a algunos de mis compañeros mejorar el rendimiento de algunas consultas hasta límites increíbles.

Sin embargo, todo arte tiene parte de técnica, y esta técnica puede aprenderse. Eladio y su equipo han conseguido crear una metodología que sistematiza el modo en que se puede analizar y mejorar el rendimiento de un servidor SQL Server, y parte de esta metodología se puede aprender en este libro. Sin embargo, siempre me asombran con destellos de grandeza tecnológica, al conseguir optimizar lo que ya parecía inmejorable.

Soy de los que piensan que todo empieza con un buen diseño o, mejor aún, con una adecuada arquitectura para la solución a implementar. Pero al menos, todos deberíamos aprender a distribuir nuestros datos de un modo lógico, mediante un adecuado diseño, y de crear las estructuras adecuadas para facilitar su consulta eficiente.

Enlaces De Descarga
SQL Server Para Administradores de Bases de Datos
10 Puntos Score: 10
Visitas: 290 Favoritos: 0
Ver los usuarios que votaron...

0 Comentarios

Para dejar un comentario Registrate! o.. eres ya usuario? Accede!