Objetivos del curso:

 Proveer al alumno las conocimientos necesarios para la definicion de una estrategia de respaldo y de recuperacion
valida y completa ante la mayor cantidad de desastres.
 Ofrecer una guia visual de los pasos a seguir para que los procesos de recuperacion sean lo mas rapidos y con el
menor esfuerzo posible.
 Tener las practicas necesarias en ambientes controlados para este tipo de recuperacion
 Evacuar cualquier pregunta o duda correspondientes a las tareas de respaldo y recuperacion de BD.

TEMARIO CURSO DE ORACLE AVANZADO (BACKUP Y RESTAURACION)

VISION GENERAL DE LA COPIA DE SEGURIDAD Y RECUPERACIÓN DE LA BBDD

Recuperacion y Respaldo de Bases de datos Oracle se refiere a la teoria de proteger una Base de datos de produccion en
contra perdidas y poder recuperar con éxito los datos de la instancia despues de la restauracion. Las razones de las caidas
pueden ser muchas: problemas tecnicos o por errores logicos producidos por los usuarios en la operación de los sisteamas,
tambien porque los administradores puedan borrar los archivos equivocados.

El concepto de respaldo y recuperacion es el conjunto de estrategias y guias paso a paso para poder hacer la restauracion de
los datos en el menor tiempo posible con la menor cantidad posible de perdidas de informacion. En el mundo ideal nunca
deberian de haber perdidas de datos o caidas de sistemas, sin embargo, siempre existe el riesgo de error ya sea humano o por
problemas en los equipos y/o cualquiera de sus componentes.

En nuestra vida practica como Administradores de Bases de Datos siempre estamos a cargo de administrar y mantener las
instancias, monitorear y afinar el rendimiento, pero tambien tenemos que agregarles una serie de metas realistas a cumplir:

 Proteger las BD (y la informacion) contra la mayor cantidad posibles de fallas.

 Incrementar el tiempo entre fallas.
 Decrementar el tiempo real de recuperacion.
 Minimizar la perdida de datos cuando haya una recuperacion.

RMAN es la manera principal de proteccion de una BD Oracle, ya toda la utilidad se encuentra embevida dentro del codigo, no
se tienen que pagar cargos adicionales por su uso. Fue inicialmente introducido en la version 8 de Oracle y a partir de ahí ha
tenido muchas mejoras hasta el punto de ser considerado la herramienta mas poderosa para respaldar y recuperadad BD
Oracle. Durante el curso exploraremos las formas tradicionales de respaldo y recuperacion de Bases de datos Oracle y tambien
utilizaremos RMAN para completar nuestra politica de Respaldo y Recuperacion.

Tipos De Fallos

Ya que los respaldos estan diseñados para proteger por fallas en las BD, rapidamente explicaremos los tipos de fallos que
pueden ocurrir. Muchas restauraciones se pueden hacer sin mucho esfuerzo por parte del administrador, ya que el motor
incluye procesos de recuperacion automaticos a partir de ciertos tipos de fallas, pero los mas criticos tipos de fallas requiere la
intervension del adminitrador para la restauracion utilizando respaldos, estos pueden ser catalogados en las siguientes
categorias:

Fallo en una consulta:

Un ejemplo tipico de esta situacion es cuando un programa quiere insertar registros invalidos dentro de una tabla. La consulta
fallara por el proceso de verificacion de los datos a insertar, la solucion es simple: validar los datos y corregirlos, posiblemente
en algunos casos la consulta falla por errores en la logica de programacion, por lo que habria que regresarlo al equipo de
desarrollo para su revision y correcion.
Tambien se presenta cuando un gran proceso de insercion de datos o la importacion de datos falla a la mitad porque no hay
espacio disponible para poder almacenar todos estos nuevos registros, la solucion aca es asignarle mas espacio de crecimiento
a los Tablespaces adecuados.

Fallo en el proceso usuario:

Algunas veces los procesos usuarios fallan de forma abrupta por desconexiones no adecuadas o por errores en la PC que
utilizan teniendo como resultado la desconexion de la BD, como Administradores, no hay mucho que hacer ya que los procesos
de background de Oracle se encargan en la hacer la correcion, hacer rollback de los datos sin commit y liberar los bloqueos
generados por esas sesiones anormalas.

Fallo de Red:

Un problema de red podria tambien generar un problema en la Base de Datos. Estos problemas pueden ocurrir porque el
Listener de Oracle, la tarjeta de red (NIC) o la conectividad ha fallado. Como Administradores se tienen que configurar varias
tarjetas de red, tener una conexión de respaldo y tambien respaldar los archivos utilizados por el listener para poder tener una
proteccion contra estos tipos de eventos.

Falla de Instancia:

Se experimienta este tipo de fallas cuando la instancia se cae por algun evento como podria ser daño de Hardware, problema
electrico, por un procedimiento de emergencia o por un proceso de Background de Oracle (PMON) falla por alguna condicion
de error.

Lo primero que hay que verificar son los archivos de alertas y traces en busqueda que cualquier pista que nos ayude a ubicar la
causa de la falla de la instancia, luego de esto ejecutar el comando startup desde la linea de comandos del SQL Plus. Ya que la
BD no fue cerrada de la forma correcta, sus archivos no se encuentran sincronizados por lo que Oracle ejecutara de forma
automatica un proceso de crash recovery, hara inicialmente un rollback de las transacciones sin commit que pueda encontrar en
los UNDO Segments y luego un roll forward de los datos con commit que se encuentren en los Redo Logs, luego de este
proceso todos los archivos de la BD estaran sincronizados teniendo unicamente datos validos. La BD se puede abrir sin
problemas. Esto es unicamente valido cuando no hay ninguna falla en el hardware del equipo en donde la instancia fallo.

Error de Usuario:

Borrar una tabla importante es un es un error que podriamos cometer como administradores, adicionalmente los usuarios
podrian modificar o borrar datos importantes, Oracle provee varias tecnicas para poder solucionar eventos como estos:
flashback table es una funcionalidad para reconstruir una tabla a un punto en el tiempo, por supuesto siempre se puede hacer
rollback hasta el ultimo commit. Oracle tambien provee una herramienta llamada LogMiner la cual es muy util en estos casos.

Error en el Medio (Media Failure):

Este tipo de errores ocurre cuando hay una perdida de un componente del equipo en donde se encuentra instalada la instancia,
por ejemplo discos duros o una controladora de discos, corrupcion de un archivo, sobreescritura o borrar un datafile, de manera
general, cualquier error que se genere al leer o escribir a un disco consiste en Error en el medio y para poder recuperarnos a
partir de este error tenemos que hacer uso de nustros respaldos.

Cada tipo de error en el medio tiene una solucion diferente desde el punto de vista de recuperacion, por ejemplo, eliminar
accidentalmente un archivo de control, no es necesario restaurarlo desde un respaldos a diferencia de la eleiminacion de un
datafile, siempre hay necesidad de restaurar a partir de un respaldo y aplicar luego los Archive redo logs.

