4. Recuperación Manual

Transcripción

1 4. Recuperación Manual Un backup físico es una copia de los archivos físicos de la base de datos, que puede ser realizado de dos maneras diferentes. Una es a través de una herramienta llamada Recovery Manager (RMAN) provista por Oracle. La otra forma es a través de operaciones realizadas manualmente por el usuario (DBA) ó backup NO RMAN. En este capítulo vamos a ver el funcionamiento de este último modo de realizar backups. El backup manual se ha utilizado por años para la realización de copias de respaldo de las bases de datos Oracle. Los scripts del sistema operativo de backup son una solución muy flexible y detallada y, por lo general, suele venir integrada a herramientas particulares ó de terceras partes. Este tipo de backup consiste en un backup realizado por el sistema operativo a través de un lenguaje del tipo scripting secuencia de comandos como ser Korn Shell ó Bourne Shell para ambientes Unix ó comandos batch para ambientes Windows. A pesar que el backup manual se ha utilizado históricamente, en la actualidad se está marcando la tendencia que en las grandes bases de datos Oracle están utilizando RMAN para las tareas de backup. Es por esto que la utilidad RMAN está extendiendo sus capacidades y su operatibilidad de multiplataforma. De todas maneras, el backup manual sigue siendo una herramienta útil para un DBA. Adicionalmente, se puede utilizar para el entrenamiento del DBA, para que logre un entendimiento de los fundamentos del backup físico.

2 4.1 Backup Manual En la figura se presenta una clasificación de los contenidos tratados en esta subunidad, teniendo en cuenta, la relación de los mismos con el Material del Estudiante (kit). Esta clasificación sugiere diferentes momentos de lectura, estudio y revisión, entre los contenidos de este currículo y el Material del Estudiante (Kit). Según esta clasificación los contenidos pueden ser de: Lectura Previa: Se sugiere la lectura de estos contenidos antes de abordar los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Complementaria: Se sugiere la lectura de estos contenidos como complemento a los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Adicional: Se sugiere la lectura posterior de estos contenidos, como material adicional a los tratados en el Material del Estudiante (Kit). Prácticas : Actividades de laboratorios e interactivas incluidas como práctica adicional al Material del Estudiante (Kit).

3 4.1 Backup Manual Objetivos En este capítulo tenemos como meta que usted llegue a conocer en profundidad, al concepto backup; para ello pretendemos que pueda describir el backup y la recuperación manual; discutir las tareas de backup y saber realizarlas, tanto en bases de datos cerradas como en las abiertas. Otro punto importante es que pueda realizar copias de los Archivos de Control ó Control File; que usted sepa que en caso de fallos del backup, es propicio realizar tareas de limpieza y posteriormente, que conozca cómo verificar esas tareas recién mencionadas.

4 4.1 Backup Manual Cuestionario de Iniciación

