ORACLE: Backup y Recuperacin

Para conseguir un funcionamiento seguro de la BD y una pronta recuperacin ante fallos se necesita planear una estrategia de copias de seguridad, backup, y de recuperacin, recovery, ya que de nada sirve pensar que estamos a salvo de tales circunstancias, y que eso no me puede pasar a m. Y el primer paso a dar es definir las caractersticas fundamentales de la implantacin, porque mal vamos a conseguir unos objetivos si se desconocen o estn indefinidos. El segundo paso es establecer unos planes de copias de seguridad y recuperacin que nos permitan asegurar los objetivos. Mayo de 1998. Jess Vegas Dpto. Informtica Universidad de Valladolid jvegas@infor.uva.es

ndice
1 Introduccin al Backup y a la Recuperacin 1.1 Presentacin del Backup 1.2 Presentacin de la Recuperacin 2 Principios de Backup 2.1 Diseo de la BD y Reglas Bsicas de Backup 2.2 Backups Fsicos 2.3 Backups Lgicos 3 Principios de la Recuperacin 3.1 Definiciones y Conceptos 3.2 Mtodos de Recuperacin 3.3 Recuperacin Fsica 3.4 Recuperacin Lgica

1 Introduccin al Backup y a la Recuperacin

Planear y comprobar los procedimientos de backup del sistema es la nica garanta que existe contra fallos del sistema, del SO, del software o cualquier otro tipo de circunstancias. Las causas de error en una sistema de BD pueden agruparse en las siguientes categoras:

Fsicas son causadas por fallos del hardware, como por ejemplo del disco o de la CPU.

de Diseo son agujeros en el software, ya sea en el SO o en el SGBD.

de Funcionamiento son causadas por la intervencin humana, debidos a fallos del DBA, configuraciones inapropiadas o mal planteamiento de los procedimientos de backup.

del entorno como por ejemplo desastres naturales, fallos de corriente, temperatura excesiva.

De entre todas estas posibilidades, el DBA slo puede influir y prever los errores de funcionamiento, ya que el resto habitualmente no est dentro de sus responsabilidades y capacidades. Dada la complejidad de los sistemas actuales y las necesidades cada vez ms crticas en la disponibilidad de los sistemas, donde una BD caida puede causar prdidas millonarias, puede ser interesante considerar los mecanismos de proteccin hardware y de redundancia que la tecnologa nos proporciona:

UPS o fuentes de corriente ininterrumpida, espejado de disco, o tecnologa RAID, Componentes duplicados, Sistemas redundantes.

Una de las ms importantes decisiones que un DBA debe tomar es decidir si arrancar la BD en modo ARCHIVELOG o no. Esta decisin tiene sus ventajas e inconvenientes:

Ventajas: o Aunque se pierdan los ficheros de datos, siempre se puede recuperar la BD con una copia antigua de los ficheros de datos y los ficheros de redo log archivados. o Es posible realizar backups en caliente. Inconvenientes: o Se necesitar ms espacio en disco. o El trabajo del DBA se incrementa al tener que determinar el destino del archivado de los redo log.

1.1 Presentacin del Backup

Los backups se pueden clasificar en fsicos y lgicos. Los fsicos se realizan cuando se copian los ficheros que soportan la BD. Entre estos se encuentran los backups del SO, los backups en fro y los backups en caliente. Los backups lgicos slo extraen los datos de las tablas utilizando comandos SQL y se realizan con la utilidad export/import. Backups del SO Este tipo de backup es el ms sencillo de ejecutar, aunque consume mucho tiempo y hace inaccesible al sistema mientras se lleva a cabo. Aprovecha el backup del SO para almacenar tambin todos los ficheros de la BD. Los pasos de este tipo de backup son los siguientes: 1. 2. 3. 4. Parar la BD y el SO Arrancar en modo superusuario. Realizar copia de todos los ficheros del sistema de ficheros Arrancar el sistema en modo normal y luego la BD.

Backups de la BD en Frio Los backups en frio implican parar la BD en modo normal y copiar todos los ficheros sobre los que se asienta. Antes de parar la BD hay que parar tambin todos las aplicaciones que estn trabajando con la BD. Una vez realizada la copia de los ficheros, la BD se puede volver a arrancar.

Backups de la BD en Caliente El backup en caliente se realiza mientras la BD est abierta y funcionando en modo ARCHIVELOG. Habr que tener cuidado de realizarlo cuando la carga de la BD sea pequea. Este tipo de backup consiste en copiar todos los ficheros correspondientes a un tablespace determinado, los ficheros redo log archivados y los ficheros de control. Esto para cada tablespace de la BD. Backups Lgicos con Export/Import Estas utilidades permiten al DBA hacer copias de determinados objetos de la BD, as como restaurarlos o moverlos de una BD a otra. Estas herramientas utilizan comandos del SQL para obtener el contenido de los objetos y escribirlos en/leerlos de ficheros Una vez que se ha planeado una estrategia de backup y se ha probado, conviene automatizarla para facilitar as su cumplimiento.