Una vez que la BD este funcionando podria verse comprometida cuando alguno de cualquiera de estos eventos es verdadero:

 Cualquiera de los archivo de control, que estan multiplexados, es eliminado o perdido por algun error en uno de los
discos (Media Failure)
  Cualquier datafile que corresponda al tablespace del System o Undo es borrado o eliminado por problema de discos,
en este caso la BD puede que no se caiga de forma inmediata.
 La perdida de un grupo de redo logs

La BD no se caera pero si estara inestable si cualquiera de los eventos es verdadero:

 Perdida o eliminacion de un datafile no critico (desde el punto de vista de Oracle estos son cualquiera que no sean del
System o de Undo)
 Perdida de un miembro de algun grupo de Redo Logs.

Conceptos de Respaldo y Recuperacion

Oralce utiliza muchos procesos para el mantenimiento de la instancia pero alguno de esos procesos son de vital importancia en
las tareas de respaldo y recuperacion, estos se puede apreciar en el siguiente grafico:

La instancia de Oracle consiste en el System Global Area (SGA) la cual es memoria fisica de la RAM del equipo asignada a la
instancia de Oracle, y el conjunto de procesos de Oracle llamado tambien Background process, estos se inician cuando la
instancia arranca y se mantienen funcionando mientras la instancia este viva. Cada proceso tiene una funcionalidad especifica.
Para las actividades de respaldo y recuperacion de BD lso procesos criticos son: el proceso de Checkpoint , el proceso de log
writer y el proceso de archivado (archiver):

El proceso de Checkpint:

 Avisa al proceso de escritura en la BD (Database writer DBWn) en cada checkpoint

 Actualiza el encabezado de los datafiles con la informacion del checkpoint
 Actualiza la informacion del checkpoint en los archivos de control.

Proceso de escrituras de bitacoras (Log Writer LGWR):

Los redo logs files, almacenan todos los cambios realizados a la BD, ya que Oracle utiliza el protocolo de escritura adelantada
(write ahead protocol), para lo cual primero se escribe la informacion en los redo logs files para luego ser escritos en los
datafiles, por lo tanto es de suma importancia asegurarse que los redo logs files estan multiplexados.

Los redo logs entran en la jugada cuando la BD falla o se cae, lo primero que hace al inicializarse es leer estos archivos en
busqueda de cualquier informacion con commit y que aun no han sido almacenados en los datafiles. El proceso LGWR es
responsable de transsferir el contenido del Redo Log Buffer a los Redo Logs Files y esta escritura se realiza dentro de las
siguientes circunstancias:
 Despues de cada commit
 Cada 3 segundos
 Cuando el Redo Log Buffer esta a un tercio de lleno
Lo importante a recordar es que el LGWR escribe antes que el DBWR por el protocolo de escritura adelantada. Los cambios no
estan necesariamente escrito a los datafile cuando se realiza commit a la transaccion, pero si son escritos siempre a los Redo
Logs Files.

TIP: Oracle cuenta con caracteristicas para evitar la generacion de Redo, estas son utiles
cuando se necesita acelerar la carga de mucha informacion en la BD, sin embargo, este
beneficio tiene un riesgo ya que la informacion sera irrecuperable y se tendria que hacer un
respaldo al finalizar la carga.

El proceso de archivado (ARCH):

Es un proceso de background opcional, se encarga de archivar los archive redo logs llenos, para que luego puedan ser
sobreescritos con informacion nueva. Este proceso se habilita cuando la BD esta configurada en ArchiveLog.

> Estructuras involucradas en la recuperación de la BBDD:

 Datafiles
 Redo Logs (Archived and online)
 Control Files
 Undo Records

En una basica configuracion de recuperacion, lo primero que hay que hacer es restituir desde un respaldo todos los datafiles,
una vez que este paso se completo ejecutar el comando recover el cual resultara en la BD en el rollforward de todos los datos
con commit para la sincronizacion de todos los datafiles, tambien se realiza un rollback de la informacion sin commit que se
encuentra almacenada en los segementos de UNDO que son del tablespace Undo. Oracle almacena todos los datos realizados
a la BD en los online redo logs, como Oracle utiliza el algoritmo round-robin para escribir a los miembros de cada grupo de Redo
logs, por lo tanto es de suma importancia garantizar una copia de estos archivos antes de ser reutilizados, este proceso es el
llamado Archivado (archive), los archivos redo, una vez guardados reciben el nombre de : archive redo log files, un proceso de
recuperacion del medio utiliza ambos archivos.

El archivo de control (control file) es esencial en el funcionamiento de la instancia, ya que en el se almacena toda la informacion
concerniente a tablespace y datafiles, checkpoints, secuencia de encabezados de datafiles y redo logs, etc, etc.
TIP: No se debe nunca respaldar los online redo log files, en lugar es recomendable hacer
multiplexacion de los mismos para protegerlo en contra de perdidas de algun miembro por
problemas fisicos.

> MODOS DE ARCHIVADO DE LA BASE DE DATOS

Modo NOARCHIVELOG y Modo ARCHIVELOG:

La BD puede operar en ambos modos. En modo Noarchivelog, los redo logs llenos seran sobreescritos en demanda al contraro
del modo Archivelog. En el modo Noarchivelog estamos protegidos unicamente contra daños de instancia, pero no por daños
en el medio, los cambios que han sido sobreescritos se pierden para siempre y la BD no tendra capacidad de poder acceder
dichas modificaciones para recuperar la informacion. Las transacciones realizadas desde el ultimo respaldo se pierden y
unicamente podemos recuperarnos desde el ultimo respaldo (logico o fisico) realizado.

Si la BD esta en modo Noarchivelog y hay perdida de un datafile estos serian los pasos a seguir:
 Si la BD no se ha caido, hacer un shutdown
 Restaurar toda la BD (datafiles y archivos de control) de un respaldo en frio
 Reinicializar la BD.
 Se perdera cualquier informacion que haya sido ingresada desde el ultimo respaldo.

TIP: Es un riesgo muy alto correr una BD de produccion en modo NOARCHIVELOG ya que no
tendriamos ya que existen muchas posibilidades de perdidas de informacion, utilizar las
herramientas como EXPORT o EXPDP garantizan un respaldo logico, pero estas por si solas no
es un respaldo, es un complemento a una estrategia de respaldos.

Tipos de Respaldos:

Los respaldos en Oracle es mucho mas de una copia de todos los archivos y se podrian clasificar de la siguiente forma:

Respaldos Fisicos y Logicos:

Cuando se realiza una copia de los archivos de la BD utilizando una herramienta del sistema operativo (cp) pueden ser
utilizados para hacer una restauracion de los contenidos de la BD en el caso de perdida de algun medio en donde se encuentre
algun archivo de la BD, las copias de la BD incluye: todos los datafiles, redo logs y archivos de control esto hace un respaldo
fisico. Es importante mencionar que la BD debe de haber sido cerrada con un shutdown que garantice la sincronizacion de los
datafiles (shutdown immediate).