5 4.1 Backup Manual Conceptos Iniciales Como se mencionó anteriormente, cada sitio puede personalizar sus tareas de backup y recuperación manual para suplir diferentes necesidades. Esta personalización es posible debido al tipo de tarea, que es generalmente por scripting escrito en el sistema operativo. Como resultado se puede obtener un script con operaciones de backup ó recuperación en forma detallada de las operaciones deseadas. Trabajar de esta manera tiene beneficios y desventajas. La habilidad de poder personalizar la tarea de backup puede llevar a que en momentos de verificación cause algún error y, por más pequeño e insignificante que sea, podría invalidar todo el proceso de backup ó recuperación. A pesar de estos posibles efectos adversos, los backups manuales se han estado utilizando por años en los ambientes Oracle, con lo que con el paso de su utilización en estos años se obtuvieron habilidades y tareas muy refinadas donde se aplica todo el conocimiento de las copias de seguridad al detalle. Es por esto que todo DBA debería estar muy familiarizado con este tipo de tareas ya que este conocimiento le permitirá tomar la decisión correcta en caso de algún tipo de falla, ya sea por backup manual ó por la utilidad RMAN. Adentrándonos en la terminología de estas tareas, encontramos: Backup Completo de la base de datos. Se refiere a un backup que incluye todos los archivos físicos de una base de datos. Este tipo de backup se puede hacer tanto en el modo ARCHIVELOG como en el modo NOARCHIVELOG. Antes de tomar la decisión de hacer una tarea de este tipo, se deben tomar ciertas consideraciones. Si está en modo NOARCHIVELOG, el backup siempre se debe hacer con la base de datos detenida y, por lo tanto, se obtiene como resultado un backup consistente. Por lo contrario, si se opera en modo ARCHIVELOG, las operaciones de backup se pueden hacer ya sea con la base de datos abierta ó cerrada. Si el backup se realiza con la base de datos cerrada correctamente, entonces se tendrá un backup consistente, pero si el backup se toma cuando la base está operando, los tablespaces se deben poner en estado de backup. Este backup es inconsistente pero válido si se tiene los archivos Redo Log Archivados que se generaron en el momento de los tablespaces en modo backup. En otras palabras, los archivos Redo Log Archivados hacen que el backup inconsistente sea consistente. La Figura muestra las distintas alternativas que se pueden realizar con el backup manual. Un Backup de un Tablespace es un backup tomado de un tablespace en particular o sea de los Archivos de Datos ó Data Files que lo componen. Para poder realizar esta tarea, es necesario que la base de datos esté operando en modo ARCHIVELOG. Por lo tanto un Backup de un Data File puede hacerse con la base abierta (en modo ARCHIVELOG) ó con la base cerrada (en modo NOARCHIVELOG) Finalmente se puede realizar copias de seguridad de los Archivos de Control ó Control Files de la misma manera, ya sea por RMAN ó manualmente.

6

7 4.1 Backup Manual Planificación del Backup Antes de comenzar con las tareas de backup manual, posiblemente se requiera información sobre el estado actual y los objetos a resguardar. Esto se realiza consultando una serie de vistas dinámicas del diccionario de datos de la base de datos, como ser: V$DATAFILE muestra información sobre los archivos de datos ó Data Files, incluyendo su ubicación física y estado V$CONTROLFILE hace lo mismo pero para los Archivos de Control ó Control Files. La vista V$LOGFILE obtiene información sobre los archivos Redo Log La vista V$TABLESPACE está relacionada con la vista V$DATAFILE, ya que se puede obtener información sobre los archivos de datos y del tablespace que las contiene lógicamente.

8 4.1 Backup Manual Tipos de Backup Es posible resguardar la base de datos contra pérdidas de información debido a fallos en el medio físico eligiendo el método de backup más apropiado en función de los requerimientos y disponibilidades del negocio. Una de las alternativas es la realización de backups en forma manual, las cuales pueden hacerse con la base de datos abierta ó cerrada. Entonces los métodos de backup físico pueden ser: Backup del sistema operativo sin utilizar las características de archivado, en donde se recuperará hasta el punto del último backup realizado correctamente, es decir, sea consistente y válido. Backup del sistema operativo utilizando las funcionalidades del archivado ó modo ARCHIVELOG, en donde las posibilidades de recuperación de los datos es al momento anterior de producirse la falla.

9

