domingo, 18 de diciembre de 2011

Mover los archivos de una base de datos MSSQL Server

Hoy me he tenido que ver en la tesitura de mover los archivos de una BBDD SQL Server 2008 de un directorio a otro: el motivo, una BBDD que ha crecido de manera desmesurada en pocas horas, así que me he tenido que buscar las castañas para devolver el servicio a la plataforma. Y ya hablaremos con el cliente para ver qué quiere hacer.

El caso es que mover la BBDD ha sido sencillo, una vez he tenido un poco de idea de cómo hacerlo. En mi caso, lo he hecho para un MSSQL 2008, pero imagino que el procedimiento será el mismo en otras versiones.

Antes de empezar
1) tener claro dónde están los datos actuales de la BBDD y dónde lo vamos a mover, y sobre todo, si hay espacio suficiente. Sé que puede parecer una tontería, pero no lo es.
2) configuraremos el directorio destino. Con esto me refiero a que asignaremos los mismos permisos al directorio de destino que tiene el directorio origen. En mi caso, que trabajo con un usuario administrador, sólo me hizo falta añadir al usuario SQLUser con control total en el directorio, y después, al mover los archivos, y en los archivos.

Una vez tenemos el escenario preparado, los pasos serán los siguientes:
 - Arranca el SQL Server Management Studio
 - Expande la instancia de tu servidor SQL y las Bases de datos (Databases)
 - Botón derecho sobre la BBDD que quieres mover y elige 'Tasks' y después 'Detach'. Con esto, la BBDD queda desvinculada del servidor SQL, aunque sigue en nuestro disco duro. Haz con cuidado este paso y asegúrate que no hay activada ninguna opción tipo 'Drop'. Haz click en 'OK' cuando hayas comprobado toda la información de la ventana 'Detach'.
 - Desde el directorio origen de datos de SQL, mueve los datos (xxxx.mdf y xxxx.ldf) a su nuevo directorio. Recuerda comprobar los permisos unas vez movidos los archivos, y que sean los mismos que originalmente.
 - Botón derecho sobre 'Databases' y elige la opción 'Attach'; con esto, volveremos a vincular la BBDD al servidor SQL. Se abrirá una ventana que nos pedirá que ubiquemos los archivos de la BBDD que vamos a vincular; navegamos y seleccionamos el archivo .mdf que acabamos de mover, y 'OK'.
 - En el siguiente panel comprueba que la nueva localización está configurada tanto para el archivo .mdf como para el .ldf. Una vez comprobado, 'OK'.
 - Una vez se haya vinculado de nuevo la BBDD, comprueba que se haya hecho bien, refrescando la vista y comprobando que la BBDD se lista de nuevo correctamente.


Como véis, el proceso no es muy complicado, sólo que las primeras veces hay que ir con ojo. Aún así, me he encontrado con dos problemas, y paso a relatar cómo los he solucionado.
  • Por un lado, al vincular la BBDD de nuevo, el SQL lo hacía en modo Read-Only. Esto ha sido debido a que los permisos del nuevo directorio y de los archivos copiados no eran los mismos que originalmente; por eso hago tanto hincapié durante la explicación.
  • Por otro lado, una vez ha finalizado correctamente todo el proceso, otra BBDD se ha quedado en estado 'in recovery', y no se podía realizar ninguna acción sobre ella. En esta BBDD no se ha hecho ningún cambio, pero es posible que a nivel interno tuviera alguna relación con la BBDD que se ha movido; el caso es que pasados unos minutos en este estado, se ha solucionado solo, la BBDD ha salido de este estado una vez ha finalizado la recuperación.

miércoles, 7 de diciembre de 2011

Haciendo mis pinitos en Oracle: recursos en STOP_FAILED

En mi caso, alguna vez me he encontrado con que no se puede establecer una conexión entre un tomcat y una BBDD oracle; el error típico es el siguiente

[06/12/11 23:44:11:396] com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask run INFO: An exception occurred while acquiring a poolable resource. Will retry.
java.sql.SQLException: Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was:
192.168.168.168:1521:BBDD01


Al acceder al nodo activo de oracle, y ver el estado, hay un recurso que ha intentado pararse pero no ha podido. Para consultar el estado, ejecutamos

scstat -g

y obtenemos

-- Grupos de recursos y recursos --

            Nombre del grupo Recursos
            ---------------- --------
 Recursos:  grupo_recurso-rg servicio_01 servicio_02 servicio_03 servicio_n


-- Grupos de recursos --

            Nombre del grupo Nombre del nodo          Estado         Suspendido
            ---------------- ---------------          ------         ----------
     Grupo: grupo_recurso-rg BD1                     Error: parada no satisfactoria No
     Grupo: grupo_recurso-rg BD2                     Offline        No


-- Recursos --

            Nombre del recurso Nombre del nodo          Estado         Mensaje de estado
            ------------------ ---------------          ------         -----------------
  Recurso:  servicio_01    BD1                      Online         Online - LogicalHostname online.
  Recurso:  servicio_01    BD2                      Offline        Offline - LogicalHostname offline.

  Recurso:  servicio_02 BD1                     Online         Online
  Recurso:  servicio_02 BD2                     Offline         Offline

  Recurso:  servicio_03 BD1                     Online         Online
  Recurso:  servicio_03 BD2                     Offline         Offline

  Recurso:  servicio_n BD1                     Parada no satisfactoria Con fallo
  Recurso:  servicio_n BD2                     Offline       Offline

Localizamos que el problema está en el recurso servicio_pen-oracle_server del nodo BD11. El estado es STOP_FAILED. En este caso, lo que debemos hacer es poner el recurso en estado offline y después balancear el clúster al nodo pasivo para volver a tener servicio. Primer ejecutaremos

scswitch -c -h BD1 -j servicio_n -f STOP_FAILED

donde
-c: pasar a offline
-h: nodo
-j: recurso
-f: estado actual

Una vez ejecutado, nos devuelve el siguiente mensaje

scswitch: NOTICE: Operation succeeded, but resource group oracle-rg remains in ERROR_STOP_FAILED state on node server1 because some resources in the group remain
online while others are offline. To clear this condition, switch the resource group offline.

y ejecutamos el siguiente comando para pasar el grupo de recursos offline (es decir, todos los recursos, no sólo el que da problemas)

scswitch -F -g grupo_recurso-rg

Una vez ha finalizado, comprobamos que el todo ha quedado sin errores: scstat -g
Por último, para pasar el clúster al nodo inactivo, lo hacemos ejecutando

scswitch -z -g grupo_recurso-rg -h BD2

donde
-z: balanceo
-g: grupo de recursos
-h: nodo al que vamos a pasar el grupo de recursos

Una vez finalice, comprobamos que los servicios han quedado bien levantados con scstat -g