1.2 Presentacin de la Recuperacin

Oracle proporciona diferentes modos de recuperar un fallo en la BD, y es importante que el DBA conozca como funciona cada uno de ellos para determinar cundo ha de ser utilizado. Una de las mayores responsabilidades del DBA consiste en tener la BD a punto, y prepararla ante la posibilidad de que se produzca un fallo. As, ante un fallo el DBA podr recuperar la BD en el menor tiempo posible. Los procesos de recuperacin dependen del tipo de error y de las estructuras afectadas. As, los tipos de error que se pueden producir son: Errores de Usuario Como por ejemplo un usuario borrando una fila o eliminando una tabla. Estos errores se solucionan importando una tabla de una copia lgica anterior. Si no se dispone de la copia lgica, se puede recuperar la BD en una instancia auxiliar, exportar la tabla en cuestin de la instancia auxiliar e importarla en la instancia operativa. Fallos de Sentencias

Se definen como la imposibilidad del SGBD Oracle de ejecutar alguna sentencia SQL. Un ejemplo de esto se produce cuando se intenta una seleccin de una tabla que no existe. Estos fallos se recuperan automticamente mediante un rollback de la transaccin que contena la sentencia fallida. El usuario necesitar volver a ejecutar otra vez la transaccin cuando se haya solucionado la causa del problema. Fallos de Procesos Es una terminacin anormal de un proceso. Si el proceso era un proceso de usuario, del servidor o de una aplicacin el PMON efectuar la recuperacin del proceso. Si el proceso era alguno de los de background, la instancia debe de ser parada y arrancada de nuevo, proceso durante el cual se recupera la caida efectuando un roll forward y un rollback de las transacciones no confirmadas. Fallos de la Red Algunas veces los fallos en la red producen fallos de proceso, que son tratados por el PMON. Si en el error de red se ve envuelta una transaccin distribuida, una vez que se reestablece la conexin, el procesoRECO resuelve los conflictos automticamente. Fallos de Instancia Pueden deberse a fallos fsicos o de diseo del software que hacen que algn proceso background caiga y la instancia con l. La recuperacin es automtica cuando se levanta la BD, tomandose ms o menos tiempo en la recuperacin. Fallos del Sistema Son los fallos ms peligrosos, no slo porque se pueden perder datos, sino porque se tarda ms tiempo en recuperar que los otros fallos. Adems se depende mucho de la experiencia del DBA para levantar la BD rpidamente y sin pdida (o casi) de datos. Existen tres tipos de recuperacin en Oracle: a nivel de bloque, de thread y fsica. Recuperacin de bloques

Es el mecanismo de recuperacin ms simple, y se realiza automticamente. Se produce cuando un proceso muere justo cuando est cambiando un bloque, y se utilizan los registros redo log en lnea para reconstruir el bloque y escribirlo en disco. Recuperacin de threads Se realiza automticamente cuando Oracle descubre que una instancia muere dejando abierto un thread, entonces se restauran los bloques de datos modificados que estaban en el cache de la instancia muerta, y cerrando el thread que estaba abierto. La recuperacin se efectua automticamento cuando la BD se levanta. Recuperacin fsica Se realiza como respuesta a un comando RECOVER. Se utiliza para convertir los ficheros de backup en actuales, o para restaurar los cambios que fueron perdidos cuando un fichero de datos fue puesto offline sin uncheckpoint, aplicando los fichero redo log archivados y en lnea.

2 Principios de Backup
Un backup vlido es una copia de la informacin sobre la BD necesaria para reconstruir la BD a partir de un estado no utilizable de la misma. Normalmente, si la estrategia de backup se basa en la copia de los ficheros de datos y en el archivado de los ficheros redo log, se han de tener copias de los ficheros de datos, de los ficheros de control, de los ficheros redo log activos y tambin de los archivados. Si se pierde uno de los ficherosredo log archivados se dice que se tiene un agujero en la secuencia de ficheros. Esto invalida el backup, pero permite a la BD ser llevada hasta el principio del agujero realizando una recuperacin incompleta.

2.1 Diseo de la BD y Reglas Bsicas de Backup

Antes de nada, es muy importante entender ciertas reglas que determinan la situacin de los ficheros y otras consideraciones que afectarn al esquema de backup:

