Вы находитесь на странице: 1из 20

BACKUPS en Oracle:

1. Introducción.

El enfoque en un Backup de una Base de Datos Oracle es la recuperación física


de los archivos de bases de datos, lo que permite reconstruirla en casos especiales
como el daño de archivos, la eliminación accidental de un archivo de datos, el
fallo de una unidad de disco o migración física de los datos a otro servidor

Tipos de Backup.
Los backups se pueden clasificar en físicos y lógicos.

Backup Físicos: Los físicos se realizan cuando se copian los ficheros que soportan la
BD.

 Backup de SO: El mas sencillo de ejecutar, aunque consume mucho tiempo y


hace inaccesible al sistema mientras se lleva a cabo.

 Backup en frío:Los backups en frío 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 también todas las aplicaciones que estén trabajando con la BD.

 Backup 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 ficheros correspondientes a un tablespace determinado, los ficheros
REDO LOG archivados y los ficheros de control.

Backup Lógicos: Los backups lógicos sólo extraen los datos de las tablas utilizando
comandos SQL y se realizan con la utilidad export/import.

 Backup 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

Presentación de la recuperación
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.
Tipos de errores en la recuperación de BD en Oracle.

 Errores de Usuario: Pueden ocurrir cuando el usuario borra una fila o elimina
una tabla. Estos errores se solucionan importando una tabla de una copia lógica
anterior. Tambien se puede recuperar la BD en una instancia auxiliar, ya sea
importanto o exportando la tabla.

 Fallos de Sentencias: Se definen como la imposibilidad del SGBD Oracle de


ejecutar alguna sentencia SQL. Estos fallos se recuperan automáticamente
mediante un rollback de la transacción que contenía la sentencia fallida.

 Fallos de Procesos: Terminacion 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.

 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
transacción distribuida, una vez que se reestablece la conexión, el proceso
RECO resuelve los conflictos automáticamente.

 Fallos de Instancia: Pueden deberse a fallos 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.

 Fallos del Sistema: Son los fallos más peligrosos, no sólo porque se pueden
perder datos, sino porque se tarda más tiempo en recuperar que los otros fallos.

Niveles de Recuperación en Oracle.


 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. Automática al levantar la BD.

 Recuperación física: Se realiza como respuesta a un comando

RECOVER. Se utiliza para convertir los ficheros de backup en actuales. Restaura cambios
perdidos al poner un fichero offline sin checkpoint.

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.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 después
de una caida, se necesitará efectuar una recuperación que consiste en dos pasos: avanzar
la BD hacia adelante aplicando los registros redo log, deshacer las transacciones no
confirmadas

 Recuperación lógica: 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 exportación y
ejecuta las sentencias que almacenan creando las tablas y
llenándolas de datos.
 Importación y Exportación o Métodos de Export puede ser: Modo Tabla, Modo
Usuario, Modo tablespace, Modo BD Entera o por DataPump.

 Recuperación física: La utilización de una copia de backup de ficheros de datos


siempre necesita de una recuperación física. También es así cuando un fichero
de datos se pone offline sin un checkpoint.

Requisito para utilizar recuperacion fisica:

1. Que utilice ARCHIVELOG.


2. Recuperacion de la BD: La BD debe estar montada pero no abierta.
3. Recuperacion de un tablespace: La BD debe estar abierta, pero con el
tablespace a recuperar offline.
4. Recuperacion de un fichero de control: 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.

2. BACKUPS FÍSICOS

Un backup es una copia de estructuras y datos de la base de datos que


tiene como finalidad el poder llegar a recuperar en el tiempo nuestra base
de datos en el caso de un fallo en el sistema. Para establecer la estrategia
de backup a utilizar se debe tomar en cuenta la naturaleza de los datos,
en que momento se modifica esa información y que crítica es esa
información en nuestro negocio.

2.1. BACKUPS EN FRIO