Los respaldos logicos se hacen con una utilidad de Oracle llamada Export o Data Pump, con la cual se realiza un archivo que
contiene las definiciones de los objetos en la BD (procedimientos, triggers, tablas, etc) y los datos almacenados en las tablas, la
contraparte de esta herramienta en la Import Utility el cual sirve para actualizar en otra BD el contenido del archivo generado
con el EXP, los respaldos logicos no son una solucion completa para un escenario de respaldo y recuperacion, la funcion es
completar o ser un medio secundario de respaldo de informacion importante valida para en algunos escenarios.

Para ambos tipos de respaldo es irrelevante el tener la BD en modo ARCHIVELOG o no

Respaldos totales y parciales:

Un respaldo total incluye todos los archivos necesarios para el funcionamiento de la BD, mientras que un respaldo parcial
corresponde a un grupo de datafiles especificos en un punto en el tiempo, tambien podria ser la copia de un archivo de control,
tambien se podria hacer al invocar una copia binaria de este mismo.
Para hacer un respaldo parcial, es necesario tener la BD en modo ARCHIVELOG, se tienen que ejecutar la sentencia: alter
database tablespace users begin backup; se copian los datafiles correpondientes y luego alter database tablesapce users end
backup;

Respaldos Online y Offline:

RMAN soporta ambos tipos de respaldos:

Offline son similares a los realizados del modo fisico, pero controlados por medio de la interfaz del RMAN y subir la BD a modo
mount.

Online, es tambien llamados respaldos en calientes, estos son realizados cuando la BD esta abierta y en operación, por
definicion, este tipo de respaldos son incosistentes siempre es necesaria la aplicación de los archive logs necesarios para
hacerlos consistentes, esto es unicamente valido para BD seteadas en forma ARCHIVELOG.

Respaldo totales e Incrementales

Los respaldos totales son copias completas de todos los archivos contenidos en la BD, mientras que los incrementales nada
mas contienen los bloques de datos que han tenido algun tipo de modificacion desde el ultimo respaldo total.
Consecuentemente los respaldos incrementales toman mucho menor tiempo en completarse. Los respaldos incrementales
unicamente son posibles utilizando RMAN, no se puede hacer respaldo incrementales a BD Oracle utilizando tecnicas manuales
de respaldo.

Respaldos Consistentes e Inconsistentes:

Hay una diferencia crucial entre estos dos tipos de respaldos y para entenderlos hay que conocer el concepto de SCN (System
Change Number).

El SCN es un numero asignado por Oracle a nivel de servidor que representa la version con commit de la BD. Es posible que
diferentes datafile en la BD tengan numero distinto de SCN en cualquier punto en el tiempo y si el SCN es sincronizado en todos
los datafiles, significa que todos estan al mismo punto en el tiempo, por lo tanto, consistentes.

Durante cada checkpoint, el servidor hace todos los archivos consistentes con respecto a un solo SCN, el cual es almacenado
en el Archivo de Control, esta sincronizacion garantiza la consistencia de la BD. Si se hace un respaldo en caliente (mientras la
BD esta corriendo) a los datafiles al final se cuenta con un archivos con diferentes SCN, por lo tanto inconsistente.

En modo NOARCHIVE unicamente se pueden hacer respaldos consistentes para restaurar la BD a diferencia que en modo
ARCHIVE se pueden restaurar a partir de respaldos inconsistentes aplicando todos los Redo Logs necesarios para sincronizar
el SCN a los datafiles. La clave del proceso para hacer consistente lo inconsistente es aplicando todos los archive redo logs
necesarios.

No es recomendable respaldar una BD inconsistente que haya sido resultado de un shutdown abrupto (shutdown abort) cuando
se encuentra configurada en modo NOARCHIVELOG, a manera contraria, corriendo en modo ARVICHELOG se puede
respaldar la BD en cualquiera de las siguientes formas:
 Cerrada y consistente
 Cerrada e inconsistente
 Abierta e inconsistente

Tipos de Recuperacion:

Recuperacion de BD con respaldos Consistentes vrs Inconsistentes

Si la BD fue bajada de forma normal (Norma, Immediate, transactional) se tiene una BD cerrada de forma consistente y esto
sucede cuando:
  Se le aplica el proceso de rollback a todos los datos sin commit
 El contenido del buffer Cache es escrito a los datafiles
 Todos los recursos asignados son liberados

Al momento de reiniciar la instancia no hay necesidad de hacer ningun tipo de recuperacion.

Si la BD fue bajada de forma abrupta (shutdown abort o force) se baja de forma inconsistente, por lo tanto cualquiera de los
siguientes eventos pueden ser verdaderos:
 Cualquier cambio con commit no son aplicados procesos de rollback.
 Cualquier cambio hecho a la BD que se encuentre en el buffer cache no son escritos a los datafiles
 Todos los recursos (bloqueos y latches) no son liberados

YA que no fue cerrada de forma normal cerrada en medio de procesamiento de usuarios que no han sido propiamente escritos
a los datafiles, cuando se reinicializa el proceso la BD realiza inicialmente lo siguiente:
 Utiliza la informacion contenida en los Online Redo Logs para reaplicar los cambios
 Usa la informacion contenida en los UNDO para hacer rollback
 Liberacion de los recursos asignados

Todo este proceso es obligatorio pero realizado de forma automatica con poca o ninguna intervension de parte del DBA.

Crash Recovery:

Esta es la realizada de forma automatica por el servidor luego de haber sido cerrada de forma abrupta, para sincronizar los
archivos Oracle realiza los siguientes procesos clave:

Rolling forward: Durante este proceso Oracle actualizara toda la informacion contenida en los Online redo logs hacia los
datafiles, durante este proceso Oracle aplicara a los datafiles todos los cambios desde el ultimo checkpoint hasta el final de los
redo log, este proceso es afinable a traves del parametro de inicializacion fast_start_mttr_target para especificar el numero
en segundos que la recuperacion puede tomar, Oracle lo realizara lo mas cercano posible a ese numero. El maximo numero de
este parametro es 3,600 segundos (1 hora).

Rolling back: Durante este proceso todos los cambios sin commits que fueron escritos a los datafiles durante el proceso de
rollforward son deshechos, para esto se auxilia del Undo tablespace el cual contiene toda la informacion en su estado original.

Media recovery:

Esta es una situacion mas seria, ya que hay un daño en algun medio que impide que la BD se recupere de forma automatica,
para recuperar hay que sumistrar los datafiles faltantes desde un respaldo valido y todos los archive redo log necesarios para la
completa sincronizacion de este archivo con respecto al SCN. Cuando el motor de Oracle presenta algun tipo de error indicando
problemas en el medio, primeramente se debe de consultar la vista V$RECOVER_FILE el cual presenta todos los archivos
que necesiten recuperacion por algun erreor en el medio.

