tema 20 backups y procedimientos de recuperaciÓn

Formación 2002. Tema 20. Backups y Procedimientos de Recuperación.

Práctica de Bases de Datos. of 14

TEMA 20 BACKUPS Y PROCEDIMIENTOS DE RECUPERACIÓN

1. Tipos de Backups. 2. Backups Lógicos. 3. Export. 4. Import. 5. Backups Físicos. 6. Offline Backups. 7. Online (ARCHIVELOG) Backups. 8. Implementación Export. 9. Implementación Import.



1. TIPOS DE BACKUPS.

• Existen tres métodos para hacer un backup en una base de datos ORACLE:

i. Export. à Backup lógico de la base de datos. ii. Offline backups. à Backup físico de la base de datos. iii. Online (ARCHIVELOG) backups. à Backup físico de la base de

datos.

2. BACKUPS LÓGICOS.

• Un backup lógico de una B.D. implica el leer un conjunto de registros y escribirlos en un fichero.

• Estos registros son leidos independientemente de su localización física. • La utilidad export es usada para realizar este tipo de backup. • Para recuperar un backup que se ha generado con la utilidad export

usaremos la utilidad import.

3. EXPORT.

• La utilidad export lee la base de datos, incluyendo el diccionario de datos, y escribe la salida en un fichero binario llamado fichero “dump”.

• La extensión de este fichero es “dmp”. • Podemos exportar la base de datos completa, especificar usaurios, o

especificar tablas. • Durante la exportación se puede escoger si queremos exportar la

información del diccionario asociada a tablas, como son los privilegios, índices, restricciones asociadas a ellas.

• La exportación se puede realizar para todas las tablas, o sólo para aquellas tablas que han sufrido cambios desde la última exportación.

• Hay dos tipos diferentes de exportaciones incrementales: i. Incremental: Exportará todas las tablas que han cambiado desde la

última exportación. ii. Acumulativa: Exportará todas las tablas que han cambiado desde la

ultima exportación completa.

4. IMPORT.

• Una vez que los datos se han exportado, pueden ser importados a través de la utilidad import.

• La utilidad import lee el fichero binario “dmp” y ejecuta los comandos encontrados allí. Por ejemplo, estos comandos pueden ser el comando “create table” seguido de un insert para cargar los datos en una tabla.



• Los datos que han sido exportados no tienen por qué ser importados dentro de la misma base de datos, o en el mismo esquema.

• Se pueden importar toda o parte de los datos exportados. Si se importa el fichero “dmp” de una exportación completa, todos los objetos, incluyendo espacios de tablas, ficheros de datos y usuarios, serán creados durante la importación.

• La importación se puede realizar en una base de datos con versión superior de Oracle.

5. BACKUPS FÍSICOS.

• Los backups físicos implica compiar los ficheros que constituyen la B.D. sin importar su contenido lógico.

• Oracle incluye dos tipos de backups físicos: i. Offline backups.

ii. Online backups.

6. OFFLINE BACKUPS.

• Offline backups ocurre cuando la B.D. ha sido apagada (shutdown). • Cuando la B.D. está offline se hace un backup de los siguientes ficheros:

i. Todos los ficheros de datos. ii. Todos los ficheros de control. iii. Todos los ficheros redo log. iv. El fichero init.ora. (opcional)

• Teniendo un backup de estos ficheros cuando la base de datos se ha puesto

offline, es como si tuviéramos una imagen completa de la B.D. justo antes de ponerla offline.

• No se puede hacer un backup del sistema de ficheros, mientras la base de datos está abierta, si no es un backup en caliente (backup ARCHIVELOG).

7. ONLINE BACKUPS.

• Se puede usar backups online para una B.D. que se está ejecutando en modo ARCHIVELOG.

• En este modo los redo logs son almacenados, creando un fichero log de todas las transacciones de la base de datos.

• Oracle escribe en los ficheros “redo log” de una forma cíclica. Después de rellenar el primer fichero “redo log”, se comienza a escribir en el segundo fichero “redo log”, y así sucesivamente (Proceso LGWR).



• Cuando Oracle se ejecuta en modo ARCHIVELOG, el proceso ARCH hace una copia de cada fichero “redo log” antes de sobreescribirlo.

• Por tanto, se puede realizar un backup con la B.D. abierta, si se está ejecutando el modo ARCHIVELOG.

