Restaurando una base de datos completa

No es algo muy común que tengamos que recuperar una base de datos completa, generalmente los recoveries vamos a necesitar hacerlos de algún archivo que se dañe, como alguna tablespace, etc. Pero supongamos que por alguna razón se han dañado la mayor parte de los ficheros de la base de datos y decidimos que en vez de hacer un recovery por ficheros, o por alguna tablespace, la única manera que tenemos de solucionarlo es haciendo un recovery completo de la base de datos.

Ya sabemos, que para hacer una recuperación en Oracle, lo primero es hacer una restauración de los ficheros dañados, a partir de algún backup que tengamos hecho, y luego aplicar el recovery.

Para esto, lo primero es asegurarse de haber hecho backups previamente, hemos visto durante el curso, que hemos hecho varios, pues éstos servirian para el caso de tener que recuperar la base datos. Otra cuestión a tener en cuenta es que debemos saber dónde se encuentran los ficheros de nuestra base de datos. Vayamos a una terminal de Linux, dentro del directorio datafile perteneciente a la base de datos ORCL

Si borrásemos el contenido de este directorio, la base de datos no tendria acceso a estos recursos y empezaria a dar errores. Pues esto es precisamente lo que vamos a hacer, vamos a eliminar todo el contenido de este directorio.

Para este ejemplo, hay que tener cuidado de no eliminar los ficheros de control y de redo, que igual no se encuentran en este directorio, pero es bueno saber que si se eliminase algunos de esos ficheros, no arrancaria bien la base de datos. En fin, en este ejemplo vamos a eliminar todo el contenido del directorio datafile.

Para ello escribimos el comando:

• rm *

Presionamos Intro, y si hacemos un ls -l, podemos ver que ahora no tenemos fichero alguno dentro del directorio datafile, los hemos borrado.

Regresemos a la terminal donde nos encontramos dentro del sqlplus, y vamos a intentar hacer un shutdown immediate, es bueno saber que aunque no tengamos ningún mensaje de error, eventualmente irán apareciendo. De hecho, es muy posible que cuando intentemos hacer el shutdown, nos muestre algún error.

Antes vamos a visualizar el fichero alert de esta base de datos, de esta manera podemos también ir viendo en tiempo real los errores que vayan apareciendo en la base de datos.

Y en unos instantes vemos que comienzan a aparecer errores que tienen que ver con archivos que hemos eliminado del directorio datafile, como aquí que no encuentra el user, o más arriba, que no encuentra la tablespace NOMBRES, todos ficheros que recién eliminamos.

Volviendo al sqlplus, ahora si vamos a intentar hacer un shutdown:

• shutdown immediate

Y vemos que aparece un error importante. Vemos además en el fichero alert, vemos que continúa mostrando más y más errores, relacionados con el acceso a los ficheros. Y es que no puede acceder simplemente porque el fichero no existe, lo hemos borrado.

Los mensajes de error de este archivo, como los errores que nos muestre sqlplus, a partir de una base de datos dañanda, ya que podemos identificar dónde está el problema, y a partir de ahí, hacer el tipo de backup que corresponda.

De vuelta a la terminal donde nos encontramos dentro del sqlplus, vamos a intentar arrancar la base de datos en modo MOUNT, presionamos Intro y nos devuelve otro error, lo que sucede es que se ha cerrado la instancia, debemos conectar un usuario nuevamente. Entonces escribimos:

• connect / as sysdba

Y estamos conectados con este usuario, ahora si, vamos a arrancar la base de datos en modo mount:

• startup mount

Y vemos cómo arranca la base de datos en modo mount. Esto es posible porque el fichero de control está intacto, no lo hemos tocado, y para arrancar la base de datos en este modo no se necesita de nada más. En nuestro caso, como tenemos una pérdida catastrófica de los ficheros de datos, comenzando por el sysaux y el system, la base de datos no se va a abrir, es por ello que no es posible arrancarla en un modo superior al modo mount. Aquí se puede ver la importancia de proteger el fichero de control, tener copias multiplexadas, etc., porque ante una pérdida de archivos que impidan que se abra la base de datos, todavía podemos arrancarla en modo mount.

Es el momento de comenzar con el proceso de backup, para ello nos vamos a esta terminal, donde estamos dentro de RMAN. Pero como esta conexión es antigua, y ya hemos cerrado la base de datos y por demás se nos ha caido la instancia, debemos cerrar esta conexión, y conectarnos de nuevo

Ya conocemos que el primer paso para realizar una recuperación de una base de datos, es el RESTORE:

• RESTORE DATABASE

Lo que hace rman, es tomar esos ficheros del backup correspondiente y dejarlos en el sitio correcto, para que de esta manera sean accesibles cuando hagamos el RESTORE.

Y vemos que primero, rman nos muestra los ficheros que se necesitan restaurar. Una vez que termine el RESTORE. Vayamos a esta terminal de Linux, donde estamos dentro del directorio datafile y hagamos un ls -l, recordar que entes no teníamos nada aquí dentro, lo habiamos borrado todo, ahora tenemos estos ficheros, resultado de la restauración.

Fijémonos en la hora de creación de los ficheros, difiere en algunos minutos de los que teníamos de antes. Pero hay un inconveniente, estos ficheros no están actualizados, los hemos restaurado a partir de un backup anterior, que para nada van a estar acordes a cómo iba la base de datos. El resto de información, que nos garantiza que se haga una restauración de la base de datos hasta el instante donde ha fallado, lo tenemos en los archive logs y en los online redo logs, ya que estos archivos contienen las transacciónes que se han prod