Se debe tener en cuenta que para realizar un backup en frio la base debe
ser desmontada eso significa que no se puede realizar en bases de datos
que funcionan 24/7 (las 24 horas los 7 días de la semana), es decir
siempre.

¿Cómo hacerlo?

Backup:

En primer lugar detendremos la base de datos para ello abrimos


SQL*PLUS:
cmd> sqlplus /nolog

sql> conn sys AS sysdba

sql> shutdown IMMEDIATE;

Una vez detenida la base copiamos los ficheros q la componen (datos, control, redolog)
y ficheros de configuración y contraseñas (SPFILE y PWDFIle) , suelen esta ubicados
en
$oracle_home/dbhome_1/DATABASE
Copiaremos también todos los ficheros de log archivado:
$flash_recovery_area
Una vez copiados todos los ficheros a una ubicación de red local volveremos a iniciar la
base de datos con el comando:
sql> startup

Restauración:
Primera opcion:
Se debe de apagar la base de la siguiente manera:
sql> shutdown IMMEDIATE;
Copiamos lo que tenemos en:
$flash_recovery_area
y lo pegamos en
$oradata\orcl
Y luego volvemos a iniciar la base con el comando:
sql> startup

Segunda opcion:
Si se ha alterado la direccion de donde se puso el backup al principio
sql> oradim -NEW -SID SAME_AS_BACKED_UP_DB -pfile FULLPATH\init.ora -
syspass contraseña
Copiar los oradata a la misma direccion de la que se desea recuperar

En el caso de que el datafile halla sudo movido de la dirección, la base


de datos debe der iniciada con startup mount:
C:\SET oracle_sid= mySID

C:\sqlplus

SQL> startup mount;


(si el data file no esta en la direccion se puede especificar su direccion
con spfile=’LOCATION\SPFILESSID.ora’)

(Para que se pueda ubicar de una manera mas sencilla se puede


renombrar)
SQL> ALTER DATABASE RENAME FILE ‘OLD_LOCATION\DATAFILE_1.ora’ TO
‘NEW_LOCATION\DATAFIE_1.ora’;

SQL>ALTER DATABASE datafile ‘NEW_LOCATION\DATAFILE1.ora’ ONLINE;

SQL>ALTER DATABASE OPEN;

Tipos de errores en la recuperación de BD en Oracle.

 Errores de Usuario: Pueden ocurrir cuando el usuario borra una


fila o elimina una tabla. Estos errores se solucionan importando
una tabla de una copia lógica anterior. Tambien se puede recuperar
la BD en una instancia auxiliar, ya sea importanto o exportando la
tabla.
 Fallos de Sentencias: Se definen como la imposibilidad del
SGBD Oracle de ejecutar alguna sentencia SQL. Estos fallos se
recuperan automáticamente mediante un rollback de la transacción
que contenía la sentencia fallida.
 Fallos de Procesos: Terminacion 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.
 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 transacción distribuida, una vez que se
reestablece la conexión, el proceso RECO resuelve los conflictos
automáticamente.
 Fallos de Instancia: Pueden deberse a fallos 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.
 Fallos del Sistema: Son los fallos más peligrosos, no sólo porque
se pueden perder datos, sino porque se tarda más tiempo en
recuperar que los otros fallos.

Ventajas:

 La consistencia de datos está garantizada: No se da el caso de que


los datos a ser respaldados estén siendo usados por algún usuario
por que ellos no pueden acceder a la base de datos.
 Este tipo de respaldo incluye todos los Datafiles, los Controlfiles,
y los Logfiles; no hay posibilidad de que alguna tabla o vista no
quede en el backup.
 El espacio que ocupa es conocido, además el tiempo de respaldo y
recuperación es predecible.

Desventajas:

 Nada excluido: esto se convierte en una desventaja cuando no se


desea restaurar toda la información. Aquí no se permiten hacer
respaldos ni restauraciones parciales, es decir "se respalda todo o
nada y se restaura todo o nada"; Solo se puede hacer con la base
de datos cerrada: nadie puede estar trabajando.

