Sie sind auf Seite 1von 34

Importacin y Exportacin FAQ

Oracle de exportacin y de importacin Utilidades FAQ:


NOTA: Los usuarios de Oracle 10g y versiones posteriores deben utilizar la bomba de los
datos expdp y impdp utilidades en lugar de los de mayor edad imp y exp utilidades descritas en este
documento.
Contenido
[ Ocultar ]

1 Cul es la importacin / exportacin y por qu hace uno lo necesita?


2 Cmo se usan las utilidades de importacin / exportacin?
3 Se puede exportar un subconjunto de una tabla?
4 Se puede controlar qu tan rpido se importa una tabla?
5 Se puede importar tablas a un espacio de tabla diferente?
6 Es necesario dejar caer / truncar los objetos antes de importar?
7 Puede uno importacin / exportacin entre las diferentes versiones de Oracle?
8 Se puede exportar a varios archivos? / Se puede superar el lmite de Gig Unix 2?
9 Cmo se puede mejorar el rendimiento de importacin / exportacin?
10 Cules son los problemas comunes de importacin / exportacin?
Cul es la importacin / exportacin y por qu se necesita? [ Editar ]
De Oracle de exportacin (exp) y las importaciones (IMP) utilidades se utilizan para realizar copia de
seguridad de base de datos lgica y la recuperacin. Al exportar, los objetos de base de datos se
vuelcan en un archivo binario que puede ser importado a otra base de datos Oracle.
Estas utilidades se pueden utilizar para mover datos entre diferentes mquinas, bases de datos o
esquema. Sin embargo, ya que utilizan un formato de archivo binario de propietario, slo pueden ser
utilizados entre bases de datos Oracle. No se puede exportar datos y esperar a importarlo a una base
de datos de Oracle no.
Varios parmetros estn disponibles para controlar qu objetos se exportan o importan. Para obtener
una lista de los parmetros disponibles, ejecute el exp o imp servicios pblicos con la ayuda =
yesparmetro.
Las utilidades de exportacin / importacin son comnmente utilizados para realizar las siguientes
tareas:

Copia de seguridad y recuperacin (pequeas bases de datos solamente, dicen <+ 50 GB, si es
ms grande, utilizar RMAN en su lugar)
Mover datos entre bases de datos Oracle en diferentes plataformas (por ejemplo a partir de Solaris
para Windows)
Reorganizacin de los datos / eliminar la fragmentacin base de datos (de exportacin, gota y
mesas re-importacin)
Actualizar las bases de datos de versiones muy antiguas de Oracle (cuando en el lugar las
actualizaciones no son compatibles con la base de datos del asistente de actualizacin ms)
Detectar la corrupcin de base de datos. Asegrese de que todos los datos se pueden leer
El transporte de los espacios de tablas entre bases de datos
Etctera

A partir de Oracle 10g , los usuarios pueden elegir entre utilizar las viejas utilidades imp / exp, o los recin
introducidos DataPump servicios pblicos, llamada expdp y impdp. Estas nuevas utilidades introducen muy
necesarias mejoras en el rendimiento, las exportaciones e importaciones en base a red, etc.
NOTA: En general, se recomienda no utilizar las exportaciones como el nico medio para realizar copias
de seguridad de una base de datos. mtodos de copia de seguridad fsicas (por ejemplo, cuando se
utiliza RMAN) son normalmente mucho ms rpido y compatible con el punto en la recuperacin basada
en el tiempo (aplicar archivelogs despus de recuperarse de una base de datos). Tambin, exp / imp no
es prctico para entornos de base de datos de gran tamao.

Cmo se puede usar las utilidades de importacin /


exportacin? [ Editar ]
Busque los archivos ejecutables y "imp" "exp" en el directorio / bin $ ORACLE_HOME. Uno puede
ejecutar de forma interactiva, utilizando parmetros de lnea de comandos, o el uso de archivos de
parmetros. Mira los parmetros imp / exp antes de comenzar. Estos parmetros se pueden enumerar
mediante la ejecucin de los siguientes comandos: " ayuda exp = yes " o " ayuda imp = yes ".
Los siguientes ejemplos demuestran cmo se pueden utilizar las utilidades imp / exp:

exp archivo scott / tiger = log = emp.dmp emp.log mesas = filas emp = s
ndices = sin
exp scott / tiger archivo = tablas emp.dmp = (EMP, departamento);
archivo / tigre imp scott = emp.dmp completa = yes
archivo imp scott / tiger = emp.dmp fromuser = scott scott touser = =
tablas departamento

El uso de un archivo de parmetros:

exp = ID de usuario scott / tiger @ ORCL parfile = export.txt

... Donde export.txt contiene:

BUFFER = 10000000
ARCHIVO = account.dmp
COMPLETO = n
PROPIETARIO = scott
SUBVENCIONES = y
COMPRESS = y

NOTA: Si no te gusta utilidades de lnea de comandos, puede importar y exportar datos con la interfaz
grfica de usuario "Administrador de esquema" que se incluye con Oracle Enterprise Manager (OEM).

Se puede exportar un subconjunto de una tabla? [ Editar ]


De Oracle 8i se puede utilizar la consulta = parmetro de exportacin para descargar selectivamente un
subconjunto de los datos de una tabla. Puede que tenga que escapar caracteres especiales en la lnea
de comandos, por ejemplo: query = \ ", donde deptno = 10 \" . Mira estos ejemplos:

exp scott tablas / tigre = emp consulta = "donde deptno = 10"


exp scott / tiger archivo = abc.dmp tablas de consulta = abc = \ "donde
el sexo = f \ '\' \" filas = yes

si se enfrentan a la siguiente problema


EXP-00056: EXP-00000: Exportacin terminada sin xito

exp nombre de usuario / contrasea @ ipAddress: portNumber / serviceName

Se puede controlar qu tan rpido se importa una tabla? [ Editar ]


Si usted necesita para controlar la forma en filas rpida importados de un trabajo de importacin
corriendo, pruebe uno de los mtodos siguientes:
Mtodo 1:

seleccione substr (sql_text, Instr (sql_text, 'en "'), 30) nombre_tabla,


rows_processed,
redonda ((sysdate-to_date ( 'HH24 aaaa-mm-dd: MI: SS'
first_load_time,)) * 24 * 60,1) minutos,
trunc (rows_processed / ((sysdate-to_date (first_load_time,
'HH24 aaaa-mm-dd: mi: ss')) * 24 * 60)) rows_per_min
sys.v_ de $ sqlarea
donde sql_text como 'INSERT% EN "%'
y COMMAND_TYPE = 2
y open_versions> 0;

Para que esto funcione hay que estar en Oracle 7.3 o superior (7.2 tambin podra estar bien). Si la
importacin tiene ms de una tabla, esta declaracin slo mostrar informacin acerca de la tabla actual
est importando.

Mtodo 2:
Utilizar el parmetro de importacin REACCIN = N. Este parmetro le dir IMP para mostrar un punto
por cada N filas importadas. Por ejemplo, la retroalimentacin = 1000 mostrar un punto despus de
cada fila 1000.

Se puede importar tablas para un espacio de tablas


diferente? [ Editar ]
Oracle ofrece ningn parmetro para especificar un espacio de tabla diferente para importar datos. Los
objetos se pueden volver a crear en el espacio de tablas que se exportaron originalmente. Uno puede
alterar este comportamiento siguiendo uno de estos procedimientos:
Pre-crear la tabla (s) en el espacio de tabla correcta:

Importe el archivo de volcado utilizando la opcin indexfile =


Editar el indexfile. Retire las observaciones y especificar los espacios de tabla correctos.
Ejecutar este indexfile en contra de su base de datos, esto crear las tablas necesarias en la tabla
adecuados
Importe la tabla (s) con la opcin IGNORE = Y.
Cambiar el espacio de tabla por defecto para el usuario:

Revocar el privilegio "UNLIMITED TABLESPACE" por parte del usuario


Revocar la cuota del usuario desde el espacio de tabla desde donde se exporta el objeto. Esto
obliga a la utilidad de importacin para crear tablas en tabla predeterminado del usuario.
Hacer que el espacio de tabla a la que desea importar el espacio de tabla por defecto para el
usuario
Importe la tabla
Es necesario dejar caer / truncar los objetos antes de
importar? [ Editar ]
Antes de que uno importaciones filas en tablas ya pobladas, es necesario truncar o eliminar estas tablas
para deshacerse de los datos antiguos. Si no es as, los nuevos datos se aadirn a las tablas
existentes. Uno siempre debe caer secuencias existentes antes de volver a importar. Si las secuencias
no se eliminan, generarn nmeros incompatibles con el resto de la base de datos.
Nota: Tambin es aconsejable colocar los ndices antes de importar para acelerar el proceso de
importacin. Los ndices pueden ser fcilmente recreadas despus de que los datos se importan
correctamente.

Puede uno importacin / exportacin entre las diferentes versiones


de Oracle? [ Editar ]
Las diferentes versiones de la utilidad de importacin son compatibles hacia arriba. Esto significa que
uno puede tomar un archivo de exportacin creado a partir de una vieja versin de exportacin, y la
importacin utilizando una versin posterior de la utilidad de importacin. Esto es bastante una forma
eficaz de actualizar una base de datos de una versin de Oracle a la siguiente.
Oracle tambin enva algunos scripts catexpX.sql anteriores que se pueden ejecutar como usuario SYS
permitan versiones exp / imp de ms edad de trabajar (por compatibilidad hacia atrs). Por ejemplo, uno
puede ejecutar $ ORACLE_HOME / RDBMS / admin / catexp7.sql en una base de datos Oracle 8 para
permitir que las utilidades de Oracle 7.3 exp / imp para correr contra una base de datos Oracle 8.