10 4.1 Backup Manual Backup en Frío Como se comentó en capítulos anteriores, cuando se realizan tareas de backup una vez que la base de datos se cerró correctamente, se suele decir que se realizó un backup offline ó un backup en frío ó un backup con la base de datos cerrada. Entonces la copia de los Archivos de Datos ó DataFile debe ser realizada por comandos de copia del sistema operativo ó alguna utilidad no-oracle. Si la base de datos está operando en modo NOARCHIVELOG, entonces los cambios hechos después de haber realizado el backup, no estarán disponibles hasta el próximo backup serán datos irrecuperables ante fallos. Esto quiere decir que la recuperación sólo podrá ser posible al momento del último backup realizado correctamente. En cambio, si se está operando en modo ARCHIVELOG, a medida que los archivos Redo Log se van completando, su contenido se copia a un archivo Redo Log Archivado. Con lo que durante un fallo, si se pierden archivos de datos, se necesita hacer una recuperación de estos archivos; volviendo a tener los datos del momento anterior a la falla. Si se está ejecutando la base de datos en modo NO ARCHIVELOG, el único momento en que es posible recuperar todas las transacciones confirmadas después de una falla es cuando los archivos Redo Log no se han sobrescrito por el proceso LGWR desde la última vez que la base de datos se abrió. Luego de ese momento, no es posible este tipo de recuperación en este modo de operación. Las ventajas de un backup en frío son que es una tarea fácil de realizar y se puede automatizar muy bien. Ésta es una manera limpia y simple de realizar backups. Como se está realizando las copias con la base de datos cerradas, se asegura una copia consistente de la base de datos. Por otro lado, las desventajas de este tipo de backup, es que se debe tener la instancia cerrada de la base de datos, lo que afecta directamente a la disponibilidad de la misma. Otra desventaja es el tiempo que lleva la recuperación de la base de datos en caso de falla, el cual va a depender de los siguientes factores: Tamaño de la base de datos. La tasa de transferencia en el proceso de restauración de los archivos físicos. La Figura 1 muestra un esquema de la realización de un backup en frío, donde se puede ver la ejecución de los siguientes pasos: 1. Consultar las vistas del diccionario de datos para identificar la ubicación y nombre de los archivos físicos que forman parte de la base de datos. (V$DATAFILE, V$CONTROLFILE y V$LOGFILE) 2. Detener la instancia de la base de datos normalmente, esto es, utilizando alguna de las siguientes opciones: NORMAL, IMMEDIATE ó TRANSACTIONAL 3. Ejecutar los comandos del sistema operativo para copiar los archivos físicos al destino definido para las copias. Adicionalmente copiar también los archivos de parámetros, password y cualquier otro archivo asociado a la base de datos. Iniciar la instancia normalmente.

11 4.1 Backup Manual Backup en Caliente Si la disponibilidad de la base de datos tiene un impacto drástico en las operaciones de negocio y no es factible detener la instancia para operaciones de backup en frío, Oracle recomienda realizar el backup en forma ONLINE, también llamado backup abierto (open) ó backup en caliente. Para realizar un backup en caliente, se requiere que la base esté operando en modo ARCHIVELOG, con lo que se tendría una copia válida pero inconsistente pero que junto a los archivos Redo Log Archivados tendría el mismo valor que una copia consistente. Una de las características de los backup en caliente es que sólo necesitan copiar los archivos de dato (DataFiles) y el archivo de control (ControlFile) actual, con lo que los archivos Redo Log no requieren ser copiados. Contrariamente a los backup en frío, que requieren copiar todos los archivos de la base de datos, la unidad de backup de un backup en caliente se reduce a los tablespaces. Entonces un backup en caliente incluye los Archivos de Dato de un tablespace, el Archivo de Control Actual y todos los archivos Redo Log Archivados generados en el proceso del backup. Todos los archivos Redo Log Archivados generados después del backup, son necesarios para operaciones de recuperación completa. La principal ventaja del backup en caliente, si lo comparamos con el backup en frío, es la disponibilidad frente a los usuarios finales mientras se realizan tareas de backup y recuperación. Otra ventaja es que los Archivos de Datos no necesariamente se tienen que copiar al mismo tiempo es posible realizar backups parciales. La Figura muestra la forma de realizar un backup en caliente: 1. Inicialmente se debe consultar el diccionario de datos de la base de datos a través de la vista dinámica V$DATAFILE para obtener información sobre la ubicación y el nombre de los Archivos de Datos (Data Files). 2. Utilizar el comando SQL para poner el tablespace que se desea copiar en estado de backup: ALTER TABLESPACE system BEGIN BACKUP; Notar que si se olvida de poner un tablespace en modo backup ó si accidentalmente finaliza este modo antes que concluya el backup, entonces el backup realizado será inválido y no se podrá utilizar para recuperaciones. Si esto ocurre, se debe regresar al paso 2 3. Realizar las copias de los Archivos de Datos con comandos del sistema operativo 4. Ejecutar el comando SQL para volver a poner el estado del tablespace copiado en ONLINE (fuera del modo backup) ALTER TABLESPACE system END BACKUP; 5. Ejecutar el comando SQL para archivar el archivo Redo Log actual. Esta tarea se asegura que los archivos Redo Log Archivados tienen la operación END BACKUP archivada para la recuperación. 6. Copiar todos los archivos Redo Log Archivados generados hasta el paso Repetir los pasos 2 al 6 para cada tablespace que se desee resguardar. 8. Ejecutar el siguiente comando SQL para copiar el archivo de control de la base de datos: ALTER DATABASE BACKUP CONTROLFILE TO d:\orabup\control.bkp. Por más que sería posible poner todos los tablespaces en modo backup para copiar todos los Archivos de Datos en forma paralela, las consecuencias de esto es que se generaría mucha cantidad de información Redo si muchos usuarios están haciendo actualizaciones. Oracle recomienda utilizar este backup en forma serializada, es decir, de a un tablespace por vez. De esta manera se minimizaría el tiempo entre las operaciones de BEGIN y END BACKUP.

