Tarea Uapa

Universidad Abierta Para Adultos
UAPA
Escuela de Ingeniería y Tecnología
Carrera
Asignatura:
Sistema de base de datos
2021-2-FGI-106-Virtual201-1
Tema:
Tarea semana 5
Matricula:
Facilitador:
Santo Domingo, República Dominicana
mayo 2021
Estimado estudiante
Le recomiendo que estudie
La vida no es tan fácil como usted cree, azarozo
Idiota es una palabra derivada del griego ἰδιώτης, idiōtēs ("persona privada de habilidad

profesional", "compatriota", "individuo"), de ἴδιος, idios (privado, uno mismo).1 Empezó
usándose para un ciudadano privado y egoísta que no se ocupaba de los asuntos
públicos. En latín, la palabra idiota (una persona normal y corriente) precedió al término del
latín tardío que significa «persona sin educación» o «ignorante». Su significado y la forma
moderna data de alrededor del año 1300, del francés antiguo idiote (sin educación o
persona ignorante). En 1487 la palabra idiotez pudo haber sido el modelo de analogía de
las palabras «profeta» y de «la profecía». En la baja Edad Media, el término idiota se
utilizaba para designar a los monjes incapaces de leer las Sagradas Escrituras 2.
Síntomas
otección en tus Backup
Una copia de seguridad o backup es un duplicado de los documentos, archivos, fotos,
videos, etc. que se encuentran en un ordenador. Se trata de un componente muy
importante de la seguridad de una empresa, ya que existen desastres muy variados que
podrían provocar la pérdida de toda esta información. Las causas más frecuentes de pérdida
de datos son ataques por virus y malware, fallos de hardware o error humano.
Sin una protección frente a esos posibles escenarios se corre un riesgo importante de echar a
perder muchas horas de trabajo. Hay que tener en cuenta que el 93% de las empresas que
pierden sus datos durante 10 o más días debido a un desastre quiebran antes de un
año (National Archives & Records Administration in Washington).
En artículos anteriores te hemos explicado qué tipo de copia de seguridad es la que más

conviene a tu empresa. Si una que realiza backups del sistema completo o si una que lo hace
de solo algunos ficheros.
A continuación vamos a explicarte en qué consiste una copia de seguridad espejo, en inglés
mirror backup, una forma de proteger los archivos de una empresa doblemente.
Contenidos [ocultar]
 1 ¿Qué es una copia de seguridad espejo?
 2 ¿Cuándo se recomienda tener una copia de seguridad espejo?
 3 ¿Cómo conseguir una copia de seguridad espejo para tu empresa?
¿Qué es una copia de seguridad

espejo?
Una copia de seguridad espejo permite disponer de un servidor en casa del cliente (o
donde decida) y otro en otra localización. Por ejemplo, en las oficinas de la empresa de
seguridad informática que le gestiona los backup.
Con estos sistemas se dispone tanto de una copia en las oficinas de la empresa, como de una
copia fuera de ella con lo que los datos pueden ser recuperados aunque el desastre que
afecte a la oficina sea total.
¿Cuándo se recomienda tener una

copia de seguridad espejo?
Es imprescindible disponer de una copia de seguridad fuera de las oficinas en la que se
encuentran los datos originales. Algunos utilizan soluciones de copia en la nube, pero estas
soluciones aumentan su coste en función del volumen de datos protegidos y pueden llegar a
suponer un coste mensual muy elevado.
Una copia espejo es una solución ideal para empresas con volúmenes de datos
elevados que deseen mantener una copia fuera de las oficinas de forma automática sin unos
costes tan elevados.
¿Cómo conseguir una copia de

seguridad espejo para tu empresa?
Para saber qué tipo de copia de seguridad es más adecuada para tu empresa es
imprescindible consultarlo con expertos. De la misma forma, serán personas especializadas
en informática quienes te aconsejarán sobre la necesidad de realizar copias de seguridad
espejo y quienes implementarán esta opción a tu empresa. En Accensit te ofrecemos este
servicio, siempre trabajando mano a mano contigo y adaptándonos a los recursos de tu
negocio.
Como la confianza se gana poco a poco y queremos empezar con buen pie, te ofrecemos la
posibilidad de realizar un Diagnóstico Informático para tu empresa totalmente
gratis. ¡Contacta con nosotros!
By accensit_admin| julio 3rd, 2017|Seguridad Informática|
Para compartir esta historia, elija cualquier plataforma

FacebookTwitterLinkedinRedditTumblrGoogle+PinterestVkEmail
About the Author: accensit_admin
Buscar en el blog
Categorías
 Contacto @en
 Desarrollo de aplicaciones
 Infraestructura
 Recomendaciones
 Seguridad
 Seguridad Informática
 servicios
 Sin categorizar @en
Contacta con Nuestros Expertos
Nombre (requerido)
Correo electrónico (requerido)
Asunto
Mensaje
Enviar
Accensit
Expertos en seguridad tecnológica.
C/ Aribau 280
08006 Barcelona,
ESPAÑA
Tel.: 93 430 70 00

 Consultoría IT
 Desarrollo de software
 Mantenimiento de sistemas
 Seguridad de datos
 Quienes somos
 Contacto
 Blog Accensit
Términos Legales | Política de Cookies

Uso de cookies
Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario.
Si continúa navegando está dando su consentimiento para la aceptación de las
mencionadas cookies y la aceptación de nuestra política de cookies, pinche el e
References
There are no sources in the current document
ara conseguir un funcionamiento seguro de la BD y una pronta recuperaci�n

ante Fallas se necesita planear una estrategia de copias de seguridad, backup,
y de recuperaci�n, recovery, ya que de nada sirve pensar que estamos a salvo
de tales circunstancias, y que eso no nos puede pasar a nosotros. Y el primer
paso a dar es definir las caracter�sticas fundamentales de la implantaci�n,
porque mal vamos a conseguir unos objetivos si se desconocen o est�n
indefinidos. El segundo paso es establecer unos planes de copias de seguridad
y recuperaci�n que nos permitan asegurar los objetivos.
Junio de 2007.
Felipe Manriquez
Administraci�n de Bases de Datos Oracle
Carrera Ingenieria� Ejecuci�n Inform�tica
DUOC
fmanriquez@gmail.com
�
�ndice
1 Introducci�n al Backup and Recovery

1.1 Presentaci�n del Backup
1.2 Presentaci�n de la Recuperaci�n
2 Principios de Backup
2.1 Dise�o de la BD y Reglas B�sicas de Backup
2.2 Backups F�sicos� Administrados por Usuario DBA
2.2 Backups F�sicos� Administrados por Usuario DBA
2.3 Backups f�sicos Administrados con RMAN (Recovery
Manager)
2.4� Backups L�gicos
3 Principios de la Recuperaci�n
3.1 Definiciones y Conceptos
3.2 M�todos de Recuperaci�n
3.3 Recuperaci�n F�sica
3.4 Recuperaci�n L�gica
3.5 Recuperaci�n F�sica usando RMAN
1 Introducci�n al Backup and Recovery
Planificar y comprobar los procedimientos de backup del sistema es la �nica

garant�a que existe contra fallas del sistema, del SO, del software o cualquier
otro tipo de circunstancias.
Las causas de error en un sistema de BD pueden agruparse en las siguientes

categor�as:
 F�sicas
son causadas por Fallas del hardware, como por ejemplo
del disco o de la CPU.
 de Dise�o
son agujeros en el software, ya sea en el SO o en el
SGBD.
 de Funcionamiento
son causadas por la intervenci�n humana, debidos a
Fallas del DBA, configuraciones inapropiadas o mal
planteamiento de los procedimientos de backup.
 del entorno
como por ejemplo desastres naturales, Fallas de corriente,
temperatura excesiva.
De entre todas estas posibilidades, el DBA s�lo 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 m�s
cr�ticas en la disponibilidad de los sistemas, donde una BD caida puede
causar p�rdidas millonarias, puede ser interesante considerar los mecanismos
de protecci�n hardware y de redundancia que la tecnolog�a nos
proporciona:
 UPS o fuentes de corriente ininterrumpida,

 espejado de disco, o tecnolog�a RAID,
 Componentes duplicados,
 Sistemas redundantes.
Una de las m�s importantes decisiones que un DBA debe tomar es decidir si
arrancar la BD en modo ARCHIVELOG o no. Esta decisi�n tiene sus ventajas e
inconvenientes:
 Ventajas:
o Aunque se pierdan los archivos de datos, siempre se puede
recuperar la BD con una copia antigua de los archivos de datos y
los archivos de redo log archivados.
o Es posible realizar backups en caliente.
 Inconvenientes:
o Se necesitar� m�s espacio en disco, normalmente un disco
especial de destino de archiving, incluso en modalidad duplex .
o El trabajo del DBA se incrementa al tener que determinar el
destino del archivado de los redo log.
1.1 Presentaci�n del Backup

Los backups se pueden clasificar en f�sicos y l�gicos. Los f�sicos se
realizan cuando se copian los archivos que soportan la BD. Entre estos se
encuentran los backups del SO, los backups en fr�o y los backups en
caliente.
Los backups l�gicos s�lo 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 m�s sencillo de ejecutar, aunque consume

mucho tiempo y hace inaccesible al sistema mientras se lleva a cabo.
Aprovecha el backup del SO para almacenar tambi�n todos los
archivos 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 archivos del sistema de archivos
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 archivos sobre los que se asienta. Antes de
parar la BD hay que parar tambi�n todos las aplicaciones que
est�n trabajando con la BD. Una vez realizada la copia de los
archivos, 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 peque�a. Este tipo
de backup consiste en copiar todos los archivos
correspondientes a un tablespace determinado, los
archivos redo log archivados y los archivos de control. Esto para
cada tablespace de la BD.
Backups L�gicos 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
archivos
Una vez que se ha planeado una estrategia de backup y se ha probado,

conviene automatizarla para facilitar as� su cumplimiento.
1.2 Presentaci�n de la Recuperaci�n

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 cu�ndo 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 recuperaci�n 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 l�gica anterior. Si no se dispone de la copia l�gica, se
puede recuperar la BD en una instancia auxiliar, exportar la tabla
en cuesti�n de la instancia auxiliar e importarla en la instancia
operativa.
Fallas 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 selecci�n de una tabla que no existe. Estos
Fallas se recuperan autom�ticamente mediante un rollback de
la transacci�n que conten�a la sentencia fallida. El usuario
necesitar� volver a ejecutar otra vez la transacci�n cuando se
haya solucionado la causa del problema.
Fallas de Procesos
Es una terminaci�n anormal de un proceso. Si el proceso era

un proceso de usuario, del servidor o de una aplicaci�n
el PMON efectuar� la recuperaci�n 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.
Fallas de la Red
Algunas veces los Fallas en la red producen Fallas de proceso,

que son tratados por el PMON. Si en el error de red se ve
envuelta una transacci�n distribuida, una vez que se
reestablece la conexi�n, el proceso RECO resuelve los
conflictos autom�ticamente.
Fallas de Instancia
Pueden deberse a Fallas f�sicos o de dise�o del software que

hacen que alg�n proceso background caiga y la instancia con
�l. La recuperaci�n es autom�tica cuando se levanta la BD,
tomandose m�s o menos tiempo en la recuperaci�n.
Fallas del Sistema
Son los Fallas m�s peligrosos, no s�lo porque se pueden

perder datos, sino porque se tarda m�s tiempo en recuperar
que los otros Fallas. Adem�s se depende mucho de la
experiencia del DBA para levantar la BD r�pidamente y sin
p�dida (o casi) de datos.
Existen tres tipos de recuperaci�n en Oracle: a nivel de bloque, de thread y

f�sica.
Recuperaci�n de bloques
Es el mecanismo de recuperaci�n m�s simple, y se realiza

autom�ticamente. Se produce cuando un proceso muere justo
cuando est� cambiando un bloque, y se utilizan los
registros redo log en l�nea para reconstruir el bloque y
escribirlo en disco.
Recuperaci�n de threads
Se realiza autom�ticamente 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 recuperaci�n se efectua autom�ticamento cuando
la BD se levanta.
Recuperaci�n f�sica
Se realiza como respuesta a un comando RECOVER. Se utiliza para

convertir los archivos de backup en actuales, o para restaurar
los cambios que fueron perdidos cuando un archivo de datos fue
puesto offline sin un checkpoint, aplicando los archivo redo
log archivados y en l�nea.
2 Principios de Backup
Un backup v�lido es una copia de la informaci�n 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 archivos de
datos y en el archivado de los archivos redo log, se han de tener copias de los
archivos de datos, de los archivos de control, de los archivos redo log activos
y tambi�n de los archivados. Si se pierde uno de los archivos redo
log archivados se dice que se tiene un agujero en la secuencia de archivos.
Esto invalida el backup, pero permite a la BD ser llevada hasta el principio del
agujero realizando una recuperaci�n incompleta.
2.1 Dise�o de la BD y Reglas B�sicas

de Backup
Antes de nada, es muy importante entender ciertas reglas que determinan la
situaci�n de los archivos y otras consideraciones que afectar�n al esquema
de backup:
 Es recomendable archivar los archivos redo log en disco, y luego

copiarlos a cinta, pero siempre en un disco diferente del que soporta los
archivos de datos y de redo log activos.
 Los archivos 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 recuperaci�n. Adem�s, si se copian las
copias a cinta y se mantienen en el disco, se puede sobrevivir a diversos
Fallas de dispositivo.
 Se deber�an mantener diferentes copias de los archivos de control,
colocadas en diferentes discos con diferentes controladores.
 Los archivos redo log en l�nea deben estar multiplexados, con un
m�nimo de 2 miembros por grupo, residiendo cada miembro en un
disco distinto.
 Siempre que la estructura de la BD cambie debido a la inclusi�n,
borrado o renombrado de un archivo de datos o de redo log, se debe
copiar el archivo de control, ya que almacenan la estructura de la BD.
Adem�s, cada archivo a�adido tambi�n debe ser copiado. El archivo
de control puede ser copiado mientras la BD est� abierta con el
siguiente comando:
�
� SQL>
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 d�a.
3. Copiar todos los archivos redo log archivados cada cuatro horas. El
tama�o y el n�mero de ellos depender� de la tasa de transacciones.
4. Efectuar un export de la BD semanalmente en modo RESTRICT.
2.2 Backups F�sicos� Administrados por
Usuario DBA
Los backups f�sicos son aquellos que copian f�sicamente los archivos de la
BD. Existen dos opciones: en fr�o y en caliente. Se dice que el backup es en
frio cuando los archivos se copian con la BD est� detenida si servicios. En
caliente es cuando se copian los archivos con la BD abierta y funcionando.
Backup en Fr�o
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. Despu�s se copian los
archivos de datos, los de redo log y los de control, adem�s de los redo
log archivados y a�n no copiados.
Una buena idea es automatizar todo este proceso con

los scripts correspondientes, de modo que no nos olvidemos de copiar
ning�n archivo.
Por ejemplo, el siguiente script para Oracle 8i

#!/bin/sh
################################################
# Backup en frio para Base de Datos Oracle 8i. #
# 2000-02-29 JLM�� #
################################################
export BD
BACKUP=/tmp
export BACKUP
BD=$1;
LANG=es_ES@euro
export LANG
echo "***************************************************************"
echo "Respaldo $1 iniciado el `date +%c` ..."
echo
"****************************************************************"
echo " "
echo "Iniciando Respaldo en Frio de Archivos de Base de Datos $1"
echo " "
if [ -z "${BD}" ]
then
�� echo "Usar : ksh backup_frio <ORACLE_SID>"
�� exit 1
fi
######################################
# Seteo de las variables de ambiente #
######################################
export ORACLE_HOME=/u01/app/oracle/product/8.1.7
export NLS_LANG=spanish_spain.we8dec
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export ORACLE_SID=$BD
PATH=$ORACLE_HOME/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/us
r/local/jre:$PATH
export PATH
BLOCKSIZE=4096
###################
# Tensar la cinta #
###################
mt -f /dev/nst0 load
mt -f /dev/nst0 rewind
mt -f /dev/nst0 retension
###################################################
# Comprobamos que la base de datos este levantada #
###################################################
echo " "

echo "**************************************************"
echo "Verificando Status de Base de Datos $ORACLE_SID..."
echo "**************************************************"
echo " "
if [`ps -ef|grep -v grep|grep smon_$ORACLE_SID|wc -l` != 1 ]; then
�� echo "ERROR: Base de datos $ORACLE_SID no esta arrancada"
�� echo "�� Backup Abortado"
�� echo "-------------- FIN --------------------------"
�� exit 3
fi
echo "Base de Datos $ORACLE_SID esta online"
echo
#######################################
# Generamos fichero con los datafiles #
#######################################
echo " "

echo "**************************************************"
echo "Generando lista de Datafiles, Controlfiles y Redos..."
echo "**************************************************"
echo " "
sqlplus -s internal/ << FIN
set pagesize 0
set feedback off
set serveroutput off
spool $BACKUP/dbfiles.lst
select name from v\$controlfile
union
select name from v\$datafile
union
select member from v\$logfile;
spool off
exit
FIN
############################
# Bajamos la Base de Datos #
############################
echo " "

echo "**************************************************"
echo "Bajando Base de Datos $ORACLE_SID..."
echo "**************************************************"
echo " "
svrmgrl << FIN
connect internal;
shutdown immediate;
FIN
####################################
# Copia comprimida de los archivos #
####################################
archivos=" "
FICHEROS=`cat $BACKUP/dbfiles.lst`
for v_fichero in $FICHEROS
do
� echo $v_fichero
done
for v_fichero in $FICHEROS
do
� archivos=$archivos" "$v_fichero
done
echo " "

echo "**************************************************"
echo "Iniciando copia de los archivos a cinta..."
echo "**************************************************"
echo " "
tar cvf /dev/nst0 $archivos
tar cvf /dev/nst0 $BACKUP/dbfiles.lst
tar cvf /dev/nst0 /u01/app/oracle/admin/pfile/mpw/initmpw.ora
echo " "
echo "Copia de archivos a cinta finalizada"
echo " "
#############################
# Levantar la Base de Datos #
#############################
echo " "

echo "**************************************************"
echo "Levantando Base de Datos $ORACLE_SID..."
echo "**************************************************"
echo " "
svrmgrl << FIN
connect internal
startup
exit
FIN
echo " "
echo "Base de Datos $ORACLE_SID levantada"
echo " "
echo -n "Borrando lista de archivos..."
rm -f $BACKUP/dbfiles.lst
echo " OK"
echo " "
#echo -n "Expulsando cinta..."
#mt -f /dev/nst0 rewoffl
#echo " OK"
echo " "
echo "Respaldo en Fr�o finalizado"
echo " "
echo
"*********************************************************************
*******"
echo "Respaldo Base De Datos $1 finalizado el `date +%c`"
echo
"*********************************************************************
*******"
exit 0
Como este tipo de backup es una copia de los archivos de la BD, si estos
contienen alg�n tipo de corrupci�n, la traspasaremos a la copia de seguridad
sin detectarla. Por esto es importante comprobar las copias de seguridad.
Procedimiento Respaldo Offline o frio
1.- Bajar la base de datos (SHUTDOWN [NORMAL,| IMMEDIATE |

TRANSACTIONAL])
2.- Anote el layout f�sico de filesystems, podria ser necesario en caso de

falla de disco
3.- Hacer copias de todos los datafiles de tablespaces con comandos del
sistema operativo
4.- Hacer copias de todos los archivos de online redologs con comandos del
sistema operativo
5.- Hacer copias de todos los archivos de control con comandos del sistema
operativo
6.- Hacer copia del archivo de par�metros spfile o init%SID%.ora

Backup en Caliente
Si la implantaci�n de BD requiere disponibilidad de la misma 24h. al d�a, 7

dias a la semana no se pueden realizar backups en fr�o. Para efectuar
un backup en caliente debemos trabajar con la BD en modo ARCHIVELOG. El
procedimiento de backup en caliente es bastante parecido al fr�o. Existen dos
comandos adicionales: begin backup antes de comenzar y end backup al
finalizar el backup. Por ejemplo, antes y despu�s de efectuar
un backup del tablespace users se deber�an ejecutar las sentencias:
�
� SQL> alter tablespace users begin backup;

�� Aqui se utilizan commandos de S.O para
copiar los datafiles a la zona de respaldo

� SQL> alter tablespace users end backup;
As� como el backup en frio permit�a 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 archivos de datos
(por tablespaces), el actual archivo de control y todos los archivos redo
log archivados creados durante el periodo de backup. Tambi�n se
necesitar�n todos los archivos redo log archivados despu�s del backup en
caliente para conseguir una recuperaci�n total.
Procedimiento Respaldo Caliente

1.- Ejecute comando archive log list. Note que el valor para� Oldest
online log sequence es el redolog m�s antiguo requerido para usar en
el online backup

� SQL> archive log list;
� Database log mode�� Archive Mode
� Automatic archival�� Enabled
� Archive destination��
/u02/oradata/orion/archive
� Oldest online log sequence�� 672
� Next log sequence to archive�� 674
� Current log sequence�� 674
� SQL>

2.- Ejecute ALTER TABLESPACE nombre_tablespace BEGIN
BACKUP desde sqlplus. Esto prepara el respaldo online de los
datafiles del tablespace.

� SQL> alter tablespace users begin backup;

3.- Copie los datafiles por cada tablespace usando comandos de
sistema operativos o productos de terceros. Aseg�rese que las
copias residan en un� disco diferente al que se encuentran los
datafiles de producci�n.

4.- Ejecute ALTER TABLESPACE nombre_tablespace END BACKUP
desde sqlplus. Este paso completa el respaldo online del tablespace.

� SQL> alter tablespace users end backup;

5.- Repita pasos 2 al 4 hasta que todos los tablespaces se encuentren
respaldados. (Se except�an los tablespaces TEMPORALES)

6.- Ejecute comando archive log list nuevamente. Esta vez, note que el
valor para� Current log sequence. Este es el �ltimo redolog que
forma parte esencial del online backup

� Database log mode�� Archive Mode
� Automatic archival�� Enabled
/u02/oradata/orion/archive
� Next log sequence to archive�� 681
� SQL>

7.- Ejecute ALTER SYSTEM SWITCH LOGFILE para obligar a Oracle
a archivar el Current redolog file. Este archivo debe ser almacenado
en el area de destino de los archive log, en el caso del
ejemplo� /u02/oradata/orion/archive. Si desea, copie los
archive log que se generaron durante el proceso de respaldo (en el
ejemplo secuencias 672 a 681)� a la cinta junto con el resto del
respaldo.

� SQL> ALTER SYSTEM SWITCH LOGFILE;

8.- Crear una copia del archivo de control.

� SQL>
ALTER DATABASE BACKUP CONTROLFILE TO
'/backupDir/control.bck';

2.3 Backups f�sicos Administrados con RMAN

(Recovery Manager)

RMAN es la herramienta recomendada para realizar los respaldos y

recuperaciones� de bases de datos Oracle.

Caracter�sticas de Recovery Manager

Recovery Manager (RMAN) es una utilidad de Oracle que se usa para
manejar respaldos, restauraciones, y� operaciones de recuperaci�n
de las bases de datos Oracle. RMAN tiene un poderoso lenguaje de
comandos que es independiente del sistema operativo.� Recovery
Manager tiene una interfaz de comandos. Oracle Enterprise Manager
tambi�n proporciona un interfaz gr�fica para el Recovery Manager.
Recovery Manager puede ser utilizado en bases de datos de Oracle 8
y posteriores. RMAN proporciona varias caracter�sticas no
disponibles cuando se hacen respaldos administrados por� usuario
utilizando comandos del sistema operativo. Por ejemplo:

� Se puede almacenar operaciones de uso frecuentes como
scripts en la base de datos (cuando se utiliza CATALOGO)
� Usando la caracter�stica de backup incremental� a nivel
de� bloque, se puede limitar el backup solamente a esos
bloques que han cambiado desde el backup anterior. Esto
puede tambi�n reducir el tiempo que toma para realizar
operaciones de la recuperaci�n en modo ARCHIVELOG.
� Se puede utilizar RMAN para manejar el tama�o de piezas de
backup y para ahorrar tiempo parelelizando la operaci�n de
backup.
� Las operaciones de RMAN se pueden integrar con
la� programaci�n de tareas del sistema operativo para
automatizar operaciones de backup.

� Se puede detectar la corrupci�n de bloque. La informaci�n
referente a la corrupci�n de bloque que se detecta durante el
respaldo puede ser obtenida usando las vistas din�micas
V$BACKUP_CORRUPTION y V$COPY_CORRUPTION.
� RMAN proporciona mejoras de desempe�o tales como :

� Paralelismo� autom�tico de backup, restore, y
operaciones de la recuperaci�n
� No existe generaci�n extra de informaci�n de redo
entries durante el respaldo
� Respaldos que se restringen para limitar lecturas por
archivo, por segundo para evitar interferir con las
operaciones de OLTP.
� Evita saturaci�n de lectura/escritura de cualquier
archivo mientras todav�a mantiene un flujo activo hacia la
cinta de respaldo, usando multiplexaci�n.
�
� Bajo el m�todo de respaldo manejado por usuario se necesita
mantener control de todos los archivos y respaldos de base de
datos. En situaciones de recuperaci�n se debe ubicar los
respaldos para cada datafile, copiarlo al lugar correcto usando
comandos del sistema operativo, y elegir qu� archivos de
archivelog deben aplicarse. RMAN maneja estas tareas
autom�ticamente. Esta ventaja de usar RMAN es
especialmente verdadera si se utilizan archivos manejados por
Oracle (OMF).

La mayor ventaja de RMAN es que solo respaldar� el espacio usado en base de datos.
RMAN� no pone los� tablespaces en modo de backup, ahorrando en sobrecarga de
generaci�n de entradas de redolog
El ambiente RMAN consiste de utilidades y base de datos que juegan un rol

en el respaldo de los datos.�� El ambiente RMAN debe incluir como
m�nimo lo siguiente: :
 La base de datos que� va a ser respaldada (base de datos target)

 El cliente RMAN, que interpreta los comandos de respaldo y
recuperaci�n, dirige las sesiones de servidor para ejecutar esos
comandos, y registra la actividad de los respaldos y recuperaci�n en el
archivo de control de la base de datos target.
Algunos ambientes tambi�n usar�n las siguientes componentes opcionales:
 Un �rea llamada flash recovery area, que es un �rea de disco en la

cual la base de datos puede almacenar y manejar archivos relacionados
con respaldos y recuperaciones;
 Media management software, que son librer�as que deben proveer
los proveedores de unidades de respaldos que es requerido por RMAN
como interfaz para controlar las cintas de los dispositivos de
respaldos.�
 Una base de datos de�� catalogo de recuperaci�n, que es un
esquema de base de datos separado usado para registrar la actividad
de� RMAN en relaci�n a una o m�s bases de datos target.

Como ingresar y salir de RMAN
El cliente RMAN se inicia ejecutando el comando rman en el� prompt del

sistema operativo (usuario oracle)
Para ejecutar tareas de respaldo y recuperaci�n RMAN debe conectarse a una

base de datos target (con privilegios SYSDBA). RMAN tambien se puede
conectar a una base de datos de CATALOGO DE RECUPERACION si se
desea utilizar uno. Se especifica las base de datos target y de catalogo de
recuperaci�n usando las opciones de linea de comando o� usando el
comando CONNECT dentro de RMAN.
Este comando conecta a� RMAN a una base de datos target database y un

catalogo de� recuperaci�n:
% rman TARGET / CATALOG usuario_catalog/pwd@cat_tns_alias

Este comando conecta a� RMAN a una base de datos target sin usar� un
catalogo de� recuperaci�n:
% rman TARGET SYS/pwd@target_str

Este comando inicia� RMAN sin conectarse a una base de datos:

% rman

Configuraci�n de Seteos Persistentes para el ambiente RMAN
Se pueden Configurar las definiciones persistentes de par�metros que afectan

el ambiente RMAN, los cuales se aplican a todas las operaciones
subsecuentes, incluso si sale y vuelve a entrar a RMAN.� Estas
configuraciones forman una metadata que se guarda en el archivo de control.
Configuraci�n de Dispositivos de Discos ( Disk Devices)� y

Canales(Channels)
Los canales RMAN son conexiones a� sesiones de servidor sobre la base de

datos target, que se utilizan para realizar todas las operaciones de respaldos,
restauraci�n y de recuperaci�n. Por defecto, RMAN asigna un canal de
disco para todas las operaciones. Se pueden configurar canales adicionales
para el uso con discos y con otros medios.
Por defecto, RMAN env�a todos los respaldos a disco. Si se configura una
flash recovery area, esta es� el destino por� defecto; si no el directorio
por� defecto es dependiente de la plataforma. Si, seg�n lo recomendado, se
utiliza una flash recovery area como destino para todos los respaldos a disco,
se define� una flash recovery area utilizando el siguiente comando
CONFIGURE:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT CLEAR;

El siguiente comando configura RMAN para escribir respaldos a discos en el
directorio /tmp :
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/tmp/%U';

El formato %U is reemplazado con nombres de archivos �nicos cuando se

toman respaldos, de esta forma los respaldos RMAN nunca se pisan.
Configuraci�n de Dispositivos de Cintas ( Tape Devices)� y

Canales(Channels)
Despu�s de haber instalado y configurado el software de administraci�n de

cintas, se puede configurar RMAN para que el dispositivo de cinta sea el
destino por defecto de los respaldos RMAN:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;

Algunos administradores de cintas (por ejemplo Data Protector de HP,

Brighstore de CA, Legato de EMC, Veritas de Symantec, Tivoli de
IBM,� Netbackup, entre otros.) requieren un string PARMS para� configurar
los par�metros del dispositivo:
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=mml_env_settings';

Se pueden configurar m�ltiple canales para ejecutar respaldos en paralelo. El

siguiente comando configura dos canales sbt para usar jobs RMAN.
RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

Ejemplo de asignaci�n de canales paralelos a cinta (sbt)

�� RMAN> run {
�� 2>�� allocate channel c1 type sbt;
�� 5>�� backup
�� 6> �� incremental level = 0
�� 7> �� format '/disk1/backup/df_%d_%s_%p.bak�
�� 8> �� (datafile 1,4,5 channel c1 tag=DF1)
�� 9> �� (datafile 2,3,9 channel c2 tag=DF2)
�� 10> �� (datafile 6,7,8 channel c3 tag=DF3);
�� 11>�� alter system archive log current;
�� 12> }
Configuraci�n de Pol�tica de Retenci�n
Retention policy governs how long backup files are retained. Retention policy
can be set in terms of a recovery window (how far into the past you need to be
able to recover your database), or a redundancy value (how many backups of
each file must be retained).
La pol�tica de retenci�n gobierna cu�nto tiempo se conservan los archivos

de respaldos. La pol�tica de retenci�n se puede fijar en t�rminos de una
ventana de recuperaci�n (hasta punto en el pasado se necesita poder
recuperar la base de datos), o un valor de redundancia (cu�ntas respaldos de
cada archivo se deben retener)
El siguiente comando asegura que� RMAN retenga todos los respaldos que

se necesitan para recuperar la base de datos hasta cualquier punto en el tiempo
en los �ltimos 7 dias :
�RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
El siguiente comando asegura que� RMAN retenga tres respaldos de cada

archivo de datos :
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
Utilice el comando DELETE OBSOLETE para borrar en el acto respaldos que ya no

se requieran de acuerdo a� la pol�tica la retenci�n. (Para los respaldos
almacenados en un �rea flash recovery, no se necesita realizar este paso. La
base de datos elimina autom�ticamente archivos obsoletos y archivos que ya
han sido respaldados a cinta cuando se necesita el espacio).� Se� puede
utilizar la opci�n KEEP de los comandos� BACKUP y CHANGE para no tomar en
cuenta la pol�tica de retenci�n para respaldos individuales. -- por ejemplo,
forzar la retenci�n de un respaldo espec�fico.
Configuraci�n de� Control File Autobackups
El siguiente comando configura� RMAN para respaldar el archivo de control

despu�s de ejecutar los comandos backup o copy :
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Por defecto, RMAN nombra autom�ticamente los autobackups del archivo

de control y los almacena en el area de flash recovery. El comando siguiente
configura RMAN para generar autobackups del archivo de control al
directorio /mybackupdir:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
��FOR DEVICE TYPE DISK TO '/mybackupdir/cf%F';

El elemento %F del string de formato combina el DBID (Identificador de la
Base de Datos, aparece en la vista v$database) , el d�a, el mes, el a�o, y el
n�mero de secuencia� para generar un nombre de archivo �nico. Se
requiere %F para los autobackups del archivo de control.
Restauraci�n de Valores de Configuraci�n por Defecto
Resetee cualquier definici�n que se haya hecho con el

comando� CONFIGURE a su valor por defecto ejecutando el comando con la
opci�n CLEAR, como se muestra aqu�:
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR;
RMAN> CONFIGURE RETENTION POLICY CLEAR;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
CLEAR;
Consultar la Configuraci�n Vigente
Este comando muestra todas de definiciones de configuraci�n de RMAN :

RMAN> SHOW ALL;
La salida lista los comandos CONFIGURE para� recrear esta configuraci�n.

RMAN re-leer� un bloque de la BD hasta que esta lectura sea una imagen consistente del
bloque. Veamos el siguiente ejemplo de backup RMAN:

�� $ rman target sys/*** nocatalog
�� RMAN> run {
�� allocate channel t1 type disk;
�� backup
�� format '/app/oracle/db_backup/%d_t%t_s%s_p%p'
�� ( database );
�� release channel t1;
�� }
Ejemplo de restauraci�n de� RMAN:
�� $ rman target sys/*** nocatalog

�� RMAN>run {
�� allocate channel t1 type disk;
�� # set until time 'Aug 07 2000 :51';
�� restore tablespace users;
�� recover tablespace users;
�� release channel t1;
�� }

Los ejemplos anteriores son extremadamente simplistas y solamente �tiles para ilustrar
conceptos b�sicos. Por defecto Oracle utiliza los controlfiles de la base de datos para
almacenar la informaci�n sobre backups. Normalmente se configurar� una base de datos de
catalogo de RMAN para almacenar la meta data de RMAN. Lea la gu�a Oracle Backup and
Recovery antes de poner backups de RMAN en ejecuci�n.

Recovery Manager puede realizar los siguientes tipos de respaldos:
� Copias Imagen son copias de un� datafile,
control file, o archivos de archived redo log.
Una� copia puede hacerse con RMAN o usando
comandos de sistemas operativos. La copia de un
datafile consiste en todos los bloques del datafile,
incluyendo los bloques no usados. La copia imagen
puede incluir solo un archivo.
� Backup sets pueden incluir uno o mas datafiles, el
control file, o� archivos de archived redo log. Se
pueden generar backup set de dos formas:
- Full backup: En un full backup, se respalda uno
o m�s archivos. En un full backup, se
respaldan todos los bloques� que contienen
datos para los archivos especificados.
- Backup Incremental: Un backup incremental es
un respaldo de datafiles que incluye solo los
bloques que han cambiado
desde ultimo backup incremental. Un backup
incremental requiere un respaldo de nivel
0� (o nivel� incremental 0), que respalda
todos los bloques de datos que contienen los
archivos especificados.� Un respaldo
incremental� level 0 y full backups copian
todos los bloques en los datafiles, pero� full
backups no pueden ser usados en una
estrategia de backup incremental.
Nota: Se pueden configurar respaldos autom�ticos de archivo de
control de tal manera que cada vez que se usen los comandos
BACKUP o COPY se respalden los archivos de control y archivo de
par�metros.

Backup Sets
Un backup set consiste de uno o m�s archivos f�sicos almacenados
en un formato especifico de RMAN, ya sea en disco o cinta. Se puede
generar un backup set que contenga datafiles, control files, y
archivelogs. Tambi�n se puede respaldar un backup set. Los Backup
sets pueden ser de dos tipos:
� Datafile: Puede contener datafiles y control files,
pero no archivelogs
� Archived log: Contiene archivelogs, pero no
contiene datafiles ni control files

Nota: Los Backup sets necesitan ser restaurados por el Recovery
Manager antes que se pueda ejecutar la operaci�n de� recovery
(recuperaci�n), a diferencia de las copias� im�genes que ya
residen en disco.

Control Files en� Backup Sets del tipo Datafile
Cada archivo en un backup set debe tener el mismo tama�o de
bloque� Oracle. Cuando se incluye un control file este se escribe en
el �ltimo backup set. Se puede incluir un� archivo de control en un
backup ya sea:
� Expl�citamente usando la sintaxis� INCLUDE
CONTROL FILE, o;
� Impl�citamente respaldando el datafile� 1 (el
datafile de tablespace system)
El comando� BACKUP se usa para respaldar datafiless, archived
redo log files, y control files.� El comando� BACKUP respalda los
archivos en uno o m�s backup sets sobre� disco o cinta. Se pueden
realizar los respaldos cuando la BD est� abierta o cerrada . Los
respaldos pueden ser incrementales o full.

Respaldo de Archivos de Base de Datos
Utilice el comando BACKUP para respaldar archivos de base de datos.

Normalmente, antes se tendr�n configurado los dispositivos por defecto y los
canales. El comando BACKUP respalda los datos hacia el dispositivo por defecto
y canales que hayan sido configurados para el tipo respaldo requerido.
Si se especifica� BACKUP AS COPY, entonces RMAN copia los archivos

como copias im�genes, es decir, copias bit-por-bit de la base de datos, las
cuales pueden ser creadas solo en disco.
Este� comando crea respaldos copias imagen de todos los datafiles en la base

de datos:
RMAN> BACKUP AS COPY DATABASE;

Si se especifica BACKUP AS BACKUPSET, entonces RMAN almacena sus respaldos

en backup sets. Un backup set consiste de una o m�s piezas o backup
pieces, archivos f�sicos que contienen los datos. Usualmente un backup set
contiene solo una pieza. Solo RMAN puede crear y restaurar� backup sets.
El siguiente comando crea un respaldo de la base de datos y archivos de
archivelogs� sobre cinta, en formato de backup set, usando los canales
configurados:
RMAN> BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
Respaldo de archivos individuales
You can back up individual tablespaces, database files, server parameter files,
and backup sets with various options, as in these examples:
Se pueden respaldar en forma individual las siguientes estructuras o archivos

de la base de datos: tablespaces, archivos de base datos, archivos de
archivelogs, archivos de par�metro, y backup sets. Por ejemplo :
RMAN> BACKUP ARCHIVELOG COMPLETION TIME BETWEEN
��'SYSDATE-31' AND 'SYSDATE-7';
RMAN> BACKUP TABLESPACE system, users, tools;
RMAN> BACKUP AS BACKUPSET DATAFILE
��'ORACLE_HOME/oradata/trgt/users01.dbf',
��'ORACLE_HOME/oradata/trgt/tools01.dbf';
RMAN> BACKUP CURRENT CONTROLFILE TO '/backup/curr_cf.copy';
RMAN> BACKUP SPFILE;
RMAN> BACKUP BACKUPSET ALL;
Observe que en los ejemplos anteriores se debe ingresar el directorio de su

propio Oracle home en lugar de �ORACLE_HOME�.
Opciones del comando Backup
Aqu� est�n algunas opciones de uso frecuente del comando BACKUP:
Parametro Ejemplo Explicaci�n
FORMAT FORMAT '/tmp/%U' Especifica una ubicaci�n y un nombre para las

piezas y copias de respaldos. Se deben utilizar
variables de substituci�n para generar nombres de
archivos �nicos.
TAG TAG 'full_bak' Especifica un string definido por el usuario como
etiqueta para el respaldo. Si no se especifica una
etiqueta, entonces RMAN asigna una etiqueta por
defecto con la fecha y la hora.
Los comandos BACKUP siguientes ilustran estas opciones:

RMAN> BACKUP FORMAT='ARCH_%d/%t/%s/%p' ARCHIVELOG LIKE '%arc_dest%';
RMAN> BACKUP TAG 'bkup_bd_full_semanal' DATABASE MAXSETSIZE 512M;
RMAN> BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;
Respaldos Incrementales
Si se especifica BACKUP INCREMENTAL, RMAN crear� backups

incrementales de su base de datos. Los respaldos incrementales capturan a
nivel de bloque los cambios de la base de datos desde el �ltimo backup
incremental. El punto de partida para una estrategia de respaldo
incremental es un respaldo incremental de nivel 0, que respalda todos los
bloques en la base de datos. Los respaldos incrementales de Nivel 1 , tomados
a intervalos regulares, contienen solamente los bloques que han cambiado
desde el respaldo incremental anterior. �stos respaldos pueden
ser acumulativos (todos los bloques que han cambiado desde el �ltimo
respaldo de nivel 0) o diferencial (incluir solamente bloques que han
cambiado desde el respaldo incremental m�s reciente, ya sea de nivel 0 o
nivel 1 ).
Los respaldos incrementales son generalmente m�s peque�os y m�s

r�pidos que los respaldos full de la base de datos. La recuperaci�n de un
respaldo incremental es m�s r�pida que la recuperaci�n que usa solamente
archivos de archivelogs. Durante una restauraci�n de un respaldo
incremental, se utiliza el respaldo del nivel 0 como el punto de partida, luego
los bloques que han cambiado son actualizados basado en el respaldo de nivel
1 en lo posible para evitar reaplicar uno a uno los cambios desde archivos de
archivelogs. La recuperaci�n con respaldos incrementales no requiere
ning�n esfuerzo adicional de su parte. Si los respaldos incrementales est�n
disponibles, RMAN las utilizar� durante la recuperaci�n.
La caracter�stica de respaldos actualizados incrementalmente� de RMAN

permite una rutina de respaldo incremental m�s eficiente. Los cambios desde
el� respaldo de nivel 1 se pueden utilizar para hacer avanzar un respaldo de
copia imagen incremental del nivel 0, de modo que incluya todos los cambios
hasta� el SCN en el cual el respaldo incremental del nivel 1 fue creado. La
recuperaci�n que usa el respaldo� incremental del nivel 0 actualizada es
m�s r�pida, porque todos los cambios del respaldo incremental del nivel 1
ya se han aplicado.
Ejemplo Respaldo Incremental
Usted est� manteniendo una base de datos de 800 GB, que est� creciendo
continuamente. Basado en el hardware existente, se determina que un respaldo
completo de la� base de datos toma 4 horas. La base de datos est� en l�nea
24 horas al d�a, 7 d�as a la semana y los respaldos est�n consumiendo
demasiados recursos de sistema durante este per�odo del tiempo. Los
respaldos de nivel 0 no se pueden realizar m�s que una vez por semana, pero
se requiere recuperaci�n r�pida en caso de falla. Usted por lo tanto toma la
decisi�n siguiente como estrategia de respaldo y� recuperaci�n:
� Se ejecutar� un respaldo del nivel 0� cada semana en el

d�a con la menos actividad. Usted determina que ese d�a es el
domingo.
�� RMAN> BACKUP INCREMENTAL level

0 database;
� En forma diaria se ejecutar�n respaldos incrementales de

nivel 2, excepto el mi�rcoles en que se realizar� un respaldo
de nivel 1. De esta manera, los respaldos ser�n r�pidos porque
solamente ser�n copiados los bloques que han cambiado a partir
del d�a anterior:
�� RMAN> BACKUP INCREMENTAL level

2 database;

Vistas Din�micas RMAN
Se pueden usar las siguientes vistas para obtener informacion RMAN
almacenanada en el control file :

� V$ARCHIVED_LOG muestra qu� archivos se han creado,
respaldado, y se han limpiado en la base de datos.
� V$BACKUP_CORRUPTION muestra qu� bloques se han
encontrado corruptos durante un respaldo de un backup set.
� V$COPY_CORRUPTION muestra qu� bloques se han
encontrado corruptos durante un respaldo de copia imagen
(comando COPY).
� V$DATABASE_BLOCK_CORRUPTION Despliega
informaci�n sobre los bloques de la base de datos que se
corrompieron despu�s del �ltimo backup.
� V$BACKUP_DATAFILE es �til para crear backup sets
de� igual tama�o� determinando el n�mero de bloques en
cada datafile. Puede tambi�n ser �til para encontrar el
n�mero de bloques corruptos para el datafile.
� V$BACKUP_REDOLOG muestra archivos de archivelogs
almacenados en backup sets.
� V$BACKUP_SET muestra backup sets que han sido creados.
� V$BACKUP_PIECE muestra piezas de� backup� creadas
para backup sets.

2.4 Backups L�gicos
Este tipo de backups copian el contenido de la BD pero sin almacenar la
posici�n f�sica de los datos. Se realizan con la herramienta export que copia
los datos y la definici�n de la BD en un archivo en un formato interno de
Oracle.
Para realizar un export la BD debe est�r 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
transacci�n durante el proceso de export. Esto se puede conseguir si se abre
la BD en modo RESTRICT.
Entre las ventajas de efectuar un export est�n las siguientes:
 Se puede detectar la corrupci�n en los bloques de datos, ya que el

proceso de export fallar�.
 Protege de Fallas de usuario, por ejemplo si se borra una fila o toda una
tabla por error es f�cil 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 m�quinas.
Una de las desventajas de realizar backups l�gicos con export es que son

mucho m�s lentos que los backups f�sicos.
Par�metros de Export
[oracle@hercules ~]$ exp help=y

Export: Release 10.2.0.3.0 - Production on Thu Jun 28 09:06:09 2007

Copyright (c) 1982, 2005, Oracle.� All rights reserved.

You can let Export prompt you for parameters by entering the EXP
command followed by your username/password:

�� Example: EXP SCOTT/TIGER

Or, you can control how Export runs by entering the EXP command
followed
by various arguments. To specify parameters, you use keywords:

�� Format:� EXP KEYWORD=value or
KEYWORD=(value1,value2,...,valueN)
�� Example: EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP,DEPT,MGR)
�� or TABLES=(T1:P1,T1:P2), if T1 is
partitioned table

USERID must be the first parameter on the command line.

Keyword�� Description (Default)�� Keyword��
Description (Default)
-------------------------------------------------------------------
-------
USERID�� username/password�� FULL��
export entire file (N)
BUFFER�� size of data buffer�� OWNER�� list
of owner usernames
FILE�� output files (EXPDAT.DMP)� TABLES�� list of
table names
COMPRESS�� import into one extent (Y) RECORDLENGTH length of IO
record
GRANTS�� export grants (Y)�� INCTYPE��
incremental export type
INDEXES�� export indexes (Y)�� RECORD�� track
incr. export (Y)
DIRECT�� direct path (N)�� TRIGGERS��
export triggers (Y)
LOG�� log file of screen output� STATISTICS�� analyze
objects (ESTIMATE)
ROWS�� export data rows (Y)�� PARFILE��
parameter filename
CONSISTENT cross-table consistency(N) CONSTRAINTS� export
constraints (Y)
OBJECT_CONSISTENT�� transaction set to read only during object
export (N)
FEEDBACK�� display progress every x rows (0)
FILESIZE�� maximum size of each dump file
FLASHBACK_SCN�� SCN used to set session snapshot back to
FLASHBACK_TIME�� time used to get the SCN closest to the
specified time
QUERY�� select clause used to export a subset
of a table
RESUMABLE�� suspend when a space related error is
encountered(N)
RESUMABLE_NAME�� text string used to identify resumable
statement
RESUMABLE_TIMEOUT�� wait time for RESUMABLE
TTS_FULL_CHECK�� perform full or partial dependency check
for TTS
VOLSIZE�� number of bytes to write to each tape
volume
TABLESPACES� ��list of tablespaces to export
TRANSPORT_TABLESPACE export transportable tablespace metadata (N)
TEMPLATE�� template name which invokes iAS mode
export
Par�metro Defecto Descripci�n
el username/password del usuario
USERID indefinido
que efectua el export.
El tama�o en bytes del buffer

BUFFER dependiente del SO
utilizado.
FILE expdat.dmp el nombre del archivo destino.
indica si se exportan tambi�n los

GRANTS Yes
derechos.
indica si se exportan tambi�n los
INDEXES Yes
�ndices.
indica si se exportan tambi�n las

ROWS Yes filas de las tablas, o s�lo las
definiciones de las tablas.
indica si se exportan tambi�n las

CONSTRAINTS Yes
restricciones.
indica si se exporta en modo

COMPRESS Yes
comprimido.
FULL No indica si se exporta la BD entera.
una lista de usuarios cuyos objetos

OWNER usuario actual
se quieren exportar.
TABLES indefinido la lista de tablas a exportar.
la longitud en bytes del registro del

RECORDLENGTH dependiente del SO
archivo.
INCTYPE indefinido el tipo de export incremental.
indica si se anota
RECORD Yes el export incremental en las
tablas SYS.INCVID y en SYS.INCEXP.
el archivo de par�metros, donde

PARFILE indefinido se pueden definer todas las
opciones anteriores.
Modos de Export
Existen tres modos de realizar una exportaci�n 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 m�s los clusters, enlaces de
BD, vistas, sin�nimos privados, secuencias, procedimientos,
etc. del usuario.
Modo BD Entera
Adem�s de todo lo del modo Usuario, exporta los roles, todos
los sin�nimos, los privilegios del sistema, las definiciones de
los tablespaces, las cuotas en los tablespaces, las definiciones
de los segmentos de rollback, las opciones de auditor�a 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 s�lo los c�mbios en los
datos y en las definiciones.
Completo
Exporta todas las tablas de la BD e inicializa la informaci�n
sobre la exportaci�n incremental de cada tabla. Despu�s de
una exportaci�n completa, no se necesitan los archivos 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 exportaci�n Acumulativa o Completa, y registra
los detalles de exportaci�n para cada tabla exportada.
Despu�s de una exportaci�n acumulativa, no se necesitan los
archivos de exportaciones incrementales de la BD anteriores.
�
inctype=cumulative constraints=Y
� file=cumulative_export_filename
Incremental
Exporta todas las tablas modificadas o creadas desde la �ltima
exportaci�n Incremental, Acumulativa o Completa, y registra los
detalles de exportaci�n para cada tabla exportada. Son
interesantes en entornos en los que muchas tablas permanecen
est�ticas por periodos largos de tiempo, mientras que otras
var�an y necesitan ser copiadas. Este tipo de exportaci�n es
�til cuando hay que recuperar r�pidamente una tabla borrada
por accidente.
�
inctype=incremental constraints=Y
� file=incremental_export_filename
La pol�tica de exportaci�n puede ser la siguiente: realizar una exportaci�n

completa el d�a 1 (por ejemplo el domingo), y luego realizar exportaciones
incrementales el resto de la semana. De este modo de lunes a s�bado s�lo se
exportar�n aquellas tablas exportadas, ahorrando tiempo en el proceso.
3 Principios de la Recuperaci�n
Para entender los principios de la recuperaci�n, se necesita entender las

estructuras de datos subyacentes utilizadas en la recuperaci�n.
3.1 Definiciones y Conceptos

Los archivos 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 n�mero de versi�n, el c�digo de
la transacci�n, y la direcci�n del bloque afectado.
Registro Redo log
es un conjunto de vectores de cambio que describen un cambio
at�mico sobre la BD. La transacci�n es tambi�n la unidad de
recuperaci�n.
Evoluci�n de Redo log por d�a
se puede calcular ejecutando el comando archive log list en
dos d�as consecutivos y calculando la diferencia del n�mero
de secuencia de los archivos redo log, multiplicado por el
tama�o de un archivo redo log:
�
� Database log mode�� No
Archive Mode
� Automatic archival��
Disabled
/opt/app/oracle/admin/demo/arch/arch.log

System Change Number, SCN
es un dato que define la versi�n confirmada (commit) de la BD
en este instante de tiempo. Cuando una transacci�n es
confirmada, se le asigna un SCN que la identifica
un�vocamente. Los archivos redo log son marcados con dos
SCN. Cuando se abre un nuevo archivo redo log se le marca
con un SCN, low SCN, que es uno mas que el SCN mayor del
anterior archivo redo log; y su high SCN es puesto a infinito. Los
SCN tambi�n se asocian al archivo de control, ya que cuando
se para una BD, un tablespace o archivo de datos, se almacena
para cada archivo de datos su stop SCN en el archivo de
control.
Cambio de redo log
es el proceso mediante el cual se deja de utilizar un
archivo redo log y el LGWR combia al siguiente archivo redo
log disponible. Se puede hacer con el comando alter system
switch logfile;.
Checkpoints
son activados autom�ticamente 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 cambios con un SCN
menor que el del checkpoint dado han sido escritos en el disco.
3.2 M�todos de Recuperaci�n

Existen varios m�todos de recuperaci�n, pero todos ellos se basan en la
aplicaci�n de los registros de redo log.
Aplicaci�n 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 archivos de log y de datos. Si la BD se arranca por
primera vez despu�s de una ca�da o falla, se necesitar� efectuar una
recuperaci�n que consiste en dos pasos: avanzar la BD hacia adelante
aplicando los registros redo log (roll forward), deshacer las transacciones no
confirmadas (rolback).
Cada archivo de datos tiene en su cabecera el �ltimo checkpoint efectuado,

as� como el archivo de control tambi�n lleva esa cuenta.
El checkpoint lleva incluido el SCN. Este es conocido como SCN de inicio de
archivo. Asociado a cada archivo de datos el archivo 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 archivo de datos al SCN almacenado en cada archivo 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 archivos de datos
coincide con el correspondiente del archivo de control. Si es as�, se compara
el SCN de inicio de cada archivo de datos con el SCN de final almacenado en
el archivo de control. Si son iguales no se necesita recuperaci�n en este
archivo de datos. Como parte de la apertura se pone a infinito el SCN de final
para ese archivo de datos.
Si la BD se par� con en modo abort no se ejecut� el checkpoint y el SCN de

fin para los archivo 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 recuperaci�n
aplicando los cambios almacenados en los archivos redo log en l�nea para
avanzar la BD, y los registros de roll back de los segmentos de roll back para
deshacer las transacciones no confirmadas.
Si despu�s de parar la BD se reemplaza un archivo de datos por su copia de

seguridad, al arrancar la BD Oracle detecta que el contador de checkpoints del
archivo de datos no coincide con el almacenado en el archivo de control.
As�, se tendr� que echar mano a los archivos redo log archivados
(archivelogs), empezando por aquel cuyo n�mero de secuencia aparece en la
cabecera del archivo de datos.
3.3 Recuperaci�n F�sica
La utilizaci�n de una copia de backup de archivos de datos siempre necesita
de una recuperaci�n f�sica. Tambi�n es as� cuando un archivo de datos
se pone offline sin un checkpoint.
Oracle detecta que se necesita una recuperaci�n f�sica cuando el contador

de checkpoints de la cabecera del archivo de datos no coincide con el
correspondiente contador de checkpoints del archivo de control. Entonces se
hace necesario el comando recover. La recuperaci�n comienza en el SCN
menor de los archivos de datos en recuperaci�n, aplicando los registros
de redo log a partir de �l, y parando en el SCN de final mayor de todos los
archivos de datos.
Existen tres opciones para realizar una recuperacion f�sica. La primera es

una recuperaci�n de BD donde se restaura la BD entera. La segunda es una
recuperaci�n de tablespace donde, mientras una parte de la BD est� abierta,
se puede recuperar un tablespace determinado. Esto significa que ser�n
recuperados todos los archivos de datos asociados al tablespace. El tercer tipo
es la recuperaci�n de un archivo de datos espec�fico mientras el resto de la
BD est� abierta.
Requisitos para Utilizar Recuperaci�n F�sica
La primera condici�n que se ha de poner para poder recuperar f�sicamente

una BD es que �sta se est� utilizando en modo ARCHIVELOG. De otro modo,
una recuperaci�n completa puede que no sea posible. Si trabajamos con la
BD en modo NOARCHIVELOG, y se hace una copia semanal de los archivos de la
BD, se deber�a estar preparado para perder, en el peor de los casos, el trabajo
de la �ltima semana si sucede un fallo. Ya que los archivos de redo
log contendr�an 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.
Recuperaci�n de la BD
La BD debe estar montada pero no abierta. El comando de recuperaci�n es el

siguiente:

� RECOVER [AUTOMATIC] [FROM 'localizacion']
[BD]
� ��[UNTIL CANCEL]
� ��[UNTIL TIME fecha]
� ��[UNTIL CHANGE entero]
� [USING BACKUP CONTROLFILE]
Las opciones entre corchetes son opcionales:
 AUTOMATIC hace que la recuperaci�n se haga autom�ticamente sin

preguntar al DBA por el nombre de los archivos redo log. Tambi�n se
puede utilizar para este cometido el comando set autorecovery on/off.
Los archivos redo log deben estar en la localizaci�n fijada
en LOG_ARCHIVE_DEST y el formato del nombre de los archivos debe ser el
fijado en LOG_ARCHIVE_FORMAT.
 FROM se utiliza para determinar el lugar donde est�n los archivos redo
log, si es distinto del fijado en LOG_ARCHIVE_DEST.
 UNTIL sirve para indicar que se desea realizar una recuperaci�n
incompleta, lo que implica perder datos. Solo se dar� cuando se han
perdido redo log archivados o el archivo de control. Cuando se ha
realizado una recuperaci�n 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 archivo de control. Existen tres opciones para parar la
recuperaci�n:
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 archivo de redo log
o UNTIL CHANGE permite recuperar hasta un SCN dado.
o USING BACKUP CONTROLFILE utiliza una copia de seguridad del
archivo de control para gobernar la recuperaci�n.
Recuperaci�n de un tablespace
La BD debe estar abierta, pero con el tablespace a recuperar offline. El

comando de recuperaci�n es el siguiente:

� RECOVER
[AUTOMATIC] [FROM 'localizacion']
� ��TABLESPACE nombre_tablespace [,
nombre_tablespace]
Recuperaci�n de un Archivo de Datos
La BD debe estar abierta o cerrada, dependiendo del archivo a recuperar. Si el

archivo a recuperar es de un tablespace de usuario la BD puede estar abierta,
pero con el archivo a recuperar offline. Si el archivo es
del tablespace SYSTEM la BD debe estar cerrada, ya que no puede estar abierta
con los archivos del SYSTEM offline. El comando de recuperaci�n es el
siguiente:

� RECOVER
[AUTOMATIC] [FROM 'localizacion']
� ��DATAFILE nombre_archivo [,
nombre_archivo]
Creando un Archivo de Control
Si el archivo de control ha resultado da�ado y se ha perdido se puede utilizar

una copia de seguridad del mismo o crear uno nuevo. El comando de
creaci�n de un nuevo archivo de control es CREATE CONTROLFILE. Este
comando se puede ejecutar s�lo con la BD en estado nomount. La ejecuci�n
del comando produce un nuevo archivo de control y el montaje autom�tico
de la BD.
Un comando interesante que ayuda a mantener los archivos de control a salvo

es el siguiente:
� SQL>alter database backup controlfile to

trace;
trace as '/algun/directorio/';
trace as '/algun/directorio ' reuse;
�
que produce un script que puede ser utilizado para generar un nuevo archivo

de control y recuperar la BD, en caso necesario. El archivo de traza generado
es el siguiente:
�
-- The following are current System-scope REDO Log Archival related
-- parameters and can be included in the database initialization file.
--
-- LOG_ARCHIVE_DEST=''
-- LOG_ARCHIVE_DUPLEX_DEST=''
--
-- LOG_ARCHIVE_FORMAT=orion_%t_%s_%r.dbf
--
-- DB_UNIQUE_NAME="orion"
--
-- LOG_ARCHIVE_CONFIG='SEND, RECEIVE, NODG_CONFIG'
-- LOG_ARCHIVE_MAX_PROCESSES=2
-- STANDBY_FILE_MANAGEMENT=MANUAL
-- STANDBY_ARCHIVE_DEST=?/dbs/arch
-- FAL_CLIENT=''
-- FAL_SERVER=''
--
-- LOG_ARCHIVE_DEST_1='LOCATION=/u02/oradata/orion/archive'
-- LOG_ARCHIVE_DEST_1='OPTIONAL REOPEN=300 NODELAY'
-- LOG_ARCHIVE_DEST_1='ARCH NOAFFIRM NOEXPEDITE NOVERIFY SYNC'
-- LOG_ARCHIVE_DEST_1='REGISTER NOALTERNATE NODEPENDENCY'
-- LOG_ARCHIVE_DEST_1='NOMAX_FAILURE NOQUOTA_SIZE NOQUOTA_USED
NODB_UNIQUE_NAME'
-- LOG_ARCHIVE_DEST_1='VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES)'
-- LOG_ARCHIVE_DEST_STATE_1=ENABLE

--
-- Below are two sets of SQL statements, each of which creates a new
-- control file and uses it to open the database. The first set opens
-- the database with the NORESETLOGS option and should be used only if
-- the current versions of all online logs are available. The second
-- set opens the database with the RESETLOGS option and should be used
-- if online logs are unavailable.
-- The appropriate set of statements can be copied from the trace into
-- a script file, edited as necessary, and executed when there is a
-- need to re-create the control file.
--
--�� Set #1. NORESETLOGS case
--
-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- Additional logs may be required for media recovery of offline
-- Use this only if the current versions of all online logs are
-- available.

-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--� ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORION" NORESETLOGS� ARCHIVELOG
�� MAXLOGFILES 16
�� MAXLOGMEMBERS 3
�� MAXDATAFILES 100
�� MAXINSTANCES 8
�� MAXLOGHISTORY 292
LOGFILE
� GROUP 1 '/u02/oradata/orion/redo01.log'� SIZE 50M,
� GROUP 3 '/u02/oradata/orion/redo03.log'� SIZE 50M
-- STANDBY LOGFILE

DATAFILE
� '/u02/oradata/orion/system01.dbf',
� '/u02/oradata/orion/undotbs01.dbf',
� '/u02/oradata/orion/sysaux01.dbf',
� '/u02/oradata/orion/users01.dbf',
� '/u02/oradata/orion/designer6i_data01.DBF',
� '/u02/oradata/orion/designer6i_index01.dbf'
CHARACTER SET WE8ISO8859P1
;

-- Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE
AUTOBACKUP','ON');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('DEFAULT DEVICE
TYPE TO','DISK');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','1
DEVICE TYPE DISK FORMAT�� ''/home/oracle/rman/spfile_bck_%U''');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION
POLICY','TO REDUNDANCY 2');
AUTOBACKUP FORMAT FOR DEVICE TYPE','DISK TO
''/home/oracle/rman/cf_orion_%F.bck''');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE
TYPE DISK FORMAT�� ''/home/oracle/rman/spfile_bck_%U''');
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- ALTER DATABASE REGISTER LOGFILE
'/u02/oradata/orion/archive/orion_1_1_562360180.dbf';
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE

-- All logs need archiving and a log switch is needed.
ALTER SYSTEM ARCHIVE LOG ALL;

-- Database can now be opened normally.
ALTER DATABASE OPEN;

-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/orion/temp01.dbf'
�� SIZE 39845888� REUSE AUTOEXTEND ON NEXT 655360� MAXSIZE
32767M;
-- End of tempfile additions.
--
--�� Set #2. RESETLOGS case
--
-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- The contents of online logs will be lost and all backups will
-- be invalidated. Use this only if online logs are damaged.

-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--� ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORION" RESETLOGS� ARCHIVELOG
�� MAXLOGFILES 16
�� MAXLOGMEMBERS 3
�� MAXDATAFILES 100
�� MAXINSTANCES 8
�� MAXLOGHISTORY 292
LOGFILE
� GROUP 3 '/u02/oradata/orion/redo03.log'� SIZE 50M
-- STANDBY LOGFILE

DATAFILE
� '/u02/oradata/orion/system01.dbf',
� '/u02/oradata/orion/undotbs01.dbf',
� '/u02/oradata/orion/sysaux01.dbf',
� '/u02/oradata/orion/users01.dbf',
� '/u02/oradata/orion/designer6i_data01.DBF',
� '/u02/oradata/orion/designer6i_index01.dbf'
CHARACTER SET WE8ISO8859P1
;

AUTOBACKUP','ON');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('DEFAULT DEVICE
TYPE TO','DISK');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','1
DEVICE TYPE DISK FORMAT�� ''/home/oracle/rman/spfile_bck_%U''');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION
POLICY','TO REDUNDANCY 2');
AUTOBACKUP FORMAT FOR DEVICE TYPE','DISK TO
''/home/oracle/rman/cf_orion_%F.bck''');
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE
TYPE DISK FORMAT�� ''/home/oracle/rman/spfile_bck_%U''');
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE USING BACKUP CONTROLFILE

-- Database can now be opened zeroing the online logs.
ALTER DATABASE OPEN RESETLOGS;

-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/orion/temp01.dbf'
�� SIZE 39845888� REUSE AUTOEXTEND ON NEXT 655360� MAXSIZE
32767M;
-- End of tempfile additions.
--
3.4 Recuperaci�n L�gica

Oracle dispone de la herramienta import para restaurar los datos de una BD a
partir de los archivos resultados de un export. Import lee los datos de los
archivos de exportaci�n y ejecuta las sentencias que almacenan creando las
tablas y llen�ndolas de datos.
Par�metros del Import

[oracle@hercules ~]$ imp help=y

Import: Release 10.2.0.3.0 - Production on Thu Jun 28 09:16:19 2007

Copyright (c) 1982, 2005, Oracle.� All rights reserved.

You can let Import prompt you for parameters by entering the IMP
command followed by your username/password:

�� Example: IMP SCOTT/TIGER

Or, you can control how Import runs by entering the IMP command
followed
by various arguments. To specify parameters, you use keywords:

�� Format:� IMP KEYWORD=value or
KEYWORD=(value1,value2,...,valueN)
�� Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N
�� or TABLES=(T1:P1,T1:P2), if T1 is
partitioned table

USERID must be the first parameter on the command line.

Keyword� Description (Default)�� Keyword��
Description (Default)
-------------------------------------------------------------------
-------
USERID�� username/password�� FULL��
import entire file (N)
BUFFER�� size of data buffer�� FROMUSER�� list of
owner usernames
FILE�� input files (EXPDAT.DMP)�� TOUSER�� list of
usernames
SHOW�� just list file contents (N) TABLES�� list of
table names
IGNORE�� ignore create errors (N)�� RECORDLENGTH length of IO
record
GRANTS�� import grants (Y)�� INCTYPE��
incremental import type
INDEXES� import indexes (Y)�� COMMIT�� commit
array insert (N)
ROWS�� import data rows (Y)�� PARFILE��
parameter filename
LOG�� log file of screen output�� CONSTRAINTS� import
constraints (Y)
DESTROY�� overwrite tablespace data file (N)
INDEXFILE�� write table/index info to specified
file
SKIP_UNUSABLE_INDEXES� skip maintenance of unusable indexes (N)
FEEDBACK�� display progress every x rows(0)
TOID_NOVALIDATE�� skip validation of specified type ids
FILESIZE�� maximum size of each dump file
STATISTICS�� import precomputed statistics
(always)
RESUMABLE�� suspend when a space related error
is encountered(N)
RESUMABLE_NAME�� text string used to identify resumable
statement
RESUMABLE_TIMEOUT�� wait time for RESUMABLE
COMPILE�� compile procedures, packages, and
functions (Y)
STREAMS_CONFIGURATION� import streams general metadata (Y)
STREAMS_INSTANTIATION� import streams instantiation metadata (N)
VOLSIZE�� number of bytes in file on each
volume of a file on tape

The following keywords only apply to transportable tablespaces
TRANSPORT_TABLESPACE import transportable tablespace metadata (N)
TABLESPACES tablespaces to be transported into database
DATAFILES datafiles to be transported into database
TTS_OWNERS users that own data in the transportable tablespace set

Import terminated successfully without warnings.
[oracle@hercules ~]$

Par�metro Defecto Descripci�n
el username/password del usuario
USERID indefinido
que efectua el import.
El tama�o en bytes del buffer

BUFFER dependiente del SO
utilizado.
FILE expdat.dmp el nombre del archivo de
exportaci�n a importar.
indica si se muestran los contenidos

SHOW No del archivo de exportaci�n, sin
importar ning�n dato.
indica si ignorar los errores

IGNORE Yes producidos al importar un objeto
que ya existe en la BD.
indica si se importan tambi�n los

GRANTS Yes
derechos.
indica si se importan tambi�n los

INDEXES Yes
�ndices.
indica si se importan tambi�n las

ROWS Yes
filas de las tablas.
indica si se importan el archivo

FULL No
entero.
una lista de los usuarios cuyos

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

TOUSER Indefinido
nombre se importan los objetos.
TABLES indefinido la lista de tablas a importar.
la longitud en bytes del registro del

RECORDLENGTH dependiente del SO
archivo.
el tipo de import incremental
INCTYPE indefinido
(SYSTEM o RESTORE).
indica si se efectua
un commit despu�s de importar
cada fila. Por
COMMIT No
defecto, import efectua
un commit despu�s de cargar cada
tabla.
PARFILE indefinido el archivo de par�metros.
Para importar un export incremental se puede efectuar la siguiente secuencia

de pasos:
1. Utilizar la copia m�s reciente del import para restaurar las definiciones

del sistema:
�

Tarea Uapa

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tarea Uapa

Cargado por

Copyright:

Formatos disponibles

Universidad Abierta Para Adultos

Sistema de base de datos

Santo Domingo, República Dominicana

Le recomiendo que estudie

La vida no es tan fácil como usted cree, azarozo

Idiota es una palabra derivada del griego ἰδιώτης, idiōtēs ("persona privada de habilidad

En artículos anteriores te hemos explicado qué tipo de copia de seguridad es la que más

¿Qué es una copia de seguridad

¿Cuándo se recomienda tener una

¿Cómo conseguir una copia de

By accensit_admin| julio 3rd, 2017|Seguridad Informática|

Para compartir esta historia, elija cualquier plataforma

Contacta con Nuestros Expertos

Términos Legales | Política de Cookies

ara conseguir un funcionamiento seguro de la BD y una pronta recuperaci�n

1 Introducci�n al Backup and Recovery

1 Introducci�n al Backup and Recovery

Planificar y comprobar los procedimientos de backup del sistema es la �nica

Las causas de error en un sistema de BD pueden agruparse en las siguientes

 UPS o fuentes de corriente ininterrumpida,

1.1 Presentaci�n del Backup

Los backups l�gicos s�lo extraen los datos de las tablas utilizando

Este tipo de backup es el m�s sencillo de ejecutar, aunque consume

Los backups en frio implican parar la BD en modo normal y

El backup en caliente se realiza mientras la BD est� abierta y

Estas utilidades permiten al DBA hacer copias de determinados

Una vez que se ha planeado una estrategia de backup y se ha probado,

1.2 Presentaci�n de la Recuperaci�n

As�, los tipos de error que se pueden producir son:

Como por ejemplo un usuario borrando una fila o eliminando una

Se definen como la imposibilidad del SGBD Oracle de ejecutar

Es una terminaci�n anormal de un proceso. Si el proceso era

Algunas veces los Fallas en la red producen Fallas de proceso,

Pueden deberse a Fallas f�sicos o de dise�o del software que

Fallas del Sistema

Son los Fallas m�s peligrosos, no s�lo porque se pueden

Existen tres tipos de recuperaci�n en Oracle: a nivel de bloque, de thread y

Es el mecanismo de recuperaci�n m�s simple, y se realiza

Se realiza autom�ticamente cuando Oracle descubre que una

Se realiza como respuesta a un comando RECOVER. Se utiliza para

Un backup v�lido es una copia de la informaci�n sobre la BD necesaria

2.1 Dise�o de la BD y Reglas B�sicas

 Es recomendable archivar los archivos redo log en disco, y luego

Teniendo en cuenta las reglas anteriores, los siguientes puntos pueden

El primer paso es parar la BD con el comando shutdown normal. Si la BD se

Una buena idea es automatizar todo este proceso con

Por ejemplo, el siguiente script para Oracle 8i

echo " "

echo " "

echo " "

echo " "

echo " "

Procedimiento Respaldo Offline o frio

1.- Bajar la base de datos (SHUTDOWN [NORMAL,| IMMEDIATE |

2.- Anote el layout f�sico de filesystems, podria ser necesario en caso de

6.- Hacer copia del archivo de par�metros spfile o init%SID%.ora

Si la implantaci�n de BD requiere disponibilidad de la misma 24h. al d�a, 7

As� como el backup en frio permit�a realizar una copia de toda la BD al

Procedimiento Respaldo Caliente

2.3 Backups f�sicos Administrados con RMAN

RMAN es la herramienta recomendada para realizar los respaldos y

El ambiente RMAN consiste de utilidades y base de datos que juegan un rol

 La base de datos que� va a ser respaldada (base de datos target)

�� $ rman target sys/*** nocatalog

�� RMAN> BACKUP INCREMENTAL level

�� RMAN> BACKUP INCREMENTAL level