Se puede exportar a varios archivos? / Se puede superar el lmite


de Gig Unix 2? [ Editar ]
A partir de Oracle8i, la utilidad de exportacin soporta mltiples archivos de salida. Esta caracterstica
permite a las grandes exportaciones que se dividen en archivos cuyo tamao no exceder los lmites del
sistema operativo (FILESIZE = parmetro). Cuando la importacin proceda de exportacin de varios
archivos debe proporcionar los mismos nombres de archivo en la misma secuencia en el archivo =
parmetro. Mira este ejemplo:

exp Scott / Tiger de FILE = D: F1.dmp, E: F2.dmp FILESIZE = 10 m = LOG


scott.log

Utilice la tcnica siguiente si utiliza una versin de Oracle 8i antes de:


Crear un comprimido de exportacin sobre la marcha. Dependiendo del tipo de datos, es probable que
pueda exportar hasta 10 gigabytes en un solo archivo. En este ejemplo se utiliza gzip. Ofrece la mejor
compresin que conozco, pero tambin se puede sustituir con zip, comprimir o lo que sea.

# Crear una canalizacin con nombre


mknod exp.pipe p
# Leer la tubera - salida al archivo zip en el fondo
gzip <exp.pipe> scott.exp.gz y
# Alimentar la tubera
exp userid = archivo de scott / tiger = exp.pipe ...

Importar directamente desde una exportacin comprimido:


# Crear una tubera nombre
mknod imp_pipe p
# Leer el archivo zip y salida a la tubera
gunzip <exp_file.dmp.gz> imp_pipe y
# Alimentar la tubera
imp sistema de archivos SID @ pwd / = log = imp_pipe imp_pipe.log ...

En caso de sistema de baja el rendimiento, es mejor agregar el parmetro RecordLength con pequeo
valor para asegurar que gzip tiene tiempo suficiente para extraer los datos antes de imp lo lee:

sistema de imp / pwd @ sid = RecordLength archivo 4096 = log = imp_pipe


imp_pipe.log ...

Cmo se puede mejorar el rendimiento de importacin /


exportacin? [ Editar ]
EXPORTAR:

Ajuste el parmetro BUFFER a un valor alto (por ejemplo, 2Mb - entr como un entero "2000000")
Ajuste el parmetro RecordLength a un valor alto (por ejemplo, 64Kb - introducida como un entero
"64000")
El uso directo = yes (exportacin modo directo)
Detener aplicaciones innecesarias para liberar recursos para su trabajo.
Si ejecuta varias sesiones de exportacin, garantizar que escriben a diferentes discos fsicos.
NO exportar a un sistema de archivos NFS montado. Se llevar para siempre.
IMPORTAR:

Crear una indexfile para que pueda crear ndices despus de haber importado los datos. Para ello,
establezca indexfile a un nombre de archivo y luego de importacin. No hay datos sern
importados, pero se crear un archivo que contiene las definiciones de ndice. Debe editar este
archivo despus y suministrar las contraseas de los esquemas de todas las sentencias
CONNECT.
Coloque el archivo a importar en un disco fsico independiente de los archivos de datos de Oracle
Aumentar DB_CACHE_SIZE (DB_BLOCK_BUFFERS anteriores a 9i) considerablemente en el
archivo SID.ora $ init
Ajuste el LOG_BUFFER de un gran valor y el orculo de reinicio.
Deja de registro de rehacer de archivado si se est ejecutando (ALTER NOARCHIVELOG base de
datos;)
Crear un espacio de tabla grande con un segmento de cancelacin grande por dentro. Establecer
todos los dems segmentos de rollback fuera de lnea (excepto el segmento de cancelacin
SISTEMA, por supuesto). El segmento de cancelacin debe ser tan grande como su mayor mesa
(creo?)
Utiliza COMMIT = N en el archivo de parmetros de importacin, si se lo puede permitir
Utilizar las estadsticas = ninguno en el archivo de parmetros de importacin de evitar requiere
mucho tiempo para importar las estadsticas
Recuerde que debe ejecutar el indexfile creado previamente

Cules son los problemas / exportacin de importacin


comunes? [ Editar ]
ORA-00001 : restriccin nico (...) viol
Est importando las filas duplicadas. Utilice IGNORE = S para saltar tablas que ya existen (imp
dar un error si se vuelve a crear el objeto).

ORA-01555 : Instantnea demasiado viejo