Es recomendable archivar los ficheros redo log en disco, y luego copiarlos a cinta, pero siempre en un disco diferente del que soporta los ficheros de datos y de redo log activos. Los ficheros copias no deben estar en el mismo dispositivo que los originales. No siempre hay que pasar las copias a cinta, ya que si se dejan en disco se acelera la recuperacin. Adems, si se copian las copias a cinta y se mantienen en el disco, se puede sobrevivir a diversos fallos de dispositivo. Se deberan mantener diferentes copias de los ficheros de control, colocadas en diferentes discos con diferentes controladores. Los ficheros redo log en lnea deben estar multiplexados, con un mnimo de 2 miembros por grupo, residiendo cada miembro en un disco distinto. Siempre que la estructura de la BD cambie debido a la inclusin, borrado o renombrado de un fichero de datos o de redo log, se debe copiar el fichero de control, ya que almacenan la estructura de la BD. Adems, cada fichero aadido tambin debe ser copiado. El fichero de control puede ser copiado mientras la BD est abierta con el siguiente comando: SVRMGR> alter database backup controlfile to 'destino';

Teniendo en cuenta las reglas anteriores, los siguientes puntos pueden considerarse un ejemplo de estrategia de backup: 1. Activar el modo ARCHIVELOG. 2. Realizar un backup al menos una vez a la semana si la BD se puede parar. En otro caso, realizar backups en caliente cada da. 3. Copiar todos los ficheros redo log archivados cada cuatro horas. El tamao y el nmero de ellos depender de la tasa de transacciones. 4. Efectuar un export de la BD semanalmente en modo RESTRICT.

2.2 Backups Fsicos

Los backups fsicos son aquellos que copian fsicamente los ficheros de la BD. Existen dos opciones: en fro y en caliente. Se dice que el backup es en frio cuando los ficheros se copian con la BD esta parada. En caliente es cuando se copian los ficheros con la BD abierta y funcionando. Backup en Fro El primer paso es parar la BD con el comando shutdown normal. Si la BD se tiene que parar con inmediate o abort debe rearrancarse con el modo RESTRICT y vuelta

a parar en modo normal. Despus se copian los ficheros de datos, los de redo log y los de control, adems de los redo log archivados y an no copiados. Una buena idea es automatizar todo este proceso con los scripts correspondientes, de modo que no nos olvidemos de copiar ningn fichero. Como este tipo de backup es una copia de los ficheros de la BD, si estos contienen algn tipo de corrupcin, la traspasaremos a la copia de seguridad sin detectarla. Por esto es importante comprobar las copias de seguridad. Backup en Caliente Si la implantacin de BD requiere disponibilidad de la misma 24h. al da, 7 dias a la semana no se pueden realizar backups en frio. Para efectuar un backup en caliente debemos trabajar con la BD en modo ARCHIVELOG. El procedimiento de backup en caliente es bastante parecido al frio. Existen dos comandos adicionales: begin backup antes de comenzar y end backup al finalizar el backup. Por ejemplo, antes y despus de efectuar un backup del tablespace users se deberan ejecutar las sentencias: SVRMGR> alter tablespace users begin backup; SVRMGR> alter tablespace users end backup; As como el backup en frio permita realizar una copia de toda la BD al tiempo, en los backups en caliente la unidad de tratamiento es el tablespace. El backup en caliente consiste en la copia de los ficheros de datos (portablespaces), el actual fichero de control y todos los ficheros redo log archivados creados durante el periodo de backup. Tambin se necesitarn todos los ficheros redo log archivados despus del backup en caliente para conseguir una recuperacin total.

2.3 Backups Lgicos

Este tipo de backups copian el contenido de la BD pero sin almacenar la posicin fsica de los datos. Se realizan con la herramienta export que copia los datos y la definicin de la BD en un fichero en un formato interno de Oracle. Para realizar un export la BD debe estr abierta. Export asegura la consistencia en la tabla, aunque no entre tablas. Si se requiere consistencia entre todas las

tablas de la BD entonces no se debe realizar ninguna transaccin durante el proceso de export. Esto se puede conseguir si se abre la BD en modo RESTRICT. Entre las ventajas de efectuar un export estn las siguientes:

Se puede detectar la corrupcin en los bloques de datos, ya que el proceso de export fallar. Protege de fallos de usuario, por ejemplo si se borra una fila o toda una tabla por error es fcil recuperarla por medio de un import. Se puede determinar los datos a exportar con gran flexibilidad. Se pueden realizar exports completos, incrementales y acumulativos. Los backups relizados con export son portables y sirven como formato de intercambio de datos entre BDs y entre mquinas.