2.2. BACKUPS EN CALIENTE

Conexión a RMAN
La forma más simple de conectarse a RMAN es la siguiente (con el usuario oracle):
$ rman target /

Recovery Manager: RELEASE 10.2.0.1.0 - Production ON Wed Mar 8


13:16:22 2006

Copyright (c) 1982, 2005, Oracle. ALL rights reserved.

connected TO target DATABASE: LCBDPROD (DBID=2582320114)

RMAN>

Si queremos que nuestras actividades se registren en un archivo log:


$ rman target / LOG /ruta/archivo.LOG [append]
Parámetros de configuración de RMAN
RMAN viene configurado con una serie de parámetros predefinidos, mismos que
podemos ver con el comando show:
RMAN> show ALL ;

using target database control file instead OF recovery catalog

RMAN configuration parameters are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # DEFAULT

CONFIGURE BACKUP OPTIMIZATION OFF; # DEFAULT

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # DEFAULT

CONFIGURE CONTROLFILE AUTOBACKUP OFF; # DEFAULT


CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
# DEFAULT

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; #


DEFAULT

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # DEFAULT

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; #


DEFAULT

CONFIGURE MAXSETSIZE TO UNLIMITED; # DEFAULT

CONFIGURE ENCRYPTION FOR DATABASE OFF; # DEFAULT

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # DEFAULT

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # DEFAULT

CONFIGURE SNAPSHOT CONTROLFILE NAME TO


'/oracle/10.2.0/dbs_1/dbs/snapcf_LCBDPROD1.f';

# DEFAULT

Respaldos incrementales

Un respaldo incremental consta de dos niveles: 0 (respaldo completo de la base de datos


y que sirve de base a los respaldos incrementales) y 1 (respaldos incrementales en los
que solamente se respaldan los bloques que han cambiado desde el último respaldo).
Adicionalmente, es posible “actualizar” el respaldo de nivel 0 con los cambios del
respaldo de nivel 1. Un respaldo de este tipo se haría de la siguiente forma:

Paso 1. Respaldo completo (nivel 0):


RMAN> backup incremental LEVEL 0 tag ‘INC_L0’ database ;

Paso 2: Primer respaldo incremental (nivel 1):


RMAN> backup incremental LEVEL 1 FOR recover OF copy tag ‘INC_L0’
database ;
Paso 3: Aplicar el respaldo incremental al respaldo de nivel 0, es decir, aplicar los
cambios en los bloques al respaldo base.
RMAN> recover copy OF database WITH tag ‘INC_L0’ ;
Para que el desempeño del respaldo incremental sea óptimo, es necesario habilitar la
opción llamada block change tracking, que es un archivo que lleva el registro de los
bloques que van cambiado desde el último respaldo. Si no está habilitado, RMAN tiene
que leer todos los bloques de la base de datos para determinar cual respaldar, haciendo
el respaldo tan caro como un full backup. Para habilitar block change tracking:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING ;
El archivo de tracking se genera automáticamente en el área de flashback.
Respaldo de los respaldos
Si los respaldos se están haciendo en flashback recovery area, es conveniente respaldar
también esta área que se encuentra en disco.
RMAN> backup recovery area ;
Esto respalda todos los archivos de recuperación en flashback recovery area: full
backups, copies, incrementals, respaldos de controlfiles, y archivelogs. No se respaldan
block change tracking files, controfiles actuales ni redo logs. El único destino válido
para estos respaldos es cinta.

Políticas de retención
Las políticas de retención nos ayudan a determinar qué respaldos todavía son necesarios
y cuáles ya no debido a que han quedado obsoletos por un respaldo más reciente. Hay
dos tipos de políticas de retención y son mutuamente excluyentes: redundancy y
recovery window.

 Redundancy: determina cuantas copias de un archivo se necesitan antes de