12

13 4.1 Backup Manual Comportamiento de los Tablespaces Cuando se están efectuando tareas de backup sobre un tablespace en particular, puede ocurrir que se produzca una falla que ocasione el cierre inesperado de la instancia. Si esto ocurre se podrían dar las siguientes situaciones: Que los archivos copiados sean inutilizables porque el sistema operativo no terminó con el proceso de copia, con lo que se deberá iniciar el backup nuevamente. Que los archivos que se estaban copiando no estén sincronizados con la base de datos, porque los encabezados quedaron congelados por el comando BEGIN BACKUP Que la base de datos no abra porque Oracle Server asuma que los archivos fueron restaurados de un backup. Para solucionar los dos últimos problemas, se debe utilizar el comando ALTER DATABASE END BACKUP para sacar los tablespaces del modo backup. Si no está seguro del origen de los archivos de la base de datos, adicionalmente se puede consultar la vista del diccionario de datos V$BACKUP, para obtener información sobre los archivos (si necesitan recuperación o no). Otra opción en cuanto a backup de tablespaces es la realización de backup de un tablespace en modo Read-Only. El principal propósito de los tablespaces Read-Only es el de eliminar la necesidad de escritura en los Archivos de Datos. El estado Read-Only habilita al usuario a eliminar objetos como ser tablas ó índices, pero no permite la creación ó modificación de tales objetos. Para poner un tablespace en modo Read Only, se debe ejecutar el siguiente comando: ALTER TABLESPACE oratest READ ONLY. Este comando inicia un proceso checkpoint para todos los Archivos de Datos (Data Files) pertenecientes al tablespace modificado. Cuando se necesitan hacer tareas de backup, simplemente se requiere hacer copias directas de los Archivos de Datos, sin necesidad de poner el tablespace en modo backup.

14 4.1 Backup Manual Archivos de la Base de Datos Como es sabido, el archivo de control contiene información vital de la base de datos, incluyendo su estructura. El archivo es abierto por Oracle Server en el momento de montaje de la base de datos y es constantemente utilizado a medida que se utiliza la base de datos. El archivo de control es actualizado cuando ocurre un cambio estructural en la base de datos ó cuando ocurre un proceso checkpoint. Cuando se produce un cambio en la estructura de la base de datos, es requerido realizar un backup del archivo de control. Si por algún motivo se pierden todos los archivos de control de esa base de datos, es posible utilizar una copia ó generar un archivo de control nuevo. Existen dos maneras de hacer un backup del archivo de control. La primera es hacer un backup del archivo de control a un archivo binario. Este es un método definido de las versiones anteriores para este tipo de backup: ALTER DATABASE BACKUP CONTROLFILE TO d:\bup\control.bkp ; La segunda opción es hacer un backup del archivo de control a un archivo TRACE. Esta opción es más útil para la creación de un nuevo archivo de control: ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

15

