Por el motivo que sea, un día puede que cambiamos de trabajo o de funciones dentro de nuestra empresa y de repente heredemos un entorno de base de datos Microsoft SQL Server con un servidor o clúster de bases de datos para que nos encarguemos de él. Antes de empezar a cambiar cosas, es totalmente necesario conocer el uso que se hace de la base de datos, la criticidad de las aplicaciones que la usan, las dependencias entre ellas etc... A continuación una lista de las primeras cuatro tareas que podríamos llevar a cabo para empezar a hacerlo nuestro.
Antes de empezar a hacer nada, lo obligatorio será conocer el tipo de entorno al que nos intentamos conectar. ¿Es el entorno de producción o el de desarrollo? Si es desarrollo podemos mirar sin temor, si sabemos que es producción cuidado no rompamos nada.
- El primer paso será disponer de un usuario con permisos de administración para cada instancia de la base de datos. Si no tenemos ninguno y no hay nadie que tenga acceso a nivel de base de datos, podemos recuperar la contraseña del usuario "sa" de SQL Server como comento en este otro post. Una vez tengamos el usuario Administrador ya podemos empezar a trastear con lo habitual y que es primordial en los primero días. Nos conectamos a la base de datos con Microsoft SQL Server Management Studio.
- El segundo paso puede ser listar las bases de datos: No tiene mucha más complicación que conectarnos a la base de datos con Management Studio y observar el listado de objetos dentro de Bases de datos. Si entramos en detalle nos puede interesar su tamaño, que podemos ver uno a uno en sus propiedades. otra manera es sacar un listado con la siguiente consulta que nos devuelve la ruta de los ficheros, el tamaño actual en Mb, el tipo y el nombre de la base de datos.
SELECT database_id, type_desc, name, physical_name, size*8/1024 AS mb_size FROM sys.master_files
- En el tercero lo que haría sería comprobar la política de copias de seguridad para cada una de las bases de datos. Primero debemos conocer el tipo de recovery model usado y el seguimiento (simple, full, bulk-logged). Como en el punto anterior, podemos ir mirando las propiedades de la base de datos una a una o sacarnos un listado a modo resumen con una consulta:
SELECT name, recovery_model_desc, state_desc FROM sys.databases
A continuación también debemos averiguar si se están haciendo copias y como. De forma rápida se me ocurren distintos lugares donde podemos comprobar si hay alguna:
1. Planes de mantenimiento: Los podemos consultar en el Explorador de Objetos, en Administración > Planes de mantenimiento
2. Tarea del agente: Es posible que haya algún script que se ejecuta periódicamente como Tarea del Agente de SQL Server. Cuidado porque los planes de mantenimiento (punto anterior) se traducen finalmente en tareas del agente.
3. Tareas del sistema operativo: Parecido al punto anterior, un script que se ejecuta desde una Tarea Programada en el Programador de Tareas. Es otra manera y es posible que esté así...
Con la información obtenida en los puntos anteriores ya tenemos un punto de partida con el que empezamos a conocer que tenemos entre manos: tenemos una lista con las bases de datos, sabemos si se hacen copias y ahora nos toca ver que aplicaciones utilizan cada una de las bases de datos.
- El cuarto paso sería obtener usuarios activos y saber que bases de datos se usan de forma automática durante un periodo de tiempo. Una manera de hacerlo sería crear un trigger de auditoria en la apertura de conexiones al servidor. Existe un trigger de server que se dispara una vez conectado (ver logon trigger) que se podría usar para hacer algo parecido a esto que hice con MySQL, Otra manera de hacerlo menos critica y más sencilla si no estamos seguro sería consultando de forma continua las sesiones activas y cargar los resultados en una tabla:
Primero creamos la tabla donde cargaremos los datos:
CREATE TABLE msdb.dbo.log_de_acceso ( id int IDENTITY(1,1) NOT NULL, dbname nvarchar(128) NULL, dbuser nvarchar(128) NULL, hostname nchar(128) NOT NULL, program_name nchar(128) NOT NULL, nt_domain nchar(128) NOT NULL, nt_username nchar(128) NOT NULL, net_address nchar(12) NOT NULL, logdate datetime NOT NULL CONSTRAINT DF_user_access_log_logdate DEFAULT (getdate()), CONSTRAINT PK_user_access_log PRIMARY KEY CLUSTERED (id ASC) ) )
Luego abrimos otra ventana de consulta donde ejecutamos el siguiente trozo de código. Podemos elegir cada cuanto ejecutamos la consulta modificando el DELAY. La auditoria funcionará mientras tengamos el código ejecutándose.
WHILE 1=1
BEGIN
WAITFOR DELAY '00:00:30';
INSERT INTO msdb.dbo.log_de_acceso (dbname,dbuser,hostname,program_name,nt_domain,nt_username,net_address )
SELECT distinct DB_NAME(dbid) as dbname,
SUSER_SNAME(sid) as dbuser,
hostname,
program_name,
nt_domain,
nt_username,
net_address
FROM master.dbo.sysprocesses a
WHERE spid>50
AND NOT EXISTS( SELECT 1
FROM msdb.dbo.log_de_acceso b
WHERE b.dbname = db_name(a.dbid)
AND NULLIF(b.dbuser,SUSER_SNAME(a.sid)) IS NULL
AND b.hostname = a.hostname
AND b.program_name = a.program_name
AND b.nt_domain = a.nt_domain
AND b.nt_username = a.nt_username
AND b.net_address = a.net_address )
END
Con la información obtenida hasta ahora ya tenemos una base suficiente para seguir hablar con los responsables de las aplicaciones que usan nuestra base de datos y conocer cual es su función. También es necesario saber de primera mano la criticidad de las mismas y dependencias entre los datos que usa. Más de una vez las aplicaciones usaran más de una tabla contenida en distintas bases de datos.
- Una vez tengamos esto podemos considerar que ya tenemos una visión global y debemos centrarnos más en aspectos técnicos. Yo seguiría por indagar más en nuestros servidores. Como paso final me centraría en obtener la información puramente técnica del entorno y documentar lo siguiente:
-La versión de SQL Server, su estado de actualización y estado de licencias.
-La edición (Enterprise, Standard,e tc...).
-Parcheado. Interesa saber si se ha aplicado algún parche, además del service pack.
-Las características de la instalación en uso. Según la versión de base de datos, puede que necesitemos saber si usamos solo el motor de base de datos o tenemos instancias de SQL Server Reporting Services (motor de informes) o SQL Server Analysis Services (cubos de información).
-Privilegios. Entrar en detalle y saber que otros usuarios activos tienen permisos de administración etc...
En conclusión...
... , la lista de cosas por hacer es larga y no todo está incluido en este post, pero por algo se empieza. Aunque no en en este orden, lo incluido lo veo esencial para poder entender que tenemos entre manos y cubrirnos bien las espaldas desde el primer dia en el que el "marron" es nuestro.