• Mientras la B.D. está abierta, se hace un backup de los siguientes ficheros: i. Todos los ficheros de datos.

ii. Todos los archivos “redo log” . iii. Un fichero de control, a través de “alter database”.

• Online backups son muy poderosos por dos razones:

i. Permite recuperar completamente la base. ii. Permite a la base estar abierta durante el proceso de backup.

8. IMPLEMENTACIÓN EXPORT.

• La utilidad export tiene 3 niveles de funcionalidad:

i. Full mode: La B.D. completa es exportada. El diccionario de datos es leido completamente, y los DDL necesarios para recrear la B.D. completa es escrito en el fichero “dmp”. El fichero “dmp” incluirá definiciones de todos los espacios de tablas, todos los usuarios y todos los objetos, datos, y privilegios en sus esquemas.

ii. User mode: Los objetos del usuario son exportados, incluyendo

sus datos. Todos los privilegios e índices creados por el usuario en sus objetos son exportados. Privilegios e índices creados por usuarios distintos del propietario no son exportados con esta opción.

iii. Table mode: Una tabla específica es exportada. La estructura de

tabla, índice, y permisos son exportados junto con sus datos. Esta opción también permite exportar el conjunto de tablas propietarias de un usuario, (especificando el esquema del usuario, no sus tablas).

• El comando EXPORT posee una serie de parámetros que pueden entrar en conflicto por ser inconsistentes. Por ejemplo, FULL=Y y OWNER=HR fallaría.

• En la siguiente tabla se especifican los parámetros de este comando.



Palabra Clave Descripción USERID Login/password de la cuenta que ejecuta la exportación BUFFER Tamaño del buffer usado para las filas de datos. Suele ser un valor grande (>64000) FILE Nombre del fichero dump COMPRESS Y/N. Indica si la exportación comprimirá fragmentos segmentados en una simple

extensión. GRANTS Y/N. Indica si los permisos de los objetos serán exportados. INDEXES Y/N. Indica si los índices de tablas serán exportados. ROWS Y/N. Indica si las filas serán exportadas CONSTRAINTS Y/N. Indica si las restricciones serán exportadas. FULL Si está puesto a Y, la B.D. completa será exportada. OWNER Una lista de usuarios de la B.D. será exportados. TABLES Una lista de tablas serán exportadas. RECORDLENGTH La longitud en bytes, del registro del fichero dump. INCTYPE “COMPLETE” (default), “CUMULATIVE”, “INCREMENTAL” DIRECT Y/N. Exportación directa bypassing el buffer de cache en la exportación. RECORD Y/N. Para exportaciones incrementales, indica si el registro será grabado en el

diccionario de datos grabando la exportación. PARFILE STATISTICS “COMPUTE”, “ESTIMATE”, “N” CONSISTENT Y/N. En el caso de que las tablas sean modificadas durante la exportación, para

mantener la consistencia de los datos. LOG Nombre del fichero log generado en la exportación FEEDBACK Numero de filas despues de las cuales se muestra el progreso de la exportación. Por

defecto es 0, así que no se muestra nada hasta que la tabla no se ha exportado completamente.

POINT_IN_TIME_RECOVER Y/N. RECOVERY_TABLESPACES ---

• Estos comandos pueden ser visualizados usando el siguiente comando:

exp help=Y

• El comando exp se encuentra en c:\oracle\ora81\bin Ejemplo /*Fichero Exporta1.bat */ EXP SYSTEM/MANAGER FILE=EXPDAT.DMP OWNER=(FORM,F02)

EXPORTACIÓN COMPLETA VERSUS INCREMENTAL/ACUMULATIVA

• El parámetro INCTYPE, cuando es usado con el parámetro FULL, permite al DBA exportar solo aquellas tablas que han cambiado desde la última exportación.

• Si cualquier fila en una tabla ha cambiado, entonces todas las filas de la tabla son exportadas a través de el backup Incremental o Acuumlativo.

• La siguiente tabla nos muestra los tres tipos.



Opción Descripción COMPLETE Es el valor por defecto. Todas las tablas especificadas

serán exportadas. CUMULATIVE Si FULL=Y, sólo aquellas tablas que contienen filas que

han cambiado desde el ultimo Full export de cualquier tipo, serán exportadas

INCREMENTAL Si FULL=Y, se exportarán todas las tablas cuyas filas han cambiado desde el ultimo Cumulative/Complete exportación.