16 4.1 Backup Manual Controlando el Estado del Backup La herramienta DBVerify es una utilidad externa que opera por línea de comandos provista por Oralce, que puede ser utilizada para chequear la integridad de los archivos físicos de una base de datos. Esta utilidad le da la seguridad al DBA, que el backup realizado es válido antes que se requiera una recuperación. También es utilizada para diagnosticar errores de ceración de archivo. Los chequeos se limitan a los bloques de datos de los Archivos de Datos, con lo que esta herramienta sólo sirve para verificar Archivos de Datos, y no Archivos de Control, ni archivos Redo Log. La utilidad se ejecuta con el comando dbv en la línea de comandos. Esta herramienta tiene seis parámetros que se pueden especificar en tiempo de ejecución, como se ve en la tabla de la Figura 1.

17 4.1 Backup Manual Lectura Adicional: Casos de uso de Backup En este apartado vamos a plantear un escenario posible donde se comenta la utilización de un backup de un solo datafile en frío y la utilización de un backup en caliente: EL DBA de una empresa textil es el encargado de la realización de los backup de la base de datos de producción. La base de datos debe estar disponible 24 x 5 de lunes a viernes. La estrategia de backup involucra un backup en frío los días sábado suplementado por un backup en caliente todas las noches. El lunes a la mañana el DBA se da cuenta que necesita agregar un Data File más al tablespace de producción. Actualmente el tablespace de producción (T1) pesa 50 GB y el archivo a agregar requiere un tamaño de 1 GB. El DBA una vez que agregó el nuevo datafile procedió de la siguiente manera: 1. Ejecutó el comando ALTER DATABASE DATAFILE <nombre datafile> OFFLINE 2. Realizó la copia de sólo ese datafile con comandos del sistema operativo 3. Ejecutó el comando ALTER DATABASE DATAFILE <nombre datafile> ONLINE 4. Realizó un backup del Archivo de Control con el nuevo cambio de la estructura. Con el paso del tiempo se decide cambiar la estrategia de backup en donde se deben realizar backups parciales de la base de datos de todos los tablespaces que involucran la producción (T1, T2 y T3) cada noche. Esto significa tomar un backup online ó caliente del tablespace T1 los lunes, de T2 los martes y de T3 los miércoles y completando el ciclo con T1 los jueves, T2 los viernes, T3 los sábados y así sucesivamente, con lo que se sabe que cada tres días se tiene un backup completo de la base de datos, y no la base completa como ocurre en el backup en frío de los sábados. El día viernes ocurre una falla en el medio físico una vez que termina el backup de ese día (T2) y se pierden todos los archivos de datos. El DBA necesita restaurar los archivos de la base de datos de los backups. En ese momento el DBA cuenta en las cintas de backup los backup de los tablespaces T1 y T2, puesto que T3 está programado para el día siguiente, con lo que necesitará utilizar la última copia válida de T3 que fue el miércoles pasado a la noche. Esto significa que el DBA también debe restaurar todos los archivos Redo Log Archivados desde el miércoles a la noche. En este escenario se puede ver un caso de recuperación con backups parciales (Archivos de Datos resguardados en momentos distintos) donde se comienza con un Archivo de Datos más viejo que los actuales. Para que la recuperación termine con éxito, el DBA debió tener resguardados todos los archivos Redo Log Archivados del último backup válido. Adicionalmente, se debe asegurar que periódicamente se realicen los backups en frío.

18 4.1 Backup Manual EI: Verdadero / Falso Indentificar las afirmaciones verdaderas.

19 4.1 Backup Manual Síntesis Los backups manuales fueron los más utilizados en mucho tiempo por implementaciones Oracle. Este tipo de backup principalmente consiste en comandos del sistema operativo, como puede ser los del shell Korn en Unix ó los script batch en los ambientes Windows. También es posible integrarse a herramientas de backup de terceras partes. Los fundamentos de resguardar los datos de una base de datos Oracle se pueden ver claramente cuando se analiza este tipo de backup los backup manuales. Algunas de las técnicas utilizadas en los backup en caliente ó abiertos ú online, son utilizadas también en los backup en frío ó cerrados ú offline. Si se tiene un sólido entendimiento sobre estos conceptos, entonces claramente se comprenderá el funcionamiento de la herramienta que se incorpora a partir de Oracle 8, que es Recovery Manager (RMAN).