El comando recover realiza el proceso de recuperacion al aplicar los archive redo logs necesarios, para completar este tipo de
recuperaciones se debe de hacer lo siguiente:

 Restaurar los datafiles necesarios desde un respaldo valido

 Renombrar la ubicación de los datafiles, si es necesario
 Recuperar los datafiles aplicando toda la informacion de redo.

Para luego abrir la BD luego de la recuperacion es necesario completar lo siguiente:

 Tener sincronizadas todas las copias de los archivos de control
 Todos los datafiles sincronizados
 Tener al menos una copia de cada grupo de redo logs
Con esto se puede abrir la BD recuperrada.
Recuperacion completa o un punto en el tiempo:

Este tipo de recuperacion es tambien conocida como recuperacion incompleta, el cual trae a la BD a un punto en el tiempo
especifico en el pasado, esto implica que todos los cambios realizados despues del punto de restauracion son perdidos y esta
situacion es valida (aunque no parezca logico tener perdida de datos) cuando se presentan cualquiera de los ejemplos:

 Perdida de uno de los archive redo logs o respaldos incrementales necesarios para la completa restauracion luego de
un fallo en el medio.
 El Administrador o cualquiera de los usuarios por error aplicación actualizaciones a tablas equivocadas
 Un proceso batch realizando updates fallo.

En cualquiera de esas situaciones se puede utilizar o recuperacion en un punto en el tiempo o Flashback (introducida en 10g)
para restaurar la BD en un punto en el tiempo pasado. La tecnologia de flashback ofrece la capacidad de hacer una
restauracion a un punto en el tiempo mucho mas rapido que la forma tradicional que residen en la recuperacion de BD, cada
una de las tecnologias tiene su momento de uso:
 Utilizar recuperacion en el medio cuando la situacion es perdida, daño o un datafile inacessible.
 Un usuario borra o le hace commit a mucha informacion por error, a pesar que se puede realizar una recuperacion
aun punto en el tiempo es recomendable aplicar la opcion de flashback.
 Por algun tipo de error logico la mejor opcion es hacer una recuperacion a un punto en el tiempo.
 Corrupcion de datos en algunos bloques de datafiles.
 Si un usuario afecta mucha informacion en toda la BD, lo mejor es utilizar la tecnologia flashback database hasta un
punto valido en el tiempo.

Mejores Practicas de Repaldo y recuperacion:

 Documentar, siempre es util en momentos de restauracion cualquier informacion de configuracion realizada, siempre
es necesario documentar con el mayor detalle posible los procedimientos de respaldo y recuperacion, si es posible
realizar scripts que realicen tareas de recuperacion a realizar en momentos de crisis y por ultimo compartir toda esta
informacion con todas las personas que tengan que ver en los procesos de administracion de BD, procesos de
respaldo.

 Configurar el Flash Recovery Area, como punto de inicio de trasalado de la informacion desde los discos a las
unidades de cintas, ya que por definicion y arquitectura, es mucho mas rapido leer a disco que de cintas de respaldos.
Oracle recomienda utilizar esta area para almacenar toda la informacion concerniente a respaldos y recuperacion y
como minimo el tamaño deberia de ser lo suficientemente grande como para almacenar todos los redo logs que aun
no han sido copiados a cintas. Esta configuracion es opcional pero la recomendación es habilitar al menos una para
poder tener la opcion de utilizar la tecnologia de flashback.

 Copias de respaldo redundantes en el caso de perdidas o daño de algun juego de respaldos estos deberian de incluir
respaldo de todos los datafiles y el archivo de control, todos los archive redo log generados desde el ltimo respaldo,
copias de los archivos de control actuales y todos los archivo relacionados a configuracion (spfile, password file,
tnsnames, listener.ora). a nivel de BD esto se garantiza en multiplexar los online redo log y los archivos de control en
al menos dos ubicaciones fisicas distintas, tambien hay que considerar las opciones de redundancia que ofrecen los
sistemas operativos y las controladoras de discos (mirror, arreglos) para garantizar el funcionamiento de la BD cuando
haya problemas fisicos.

 Creacion de estrategias de respaldo fuertes y validadas determinara la fortaleza de los procedimientos de

recuperacion, esta debe de estar basada en todos los problemas posibles que las Bd puedan encontrar, entre mas
problemas o riesgos esten cubiertos, sera mas compleja la estretegia de respaldo.

 Crear copias de respaldo del archivo de control en forma regular, el cual es un archivo de suma importancia para el
funcionamiento correcto de la BD. Rman ofrece una buena solucion para garantizar sus respaldos constantes.
  Tener la BD en modo ARCHIVELOG, es la unica forma de garantizar la restauracion de la BD con ninguna perdida de
datos en los esquemas de produccion.

 Adoprtar la estrategia de almacenamiento de respaldos adecuada, ya que el proceso de recuperacion es critico y

tener los respaldos almacenados en medios distintos se reflajara en el tiempo de recuperacion, toma menos tiempo
leer de disco que de cintas

> BACKUP DE USUARIO SIN RMAN

Modo NOARCHIVELOG

Por defecto esta opcion se encuentra desactivada.

Ejemplo respaldo en frio

Paso 1. Conectarnos con privilegios SYSDBA y bajar la BD en modo consistente:

Paso 2: utilizar las herramientas del sistema operativo para copiar todos los archivos explicados con anterioridad que la BD
utiliza para su funcionamiento, una vez completado el respaldo, reiniciar la BD (conectados como sysdba)

Ejemplo de respaldo de archivo de control en forma binaria

La instrucción generara el archivo en las carpetas de trace del motor, pero tambien se puede invocar el respaldo directo del
archivo de control a una ubicación definida por nosotros:
Revision del estado del modo archive

Parametros para definir el modo archive

log_archive_dest: Define la ubicacion en donde seran almacenados los archive, Oracle por defecto solicita un lugar en donde
guardar pero pueden ser hasta 10 ubicaciones incluyendo carpetas en servidores remotos.

log_archive_start: Define si la BD funcionara o no en modo Archive, este parametro se tiene que modificar a nivel de archivo de
parametros para luego habilitar el proceso desde modo mount. Para habilitarlo, hay que tener el servicio detenido

log_archive_format: define el formato con el que Oracle generara los archive log, por ejemplo, si el formato es arch%s.arc los
archivos se generaran arch1.arc, arch2.arc, el %s define le consecutivo, las demas variables son las siguientes:

%s consecutivo

%S secuencia de numero de log, rellenada por ceros

%t numero de thread

%Tnumero de thread rellenada de ceros

%a activation ID
%d database ID

%r resetlogs ID que asegura nombres unicos para la construccion de los archive log files a traves varias encarnaciones de la
BD.

Habilitacion de modo archive en una BD

