Restaurando un tablespaces

Uno de los problemas que podemos tener al recuperar una base de datos completa, es que se necesitará recuperar muchos ficheros, entonces en el caso de que la base de datos sea muy grande, el proceso de RESTORE puede tomar bastante tiempo.

Si en la práctica, se nos presenta un problema en la base de datos, y podemos identificar que tiene que ver con ficheros asociados a una TABLESPACE, entonces podemos intentar hacer un RECOVER sólo de esa TABLESPACE, o incluso del fichero dañado.

Cuando necesitamos recuperar una tablespace, debemos saber diferenciar una tablespace no obligatoria, de una tablespace obligatoria. ¿A qué nos referimos con esto? Pues que si la TABLESPACE es una TABLESPACE de SYSTEM, entonces es necesario parar completamente la base de datos y hacer el recovery en modo mount, porque no podremos arrancar la base de datos si se ha perdido por ejemplo la SYSAUX, la UNDO, la SYSTEM. En cambio, si la tablespace que se daña es una tablespace de datos, generalmente no tendremos que parar la base datos, bastaria con restringir el acceso a esa tablespace. En el ejemplo que veremos en este video, vamos a recuperar una tablespace no obligatoria.

Mostremos las tablespaces que tengo en esta base de datos, para ello vamos a utilizar la consulta:

• SELECT TABLESPACE_NAME FROM DBA_TABLESPACES

Vemos la tablespace SYSTEM, la SYSAUX, etc, todas ellas son tablespaces del sistema, necesarias para el funcionamiento de la base de datos, a excepción de la tablespace NOMBRES, que es una de las no obligatorias, por así decirlo.

Lo que haremos en este ejemplo es eliminar esta tablespace, para recuperarla posteriormente. Antes vayamos a RMAN, para hacer un backup de esta tablespace. Escribimos el comando:

• BACKUP TABLESPACE NOMBRES

Recordar que con este comando le estamos indicando a RMAN que haga un backup solamente de la tablespace NOMBRES. Vemos que para el backup está tomando el datafile NOMBRES, este fichero es el que precisamente necesitamos eliminar para nuestro ejemplo, algo que haremos más adelante. También podemos ver que el backupset lo está almacenando dentro del directorio rman_backups.

Vayamos ahora a la terminal donde estamos dentro del sqlplus y vamos a realizar algunas operaciones, de esta manera, una vez que eliminemos el tablespace y posteriormente hagamos el RECOVER, comprobaremos que se va a recuperar hasta la última transacción que hayamos hecho.

Por ejemplo, vamos a crear una tabla, con nombre DATOS1, que va a tener una columna llamada datos, de tipo VARCHAR2 de hasta 100 caracteres y va a estar asociada a la tablespace NOMBRES. Presionamos Intro y vemos el mensaje que confirma que hemos creado una tabla.

Insertemos ahora valores a esta tabla:

• Validemos estas transacciónes haciendo un COMMIT.

Vemos los datos que tenemos ahora mismo dentro de la tabla:

• SELECT * FROM DATOS1

Analicemos el punto en que nos encontramos, hemos hecho un backup de la tablespace nombres, da igual si fue hace unos minutos o hace días, y después hemos hecho algunas operaciones que involucran a esta tablespace. Entonces, si esta tablespace quedara inutilizable, los cambios que hemos hecho no estarían en el backup, pero aun así, se recuperarian todas las transacciónes, como veremos más adelante, y esto es posible gracias a que el paso final en una recuperación es a través de la información que haya en los redologs.

Pasemos a eliminar la tablespace NOMBRES. Vamos a esta terminal de Linux donde nos encontramos dentro del directorio de la base de datos.

Si mostramos su contenido veremos que dentro se encuentra el directorio datafile, que es donde se encuentra la tablespace NOMBRES, como vimos cuando hicimos el backup de la misma.

Entramos dentro de este directorio, y si mostramos su contenido, podemos ver el fichero NOMBRES.dbf, que es precisamente el que vamos a eliminar.