20 4.2 Recuperación Manual En la figura se presenta una clasificación de los contenidos tratados en esta subunidad, teniendo en cuenta, la relación de los mismos con el Material del Estudiante (kit). Esta clasificación sugiere diferentes momentos de lectura, estudio y revisión, entre los contenidos de este currículo y el Material del Estudiante (Kit). Según esta clasificación los contenidos pueden ser de: Lectura Previa: Se sugiere la lectura de estos contenidos antes de abordar los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Complementaria: Se sugiere la lectura de estos contenidos como complemento a los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Adicional: Se sugiere la lectura posterior de estos contenidos, como material adicional a los tratados en el Material del Estudiante (Kit). Prácticas : Actividades de laboratorios e interactivas incluidas como práctica adicional al Material del Estudiante (Kit).

21 4.2 Recuperación Manual Objetivos En este capítulo pretendemos que usted esté capacitado para describir los medios de recuperación; además de que pueda ejecutar la recuperación completa, tanto en modo NOARCHIVELOG, como en modo ARCHIVELOG. También esperamos que sepa cómo restaurar Archivos de Datos en distintas ubicaciones y cómo recuperar tablespaces usando los archivos Redo Log Archivados. Por último, aspiramos a que usted llegue a conocer la recuperación de un tablespace en modo Read-Only.

22 4.2 Recuperación Manual Cuestionario de Iniciación Coloque el cursor sobre los botones numerados que aparecen a la izquierda para visualizar las preguntas de iniciación. Si desea, puede desplegar su respuesta.

23 4.2 Recuperación Manual Conceptos Iniciales La Recuperación del Medio Físico ó Media Recovery es un tipo de recuperación utilizado para recuperar cualquier tipo de archivo físico de la base de datos, ya sea un Archivo de Datos, un Archivo de Control ó un Archivo Redo Log que, por algún motivo, deja de estar disponible. Cuando ocurre una situación donde es necesario hacer tareas de recuperación, el DBA debe restaurar el archivo dañado (obtener la copia correcta del backup) para su recuperación (aplicar las transacciones necesarias para dejarlo válido). Una de las decisiones que debe tomar un DBA, con respecto al backup y a la recuperación es, como se hablo en temas anteriores, determinar si va a operar en modo ARCHIVELOG ó NO ARCHIVELOG; esto va a depender de: NOARCHIVELOG - La pérdida de información entre backups es tolerada. - Las transacciones a aplicar son rápidas. - No es muy probable que los datos cambien (Datawarehouse). ARCHIVELOG - No es posible detener la instancia para realizar el backup. - No se tolera la pérdida de información entre backups. - El ambiente transaccional es alto (OLTP). Cuando la base de datos se encuentra operando en modo ARCHIVELOG, significa que está generando información histórica sobre los cambios ocurridos en la base de datos, almacenándolos en los archivos Redo Log Archivados. Estos Logs pueden ser aplicados a archivos restaurados de un backup, recuperando de esta manera la base de datos al momento de la falla. La Figura 1 muestra un esquema de una recuperación en modo ARCHIVELOG. En cambio, si la base de datos está operando en modo NOARCHIVELOG, al no tener este tipo de información histórica, se tendrá como resultado que, no contará con archivos Redo Log Archivados y en consecuencia, será necesario realizar una recuperación completa volviendo a la información que cuenta el archivo de backup y necesitando que los cambios desde ese backup se vuelvan a aplicar en forma manual. La Figura 2 muestra un esquema de operación en este modo.

24