1. Revision de los parametros de inicio en el archivo de control, agregarlos de ser necesarios (para esto es necesario
hacer inicialmente un create pfile from spfile).

2. Despues de
agregar los
parametros
adecuados, bajar
la BD y volver a
subir hasta modo mount
3. En modo mount escribir lo siguiente:alter database archive log y luego abrir la bd

4. Revisar que el modo archive esta funcionando:

Respaldos en caliente:

A como fue explicado en las paginas anteriores, ya con la BD configurada en modo archive es posible la realizacion de
procedimientos de respaldos inconsistentes y el caliente, al bloquear los encabezados de los datafiles.

A nivel de tablespace

Al bloquear los encabezados de los datafiles, pueden ser copiados de forma normal por medio de las utilidades del sistema
operativo.

Esto se puede monitorear por medio de la consulta a v$backup

Una vez finalizado el proceso de copia de los archivos del datafile se procede a finalizar el proceso de respaldo, de lo contrario
el tablespace se mantendra con los encabezados bloqueados y no se aplicara toda la informacion nueva generada a partir del
inicio de proceso de respaldo.

Luego de finalizar el proceso de respaldo, la informacion en v$backup cambia a como se muestra en la pantalla a continuacion.
Estos tipos de respaldo deberia de hacerse de forma semanal, siempre manteniento tambien todas los archive redo logs
generados para su posterior aplicación, es importante tambien convinarlos con respaldos fisicos totales (respaldos en frio) para
tener un punto de referencia a la hora de restaurar. Los respaldos fisicos deberian de realizarse una vez al menos (cuando
menos) la ventaja es que se reduce la cantidad de archive logs necesarios para la completa restauracion de la BD pero la
desventaja es que hay que bajar por completo la BD para realizarlos.

Otro punto muy importante es validar los respaldos generados de manera que estemos seguros de lo que estamos haciendo
nos funcionara cuando los necesitemos.

En este punto es donde se integran mas que en cualquier otro lugar las tareas de Administracion de BD con las de Sistemas
operativos esto para garantizar la disponibilidad de espacio en discos, cintas de respaldos, nomenclatura, etc. El mejor consejo
es, en lugar de duplicacion de funciones y por ende de esfuerzo es mejor la integracion de ambas de acuerdo a los
procedimientos y las necesidades de cada organización.

Es de mucha importancia hacer respaldos de los archivos criticos (a nivel de funcionamiento de Oracle) esto son: los datafiles
del tablespace SYSTEM el cual contiene toda la informacion del diccionario de datos de Oracle, y es vital para el funcionamiento
del motor.

TIP: Es una buena practica una vez que se le haya agregado algun datafile a un tablespace, proceder de forma inmediata a su
respaldo, para que, en el caso de daño en el medio no nos resulte imposible la restauracion de dicho archivo, tambien incluir
este nuevo datafile en las politicas de respaldos.

Recuperaciones en modo archive

A como se analizo en paginas anteriores, la BD seteada en modo NOARCHIVELOG unicamente puede ser recuperada a partir
de un respaldo fisico en frio realizado con anterioridad, toda la informacion despues del respaldo hasta el momento de la
recuperacion se pierte. A diferencia del modo ARCHIVE con el cual tenemos varias formas de recuperacion de manera que la
perdida de datos podria estar muy cercana al cero.

Recover Database:

Se utiliza la informacion del archivo de control actual, la BD puede estar montada pero no abierta, el encabezado de los datafiles
es comparado con la informacion almacenada en el archivo de control y a partir de ahí aplica todos los archive redo logs
necesarios para la correcta y completa sincronizacion de los encabezados.
En la figura se nota que el datafile necesita recuperacion porque no esta sincronizado con la informacion de encabezados
almacenada en los archivos de control y la bd no se encuentra abierta.

Al aplicar el comando recover database, la instancia procede a aplicar todos los redo logs necesarios para la correcta
sincronizacion de los datafiles
Con la finalizacion de la sincronizacion se procede a abrir la BD con el comando alter database open; con el cual esta listo para
la conexión de usaurios.

Recover Datafile:

Este comando es usado cuando la BD esta funcionando y no puede ser detenida aunque tambien podria ser desde modo
mount.
El datafile del tablespace users no se encuentra sincronizado con respecto al diccionario de datos.
Con la sincronizacion realizada, se procede a abrir la BD

Nota: para efectos de laboratorio, la BD deberia de estar en modo OPEN y no en modo MOUNT, lo cual no logre reproducirlo
por ser un ambiente no produccion, pero el comportamiento (a nivel de comandos y funcionalidad) es exactamente el mismo.

Recover Tablespace:

El tablespace debe de estar fuera de linea y la BD en modo OPEN, la idea es la recuperacion de un solo tablespace al momento
actual, este comando no puede ser usado en los tablespace del SYSTEM o cualquier tablespace que tenga asignado
segmentos de rollback o de UNDO que esten en status “in use”, es igual al primer escenario de recuperacion con el detalle que
la BD esta en modo OPEN.

Recover database Manual:

La recuperacion manual nos da el control de poder de controlar que tantos archive redo logs se aplicaran a la BD, esto es util
para deshacer cambios inadvertidos a la BD al detener la recuperacion antes de aplicar el cambio. La opcion manual es
necesaria para recuperacion con un archivo de control viejo y el archivo de control actual no esta disponible.

La BD debe de estar en modo MOUNT pero no OPEN, luego de montar la BD se tiene que dar el comando recover database
manual, luego ira aplicando iniciando con los redo logs mas viejos, el proceso de recuperacion es de hacerla hasta el momento
antes que se necesite al escribir CANCEL a la hora de preguntar por el siguiente archive redo log.

Recover database Until:

Es parecido al concepto anterior pero no se puede hacer con la version vieja de un archivo de control, aca se le tiene que definir
el tiempo en donde se quiere recuperar la BD definiendole el punto en el tiempo hasta donde se quiere recuperar.
Luego de una recuperacion hasta un punto en el tiempo hay que abrir la BD con el comando resetlogs;

La opcion de resetlogs limpia todos los online redo logs y modifica todos los online data files para indicar que no es necesaria la
recuperacion, luego de hacer abrir la BD de esta forma, ninguno de los archive log files y de los juegos de respaldo generados
con anterioridad son validos ya que el encabezado que se encuentra en todos ellos es sobreescrito por una nueva numeracion
(iniciando de cero), esta opcion es de sumo cuidado aplicarla ya que al resetear los encabezados cualquier informacion que
existira en los online redo logs no es aplicada a la BD, por lo tanto, se pierde. Es recomendale hacer un backup total en frio
antes y despues de aplicar el resetlogs. Todos los datafiles de la BD tienen que estan en linea para que sean reescritos los
encabezados de lo contrario no seran utiles en la nueva encarnacion de la BD.
Utilidad DBVERIFY

