SQL Server Para Administradores De Bases De Datos Accidentales

Prólogo
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 primerasversiones 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 estabilidadde
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 comoprogramador para
resolverlos adecuadamente.
Muchos años han pasado desde entonces, y con esos años, muchas versiones de SQL
Server 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
horascon SQL Server.

SQL Server para DBAs Accidentales
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 encuenta 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 encontrandocon 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 ficherorelleno 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...