EXPORTACIONES CONSISTENTES

• Supongamos que tenemos dos tablas A,B, donde la tabla B contiene una clave foránea a la tabla A.

• Supongamos que ocurre lo siguiente: i. Comienza la exportación

ii. La tabla A es exportada iii. Se hace una transacción en la tabla B y se ejecuta su COMMIT. iv. Esta transacción ha afectado a la tabla A, pero la exportación de

dicha tabla ya se ha realizado antes. v. La tabla B es exportada.

• Como vemos, el fichero dump generado en la exportación contiene datos inconsistentes.

• Para evitar este problema hay dos opciones: i. Evitar que nadie haga modificaciones de tablas.

ii. Usar el parámetro CONSISTENT.

• El parámetro CONSISTENT está sólo disponible para exportaciones completas. Incremental y Acumulativas no pueden usarlo.

• Cuando CONSISTENT=Y la B.D. mantendrá un segmento rollback para seguir cualquier modificación realizada desde que comenzó el último export.

• Las entradas en el segmento de rollback pueden ser usadas para recrear los datos de la exportacion.

• El costo de esto implica el uso de un segmento rollback grande EXPORTACIONES DE ESPACIOS DE TABLAS

• Las exportaciones de los espacios de tablas se realizan por dos motivos: i. Defragmentar un espacio de tablas.

ii. Crear una copia de los objetos .

• Consideremos que tenemos dos cuentas: A y B.



• Si el usuario A crea un índice en una de las tablas de B, entonces una exportación del usuario A, no grabaría el índice porque A no es propietario de la tabla de B.

• Una exportación del usuario B, tampoco grabaría el índice, ya que el propietario del índice es A.

• Lo mismo ocurre con los permisos. • Para ello podemos crear un script mirando en DBA_TABLES y

DBA_INDEXES. Ejemplo: /* Fichero chequea.sql */ SELECT OWNER, TABLESPACE_NAME, COUNT(*) ||' tables' OBJECTS FROM DBA_TABLES GROUP BY OWNER, TABLESPACE_NAME UNION SELECT OWNER, TABLESPACE_NAME, COUNT(*) ||' indexes' OBJECTS FROM DBA_INDEXES GROUP BY OWNER, TABLESPACE_NAME; / SQL> @CHEQUEA OWNER TABLESPACE_NAME OBJECTS ------------------------------ ------------------------------ ------------------------------------------------ FLOWER USERS 3 tables 2 indexes HR HR_TABLES 27 tables HR_INDEXES 25 indexes THUMPER USERS 5 tables

• En este ejemplo podemos observer que el usario FLOWER y THUMPER tienen tables en el mismo tablespace USERS.

• Antes de determinar la exportación, debemos hacer el proceso inverso. Determinaremos por cada espacio de tabla, qué usarios están relaccionados con ese espacio de tabla.

SELECT TABLESPACE_NAME, OWNER, COUNT(*) ||' tables' OBJECTS FROM DBA_TABLES GROUP BY TABLESPACE_NAME, OWNER UNION SELECT TABLESPACE_NAME, OWNER, COUNT(*) ||' indexes' OBJECTS FROM DBA_INDEXES GROUP BY TABLESPACE_NAME, OWNER; /



TABLESPACE_NAME OWNER OBJECTS ------------------------------ ------------------------------ --------------------------------------- HR_INDEXES HR 5 indexes HR_TABLES HR 27 tabes USERS FLOWER 3 tables 2 indexes THUMPER 5 tables

• Según esto, el espacio de tablas HR_TABLES, contiene solo la cuenta del usario HR. Lo mismo ocurre para el espacio de tablas HR_TABLES.

• En cambio, el espacio de tablas USERS, contiene tablas e índices de diferentes cuentas.

• Por tanto, si exporto las tablas del espacio de tablas HR_TABLES,

exportará las tablas del usario HR.

Exp system/manager file=hr.dmp owner=HR indexes=Y compress=Y

• Una vez exportadas las tablas e índices del espacio de tablas HR_TABLES y HR_INDEXES, los espacios de tablas pueden ser borrados y recreados de nuevo. El procedimiento sería el siguiente:

Svrmgrl SVRMGR> connect internal SVRMGR> drop tablespace HR_TABLES including contents; SVRMGR> drop tablespace HR_INDEXES including contents; SVRMGR> create tablespace HR_TABLES.... SVRMGR> create tablesapce HR_INDEXES... SVRMGR> exit

• Una vez creados de nuevos los espacios de tablas podemos proceder a importar los objetos del fichero dmp.

imp system/manager file=hr.dmp full=Y buffer=64000 commit=Y • Antes de llegar a este punto hemos tenido que analizar la distribución de

los objetos de los usarios en la base de datos. Si el espacio de tabla está dedicado para un usuario el proceso es sencillo.

• Lo que no es sencillo es cuando existen objetos de diferentes usarios en un espacio de tabla. Esto requiere hacer una exportación de cada usario en ese espacio de tabla.

EXPRTANDO PARTICIONES • Se pueden referenciar particiones dentro de tablas cuando se realiza las

exportaciones de tablas.



• Por ejemplo si la tabla clientes en el esquema FORM está particionada en PART1, PART2, PART3, se puede exportar la tabla completa o sus particiones.

• Para exportar la tabla entera uso el parámetro TABLES en la exportación. Exp system/manager FILE=clientes.dmp TABLES=(FORM.CLIENTES);

• Para exportar una partición específica, la partición y el nombre de la tabla deberían estar separadas por ‘:’. Exp system/manager FILE=clientes.dmp TABLES=(FORM.CLIENTES:PART1);

9. IMPLEMENTACIÓN IMPORT.

• La utilidad import lee los ficheros dmp y ejecuta los commandos que se encuentra dentro.

Palabra Clave Descripción USERID Login/password de la cuenta que ejecuta la importación BUFFER Tamaño del buffer usado para las filas de datos. Suele ser un valor grande (>100000) FILE Nombre del fichero dump SHOW Y/N. Indica si los contenidos del fichero deberían ser mostrados cuando se ejecute. IGNORE Y/N. Especifica si la importación ignora errores encontrados cuando use comandos

CREATE. Esto es por si los objetos importados ya existen. GRANTS Y/N. Indica si los permisos de los objetos serán exportados. INDEXES Y/N. Indica si los índices de tablas serán exportados. ROWS Y/N. Indica si las filas serán exportadas FROMUSER Una lista de cuentas de usarios cuyos objetos deberían ser leidos desde el fichero de

exportación, es decir, cuando FULL=N. TOUSER Una lista de cuentas de usarios en la cual los objetos en el fichero de exportación será

importado. FROMUSER y TOUSER no tienen por qué tener el mismo valor. FULL Si está puesto a Y, la B.D. completa será importada. TABLES Una lista de tablas serán importadas. RECORDLENGTH La longitud en bytes, del registro del fichero dump. INCTYPE “COMPLETE” (default), “CUMULATIVE”, “INCREMENTAL” COMMIT Y/N. Indica si la importación debería commit despues de cada array (cuyo tamaño

está en el buffer). Si está a N, el commit se ejecutará después de la importación de cada tabla.

INDEXFILE Muy útil para separar indices de tablas. Es el fichero en el que se importarán los indices. Pondremos INDEXES=N, con lo que no se importan los índices, y luego importamos los índices a través de este fichero.

DESTROY Y/N. Para los comandos CREATE TABLESPACE encontrados en los ficheros dmp en una exportación completa, si se ejecuta o no, destruyendo los ficheros de datos eb la base de datos a la cual se va a importar.

PARFILE LOG Nombre del fichero log generado en la exportación FEEDBACK Numero de filas despues de las cuales se muestra el progreso de la importación. Por

defecto es 0, así que no se muestra nada hasta que la tabla no se ha importado completamente.

POINT_IN_TIME_RECOVER Y/N. CHARSET Carácter establecido a usar en la importación. ANALYZE Y/N. Indica si la importación debería ejecutar comandos ANALYZE encontrados en

los ficheros dmp exportados.



REQUERIMIENTOS DE LOS SEGMENTOS DE ROLLBACK • Por defecto la base de datos ejecutará un commit después de que cada

tabla sea importada completamente. Si yo tengo una tabla de 300 MB de datos, mi segmento de rollback debe ser al menos del tamaño de esa tabla. Para reducir los tamaños de los segmentos de rollback, especificaremos COMMIT=Y con un valor para buffer. Un commit será ejecutado entonces después de cada llenado de buffer.