DBVerify o DBV es una herramienta que revisa los datafiles de Oracle en busqueda de corrupcion y le aplica medidas
correctivas. Esta herramienta se puede correr en archivos abiertos por alguna instancia (en versiones anteriores a 10g no se
podia hacer esto) ya que esta herramienta abre de forma de lectura los datafiles. Esta se ejecuta a nivel de consola

Tiene varias opciones que deben de ser pasadas como parametros:

FILE: El archivo a verificar

START: Bloque de inicio a revisar en los datafiles.
END: Bloque final de revision
BLOCK SIZE: El tamaño del bloque a utilizar, por defecto el tamaño es 2048 k
LOGFILE: Bitacora de los resultados de ejecucion del proceso, por defecto es NONE y se presenta en pantalla
FEEDBACK: Presenta un progreso cada N paginas, es util cuando la utilidad esta trabajando en medio de archivos
PARFILE: Archivo de parametros que contenga cualquiera de las opciones explicadas
HIGH_SCN: Valor mas alto para la verificacion del SCN.
USERID: (usuario/password) si el archivo que se esta verificando se esta utilizando en alguna arquitectura ASM

Limitantes:

 Esta utilidad esta diseñada para la verificacion a nivel de bloques, no detecta inconsistencias entre bloques de indices
contra los de las tablas.
 Esta utilidad unicamente puede ser utilizada contra archivos de datos, no para verificacion de redo logs o archivos de
control
 Se puede verificar en datafiles contenidos en ASM pero la BD debe de estar abierta para la validacion del
usuario/password.
 No se puede utilizar en contra de dispositivos tipo RAW ya que espera una extension en los archivos de entrada, la
solucion para esto es definirles una antes de ejecutarlos:
Eg: ln -s /dev/rdsk/mydevice /tmp/mydevice.dbf
Utilizar DBV contra /tmp/mydevice.dbf
 Para dispositivos tipo RAW hay que utilizar el parametro END para evitar llegar al final del datafile, si se setea este
parametro muy alto DBV puede marcar como corupto la parte final del datafile. El cual se puede hayar al revisar la
vista V$DATAFILE
El comando seria:

dbv file=/dev/rdsk/r1.dbf blocksize=8196 END=2650

 Hay algunas limitantes por plataformas Windows en archivos mayores a 2 GB.

 DBV revisa unicamente bloques por isolacion, no sabe si el bloque es parte de algun objeto o no.

Ejemplos de uso
Recuperacion utilizando RMAN

Arquitectura del RMAN:

Se puede comenzar a utilizar esta herramienta sin hacer ningun tipo de instalaciones o de configuraciones, simplmenete
ejecutando la heramienta llamada rman situada en la carpeta bin del Oracle Home. Se pueden tambien hacer la administracion
del RMAN por medio del GUI del Enterprise Manager Pero para hacer una estrategia de respaldo y recuperacion robusta hay
que configurar ciertos componentes opcionales:

Catalogo de Recuperacion (recovery catalog): es la BD que almancena la informacion del repositorio del RMAN, es tambien
llamada Rman metadata, es una muy buena recomendación dejar un servidor dedicado para este repositorio, elimando el riesgo
de quedarse sin espacio.

Flash Recovery Area: es el espacio en disco que la BD almacenara toda la informacion concerniente a recuperaciones.

Una sesion en unix de Rman consiste de los siguientes procesos:

 El proceso del RMAN

 Un canal por defecto, el cual es el medio de conexión a la BD destino.
 Canales adicionales para alocar los targets de conexión a las BD destino.
 Si se utiliza un catalogo de recuperacion, se necesitara una conexión a la bd de recuperacion.
 Durante los proceso de duplicacion o de TSPITR (TableSpace Point In Time Recovery) hay una conexión auxiliar a la
instancia auxiliar.
 Por defecto, RMAN utiliza un pool de conexión a cada una de las BD destino para ayudar en el monitoreo de la
ejecucion de los comandos en los diferentes canales alocados.

Beneficios del RMAN

En paginas anteriores analizamos la forma de respaldos manejados por el usuario, pero estas tienen muchas desventajas, por
ejemplo, no se puede realizar un respaldo incremental y tambien se tiene que manejar varios set de backups para poder ser
aplicados en la recuperacion, los cuales tienen que ser oportunos y validos, ademas de tener que hacer las propias rutinas a
nivel de BD y de Sistema operativo, Oracle provee ambas formas de recuperacion pero siempre recomienda en la utilizacion del
RMAN para respaldos y recuperaciones de BD, algunas de las ventajas son:
 Utilizacion del Data recovery Advisor, la cual es una utilidad poderoza que permite facilmente el diagnostico y
reparacion de falltas de datos y corrupcion.
 Los comandos son mas simples
 Automaticamente maneja el juego de respaldos sin intervencion del DBA
 Automaticamente elimina respaldos viejos (en discos y cintas)
 Provee un reporte detallado de las operaciones de respaldos
 Provee una gran ayuda en el momento de creacion de una BD standby
 Permite la validacion de respaldos de BD a modo de prueba sin la recuperacion de los datos
 Lista los juegos de respaldos disponibles para recuperacion
 Permite hacer respaldos incrementales
 Detecta de forma automatica los bloques corruptos
 Si hay algunos bloques corruptos se puede recuperar a nivel de bloques sin necesidad de recuperar todo el datafile
 Se puede realizar compresion a nivel de bloques
 Permite generar backups encriptados
 Se integra con herramientas de respaldo de terceros (Veritas, TSM, etc)
 Provee una herramienta para el desarrollo de scripts a la medida.
Antes de trabajar con RMAN hay que tener ciertas consideraciones:

 Definir la politica de retension de respaldos

 Configurar respaldos automaticos del archivo de control (CONTROLFILE AUTOBACKUP ON)
 Configurar la politica de retension de los Archive logs generados, de manera que sean equivalentes con nuestra
politica de respaldo
 Generar la bitacora de los jobs de respaldo para poder monitorear y detectar errores.
 El uso del Flash Recovery Area es vital para la aceleracion de los procesos de respaldo y recuperacion.
 Validar siempre las politicas de respaldo bajo al menos los siguientes escenarios:
o Perdida del tablespace del System
o Perdida de algun grupo de Online Redo Logs
o Perdida de algun archivo de control
o Perdida de algun tablespace de datos
o Perdida de uno o varios datafiles
o Perdida de secuencias en los logs
o Perdida total a nivel de BD
o Perdida total del servidor (BD, Software, archivo de parametros)

Configuracion de parametros de Inicio:

A continuacion se detallan los parametros de inicio que se tienen que definir antes de utilizar RMAN

CONTROL_FILE_RECORD_KEEP_TIME:

Un registro de toda los respaldos realizados por rman son almacenados en el archivo de control de la BD destino, este
parametro especifica el numero de dias que se mantendra esta informacion en el archivo de control de la BD destino, luego de
llegar al limite, la informacion sera sobreescrita, en el caso que haya un umbral muy alto el motor tratara de ampliar el tamaño
del archivo de control para poder soportar mas informacion, generalmente esto siempre es exitoso ya que el tamaño del archivo
de control es relativamente pequeño comparado con los demas archivos de Oracle.