Una de las desventajas de realizar backups lgicos con export es que son mucho ms lentos que los backups fsicos. Parmetros de Export
Parmetro
USERID BUFFER FILE GRANTS INDEXES ROWS CONSTRAINTS COMPRESS FULL OWNER TABLES RECORDLENGTH INCTYPE RECORD

Defecto indefinido dependiente del SO expdat.dmp Yes Yes Yes Yes Yes No usuario actual indefinido dependiente del SO indefinido Yes

Descripcin el username/password del usuario que efectua el export. El tamao en bytes del buffer utilizado. el nombre del fichero destino. indica si se exportan tambin los derechos. indica si se exportan tambin los ndices. indica si se exportan tambin las filas de las tablas, o slo las definiciones de las tablas. indica si se exportan tambin las restricciones. indica si se exporta en modo comprimido. indica si se exporta la BD entera. una lista de usuarios cuyos objetos se quieren exportar. la lista de tablas a exportar. la longitud en bytes del registro del fichero. el tipo de export incremental. indica si se anota el export incremental en las tablas SYS.INCVID y en SYS.INCEXP.

PARFILE

indefinido

el fichero de parmetros.

Modos de Export Existen tres modos de realizar una exportacin de datos: Modo Tabla Exporta las definiciones de tabla, los datos, los derechos del propietario, los ndices del propietario, las restricciones de la tabla y los disparadores asociados a la tabla. Modo Usuario Exporta todo lo del modo de Tabla ms los clusters, enlaces de BD, vistas, sinnimos privados, secuencias, procedimientos, etc. del usuario. Modo BD Entera Adems de todo lo del modo Usuario, exporta los roles, todos los sinnimos, los privilegios del sistema, las definiciones de los tablespaces, las cuotas en los tablespaces, las definiciones de los segmentos derollback, las opciones de auditora del sistema, todos los disparadores y los perfiles. El modo BD entera puede ser dividido en tres casos: Completo, Acumulativo e Incremental. Estos dos ltimos se toman menos tiempo que el completo, y permiten exportar slo los cmbios en los datos y en las definiciones. Completo Exporta todas las tablas de la BD e inicializa la informacin sobre la exportacin incremental de cada tabla. Despus de una exportacin completa, no se necesitan los ficheros de exportaciones acumulativas e incrementales de la BD anteriores. $ exp userid=system/manager full=y inctype=complete constraints=Y file=full_export_filename Acumulativo Exporta solo las tablas que han sido modificadas o creadas desde la ltima exportacin Acumulativa o Completa, y registra los detalles de exportacin para cada tabla exportada. Despus de una exportacin acumulativa, no se necesitan los ficheros de exportaciones incrementales de la BD anteriores. $ exp userid=system/manager full=y inctype=cumulative constraints=Y file=cumulative_export_filename Incremental Exporta todas las tablas modificadas o creadas desde la ltima exportacin Incremental, Acumulativa o Completa, y registra los detalles de

exportacin para cada tabla exportada. Son interesantes en entornos en los que muchas tablas permanecen estticas por periodos largos de tiempo, mientras que otras varan y necesitan ser copiadas. Este tipo de exportacin es til cuando hay que recuperar rpidamente una tabla borrada por accidente. $ exp userid=system/manager full=y inctype=incremental constraints=Y file=incremental_export_filename La poltica de exportacin puede ser la siguiente: realizar una exportacin completa el da 1 (por ejemplo el domingo), y luego realizar exportaciones incrementales el resto de la semana. De este modo de lunes a sbado slo se exportarn aquellas tablas exportadas, ahorrando tiempo en el proceso.

3 Principios de la Recuperacin
Para entender los principios de la recuperacin, se necesita entender las estructuras de datos subyacentes utilizadas en la recuperacin.

3.1 Definiciones y Conceptos

Los ficheros redo log contienen los cambios realizados sobre la BD. Conviene presentar algunos conceptos relacionados con ellos. Vector de Cambio describe un cambio simple en un bloque de datos de la BD. Entre otros datos, contiene el nmero de versin, el cdigo de la transaccin, y la direccin del bloque afectado. Registro Redo log es un conjunto de vectores de cambio que describen un cambio atmico sobre la BD. La transaccin es tambin la unidad de recuperacin. Evolucin de Redo log por da se puede calcular ejecutando el comando archive log list en dos das consecutivos y calculando la diferencia del nmero de secuencia de los ficheros redo log, multiplicado por el tamao de un fichero redo log: SVRMGR> archive log list; Database log mode No Archive Mode Automatic archival Disabled