Ejemplos: imp system/manager file=expdat.dmp imp system/manager file=expdat.dmp buffer=64000 commit=Y

• En el primero, el commit se ejecuta después de cada importación completa de tabla.

• En el segundo, después de cada llenado del buffer. • Cuando COMMIT=Y, ese commit se ejecuta para cada llenado del array

del buffer. Esto implica que si la importación de una tabla falla, es posible que algunas de sus filas en la tabla ya hayan sido importadas y committed. Para ejecutar la importación de nuevo, tendráimos que borrar las filas ya importadas.

IMPORTANDO DENTRO DE DIFERENTES CUENTAS. • Para mover objetos de un usuario a otro usuario via export/import,

exportaremos el propietario de los objetos. • Durante la importacion especificaremos el porpietario como FROMUSER,

y la cuenta a donde irán los objetos como TOUSER. Ejemplo:

Exportar los objetos de FORM a la cuenta F02 • Primero exporto los objetos del propietario FORM, y luego importo los

objetos de FORM en la cuenta F02. Exp system/manager file=form.dat owner=FORM grants=N indexes=Y compress=Y rows=Y Imp system/manager file=form.dat FROMUSER=FORM TOUSER=F02 rows=Y indexes=Y IMPORTANDO ESTRUCTURAS QUE FALLAN AL IMPORTAR • Los parámetros de filas son muy usuales por dos razones:

i. Pueden ser usados para recrear la estructura de la base de datos, sin los datos de las tablas, incluso cuando los datos fueron exportados.



ii. Se pueden recuperar determinados objetos que no fueron creados en el primer intento de importación.

• Cuando ejecuto Export, se exportan los usarios en el orden en el que

fueron creados en la base de datos. • Las tablas de usarios se exportan alfabéticamente. • Problema:

Si intento crear un objeto, como puede ser una vista, antes de crear el objeto del cual depende, se producirá un error. En tal caso, el comando Import se puede ejecutar de nuevo, con ROWS=N and IGNORE=N, lo cual importará los objetos que no fueron creados durante la primera importación, es decir, la vista en nuestro ejemplo. Ejemplo: Imp system/manager file=expdat.dmp full=Y commit=Y buffer=64000 Imp system/manager file=expdat.dmp ignore=N rows=N commit=Y buffer=64000

• El parámetro ignore en el Segundo commando le dice al import que ignore cualquier objeto que fue creado durante el primer pase. Sólo se importará aquellos objetos que fallaron. Suelen ser vistas que referencian a tablas propiedad de múltiples usuarios.

• Si una tabla referenciada por una vista es borrada, la definición de la vista permanece en el diccionario de datos. Esta definición puede ser exportada, y la creación de la vista fallará durante la importación. La segunda importación también fallará.

USANDO IMPORT PARA SEPARAR TABLAS E ÍNDICES • Se pueden usar dos opciones de importación:

i. INDEXFILE ii. INDEXES

• INDEXFILE durante una importación nos permite crear un fichero. Este fichero puede ser editado para modificar el espacio de tabla (tablespace) y los parámetros de almacenamiento de las tablas e índices listados en ese fichero. Luego ese fichero se puede ejecutar via sql*plus.

• Cuando el indexfile es creado, los scripts create index son los únicos que no son comentados con rem. Esta utilidad permite separar a los dba los índices de las tablas en diferentes espacios de tablas.

• Luego importaremos el usario con INDEXES=N, asi que los indices del usario no serán importados. Luego ejecutaré el fichero index modificado para crear los índices en el nuevo espacio de tabla.



• El fichero de index puede contener entradas para múltiples usarios, si múltiples usuarios fueron exportados. En la práctica es útil separar el fichero index en diferentes ficheros, uno por cada usuario. Esto hará fácil guardar la consistencia de los asignamientos a espacios de tablas.

En el siguiente ejemplo, los objetos de FORM son copiados a la cuenta F02, y los índices son separados de las tablas en el proceso. a) exp system/manager file=expdat.dmp owner=FORM b) imp system/manager file=expdat.dmp indexfile=indexes.sql full=Y /*Crea el índice */ c) Edito el fichero indexes.sql para cambiar la configuración de los tablespaces de los índices d) Importo el usuario sin índices:

Imp system/manager file=expdat.dmp fromuser=FORM touser=F02 indexes=N commit=Y buffer=64000.