DB_RECOVERY_FILE_DEST:

Este parametro especifica la ubicación del FLASH_RECOVERY_AREA y deberia de estar ubicada en un filesystem diferente a
cualquier otro que contenga archivos de la BD, esto para reducir el riesgo de perdida del area de recuperacion en el caso de
daño de medio.

DB_RECOVERY_FILE_DEST_SIZE:

Define el tamaño limite maximo de espacio en disco que sera utilizado para el FLASH_RECOVERY_AREA.

Vistas dinamicas del diccionario de datos:

Las tablas dinamicas que contienen informacion especifica de las operaciones del RMAN en ambas BD.
Vista
RC_*
V$RMAN_STATUS
V$RMAN_OUTPUT
V$SESSION_LONGOPS
V$DATABASE_BLOCK_CORRUPTION
V$FLASH_RECOVERY_AREA_USAGE
V$RECOVERY_FILE_DEST
V$RMAN_CONFIGURATION
Descripcion
Vistas del catalogo de recuperacion del RMAN, unicamente
existen en la BD en donde este configurado este
Muestra informacion de las tareas finalizadas y en proceso del
RMAN
Muestra informacion de mensajes generados por los mensajes
del RMAN generados durante la sesion
Muestra informacion sobre los procesos largos
administrativos, aquellos que tienen mas de 6 segundos de
duracion
Informacion de bloques corruptos detectados por la sesion del
RMAN
El porcentaje del espacio usado por objeto dentro del flash
recovery area
Numero de archivos, espacio utilizado, espacio a reutilizar en
el flash recovey area
Parametros personalizados (que no son por defecto) para la
BD.
Configuracion del Catalogo de recuperacion

El siguiente script creara el usuario rman, que sera el dueño del catalogo de recuperacion, la cual es una BD pequeña que
contiene toda la metadata utilizada por rman para su funcionamiento, conectado como system por medio de sqlplus.

Utilizando el usuario creado anteriormente se procede a crear el catalogo de recuperacion, esto se hace al invocar el comando
del RMAN create catalog.

Salida del script:

Una vez que el catalogo esta creado, se tiene que registrar todas las BD que seran respaldadas por RMAN, en este caso nos
tenemos que conectar a la bd destino (Target) la cual sera la que se respalda y a la BD que contiene el catalogo (Catalog)

Salida del script:

Verificacion del registro de la BD:

Una vez que la BD esta registrada con el rman, podemos extraer informacion de ella desde el catalogo de recuperacion, para
esto es necesario ejecutar el comando report schema para obtener la informacion:

Exportacion del catalago de recuperacion:

La BD la cual cuenta con la informacion de recuperacion debe de ser protegida en contra de fallas, el minimo nivel de se puede
garantizar con un export del esquema (se analizara mas adelante la utilidad del export e import), con el siguiente comando se
puede realizar:

La salida del comando es algo parecido a esto:

El comando generara un archivo llamado rman-catalog-export.dmp en la ubicación en donde haya sido invocada la herramienta
de exp (en el caso que no se le haya especificado alguna ruta) con esto tenemos un archivo binario que nos permitira la
restauracion del catalogo en el caso de problemas con dicha BD.

Consultas al catalogo de recuperacion:

En algunas situaciones es necesario hacer consultas directas al catalogo de recuperacion, para esto es necesario saber primero
el ID de la BD (dbid) que queremos para buscarlas en el catalogo de recuperacion, el db_id se obtiene al consultas la vista
V$DATABASE:
Respaldo Total con RMAN

En el siguiente ejemplo se realizara un respaldo total de la BD incluyendo el SPFILE y sera almacenado en el flash recovery
area:

El comando del alter system lo que permite es asegurarnos de archivar todas las transacciones, incluyendo las que sucedieron
mientras realizabamos el respaldo, ademas asegura que podriamos realizar una recuperacion en el medio exitosa luego de
aplicar este respaldo.

Notese que se respaldo dos veces el archivo SPFILE esto es por la configuracion de configure controlfile autobackup on para
automaticamente respaldarlo.
Administracion del repositorio:

El comando del rman list muestra los respaldos incluidos en el repositorio

Agregar un Tablespace y actualizar el respaldo

En el ejemplo, se agregara un tablespace nuevo a la BD para nuevos esquemas:

Se tiene que respaldar los datafiles creados, junto con el archivo de control, en este caso es critico respaldarlo ya que incluye
informacion del nuevo tablespace creado
Tambien se puede respaldar datafiles de forma muy facil, ya que es impractico respaldar un TBS con mucha informacion en una
sola sesion de RMAN, por lo que se puede respaldar los datafiles de cada TBS en un periodo y la informacion almacenada en
los archive log files nos servira para su sincronizacion.

Copias Imágenes:

Hasta este punto se han realizado respaldo tipos backupset, pero tambien se pueden realizar copias bit a bit de un tablespace
especifico de una BD, las ventajas que se obtienen es que el respaldo se almacena directamente en el repositorio del RMAN y
los bloques son validados por corrupcion, otra ventaja es que este tipo de copias pueden ser utilizadas tan cual fuera del RMAN,
ya que por alguna razon la recuperacion se tenga que hacer fuera del RMAN.

En el ejemplo a continuacion se realiza una copia de imagen del tablespace inet_star, estas copias imágenes pueden ser
creadas en discos
Respaldo del archivo de control y del spfile:

De forma manual se podria invocar el respaldo de estos archivos, tomando en cuenta que al tener el parametro de autobackup
on, se realizara de forma automatica.
Respaldo de los Archive redo Logs:

Aunque los archive redo logs se podrian generar a varias ubicaciones de forma simultanea (por la multiplexacion), pero por su
naturaleza critica es de suma importancia el respaldo de dicha informacion, una vez completada el proceso de respaldo se tiene
la opcion de eliminarlos.

En el ejemplo, se respalda toda la informacion de los archive redo log ubicados en el flash recovery area y luego removidos del
disco:

Elminar y almacenar archive redo logs viejos puede ser acompañada al definir un rango de fechas en el comando:

En el ejemplo, todos los archive redo logs anteriores desde una semana hasta 3 semanas son copiadas a cintas y luego
eliminadas de los discos, tambien se podria definir una secuencia por SCN o el numero de secuencias.

Respaldos Incrementales:

Una estretegia alternativa es el uso de respaldos incrementables incluyendo los archive redo logs necesarios para la
recuperacion. El primer respaldo incremental es conocido como respaldo nivel 0, los respaldos incrementales siguientes son
nivel 1, ya que inicamente incluye los cambios a nivel de bloques modificados, estos pueden ser acomulativos o diferenciales. El
acomulativo respalda toda la informacion de bloques desde el primer respaldo incremental; un respaldo diferencial almacena
toda la informacion desde el ultimo incremental sin importar que sea nivel 0 o 1.

