Copias de Seguridad Físicas OFFLINE Las copias físicas offline, conocidas como Backups en frío, se realizan cuando la Base de Datos está parada. Como ya se ha comentado anteriormente, una copia en frío incluye los archivos de datos, los archivos de control, los archivos de redo log, los archivos log archivados (si se trabaja en modo archiver), los ficheros de parámetros, el fichero de passwords y generar y guardar una traza del fichero de control. Ventajas del Backup offline?? Una copia de la Base de Datos cerrada es sencilla de realizar, sólo necesitamos Cerrar la BBDD Copiar todos los archivos necesarios Abrir la BBDD?? No se requieren muchos comandos para realizar la copia de seguridad?? Es un proceso que se puede automatizar (generando y ejecutando un fichero de comandos)?? Debido a que la BBDD está cerrada y, por lo tanto, no se llevan a cabo transacciones, se puede decir que la Base de Datos es consistente hasta un punto en el tiempo Desventajas?? No se pueden realizar Backups offline en Bases de Datos de 24*7?? Mientras se realiza la copia, la Base de Datos no está disponible. El tiempo en que no está accesible depende del tamaño de la BBDD (nº y tamaño de los ficheros) y de la rapidez con que éstos pueden copiarse?? La calidad de una recuperación depende de la última copia de seguridad completa de la Base de Datos cerrada; si se pierden transacciones, tal vez sea necesario introducirlas a mano después de la recuperación Realización de un Backup offline Para realizar una copia de seguridad offline hemos de seguir los siguientes pasos: 1. Listar todos los ficheros importantes que se van a incluir en la copia de seguridad. Esto lo conseguimos a partir de sentencias SQL (SELECT) accediendo al diccionario de datos y mediante comandos de Sistema Operativo 2. Cerrar la instancia Oracle con cualquiera de las siguientes opciones: a. NORMAL b. TRANSACTIONAL c. IMMEDIATE 3. Realizar la copia de todos los archivos necesarios mediante un comando de Sistema Operativo 4. Arrancar la instancia Oracle - 17 -
Dbverify Oracle proporciona una herramienta que nos va a permitir verificar la integridad de los ficheros copiados, con el fin de detectar problemas en la copia o bloques corruptos. Esta utilidad se llama dbverify. Cómo funciona? Antes de utilizar dbverfiy se supone que ya hemos hecho la copia de los ficheros necesarios Una vez hecha la copia ejecutamos la utilidad Vemos en la ayuda los diferentes parámetros que podemos indicar a la hora de ejecutar la utilidad. De forma obligatoria hemos de indicar el fichero que queremos verificar (FILE) el tamaño del bloque Oracle (BLOCKSIZE) siempre y cuando no sea de 2k. También será interesante indicarle un fichero de traza (LOGFILE) para poder verificar los resultados. - 18 -
Vemos en este intento de ejecución el error que aparece debido a que nuestro bloque de BBDD es de 4k: El siguiente paso es ejecutar la utilidad. En este ejemplo vamos a verificar el fichero de datos USERS01.dbf (aunque en realidad deberíamos analizar la copia de este fichero) - 19 -
Ahora vamos a analizar el fichero de log que nos ha generado para comprobar el estado del fichero verificado Podemos observar que no existe ninguna página con fallo y ninguna marca corrupta con lo cual, podríamos decir que el fichero es correcto. - 20 -
Generar una traza del fichero de control Oracle recomienda tener al menos dos o tres ficheros de control ubicados en dispositivos diferentes (uno en disco D,otro en disco E,...) pero, Si yo sólo tengo un disco, es necesario tener esas copias? Lo más probable es que no, ya que el hecho de tener varias copias del fichero de control en distintos discos nos aporta un mayor grado de seguridad (seguridad que no conseguiríamos si todos los ficheros residieran en el mismo dispositivo). Por ejemplo: Vamos a suponer que tengo una máquina con dos discos (D y E) y tengo un fichero de control en cada uno de ellos. Oracle sabe que ha de acceder, leer y escribir en los dos ficheros de control porque se lo indica el parámetro CONTROL_FILES del fichero de parámetros. Si por algún motivo se borra el fichero de control del disco D o no se puede acceder al fichero, nuestra BBDD caería de forma estrepitosa (esto también depende de la versión). Al intentar arrancarla nos daría un error indicando que no encuentra el fichero de control del disco D. Qué haríamos nosotros? La solución es simple: modificar el parámetro CONTROL_FILES para indicarle a Oracle que sólo utilice el fichero de control del disco E. Hasta este punto estamos de acuerdo, pero... Si sólo tengo un disco y pierdo ese fichero, cuál es la solución? La solución es recrear el fichero de control. Cómo? Lo cierto es que esa es una labor muy costosa y duradera. Tendríamos que averiguar cuál es la sintaxis exacta de creación del fichero de control y localizar todos y cada uno de los ficheros de nuestra BBDD (ya que es el fichero de control el que guarda información sobre los ficheros de la Base de Datos) Una alternativa francamente interesante es generar una traza del fichero de control y guardarla en un dispositivo externo, un diskette, por ejemplo. Si tengo la mala suerte de perder el único fichero de control que tenía, no he de recrearlo manualmente, ejecuto la traza y ya está. - 21 -
Pasos para generar una traza del fichero de control: Realmente, para generar una traza, únicamente hemos de lanzar un comando (con la BBDD operativa) SQL> alter database backup controlfile to trace; Dónde está la traza? Debido a que la traza la he generado yo (el usuario), estará almacenada en el directorio especficado mediante el parámetro USER_DUMP_DEST: - 22 -
Una vez localizada la traza (nos guiamos por fecha de creación) la editamos y eliminamos los comentarios (todas las líneas hasta el CREATE CONTROLFILE y todas las líneas que empiecen con # ). Una vez sin comentarios la traza queda similar a esta: Contenido de la traza: Sentencia CREATE CONTROLFILE indicando el nombre de la BBDD, los máximos definidos, los ficheros de redo log y los ficheros de datos que forman parte de la Base de Datos El juego de caracteres de la BBDD El comando RECOVER DATABASE (para los casos en los que la BBDD se cerró de forma anormal) El comando para abrir la Base de Datos ALTER DATABASE OPEN Si tenemos esta traza y se corrompe el fichero de control, lo que hemos de hacer es (desde el SQL*plus, por ejemplo) ejecutar esta traza (la Base de Datos ha de estar en fase NOMOUNT): SQL> @ c:\oracle8i\ora81\admin\cya323\udump\ora01880.trc Y Oracle generaría tantos ficheros de control como se indique en el parámetro CONTROL_FILES del fichero de parámetros. Deberíamos utilizar este método (generar, modificar y ejecutar una traza del fichero de control) si deseamos ampliar los máximos definidos en el momento de la creación de la BBDD (MAXLOGFILES, MAXLOGMEMBERS,MAXDATAFILES,...).Podemos averiguar cuáles son esos máximos consultando la vista V$CONTROLFILE_RECORD_SECTION. Los pasos serían muy sencillos: 1. Generar la traza del fichero de control 2. Cambiar los valores de la traza deseados (ampliar el número máximo de ficheros de datos, por ejemplo) 3. Guardar la traza 4. Ejecutarla - 23 -
Consideraciones Debido a las variaciones que puede sufrir la Base de Datos, hemos de generar una traza (para tener una foto actual de la BBDD) cada vez que: Se añade o se elimina algún miembro o grupo de redo log Se renombre un fichero Se crea un tablespace (por que eso supone añadir al menos un fichero de datos) Se añade un fichero de datos a un tablespace Se altera el estado de un tablespace (por ejemplo si era de sólo lectura y pasa a ser de lectura/escritura) Se elimina un tablespace (ya que eso supone la eliminación de los ficheros de datos que pertenecen al tablespace) Vistas Dinámicas relacionadas A continuación se detallan algunas vistas relacionadas con el Backup offline Vista V$DATAFILE Descripción Listado de nombres y estados de todos los archivos de datos V$CONTROLFILE Listado de todos los ficheros de control V$LOGFILE Listado de todos los ficheros de redo log V$TABLESPACE Unida con V$DATAFILE obtendremos un listado de todos los ficheros de datos y sus respectivos tablespaces - 24 -