Archive destination /opt/app/oracle/admin/demo/arch/arch.log Oldest online log sequence 3 Current log sequence 5 System Change Number, SCN es un dato que define la versin confirmada de la BD en este instante de tiempo. Cuando una transaccin es confirmada, se le asigna un SCN que la identifica unvocamente. Los ficheros redo log son marcados con dos SCN. Cuando se abre un nuevo fichero redo log se le marca con un SCN, low SCN, que es uno mas que el SCN mayor del anterior fichero redo log; y su high SCN es puesto a infinito. Los SCN tambin se asocian al fichero de control, ya que cuando se para una BD, un tablespace o fichero de datos, se almacena para cada fichero de datos su stop SCN en el fichero de control. Cambio de redo log es el proceso mediante el cual se deja de utilizar un fichero redo log y el LGWR combia al siguiente fichero redo log disponible. Se puede hacer con el comando alter system switch logfile;. Checkpoints son activados automticamente durante el funcionamiento normal de la instancia, pero pueden ser activados manualmente con el comando alter system checkpoint local o alter system checkpoint global dependiendo si nos referimos a la instancia en la que estamos, o si queremos que afecte a todas las instancias activas, respectivamente. Cada checkpoint lleva implicito un SCN, y Oracle asegura que todos los cmbios con un SCN menor que el del checkpoint dado han sido escritos en el disco.

3.2 Mtodos de Recuperacin

Existen varios mtodos de recuperacin, pero todos ellos se basan en la aplicacin de los registros de redo log. Aplicacin de Redo Log Cuando una BD se arranca con el comando startup, la BD pasa por los estados nomount, mount y open. En este tercer estado, se verifica que se pueden abrir todos los ficheros de log y de datos. Si la BD se arranca por primera vez despus de una caida, se necesitar efectuar una recuperacin que consiste en dos pasos: avanzar la BD hacia adelante aplicando los registros redo log, deshacer las transacciones no confirmadas.

Cada fichero de datos tiene en su cabecera el ltimo checkpoint efectuado, as como el fichero de control tambin lleva esa cuenta. El checkpoint lleva incluido el SCN. Este es conocido como SCN de inicio de fichero. Asociado a cada fichero de datos el fichero de control tiene el SCN de final, puesto inicialmente a infinito. El SCN de inicio se incrementa con cada checkpoint. Cuando la BD se para en modo normal o inmediato iguala el SCN de parada para cada fichero de datos al SCN almacenado en cada fichero de datos. Cuando se abre otra vez la BD se realizan dos comprobaciones. La primera es mirar si el contador de checkpoints en la cabecera de los ficheros de datos coincide con el correspondiente del fichero de control. Si es as, se compara el SCN de inicio de cada fichero de datos con el SCN de final almacenado en el fichero de control. Si son iguales no se necesita recuperacin en este fichero de datos. Como parte de la apertura se pone a infinito el SCN de final para ese fichero de datos. Si la BD se par con en modo abort no se ejecut el checkpoint y el SCN de fin para los fichero de datos est a infinito. As, durante la BD se abre, y suponiendo que el contador de checkpoints coincide, se comparan los SCN de inicio y de final, y como el ltimo es infinito se efectura una recuperacin aplicando los cambios almacenados en los ficheros redo log en lnea para avanzar la BD, y los registros de roll back de los segmentos de roll back para deshacer las transacciones no confirmadas. Si despus de parar la BD se reemplaza un fichero de datos por su copia de seguridad, al arrancar la BD Oracle detecta que el contador de checkpoints del fichero de datos no coincide con el almacenado en el fichero de control. As, se tendr que echar mano a los ficheros redo log archivados, empezando por aquel cuyo nmero de secuencia aparece en la cabecera del fichero de datos.

3.3 Recuperacin Fsica

La utilizacin de una copia de backup de ficheros de datos siempre necesita de una recuperacin fsica. Tambin es as cuando un fichero de datos se pone offline sin un checkpoint. Oracle detecta que se necesita una recuperacin fsica cuando el contador de checkpoints de la cabecera del fichero de datos no coincide con el correspondiente contador de checkpoints del fichero de control. Entonces se hace necesario el comando recover. La recuperacin comienza en el SCN menor de los ficheros de datos en recuperacin, aplicando los registros de redo log a partir de l, y parando en el SCN de final mayor de todos los ficheros de datos.