e) Logarse en SQL*PLUS como el usuario y ejecuto el fichero indexfile para crar los índices. sqlplus FO2/F02 SQL>@indexes

10. OFFLINE BACKUPS.

• Un backup en frio es un backup físico de los ficheros de la base de datos, que se realiza después de que la base de datos se ha apagado (shut down) normalmente.

• Al realizarse la copia después de que la base se ha apagado, la copia contiene una imagen completa de la base de datos en el mismo estado justo antes de apagarse.

• Ficheros a copiar: i. Todos los ficheros de base de datos.

ii. Todos los ficheros de control. iii. Todos los ficheros redo logs. iv. El fichero init.ora (es opcional).

a) Apagado de la base de datos:

svrmgrl SVRMGRL> connect internal SVRMGRL> shutdown immediate;

b) Montado de la base. Después de que termine podemos proceder a montar la

base, es decir, levantarla, pero sin abrirla. SVRMGRL> startupu mount. Con esta instrucción hemos levantado la base de datos pero no la hemos abierto, por lo que nadie, excepto otro administrador, puede estar manipulando sus objetos.

c) Ahora podemos realizar la copia de los ficheros.



d) Finalmente podemos levantar la base de datos para que pueda volver a ser usada por todos los usuarios. Alter database open

11. BACKUPS ONLINE EN MODO ARCHIVELOG.

• Los backups offline sólo se pueden hacer cuando la base de datos está apagada.

• Se puede realizar un backup físico de la B.D. mientras está abierta. Para ello la base debe estar ejecutándose en modo ARCHIVELOG.

• Oracle escribe a los ficheros redo log en una forma cíclica. Después de rellenar el primer fichero log, se escribe en el segundo hasta que se llena, y comienza a escribir en el tercero. Una vez que el último se llena, el proceso LGWR comienza a sobreescribir el contenido del primer fichero redo log.

• Cuando Oracle se ejecuta en modo ARCHIVELOG, el proceso ARCH hace copias de cada redo log antes de sobreescribirlo. Estos archivos de redo log suelen escribirse a un disco. Pueden escribirse a cinta directamente también pero la operación requiere más tiempo.

• Pasos:

Svrmgrl SVRMGR> connect internal SVRMGR> startup mount cc1; SVRMGR> alter database archivelog; SVRMGR> archive log start; SVRMGR> alter database open;

• El siguiente comando visualizará el estado del ARCHIVELOG de la base de datos:

archive log list Para cambiar a modo NOARCHIVELOG usaremos los siguientes comandos: Svrmgrl SVRMGR> connect internal SVRMGR> startup mount cc1; SVRMGR> alter database noarchivelog; SVRMGR> archive log start; SVRMGR> alter database open; • La ubicación de los ficheros redo log está determinado en la configuración

del fichero init.ora. • Parámetros del fichero config.ora:



i. log_archive_dest = c:\ORACLE\ORA81\ORADATA\arch ii. log_archive_start = TRUE

• En este ejemplo el fichero redo log es escrito en ese directorio y su

nombre comenzará con los caracteres ‘arch’ seguido de un número de secuencia.. Ejemplos:

arch_170.dbf arch_171.dbf arch_172.dbf

• El tamaño de un fichero redo varía . Si no hay espacio suficiente en el

destino para guardarlo, la base de datos se parará. Esta situación se solventa haciendo un backup de los ficheros redo log, y luego borrándolos del disco, para dejar espacio a los nuevos.

• Nunca hay que borrar los ficheros redo log hasta que se halla hecho un backup de ellos. Esto es debido a que nohay forma de saltarse un fichero redo log en un proceso de recuperación.

• Si la B.D está ejecutándose , se puede ver la configuración de ARCHIVELOG a través del comando archive log list. Otra forma es como se muestra a continuación:

SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME LIKE 'log_archive%'; / • Aunque LOG_ARCHIVE_START sea TRUE, la B.D. no estará en modo

ARCHIVELOG hasta que se haya ejecutado el comando alter database archivelog.

REALIZANDO ONLINE BACKUPS • Una vez que la BD está en modo ARCHIVELOG, en esta se puede hacer

un backup mientras los usarios la usan. Aunque los backups se pueden hacer en horas de trabajo, deberían programarse para horas donde la actividad fuese reducida por diferentes razones:

tema 20 backups y procedimientos de recuperaciÓn

Documents