25 4.2 Recuperación Manual Recuperación en Modo NO Archive Log En este ítem se plantea un ejemplo de una recuperación. En este caso, la base de datos está disponible las 24 hs de lunes a viernes. Todos los sábados la base de datos es detenida para realizarse un backup completo (backup en frío) de la base de datos. Cuando se completa esta tarea, la base de datos es vuelta a iniciar. La estrategia de backup plantea que la base de datos opere en modo NO ARCHIVELOG. Al momento del inicio, se recibe el error que muestra la Figura 1. Con lo que el DBA se da cuenta que se perdió el datafile 4. En este caso, al operar en modo NO ARCHIVELOG, se debe hacer una recuperación de la base de datos de la semana anterior. Al no contar con los archivos Redo Log Archivados, una vez recuperada la base, se tendrá que volver a cargar la información de toda la semana anterior. Para realizar las tareas de recuperación, es necesario restaurar primero las copias de la cinta de backup de los Archivos de Datos, Control y Redo Log y realizar una recuperación completa. La Figura 2 muestra la secuencia realizada para esta operación. La observación más notable en este escenario cuando se está operando en modo NO ARCHIVELOG es la pérdida de información. Todos los datos ingresados después del backup y antes del momento de la falla deben ser vueltos a cargar. A demás es necesario realizar una recuperación completa de la base de datos, lo que incremente el tiempo de recuperación (MTTR Mean Time To Recover).

26

27 4.2 Recuperación Manual Recuperación en Modo Archive Log Al hablar del funcionamiento de una base de datos en modo ARCHIVELOG, se espera que su disponibilidad sea alta. En términos de la recuperación, se introducen dos nuevos conceptos, Recuperación del Medio Físico Completo e Incompleto. Una recuperación completa significa que no se producirá pérdida de datos. Independientemente del método utilizado para la recuperación, si se recuperan todos los datos, se habrá realizado una recuperación completa. Oracle brinda la capacidad de recuperar toda la base ó solamente un tablespace o archivo de datos; dependiendo del tipo de falla. Para realizar una recuperación completa es necesario restaurar los archivos involucrados al momento en que se produce la falla. La Figura muestra los archivos necesarios para una recuperación completa. Una recuperación incompleta significa que luego de la recuperación se perderán datos. En otras palabras, la información Redo no se aplica. Esta situación se suele dar en los siguientes casos: Un fallo en el medio físico destruye alguna ó todas las copias de los archivos Redo Log Archivados. Un error genera pérdida de la información, como ser el borrado involuntario de una tabla. Para realizar una recuperación incompleta, es necesario restaurar todos los Archivos de Datos del backup y recuperar un punto específico en el tiempo, antes del momento de la falla y, finalmente, abrir la base con la palabra clave RESETLOGS, con lo que no se aplicarán todas las transacciones ya que resetea los archivos Redo Log Online a 1. Es una meta del DBA, tratar siempre de hacer una recuperación completa. Si se toman los recaudos necesarios, como multiplexar los archivos Redo Log Archivados y los Archivos de Control y se tiene una correcta estrategia de backup, se debería ser capaz de poder realizar recuperaciones completas en todos los casos de fallos. La recuperación incompleta debería ser una última opción.

28 4.2 Recuperación Manual Recuperación Completa Como se comentó en capítulos anteriores, es tarea del DBA reducir al máximo el MTTR, para lo cual se requiere una estrategia acorde y probada. Cuando se presenta el caso de necesitar hacer una recuperación completa, existen dos opciones: La primera es una recuperación completa de la base de datos mientras se encuentra abierta; este tipo de recuperación se llama Online Recovery. La segunda alternativa es realizar la misma operación pero con la instancia de la base de datos en estado MOUNT, o sea, con la base de datos cerrada; esta tarea se la denomina Offline Recovery. Por ejemplo, si una base de datos tiene 20 tablespaces y el tablespace 5 solamente se daña, no tiene sentido hacer una recuperación offline. Se debería hacer una recuperación completa online siguiendo los pasos que se muestran en la Figura 1. Oracle provee distintos mecanismos para la recuperación, permitiendo a través de los comandos Sql*Plus RECOVER recuperar objetos específicos de la base de datos: RECOVER DATABASE, este comando puede ser utilizado solamente en una recuperación offline. RECOVER DATAFILE <archivo de datos> este comando puede ser utilizado tanto en una recuperación offline como online. RECOVER TABLESPACE <nombre tablespace> este comando puede ser utilizado solamente en una recuperación online.