Existen tres opciones para realizar una recuperacion fsica. La primera es una recuperacin de BD donde se restaura la BD entera. La segunda es una recuperacin de tablespace donde, mientras una parte de la BD est abierta, se puede recuperar un tablespace determinado. Esto significa que sern recuperados todos los ficheros de datos asociados al tablespace. El tercer tipo es la recuperacin de un fichero de datos especfico mientras el resto de la BD est abierta. Requisitos para Utilizar Recuperacin Fsica La primera condicin que se ha de poner para poder recuperar fsicamente una BD es que sta se est utilizando en modo ARCHIVELOG. De otro modo, una recuperacin completa puede que no sea posible. Si trabajamos con la BD en modo NOARCHIVELOG, y se hace una copia semanal de los ficheros de la BD, se debera estar preparado para perder, en el peor de los casos, el trabajo de la ltima semana si sucede un fallo. Ya que los ficheros de redo log contendran un agujero y no se podia avanzar la BD hasta el intante anterior al fallo. En este caso el nico medio para reconstruir la BD es hacerlo desde un export completo, recreando el esquema de la BD e importando todos los datos. Recuperacin de la BD La BD debe estar montada pero no abierta. El comando de recuperacin es el siguiente: RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD] [UNTIL CANCEL] [UNTIL TIME fecha] [UNTIL CHANGE entero] [USING BACKUP CONTROLFILE] Las opciones entre corchetes son opcionales:

hace que la recuperacin se haga automticamente sin preguntar al DBA por el nombre de los ficheros redo log. Tambin se puede utilizar para este cometido el comando set autorecovery on/off. Los ficheros redo log deben estar en la localizacin fijada en LOG_ARCHIVE_DEST y el formato del nombre de los ficheros debe ser el fijado en LOG_ARCHIVE_FORMAT. FROM se utiliza para determinar el lugar donde estn los ficheros redo log, si es distinto del fijado en LOG_ARCHIVE_DEST.
AUTOMATIC

sirve para indicar que se desea realizar una recuperacin incompleta, lo que implica perder datos. Solo se dar cuando se han perdido redo log archivados o el fichero de control. Cuando se ha realizado una recuperacin incompleta la BD debe ser abierta con el comando alter database open resetlogs, lo que produce que los redo log no aplicados no se apliquen nunca y se inicialice la secuencia de redo log en el fichero de control. Existen tres opciones para parar la recuperacin: o UNTIL CANCEL permite recuperar un redo log cada vez, parando cuando se teclea CANCEL. o UNTIL TIME permite recuperar hasta un instante dado dentro de un fichero de redo log o UNTIL CHANGE permite recuperar hasta un SCN dado. o USING BACKUP CONTROLFILE utiliza una copia de seguridad del fichero de control para gobernar la recuperacin.
UNTIL

Recuperacin de un tablespace La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando de recuperacin es el siguiente: RECOVER [AUTOMATIC] [FROM 'localizacion'] TABLESPACE nombre_tablespace [, nombre_tablespace] Recuperacin de un Fichero de Datos La BD debe estar abierta o cerrada, dependiendo del fichero a recuperar. Si el fichero a recuperar es de un tablespace de usuario la BD puede estar abierta, pero con el fichero a recuperar offline. Si el fichero es deltablespace SYSTEM la BD debe estar cerrada, ya que no puede estar abierta con los ficheros del SYSTEM offline. El comando de recuperacin es el siguiente: RECOVER [AUTOMATIC] [FROM 'localizacion'] DATAFILE nombre_fichero [, nombre_fichero] Creando un Fichero de Control Si el fichero de control ha resultado daado y se ha perdido se puede utilizar una copia de seguridad del mismo o crear uno nuevo. El comando de creacin de un nuevo fichero de control es CREATE CONTROLFILE. Este comando se puede ejecutar

slo con la BD en estado nomount. La ejecucin del comando produce un nuevo fichero de control y el montaje automtico de la BD. Un comando interesante que ayuda a mantener los ficheros de control a salvo es el siguiente: SVRMGR> alter database backup controlfile to trace; que produce un script que puede ser utilizado para generar un nuevo fichero de control y recuperar la BD, en caso necesario. El fichero de traza generado es el siguiente: Dump file /opt/app/oracle/admin/demo/udump/demo_ora_515.trc Oracle7 Server Release 7.3.2.3.0 - Production Release With the distributed, replication and Spatial Data options PL/SQL Release 2.3.2.3.0 - Production ORACLE_HOME = /opt/app/oracle/product/7.3.2 System name: SunOS Node name: cartan Release: 5.5 Version: Generic Machine: sun4m Instance name: demo Redo thread mounted by this instance: 1 Oracle process number: 7 Unix process pid: 515, image: oracledemo Fri May 15 11:41:19 1998 Fri May 15 11:41:19 1998 *** SESSION ID:(6.2035) 1998.05.15.11.41.19.000 # The following commands will create a new control file and use it # to open the database. # No data other than log history will be lost. Additional logs may # be required for media recovery of offline data files. Use this # only if the current version of all online logs are available. STARTUP NOMOUNT CREATE CONTROLFILE REUSE DATABASE "DEMO" NORESETLOGS NOARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 2