considerar una copia obsoleta. Si la redundancia es 1, cada que se respalde un
archivo (copia), todas las copias anteriores son obsoletas. REDUNDANCY=1 es
la política de retención por default.
 Recovery Window: determina el tiempo que debe ser retenido un archivo antes
de ser obsoleto.

Para cambiar la política de retención:


RMAN> configure retention policy TO redundancy X ;
o
RMAN> configure retention policy TO recovery window OF X days ;
Con nuestra política definida, podemos revisar los respaldos que ya son obsoletos:
RMAN> report obsolete ;
Y borrarlos si determinamos que ya no son necesarios:
RMAN> DELETE obsolete ; -- Nos pregunta si realmente queremos borrar
o
RMAN> DELETE force noprompt obsolete ; -- Borra sin confirmación.
Oracle automáticamente borrará respaldos obsoletos si flashback recovery area
comienza a tener problemas de espacio.

Configuración de cintas
RMAN no puede escribir directamente a cintas, por lo que es necesario configurar una
librería que generalmente es proporcionada por el fabricante. En versiones anteriores de
RMAN dicha librería se configuraba en $ORACLE_HOME/lib, sin embargo, en 10g
Oracle recomienda que se especifique la librería directamente:
RMAN> configure channel device TYPE sbt

2> parms= ‘SBT_LIBRARY=/PATH/librería’ ;

Reporte de operaciones
Podemos usar los comandos LIST y REPORT para generar reportes de actividades
realizadas con RMAN:
list backup summary;

list backup BY datafile;

list backup OF database;

list backup OF archivelog ALL;

list backup OF controlfile;

report obsolete ;

report need backup ;