Pedir a los usuarios que dejar de trabajar mientras se est exportando o intente utilizar un
parmetro CONSISTENTE = NO

ORA-01562 : No se ha podido extender segmento de cancelacin


Crear grandes segmentos de anulacin o conjunto de parmetros COMMIT = Y al importar

IMP-00015: Declaracin fall ... objeto ya existe ...


Utilice el parmetro IGNORE = Y importacin de ignorar estos errores, pero tenga cuidado ya
que podra terminar con las filas duplicadas.

Otra pagina web

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. Parar la BD y el SO
2. Arrancar en modo superusuario.
3. Realizar copia de todos los ficheros del sistema de ficheros
4. 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 backupconsiste 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
proceso RECO 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 puestooffline sin un checkpoint,
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 ficheros redo 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 modoARCHIVELOG. 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
(por tablespaces), 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 Defecto Descripcin

USERID
el username/password del usuario que efectua
indefinido
el export.

BUFFER
dependiente
El tamao en bytes del buffer utilizado.
del SO
FILE expdat.dmp el nombre del fichero destino.
GRANTS Yes indica si se exportan tambin los derechos.
INDEXES Yes indica si se exportan tambin los ndices.

ROWS
indica si se exportan tambin las filas de las
Yes
tablas, o slo las definiciones de las tablas.
CONSTRAINTS Yes indica si se exportan tambin las restricciones.
COMPRESS Yes indica si se exporta en modo comprimido.
FULL No indica si se exporta la BD entera.

OWNER
una lista de usuarios cuyos objetos se quieren
usuario actual
exportar.
TABLES indefinido la lista de tablas a exportar.

RECORDLENGTH
dependiente
la longitud en bytes del registro del fichero.
del SO
INCTYPE indefinido el tipo de export incremental.
indica si se anota el export incremental en las
RECORD Yes
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
de rollback, 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 logson 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:
RE
[U SCIN
[U
[U OG
NVIIL
T
T E
BR
LCC
T
C
A [AK
IA
M
H U
N
E
ATP
C
N
UfO
E
G M
eL
c
E
C A
]h TT
a]N
ent
O ICr]o]
eR O[FLRFO
ILM
E]'localizacion'][BD]

Las opciones entre corchetes son opcionales:

AUTOMATIC 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.
UNTIL 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.

Recuperacin de un tablespace

La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando


de recuperacin es el siguiente:
RT
EA
CB
OL
VES
RP[AC
UE
TO
nMAT
ombIC
re]_t[F
aR
bO
leM
sp'ac
loceali
[,znaci
omobn'] ablespace]
re_t

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 del tablespace 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:
RD
EC
AOVFI
TAER
LE[AnUoT
mOb
M ATIC
re_fi
ch][er
FR
oO[,M
no'lm
ocbalizaci
choer
re_fi n'o]]

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 Defecto Descripcin

USERID
el username/password del usuario que efectua
indefinido
el import.

BUFFER
dependiente
El tamao en bytes del buffer utilizado.
del SO
FILE expdat.dmp el nombre del fichero de exportacin a importar.
indica si se muestran los contenidos del fichero de
SHOW No
exportacin, sin importar ningn dato.

IGNORE
indica si ignorar los errores producidos al importar
Yes
un objeto que ya existe en la BD.
GRANTS Yes indica si se importan tambin los derechos.
INDEXES Yes indica si se importan tambin los ndices.

ROWS
indica si se importan tambin las filas de las
Yes
tablas.
FULL No indica si se importan el fichero entero.

FROMUSER
una lista de los usuarios cuyos objetos se han
Indefinido
exportado.

TOUSER
una lista de los usuarios a cuyo nombre se importan
Indefinido
los objetos.
TABLES indefinido la lista de tablas a importar.

RECORDLENGTH
dependiente
la longitud en bytes del registro del fichero.
del SO
INCTYPE indefinido el tipo de import incremental (SYSTEM o RESTORE).
indica si se efectua un commit despus de
COMMIT No importar cada fila. Por defecto, import efectua
un commit despus de cargar cada tabla.
PARFILE indefinido 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

Backup desde la pagina de ORACLE

RMAN: Como hacer para Restaurar y/o Recuperar solo los "Tablespaces" esenciales.
Por Joel Prez & Yenugula Venkata RaviKumar (OCM)
Publicado en Junio 2014
Reciban estimados tecnlogos Oracle un cordial saludo. A travs del presente artculo, tendremos la
oportunidad de visualizar y adentrarnos un poco en el tema restauracin/recuperacin de base de datos (
BBDDs ) utilizando la opcin Skip Tablespace.
En el contexto de recuperaciones de BBDDs existen extensas y diversas tcnicas para llevar a feliz termino el
objetivo. Tal cual como un traje hecho a la medida, no se conocer de las medidas hasta no tener al cliente al
frente. Todos los casos siempre son distintos, las situaciones siempre son diversas en su mayora. En una
infraestructura que contenga una BBDD jams sabremos que va a fallar, ni bajo que condiciones ocurrir. De
nosotros depender tener la experticia a mano para resolver el evento con rapidez, sapiencia y eficiencia.
Los comandos y opciones de RMAN son como las clases distintas de bistures para un cirujano. Se utilizan de
forma adecuada y justa de acuerdo al caso.
Planteemos el siguiente escenario: da 31 de cualquier mes del ao. 6:00pm de la tarde. Da oscuro y lluvioso
con mucha existencia de rayos. Un rayo impacta cerca de las instalaciones elctricas de la compaa y causa
un evento de desnivel de energa elctrica. La infraestructura de servidores, SAN y dems componentes no
estaban protegidos para desniveles de energa. Todos los componentes ( Servidores, SAN ) tuvieron cadas
abruptas de energa elctrica. Cuando ya la misma estaba restablecida, se decide encender los equipos y
aparece el siguiente mensaje al ejecutar el startup de la BBDD; . problemas con el datafile 1, ORA-01110:
data file 1. el de system . BBDD de 400GB ( 100GB en data con perfil transaccional OLTP activo y
300GB en histricos ).
Tiempo de Recuperacin total estimado : 8 horas.
Misin: recuperar la BBDD lo ms pronto posible para poder realizar el cierre del mes antes de las 12:00 de la
media noche.
Particularidad del caso: solo 100GB de data son los ms importantes y claves para el cierre, los otros 300GB
son de histricos. Ambas divisiones del negocio ( Transaccional e Histrico ) se encuentran en Tablespaces
bien distribuidos.
Pregunta: hay alguna opcin para recuperar la BBDD solo con los Tablespaces necesarios para el cierre con
opcin a recuperar el resto posteriormente ?
Respuesta: si si hay una opcin: SKIP TABLESPACE de RMAN
Escenario: tenemos un caso de fallo total de la BBDD respecto a sus datafiles, deseamos recuperar de
forma inmediata solo aquellos crticos para el negocio y posteriormente recuperaremos el resto manteniendo
una consistencia lineal en la historia de la data. Veamos como hacerlo:
Nota: se utilizo Oracle Database 10gR2 para el presente caso pero la misma es valida para todas las
versiones superiores de Oracle incluyendo Oracle Database 12c.
BBDD Origen: MYDB
Datafiles en Filesystem: /tmp/MYDB
Modo Archive: Activo
Visualizacin de Datafiles y Tablespaces
Reconocimiento de Datafiles:
[oracle@MyjpServer ~]$ export ORACLE_SID=MYDB
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.5.0 - Production on Wed Aug 8 15:10:36 2012
Copyright (c) 1982, 2010, Oracle. All Rights Reserved.
Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
/tmp/MYDB/users01.dbf
/tmp/MYDB/sysaux01.dbf
/tmp/MYDB/undotbs01.dbf
/tmp/MYDB/system01.dbf
SQL> select tablespace_name from dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS

SQL> archive log list


Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1
Next log sequence to archive 1
Current log sequence 1
SQL>
SQL>

Visualizado de archivos fsicos de BBDD:

[oracle@MyjpServer ~]$ cd /tmp/MYDB/


[oracle@MyjpServer MYDB]$ ls -lt
total 902384
-rw-r----- 1 oracle oinstall 7061504 Aug 8 15:10 control01.ctl
-rw-r----- 1 oracle oinstall 7061504 Aug 8 15:10 control02.ctl
-rw-r----- 1 oracle oinstall 7061504 Aug 8 15:10 control03.ctl
-rw-r----- 1 oracle oinstall 52429312 Aug 8 15:10 redo01.log
-rw-r----- 1 oracle oinstall 251666432 Aug 8 15:05 sysaux01.dbf
-rw-r----- 1 oracle oinstall 461381632 Aug 8 15:05 system01.dbf
-rw-r----- 1 oracle oinstall 26222592 Aug 8 15:05 undotbs01.dbf
-rw-r----- 1 oracle oinstall 52429312 Aug 8 15:00 redo02.log
-rw-r----- 1 oracle oinstall 52429312 Aug 8 15:00 redo03.log
-rw-r----- 1 oracle oinstall 5251072 Aug 8 15:00 users01.dbf
-rw-r----- 1 oracle oinstall 20979712 Aug 8 14:59 temp01.dbf
[oracle@MyjpServer MYDB]$

Creacin de tablespace TBSP_JP


En el tablespace TBSP_JP estar alojada la informacin equivalente a la data histrica de la cual hicimos
mencin en el planteamiento del escenario.
SQL> create tablespace tbsp_jp
2 datafile '/tmp/MYDB/tbsp_jp01.dbf' size 30m;
Tablespace created.
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
TBSP_JP

6 rows selected.
SQL> select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/tmp/MYDB/users01.dbf
/tmp/MYDB/sysaux01.dbf
/tmp/MYDB/undotbs01.dbf
/tmp/MYDB/system01.dbf
/tmp/MYDB/tbsp_jp01.dbf

SQL>

Creacion de Usuario jp
El usuario jp contendr data de muestra que se utilizara para comprobar el concepto de recuperacin parcial
de la BBDD.
SQL> create user jp identified by jp
2 default tablespace TBSP_JP
3 quota unlimited on TBSP_JP;
User created.

SQL> grant create session, create table to jp;

Grant succeeded.

SQL>

SQL> conn jp/jp


Connected.
SQL>
SQL> create table MyjpTable ( c1 number );

Table created.

SQL> insert into MyjpTable values (1000);

1 row created.

SQL> commit;

Commit complete.

SQL>
SQL> select OWNER, TABLESPACE_NAME from dba_segments
2 where SEGMENT_NAME='MYJPTABLE';

OWNER TABLESPACE_NAME
------------------------------ ------------------------------
JP TBSP_JP

Asegurado de la transaccin en Archive Redo Logs:


SQL> alter system switch logfile;
System altered.
SQL>

Backup Full de la BBDD


Realizamos un backup full a la BBDD
SQL> ho rman target /
Recovery Manager: Release 10.2.0.5.0 - Production on Wed Aug 8 15:20:54 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: MYDB (DBID=2705782573)
RMAN> backup database;
Starting backup at 08/08/2012
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=144 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/tmp/MYDB/system01.dbf
input datafile fno=00003 name=/tmp/MYDB/sysaux01.dbf
input datafile fno=00005 name=/tmp/MYDB/tbsp_jp01.dbf
input datafile fno=00002 name=/tmp/MYDB/undotbs01.dbf
input datafile fno=00004 name=/tmp/MYDB/users01.dbf
channel ORA_DISK_1: starting piece 1 at 08/08/2012
channel ORA_DISK_1: finished piece 1 at 08/08/2012
piece handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/
2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp tag=TAG20120808T152111
comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 08/08/2012
channel ORA_DISK_1: finished piece 1 at 08/08/2012
piece handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/
2012_08_08/o1_mf_ncsnf_TAG20120808T152111_825p31hm_.bkp tag=TAG20120808T152111
comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 08/08/2012
RMAN>

Simulamos un crash de BBDD


Removiendo todos los datafiles
SQL> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
/tmp/MYDB/users01.dbf
/tmp/MYDB/sysaux01.dbf
/tmp/MYDB/undotbs01.dbf
/tmp/MYDB/system01.dbf
/tmp/MYDB/tbsp_jp01.dbf

SQL> ho rm /tmp/MYDB/*.dbf
SQL>
SQL> ho ls -lt /tmp/MYDB/
total 174504
-rw-r----- 1 oracle oinstall 7061504 Aug 8 15:25 control01.ctl
-rw-r----- 1 oracle oinstall 7061504 Aug 8 15:25 control02.ctl
-rw-r----- 1 oracle oinstall 7061504 Aug 8 15:25 control03.ctl
-rw-r----- 1 oracle oinstall 52429312 Aug 8 15:24 redo01.log
-rw-r----- 1 oracle oinstall 52429312 Aug 8 15:24 redo02.log
-rw-r----- 1 oracle oinstall 52429312 Aug 8 15:24 redo03.log

SQL>
Se intenta consultar la tabla del schema jp. Obtenemos el mensaje de error por crash de instancia. Se
intenta realizar el proceso de startup y surge el error esperado relacionado con la no ubicacin del primer
datafile que el mecanismo de BBDDs Oracle comprueba.

SQL> select * from jp.myjptable;


select * from jp.myjptable
*
ERROR at line 1:
ORA-03135: connection lost contact

SQL> exit;

[oracle@MyjpServer ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 - Production on Wed Aug 8 15:26:35 2012


Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.
Total System Global Area 583008256 bytes
Fixed Size 2097984 bytes
Variable Size 159386816 bytes
Database Buffers 415236096 bytes
Redo Buffers 6287360 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '/tmp/MYDB/system01.dbf'

Recuperando solo una parcialidad de la BBDD


Estando la instancia en modo mount se procede a realizar la tcnica principal del artculo. Restaurar la
BBDD con excepcin de Tablespaces denotados en la sentencia. Si se desean agregar mas tablespaces a
ser obviados en el restore se adicionan con separacin de ,. Para el presente caso solo estaremos
realizando el skip del tablespace tbsp_jp.
SQL> ho rman target

Recovery Manager: Release 10.2.0.5.0 - Production on Wed Aug 8 15:26:54 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: MYDB (DBID=2705782573, not open)

RMAN> restore database skip tablespace tbsp_jp;

Starting restore at 08/08/2012


using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00001 to /tmp/MYDB/system01.dbf

restoring datafile 00002 to /tmp/MYDB/undotbs01.dbf


restoring datafile 00003 to /tmp/MYDB/sysaux01.dbf
restoring datafile 00004 to /tmp/MYDB/users01.dbf
channel ORA_DISK_1: reading from backup piece
/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/
2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp

channel ORA_DISK_1: restored backup piece 1


piece
handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/2012_08_
08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp tag=TAG20120808T152111
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 08/08/2012
RMAN>

Recover Database
Si intentamos aplicar la sentencia de recover database sin especificar el tablespace que no se restauro,
obtendremos el mensaje de que el mismo debe ser restaurado. Para la aplicacin de esta tcnica, el recover
debe poseer la misma clausula aplicada al restore database.
RMAN> recover database;
Starting recover at 08/08/2012

using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/08/2012 15:31:06
RMAN-06094: datafile 5 must be restored
RMAN> recover database skip tablespace tbsp_jp;

Starting recover at 08/08/2012


using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 08/08/2012
RMAN>

Startup
Una vez aplicada la tcnica, procedemos a la apertura de la BBDD. El mecanismo de consistencia de
controlfiles-datafiles no esta anuente de nuestro propsito y realiza el chequeo de todos los datafiles existente
en el diccionario de datos. Siendo as, obtenemos el mensaje de que el Datafile 5 no es identificable en el
sistema operativo.
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup
ORACLE instance started.
Total System Global Area 583008256 bytes
Fixed Size 2097984 bytes
Variable Size 159386816 bytes
Database Buffers 415236096 bytes
Redo Buffers 6287360 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/tmp/MYDB/tbsp_jp01.dbf'
Datafile Offline
A todos los Datafiles que deseemos obviar en la recuperacin, debemos establecerle estatus offline
cuando la instancia se encuentre en modo mount. De esta manera la BBDD podr aperturarse de forma
perfecta. Al final de esta etapa tendremos la BBDD abierta con la recuperacin de todos los tablespaces a
excepcin del tablespace tbsp_jp
SQL> alter database datafile 5 offline;
Database altered.
SQL>
SQL>
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup
ORACLE instance started.
Total System Global Area 583008256 bytes
Fixed Size 2097984 bytes
Variable Size 159386816 bytes
Database Buffers 415236096 bytes
Redo Buffers 6287360 bytes
Database mounted.
Database opened.
SQL>
SQL> select * from dual;
D
-
X
SQL>

Consulta a la data del Schema jp


Si tratamos de consultar la data de cualquier objeto contenido en el tablespace tbsp_jp naturalmente
obtendremos el mensaje de la no disponibilidad del mismo.
SQL> select * from jp.myjptable;
select * from jp.myjptable
*
ERROR at line 1:
ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5: '/tmp/MYDB/tbsp_jp01.dbf'
SQL>

Continuidad de Trabajo
La BBDD podr seguir trabajando de forma perfecta acumulando data de forma consistente
SQL> alter system switch logfile;
System altered.
SQL> r
1* alter system switch logfile
System altered.
SQL>

Restaurado del Tablespace tbsp_jp


Cuando ya estemos disponible para recuperar parte de la data que no se restauro lo realizamos de la manera
tradicional como se lleva a cabo el restore & recover de un tablespace regular. El tablespace ser
restaurado; los archives sern aplicados hasta el scn mas actualizado de la BBDD para que as, este
tablespace puede formar parte de la BBDD. Esta operacin se esta llevando a cabo con la BBDD abierta.
SQL> ho rman target /
Recovery Manager: Release 10.2.0.5.0 - Production on Wed Aug 8 15:38:04 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: MYDB (DBID=2705782573)
RMAN> restore tablespace tbsp_jp;
Starting restore at 08/08/2012
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=143 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00005 to /tmp/MYDB/tbsp_jp01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/product/10.2.0/
flash_recovery_area/MYDB/backupset/2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p
2868_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/
2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp tag=TAG20120808T152111
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 08/08/2012
RMAN> recover tablespace tbsp_jp;
Starting recover at 08/08/2012
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 3 is already on disk as file
/u01/app/oracle/product/10.2.0/
flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_3_825p8g7n_.arc
archive log thread 1 sequence 4 is already on disk as file
/u01/app/oracle/product/10.2.0/
flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_4_825px555_.arc
archive log thread 1 sequence 5 is already on disk as file
/u01/app/oracle/product/10.2.0/
flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_5_825q0x3v_.arc
archive log thread 1 sequence 6 is already on disk as file
/u01/app/oracle/product/10.2.0/
flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_6_825q0yof_.arc
archive log
filename=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/archivelog/
2012_08_08/o1_mf_1_3_825p8g7n_.arc thread=1 sequence=3
archive log
filename=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/archivelog/
2012_08_08/o1_mf_1_4_825px555_.arc thread=1 sequence=4
media recovery complete, elapsed time: 00:00:01

Finished recover at 08/08/2012


RMAN> sql 'alter tablespace tbsp_jp online';
sql statement: alter tablespace tbsp_jp online
RMAN>

Chequeo del trabajo realizado


Se visualiza el tablespace online y nuestra data recuperada perfectamente
SQL> select TABLESPACE_NAME, STATUS from dba_tablespaces;
TABLESPACE_NAME STATUS
------------------------------ ---------
SYSTEM ONLINE
UNDOTBS1 ONLINE
SYSAUX ONLINE
TEMP ONLINE
USERS ONLINE
TBSP_JP ONLINE
6 rows selected.
SQL>

SQL> select * from jp.myjptable;


C1
----------
1000
SQL>

Nota Importante: esta tcnica solo se podr llevar a cabo siempre y cuando no exista la necesidad de abrir la
BBDD en modo resetlogs. Si por algn motivo la BBDD tuviese que apertura se en modo resetlogs ya la
tcnica no aplicara, debido a que el Controlfile obtendra un nuevo nivel de incarnation y los Backups
anteriores ya no tendran validez. Para lograr una recuperacin sin necesidad de apertura de la BBDD en
modo resetlogs se tendr que disponer de forma perfecta del ultimo grupo de redo log en estatus current al
momento de la falla. Si hubiese perdida de al menos el grupo de Redo Log en estatus current al momento
de la falla, se tendr que restaurar completamente la BBDD y siendo ese el escenario ya no se podra realizar
una recuperacin parcial con opcin a recuperacin complementaria posterior tal cual como se desarrollo en
el articulo.
Conclusin
Voila de esta manera experimentamos una recuperacin parcial de una BBDD en base a un objetivo de
restablecimiento pronto de servicios. La misma estaba basada en una arquitectura lgica de negocio de
separacin de Tablespaces ( OLTP & DWH Histricos ).
Para una empresa que posea tiempos de recuperaciones muy lentos, causados por hardware, disco, SAN,
etc. Esta tcnica podra representar una opcin rpida de poseer disponible parte de la BBDD sin necesidad
de depender de un restaurado total.

Hago remembranzas de una ocasin cuando tuve un caso parecido; un cliente tenia una BBDD de
aproximadamente 1TB. Tuvo una falla y la recuperacin tardaba 2 das aproximadamente. En esa caso se
recuperaron los Tablespaces claves de una BBDD Oracle ( system, undo, sysaux, etc ) y los claves del
negocio y de forma progresiva se fue restaurando el resto de los Tablespaces. Una vez abierta la BBDD se
establecio recuperaciones de Tablespaces paralelas a cargo de los nodos del RAC y as se acortaron los
tiempos. Era una infraestructura de RAC, en un nodo se establecieron las recuperaciones de ciertos
Tablespaces y en el otro nodo se establecieron los restantes. Los cuellos de botellas formados por exceso
de trabajo a nivel de I/O eran recprocos porque ambos nodos posean el storage compartido como es
natural en RAC pero el consumo de CPU en la actividad si era individual para cada nodo.

As como este caso podrn existir muchos ms. Lo importante para los diversos escenarios es conocer la
naturaleza implcita de cada uno de ellos, poseer un amplio abanico de tcnicas y comandos para poder
ajustarse a las variantes del mismo.
Joel es un experto DBA con ms de 12 aos de experiencia, especializado en bases de datos con especial
nfasis en la soluciones de alta disponibilidad (RAC, Data Guard, y otras). Es un conferencista habitual en
eventos de Oracle como: OTN LAD TOUR y otros. Consultor Internacional con trabajos en ms de 20 pases
alrededor del mundo. Fue el primer latinoamericano en ser nombrado "Experto OTN" en el ao 2003, Oracle
ACE ao 2004 y actualmente Oracle ACE Director.

Yenugula Venkata Ravikumar es un DBA con ms de 15 aos de experiencia especializada en entornos de


alta disponibilidad de bases de datos (RAC, Data Guard, entre otros), afinamiento y rendimiento, migraciones,
backup y recuperacin, Oracle Exadata X2 y X3, es experto en sistemas operativos tales como AIX, HP-UX y
Linux. Ha participado como conferencista en varios eventos de Oracle en la India, donde reside actualmente.
Obtuvo el ttulo "Oracle Certified Master (OCM 10g)" en el 2009.