MAXDATAFILES 30 MAXINSTANCES 1 MAXLOGHISTORY 100 LOGFILE GROUP 1 '/export/home/oradata/demo/redodemo01.log' SIZE 2M, GROUP 2 '/export/home/oradata/demo/redodemo02.log' SIZE 2M, GROUP 3 '/export/home/oradata/demo/redodemo03.log' SIZE 2M DATAFILE '/export/home/oradata/demo/system01.dbf', '/export/home/oradata/demo/rbs01.dbf', '/export/home/oradata/demo/rbs02.dbf', '/export/home/oradata/demo/rbs03.dbf', '/export/home/oradata/demo/temp01.dbf', '/export/home/oradata/demo/tools01.dbf', '/export/home/oradata/demo/users01.dbf' ; # Recovery is required if any of the datafiles are restored backups, # or if the last shutdown was not normal or immediate. RECOVER DATABASE # Database can now be opened normally. ALTER DATABASE OPEN;

3.4 Recuperacin Lgica

Oracle dispone de la herramienta import para restaurar los datos de una BD a partir de los ficheros resultados de un export. Import lee los datos de los ficheros de exportacin y ejecuta las sentencias que almacenan creando las tablas y llenndolas de datos. Parmetros del Import
Parmetro
USERID BUFFER FILE SHOW IGNORE

Defecto indefinido dependiente del SO expdat.dmp No Yes

Descripcin el username/password del usuario que efectua el import. El tamao en bytes del buffer utilizado. el nombre del fichero de exportacin a importar. indica si se muestran los contenidos del fichero de exportacin, sin importar ningn dato. indica si ignorar los errores producidos al importar un objeto que ya existe en la BD.

GRANTS INDEXES ROWS FULL FROMUSER TOUSER TABLES RECORDLENGTH INCTYPE COMMIT PARFILE

Yes Yes Yes No Indefinido Indefinido indefinido dependiente del SO indefinido No indefinido

indica si se importan tambin los derechos. indica si se importan tambin los ndices. indica si se importan tambin las filas de las tablas. indica si se importan el fichero entero. una lista de los usuarios cuyos objetos se han exportado. una lista de los usuarios a cuyo nombre se importan los objetos. la lista de tablas a importar. la longitud en bytes del registro del fichero. el tipo de import incremental (SYSTEM o RESTORE). indica si se efectua un commit despus de importar cada fila. Por defecto, import efectua un commit despus de cargar cada tabla. el fichero de parmetros.

Para importar un export incremental se puede efectuar la siguiente secuencia de pasos: 1. Utilizar la copia ms reciente del import para restaurar las definiciones del sistema: 2. 3. $ imp userid=sys/passwd inctype=system full=Y file=export_filename 4. Poner los segmentos de rollback online. 5. Importar el fichero de exportacin completa ms reciente: 6. 7. $ imp userid=sys/passwd inctype=restore full=Y file=filename 8. Importar los ficheros de exportacin en modo acumulacin desde la exportacin completa ms reciente, en orden cronolgico: 9. 10. $ imp userid=sys/passwd inctype=restore full=Y file=filename 11. Importar los ficheros de exportacin en modo incremental desde la exportacin completa o acumulativa ms reciente, en orden cronolgico: 12. 13. $ imp userid=sys/passwd inctype=restore full=Y file=filename

METODOS DE RESPALDO Y RECUPERACION

Oracle ofrece varios tipos de respaldo para la informacin; entre ellos no existe un mtodo que sea el ms ptimo para todas las organizaciones, debido a que son muchos los factores que inciden y se deben evaluar para determinar cual es el mejor procedimiento para determinado escenario de recuperacin. Cada mtodo de respaldo cumple funciones definidas, es por ello que se debe conocer muy bien la Base de Datos, la carga transaccional y la criticidad de la informacin entre otros para determinar el tipo de respaldo que necesita cada organizacin. EXPORT E IMPORT Es uno de los ms usados por los clientes de Oracle por su flexibilidad y portabilidad y solo se puede hacer si la Base de Datos esta abierta;

Ventajas

Selectividad muy alta: se puede respaldar desde una tabla de la base de datos hasta toda la informacin almacenada en ella. Si se desea se pueden guardar nicamente las estructuras de los objetos, los triggers, los constraints etc. Esta misma selectividad funciona al restaurar la informacin posteriormente desde el Backup. Portabilidad: Un archivo de "export" puede ser exportado de y desde cualquier sistema operativo que soporte Oracle7 o superior y ser importado en y desde cualquier sistema operativo con la ayuda de SQL*Net (herramienta de conectividad de Oracle). Herramienta de Reorganizacin: una vez hecho un "export ", al restaurar los datos con el "Import" correspondiente se pueden relocalizar los objetos en otros tablespaces o si se quiere se pueden cambiar sus parmetros de almacenamiento; tambin permite crear los ndices por separado acelerando el tiempo del import y cambiar de esquema (usuario dueo) los objetos si quien los importa posee los privilegios suficientes. Permite recuperar informacin perdida por errores de usuario o del servidor como son: drops, truncates, deletes, corrupcin de registros en tablas, perdida de tablas al perderse el tablespace o la base de datos, borrado de objetos y por ende su definicin entre ellos triggers, constraints etc.