Scripts
Archivos de comandos:
Un archivo de comandos es un archivo de texto conteniendo comandos RMAN, y que
puede ser llamado de la siguiente forma:
RMAN> @/ruta/script.txt
o
$ rman target / @/ruta/script.txt
Comando RUN:
El comando RUN agrupa comandos de RMAN para ser ejecutados como uno solo. Si
uno de los comandos falla, el resto ya no es ejecutado.
RUN {

BACKUP ARCHIVELOG ALL DELETE ALL INPUT;

BACKUP INCREMENTAL LEVEL 0 TAG mon_bkup DATABASE;

Casos de recuperación
Se puede ejecutar el comando RESTORE … VALIDATE para confirmar que una
operación puede ser ejecutada correctamente. RMAN automáticamente decide qué
archivos son necesarios para la recuperación y verifica que sean utilizables.
RMAN> restore database VALIDATE ;
Caso 1. Recuperación completa de la base de datos cuando se tiene el archivo de control
y la base de datos está montada:
RMAN> restore database ;

RMAN> recover database ;

Caso 2. Se tiene la situación del caso 1 pero se desea recuperar a un punto pasado en el
tiempo:
RMAN> run {SET until TIME = ’04-MAR-06 12:00:00’;

2> restore database ;

3> recover database ;


4> }

Caso 3. Recuperación de un datafile


Identificar el número de datafile:

SQL> SELECT file#, name FROM v$datafile ;

Poner offline el datafile, ya sea desde SQL*Plus o desde RMAN:

RMAN> SQL ‘ALTER database datafile 8 offline’ ;

Recuperar el datafile:

RMAN> run {restore datafile 8 ;

2> recover datafile 8 ;

3> SQL ‘ALTER database datafile 8 online’ ;

4> }

Caso 4. Recuperación de un tablespace.


RMAN> run {SQL ‘ALTER tablespace users offline’ ;

2> restore tablespace users ;

3> recover tablespace users ;

4> SQL ‘ALTER tablespace users online’ ;

5> }

El comando run es para correr las instrucciones en modo script, pero también pueden
ser ejecutadas una por una:
RMAN> SQL ‘ALTER tablespace users offline’ ;

RMAN> restore tablespace users ;

RMAN> recover tablespace users ;

RMAN> SQL ‘ALTER tablespace users online’ ;

Caso 5. Recuperación de bloques corruptos RMAN es la herramienta ideal para


recuperación de bloques corruptos (ORA-1578). El error nos dice cual es el bloque
corrupto:
ORA-1578: ORACLE data block corrupted (file # 7, block # 1234)

Mismos que también podemos consultar en la vista v$database_block_corruption. Para


recuperar todos los bloques corruptos:
RMAN> blockrecover corruption list ;
O podemos recuperar bloques individuales:
RMAN> blockrecover datafile 7 block 1234[, datafile 10 block 3265,
...] ;
Ventajas

 Selectivo a nivel de tablespace: Se respaldan todos los datafiles (archivos físicos


de datos) de un tablespace completo y por ende todos los objetos almacenados
en él.
 No interfiere con la operación normal de la base de datos en producción: no hay
necesidad de cerrar la base de datos y los usuarios pueden estar trabajando.
 Se puede recuperar hasta cualquier punto en el tiempo: si se respaldan los Redo
Logs suficientes y se mantienen respaldos en frío o calientes anteriores, se puede
recuperar información en cualquier fecha y hora especificados.
 Siempre recupera de manera consistente: es la única manera de recuperar la
información.

Desventajas

 La consistencia es forzosa: si se recupera toda la información no hay espacio


para hacer modificaciones, selecciones o adecuaciones. Si se desea recuperar un
objeto, no importa que haya sufrido o cual objeto sea, se deben recuperar todos
los archivos de datos "datafiles" en donde ese objeto residía hasta el momento
cuando la base de datos quede consistente.
 Es necesario mantener todos los Redo Logs archivados: Si por alguna razón un
Redo Log archivado se pierde, no se podrá recuperar la base de datos mas allá
del último Redo Log antes del cual se perdió.
 Se necesitan recursos importantes de disco para almacenar todos los Redo Logs,
además de una administración cuidadosa con políticas para bajar estos archivos
a cinta en horas determinadas y para relacionar en alguna parte información
como el numero de la cinta, la fecha, la hora, de que numero a que numero de
Redo Log se bajo y la persona que realizó la labor.

2.1. BACKUPS DE SOS (SISTEMA OPERATIVO)

3. BACKUPS LÓGICOS

Importación y Exportación.
Es uno de los más usados por los clientes de Oracle por su flexibilidad y portabilidad y
solo se puede hacer si la Base de Datos esta abierta.
Es una utilidad de Oracle para realizar backups lógicos (y luego poderlos
restaurar). Esto significa que copian el contenido de la BD pero sin
almacenar la posición física de los datos. Para realizar esta operaciones
la base de datos tiene que estar abierta.
Para crear el fichero de backup se utiliza la utilidad export y para
importar el contenido o recuperar la base de datos se realiza import.

Parámetros de Export

Parámetro Defecto Descripción


El username/password del usuario que
USERID indefinido
efectua el export.
dependiente del
BUFFER
SO El tamaño en bytes del buffer utilizado.
FILE expdat.dmp
El nombre del fichero 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 filas de
ROWS Yes 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 se
OWNER usuario actual
quieren exportar.
TABLES indefinido La lista de tablas a exportar.
dependiente La longitud en bytes del registro del
RECORDLENGTH
del SO fichero.
INCTYPE indefinido El tipo de export incremental.
Indica si se anota el export incremental
RECORD Yes en las tablas SYS.INCVID y en
SYS.INCEXP.
PARFILE indefinido El fichero de parámetros.
Métodos de Export:

 Modo BD Entera
 Modo Tabla.
 Modo Usuario.

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.
Export:
$exp file=’C:app/usuario/oracle/export.dmp’ tables=(depto, empleados)
buffer=100000
Import:
$imp file=’C:app/usuario/oracle/export.dmp’ tables=(depto, empleados)
buffer=100000
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.
Ej. Donde HR es un esquema de la BD:
Export:
$exp file=’C:app/usuario/oracle/export.dmp’ LOG=
‘C:app/usuario/oracle/ LOG /export.LOG’ owner=HR buffer=100000
Import:
$imp file=’C:app/usuario/oracle/export.dmp’ LOG=’C:app/usuario/oracle/
LOG /import.LOG’ fromuser=HR buffer=100000

Modo Base de Datos 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 derollback, las opciones de auditoría del sistema, todos los
disparadores y los perfiles. Ej.:
Export:
$exp file=’C:app/usuario/oracle/export.dmp’ full=yes LOG=
‘C:app/usuario/oracle/ LOG /export.LOG’ buffer=100000
Import:
$Impo file=’C:app/usuario/oracle/export.dmp’ full=yes LOG=
‘C:app/usuario/oracle/ LOG /import.LOG’ buffer=100000

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


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.
$ EXP userid=SYSTEM/manager full=y 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.

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

Desventajas

 Tamaño y tiempos impredecibles: es muy difícil predecir el tamaño que tendrá


un archivo de "export" al igual que el tiempo que durará el mismo o en su
defecto el import. Puede que se requiera pasar todo el archivo de export para
importar solo una parte: debido al recorrido secuencial para realizar un import, si
el objeto buscado esta al comienzo del archivo se detiene después de importarlo,
pero si está al final tiene que recorrer todo el archivo para recuperar solo ese(os)
objeto(s).

Tambien se puede hacer un exportor con utilidad data pump

DataPump

DataPump es una utilidad del lado de servidor. Aunque el proceso de


usuario es el encargado de inicializar un trabajo de DataPump, son los
procesos de servidor los que se encargan de ejecutar el trabajo; de esta
manera los procesos de servidor tienen acceso directo al SGA y a los
Datafiles, sin necesidad de ir por medio de una sesión.
Un trabajo de Data Pump involucra procesos, dos colas de trabajo, 3
tipos de archivos y las tablas.

Procesos:
Hay 2 procesos: expdp e impdp que son procesos de usuario para iniciar,
controlar y monitorear los trabajos de Data Pump. Estos procesos
establecen sesión en la base de datos a través de procesos de servidor
normales.
Cuando un trabajo Data Pump es lanzado, se inician los siguientes
procesos: Data Pump Master Process (DMmn) y uno o más Worker
Process (DWnm) que son controlados por el Master Process. Por cada
trabajo Data Pump tendrá sus respectivos procesos Master y Workers.

Colas:
Un trabajo Data Pump crea dos colas. Una de Control y una de Estatus:
La cola de Control almacena las tareas individuales que tienen que hacer
los procesos Worker. El master process divide un trabajo en tareas
individuales que son ejecutadas por los procesos Worker; esta cola
almacena las tareas en forma FIFO. Los procesos worker recojen de esta
cola solo una tarea. La cola de Estatus se utiliza para monitorear:
Almacena mensajes que describen el estado del trabajo. Estos mensajes
son enviados por el Master Process. Cualquier sesión puede (Con sus
privilegios asociados) puede consultar esta cola para monitorear el
trabajo

Archivos:
Los archivos generados por Data Pump vienen en tres formas: archivos
SQL, archivos Dump y archivos de log. Los archivos SQL incluyen
sentencias DDL que describen los objetos incluidos en el trabajo. Los
archivos Dump contienen los datos exportados en formato XML. Para
finalizar, los archivos de log incluyen un historial de todo el trabajo.

Realizar expdp:
Primero conectarse como sys o system como sysdba
SQL*Plus: RELEASE 11.2.0.1.0 Production ON Dom Oct 16 22:00:43 2011

Copyright (c) 1982, 2010, Oracle. ALL rights reserved.

--Ingresar al sql Plus como system o sys as sysdba


Enter user-name: system

Enter password:

Connected TO:

Oracle Database 11g Enterprise Edition RELEASE 11.2.0.1.0 - 64bit


Production

WITH the Partitioning, OLAP, Data Mining AND REAL Application Testing
options
Crear un directorio o utilizar uno ya creado, por cuestiones practicas crearemos uno:
CREATE OR REPLACE DIRECTORY DOCUMENTS AS 'C:\app\Lesh\Backups';
Luego asignar permisos de lectura y escritura:
SQL> GRANT read,write ON DIRECTORY DOCUMENTS TO system;
-Para ver los directories disponibles y sus permisos o privilegios, consulté:
SQL> SELECT privilege,directory_name

2 FROM user_tab_privs t, all_directories d

3 WHERE t.table_name(+)=d.directory_name ORDER BY 2,1;


Para acceder a comandos en la consola desde el sql plus usamos la instrucción HOST,
que nos permitira utilizar el comando expdp
SQL> HOST
Para efectos Practicos haremos un export unicamente de dos tablas:
C:\app\lesh\product\11.2.0\dbhome_2\BIN>expdp system/manager
tables=SCOTT.EMP,

SCOTT.DEPT DUMPFILE=DOCUMENTS:orasite.dmp
LOGFILE=DOCUMENTS:orasite.log
Durante la ejecucion te pedira que ingreses de nuevo el user y el password. Al terminar
el backup se generara dos archivos uno con extencion *.dmp y uno *.log en la ubicacion
del directorio que creamos.
Si se desea hacer un backup de esquemas se cambia el tables por esquemes y los
esquemas que se desean almacenar como por ejemplo:
C:\app\lesh\product\11.2.0\dbhome_2\BIN>expdp system/manager
esquemes=SCOTT DUMPFILE=DOCUMENTS:orasite.dmp
LOGFILE=DOCUMENTS:orasite.LOG
Y si desea hacer de toda la base se cambia por FULL=Y
C:\app\lesh\product\11.2.0\dbhome_2\BIN>expdp system/manager FULL = Y
DUMPFILE=DOCUMENTS:orasite.dmp LOGFILE=DOCUMENTS:orasite.LOG
Ventajas:

 Exportación en paralelo, escribiendo en múltiples archivos en


diferentes discos.

 Se pueden estimar los requerimientos de espacio en disco.

 Se puede especificar la versión de la BD y exportar solo los


objetos compatibles con dicha versión.

Apéndice

ARCHIVELOG: protege contra la pérdida de datos cuando se produce


un fallo en el medio físico. El comando archivelog list nos dice el estado
de la base

REDO LOG: comprime los archivos en un formato propietario que


registran una historia de todos los cambios realizados a la base de datos.

SGBD: sistema de gestión de bases de datos es un conjunto de


programas que permiten crear y mantener una Base de Datos,
asegurando su integridad, confidencialidad y seguridad.

PMON : Este proceso restaura las transacciones no validadas de los


procesos de usuario que abortan, liberando los bloqueos y los recursos
de la SGA. Asume la identidad del usuario que ha fallado, liberando
todos los recursos de la BD que estuviera utilizando, y anula la
transacción cancelada. Este proceso se despierta regularmente para
comprobar si su intervención es necesaria..

RECO: Cuando una transacción distribuida se lleva a cabo puede que


problemas en la red de comunicación haga que una de las localizaciones
no aplique las modificaciones debidas. Esta transacción dudosa debe ser
resuelta de algún modo, y esa es la tarea del proceso recuperador. Está
activo si el parámetro DISTRIBUTED_TRANSACTIONS tiene un valor
distinto de 0.

RECOVER: SQL> recover database using backup


controlfile

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.

System Change Number, SCN :es un dato que define la versión


confirmada 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
ficheros redo log son marcados con dos SCN. Cuando se abre un nuevo
fichero redo log se le marca con un SCN, low SCN, que es uno mas que
el SCN mayor del anterior fichero redo log; y su high SCN es puesto a
infinito. Los SCN también 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 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 cámbios con un SCN menor que el del checkpoint
dado han sido escritos en el disco.

Вам также может понравиться