Para eliminarlo, escribimos el comando rm y el nombre del archivo que queremos eliminar, que es NOMBRES.dbf. Presionamos Intro, y si mostramos otra vez el contenido del directorio datafile, veremos que ya no existe el fichero NOMBRES.dbf, lo hemos eliminado.

Ahora, más pronto o más tarde, la base de datos comenzará a presentar errores, sobre todo con transacciónes que involucren a la tablespace que se ha eliminado.

Regresemos a la terminal donde estamos dentro del sqlplus y vamos a realizar algunas operaciones que involucren a esta tablespace. Y vamos a insertar nuevos registros a la tabla DATOS1

Podemos auxiliarnos del comando R para repetir la acción anterior unas cuantas veces más, lo importante para este ejemplo no es el contenido de la tabla, entonces podemos introducir cualquier valor en ella.

Después de insertar los valores, hagamos un COMMIT para validar estas transacciónes. Hasta este momento, no ha presentado error alguno la base de datos, pero más pronto o más tarde los dará, en cuanto tenga que hacer un commit definitivo, o sincronizar el fichero redo log con el fichero de datos, ahí saltará un error, porque no lo va a encontrar.

Otra manera de comprobarlo es simplemente parando la base de datos y volviéndola a arrancar, veremos que salta un error en cuanto la paramos. Vamos a comprobarlo:

• Hacemos un SHUTDOWN IMMEDIATE

Vemos que ya nos muestra que hay algún problema con la base de datos, si vamos al fichero de trazas, que ya lo tengo abierto de antes, veremos que nos informa de este error, y que involucra al fichero que hemos eliminado.

De vuelta al sqlplus, intentemos arrancar la base de datos en modo open y vemos que nos da un error, y es hemos cerrado la instancia antes. Vamos a conectarnos a la base de datos con el usuario sysdba. Y ahora si, hacemos un:

• STARTUP OPEN

Presionamos intro y comienza de proceso de arranque de la base de datos, pero algo ha fallado. Oracle nos informa que la base de datos está en MOUNTED, o sea, no se puedo arrancar en modo OPEN, y nos informa que tenemos un error relacionado al fichero NOMBRES.DBF.

Si intentamos hacer un ALTER DATABASE OPEN. Tendremos el mismo error, o sea, no es posible arrancar la base de datos en modo OPEN, mientras persista este error.

¿Qué pasaria si intentamos poner la tablespace en modo offline? Vamos a comprobarlo:

• ALTER TABLESPACE NOMBRES OFFLINE

Y Oracle nos muestra un mensaje indicándonos que la base de datos no está abierta, o sea, desde el modo MOUNT no es posible restringir el acceso a determinada tablespace. Para recuperar la tablespace, tenemos dos opciones.

Una, que a priori sería muy rápida de hacer, es simplemente hacer recover de la tablespace estando en modo MOUNT. Pero esta opción no sería muy práctica en un entorno real, con varios usuarios esperando para utilizar la base de datos, y suponiendo que el recover de la tablespace pueda demorar algún tiempo. Entonces, como dijimos al principio del video, hay una manera a partir del punto en que nos encontramos, donde podemos hacer el recovery de esta tablespace con la base de datos en modo OPEN.

Por ejemplo, podemos hacer lo siguiente:

• ALTER DATABASE DATAFILE

Vamos a copiar de aquí la ruta completa del fichero al que quiero restringirle el acceso:

• Y lo ponemos OFFLINE

Es decir, no podemos acceder a las tablespaces, porque estamos en modo MOUNT, y el usuario no tiene acceso a los metadatos de las tablespaces, pero si que podemos a acceder a los ficheros. Entonces con este comando, estamos poniendo el fichero NOMBRES.dbf, en modo offline. De esta manera, en teoría, debemos ser capaces de arrancar la base de datos en modo OPEN. Vamos a comprobarlo.

Hacemos un ALTER DATABASE OPEN, presionamos Intro y si no hay ningún error, ya tendremos la base de datos abierta.

A partir de lo anterior, una