Desventajas

Tamao y tiempos impredecibles: es muy difcil predecir el tamao que tendr un archivo de "export" al igual que el tiempo que durar el mismo o

en su defecto el import. Puede que se requiera pasar todo el archivo de export para importar solo una parte: debido al recorrido secuencial para realizar un import, si el objeto buscado esta al comienzo del archivo se detiene despus de importarlo, pero si est al final tiene que recorrer todo el archivo para recuperar solo ese(os) objeto(s). 2. RESPALDOS EN FRIO (Cold backup)

Es un mtodo de respaldo muy restrictivo, y debe hacerse nicamente cuando la base de datos este cerrada. Es til en el evento de perdida total de la base de datos. Ventajas: La consistencia de datos est garantizada: No se da el caso de que los datos a ser respaldados estn siendo usados por algn usuario por que ellos no pueden acceder a la base de datos. Todo incluido: Este tipo de respaldo incluye todos los Datafiles, los Controlfiles, y los Logfiles; no hay posibilidad de que alguna tabla o vista no quede en el backup. El espacio que ocupa es conocido, adems el tiempo de respaldo y recuperacin es predecible. Desventajas: Nada excluido: esto se convierte en una desventaja cuando no se desea restaurar toda la informacin. Aqu no se permiten hacer respaldos ni restauraciones parciales, es decir "se respalda todo o nada y se restaura todo o nada"; Solo se puede hacer con la base de datos cerrada: nadie puede estar trabajando.

3. RESPALDOS EN CALIENTE (Hot Backup)

Este tipo de respaldo es especialmente utilizado en organizaciones en las cuales la base de datos necesita estar disponible durante las veinticuatro horas y los siete dias de la semana. Los respaldos en caliente son una consecuencia de una funcionalidad de Oracle llamada el modo "ARCHIVE". Este modo consiste en configurar algunos parmetros de la base de datos para que se registren todos los cambios hechos a la misma por mnimos que sean en unos archivos llamados "REDO LOGS". Oracle lleva un histrico del orden de los Redo Logs (y por ende de las transacciones realizadas a la base de datos) y cuando hay necesidad de restaurar informacin, lo hace consistentemente y deja la base de datos como estaba hasta el momento en el cual las fallas ocurrieron o hasta el punto en el tiempo que el cliente lo desee; esto se hace restaurando un cold backup y aplicando los Redo Logs

(transacciones) ocurridas a partir de ese backup hasta una fecha y hora determinada que se necesite. De esta forma se obtiene una fotografa exacta y consistente de cmo estaba la base de datos en un da y hora determinados. Ventajas

Selectivo a nivel de tablespace: Se respaldan todos los datafiles (archivos fsicos de datos) de un tablespace completo y por ende todos los objetos almacenados en l. No interfiere con la operacin normal de la base de datos en produccin: no hay necesidad de cerrar la base de datos y los usuarios pueden estar trabajando. Se puede recuperar hasta cualquier punto en el tiempo: si se respaldan los Redo Logs suficientes y se mantienen respaldos en fro o calientes anteriores, se puede recuperar informacin en cualquier fecha y hora especificados. Siempre recupera de manera consistente: es la nica manera de recuperar la informacin.

Desventajas

La consistencia es forzosa: si se recupera toda la informacin no hay espacio para hacer modificaciones, selecciones o adecuaciones. Si se desea recuperar un objeto, no importa que haya sufrido o cual objeto sea, se deben recuperar todos los archivos de datos "datafiles" en donde ese objeto resida hasta el momento cuando la base de datos quede consistente. Es necesario mantener todos los Redo Logs archivados: Si por alguna razn un Redo Log archivado se pierde, no se podr recuperar la base de datos mas all del ltimo Redo Log antes del cual se perdi. Se necesitan recursos importantes de disco para almacenar todos los Redo Logs, adems de una administracin cuidadosa con polticas para bajar estos archivos a cinta en horas determinadas y para relacionar en alguna parte informacin como el numero de la cinta, la fecha, la hora, de que numero a que numero de Redo Log se bajo y la persona que realiz la labor.