Cuando existe una serie diferentes de respaldos disponibles en el catalogo, ya sea copias de imágenes, de tablespaces,
incrementales, rman utilizara la mejor opcion para recuperacion que sea mas eficiente. Aunque el DBA aun tiene la opcion de
prevenir al RMAN sobre el uso de un respaldo particular.

La decision ya sea de utilizar respaldos acomulativos o diferenciales depende de la cantidad de ciclos de CPU y la cantidad de
espacio en disco disponible. Usando respaldos acomulativos significa que cada respaldo incremental sera progresivamente mas
grande y tomara mas tiempo hasta que se realice otro respaldo incremental nivel 0, durante un proceso de recuperacion
unicamente seran utilizados un juego de respaldos a diferencia de los respaldos diferenciales que por ser mas pequeños y
manejables son necesarios todos para poder realizar la recuperacion completa.
En el ejemplo, nos damos cuenta que hay muchos archivos fuera de la politica de retencion de cuatro dias, en otras palabras,
los datafiles necesitan cuatro dias de archive log para recuperar la BD.

Para remediar la situacion, se puede realizar otro respaldo total o un respaldo incremental, la cual sera mas facil de implementar
y mantener, para un respaldo incremental a nivel 0 se realiza de la siguiente forma:
Luego en cualquier momento en el futuro podemos realizar respaldos incrementales a nivel 1:

Por defecto el respaldo se realiza de forma diferencial, la palabra clave differential no es necesaria, sin embargo se puede
realizar un respaldo acomulativo al agregar la palabra clave cumultive.

Tambien la actvidad en la BD tambien podria dictar la forma de realizar los respaldos (acomulativo o diferenciales), en un
ambiente tipo OLTP el cual tiene mucha actividad de insert, updates, los respaldos incrementales son mas manegables en
termino de utilizacion de discos. Para un ambiente de datawarehouse con casi ningun cambio, los respaldos diferenciales son
mas adecuados, en comparacion de uso de redo log files, ambos tipos de respaldo son recomendados en terminos de tiempo
de recuperacion de la BD, para cualquier se puede definir la politica de retension:

Compresion de respaldos

Se puede configurar este parametro de forma para la compresion automatica de respaldos, o se podira especificar por medio de
comandos RMAN:

Validacion de respaldos

Teniendo toda una serie de respaldos realizados de distintas formas es igual a no tener nada si no se realiza una validacion
oportuna de lo que tenemos. El comando del rman backup validate database simulara un respaldo, revisando la existencia de
los archivos especificados, asegurandose que no estan corruptos pero sin realizar el juego de respaldo, este comando es util en
el caso de validacion o de forma proactiva encontrar cualquier problema y resolverlos antes de comprometer algun respaldo.
.
Operaciones de recuperacion:

La parte clave de cualquier plan de desastres, poder tener toda la informacion de la BD disponible para su uso es fundamental.

Recuperacion a nivel de bloques:

Cuando es una pequeña parte de bloques dañados, RMAN puede hacer la recuperacion de dichos bloques en lugar de hacer
una restauracion de todo un datafile completo, este tipo de recuperaciones reduce el tiempo de aplicación de redo logs y reduce
tambien de forma drastica la cantidad de I/O necesaria para la recuperacion, mientras la recuperacion se realiza los datafiles
afectados podrian estar en uso y disponibles para los usuarios.

El error que se presenta a la hora de un bloque corrupto es el siguiente, esta informacion se encuentra disponible a nivel de las
trazas generadas por la BD.

Tambien aparece en la vista dinamica V$DATABASE_BLOCK_CORRUPTION. La recuperacion por medio de RMAN es

sumamente facil:

Recuperacion del archivo de control

Si en algun raro evento se pierde el archivo de control, es facilmente recuperable por medio del rman con la instancia en modo
NOMOUNT.

Si no se utiliza un catalogo de recuperacion, se puede hacer una recuperacion a partir de una copia anterior de la siguiente
forma:
Restauracion de un Tablespace

Si algun disco conteniendo los datafiles de un tablespace se corrompe, la recuperacion es posible y la BD siempre se mantiene
abierta para los usuarios, esto no se puede hacer si el tablespace dañado es el SYSTEM. Luego de darnos cuenta del problema
(algun usuario llama quejandose) se puede revisar la vista dinamica V$DATAFILE_HEADER para ver que archivos necesitan
recueperacion:

Ademas de que cuando se revisa el archivo log de la BD nos damos cuenta de lo siguiente:

Luego de reparar lo dañado a nivel de hardware (en el caso que sea necesario) rman viene al rescate buscando inicialmente a
que tablespace corresponde el datafile numero 4
Para la recuperacion el TBS tiene que estar en fuera de linea, por lo que hay que forzarlo

Luego de ponerlo fuera de linea hay que proceder con la restauracion y recuperacion de dicho tablespace para luego ponerlo en
linea nuevamente:
El comando recover copia el archivo de nuestro ultimo juego de respaldo y el comando recover aplica los archive redo logs
necesarios para la correcta sincronizcion contra el archivo de control.

Restauracion de un datafile

El proceso es bastante similar a la recuperacion de un tablespace con la diferencia de utilizacion de un par de simples
comandos, se determina el numero del datafile dañado y se restaura y luego se recupera:
Restauracion de una BD por completo:

Este es el evento mas desastrozo y serio que podriamos ver como Administradores, y la solucion es tener unas solidas tecnicas
de respaldo y de recuperacion, ya se demostro que se puede recuperar partes de la BD con esfuerzo minimo y sin perdidas de
informacion. Como se deben de tomar medidas como las de multiplexacion de archivos de control y los redo logs en diferentes
discos los tendremos disponibles para la recuperacion de la BD con el RMAN.

Todo el proceso de recuperacion de la BD puede realizarse dentro del RMAN, primero montar la BD:

RMAN se conecta a la BD e identifica que no esta disponible, el siguiente paso es restaurar y recuperar laBD
La BD se encuentra disponible y lista para uso, RMAN utilizara la mejor o mas eficiente forma de recuperacion de la BD con la
idea de minimizar la cantidad de archivos accesados para reducir el I/O y tener la BD consistente y en linea en el menor tiempo
posible.

Validacion de los procesos de recuperacio:

La idea es tener una certeza que al momento que necesitemos nuestros respaldos para una recuperacion, estos esten
accesibles y listos para ser utilizados por el RMAN, el comando restore preview simula el proceso de recuperacion sin hacer la
recuperacion fisica de los archivos.
En el siguiente ejemplo se realiza una recuperacion de prueba del tablespace users:

Para el proceso de recuperacion RMAN utilizara un set de backup para un simple datafile del tablespace y todos los archive
redo logs necesarios para la sincronizacion del mismo.