Estrategias

De
Backup
Y
Recovery

Autor: Ing. Marcelo Tudisco

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
INTRODUCCION.........................................................................................................................................3
ARCHIVELOG..............................................................................................................................................4
NOARCHIVELOG........................................................................................................................................4
TIPOS DE BACKUP.....................................................................................................................................5
OFFLINE BACKUP..................................................................................................................................5
ONLINE BACKUP...................................................................................................................................5
BACKUP LGICO...................................................................................................................................6
FRECUENCIA DE BACKUPS ONLINE.....................................................................................................6
BACUPS EN BASES DE DATOS DISTRIBUIDAS (O REPLICADAS)...................................................6
RECUPERACIN.........................................................................................................................................7
RECUPERACION COMPLETA...............................................................................................................7
RECUPERACION INCOMPLETA..........................................................................................................7
RECUPERACION CON BASES DE DATOS DISTRIBUIDAS.............................................................8
RECUPERACION COORDINADA DE BASES DE DATOS DISTRIBUIDAS................................9
CONCLUSIONES.......................................................................................................................................10

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
INTRODUCCION

La principal tarea de un DBA es estar preparado ante la posibilidad de una falla del
medio, hardware o software. Si cualquiera de estas fallas ocurren, el principal objetivo es
poner la base disponible en un tiempo aceptable, asegurando de que no se haya perdido
ninguna modificacin.

A los efectos de entender los mecanismos de backup y recuperacin, y para tener un

conocimiento en profundidad de las estructuras de datos, el DBA debera saber que es lo que
esta almacenado en el controlfile, datafile y log file.

El controlfile refleja la estructura de la base de datos en un punto del tiempo. Este

contiene informacin de checkpoint, nombres de los log files y los datafiles, informacin de
cabezal de los archivos y el log sequence number (el cual es muy importante en el momento
de la recuperacin). La recuperacin se realiza solo aplicando los logs cuyo log sequence
number es menor que el almacenado en el controfile actual.

Los datafiles son los archivos donde estn fsicamente almacenados los datos, en su
cabezal tienen la siguiente informacin:

Log sequence number del siguiente log que debera ser aplicado
Informacin si hay un backup en lnea en proceso.

Los redo logs son los archivos donde se va generando el logging de las actividades en
la base. En su cabezal encontramos la siguiente informacin:

Log sequence number

Informacin de si fue archivado o no.
SCN o system change number, este numero es incrementado en cada commit de la
base de datos, as que podra verse como un reloj interno de la base.

Finalmente, y no por eso menos importante, el controlfile tiene la siguiente

informacin sobre los datafiles:

Nombre de los datafiles y logfiles con el camino exacto.

Tamao de los archivos
Tamao del bloque de la base
Informacin de si un datafile esta en lnea o fuera de lnea
Si un datafile fue puesto fuera de lnea automticamente o no
Si un datafile pertenece al tablespace system o no
Una entrada para cada datafile dando el log sequence number de cuando el
tablespace que lo contiene fue sacado de lnea.

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
 Tambin tiene la siguiente informacin sobre los redo log:

Nombre con el camino exacto

Tamao del archivo
Tamao del bloque del sistema operativo
Log sequence number
Si el redo fue archivado o no

En la medida que los usuarios conectados van confirmando sus modificaciones a la

base, esta va generando automticamente un log con estos cambios (redo logs). Dependiendo
de que hagamos con estos logs es el modo en cual decimos que trabaja la base. Estos modos
son: ARCHIVELOG y NOARCHIVELOG.

ARCHIVELOG

En la medida que los logs se van generando se van archivando por lo cual podemos
tener todo un historial de los cambios que se han ido produciendo a la base.

El modo archivelog provee proteccin contra fallas del medio (disco por ejemplo)
y tambin contra fallas de instancia (corte de energa, falla de cpu, etc.).
Hasta que un redo log no es archivado este no puede ser rehusado.
El archivado puede ser hecho manual o automticamente.

NOARCHIVELOG

Una vez que un log fue generado y que deja de ser activo (tiene cambios de
transacciones confirmadas que no han sido escritos a disco) puede ser sobrescrito.

Este modo solo permite proteccin ante falla de instancia.

Solo los cambios mas recientes (o aquellos que se encuentran el online redolog
CURRENT) estn disponibles en cualquier momento.
Si una base que ha estado corriendo en modo NOARCHIVELOG necesita ser
recuperada, las opciones se limitan a (y en ambos casos se perdern las
transacciones procesadas desde el backup o el export):
Recuperar la base, redo logs, y control file de un backup anterior con la
base baja.
Crear una nueva base de datos e importar los datos de un export.

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
TIPOS DE BACKUP

OFFLINE BACKUP

Es el backup realizado con la base de datos baja, es decir habiendo realizado un

shutdown normal o immediate, tambin es conocido como cold backup, full offline backup.
Se trata de copiar los datafiles, controlfiles, y online redo logs (informacin que debera ser
consultada directamente de la base de datos antes de bajarla para mayor confiabilidad,
v$dbfile, v$controlfile, v$logfile) utilizando alguna herramienta del sistema operativo. Es
considerado como un backup completo de la base de datos. Cualquier cambio realizado luego
del backup solo podr ser recuperado si la base trabaja en modo archivelog.

Cuando se cambia la estructura de la base de datos, por ejemplo se agrega o renombra

un datafile, se crea o borra un tablespace, esto se refleja en el controlfile, por lo que es
altamente recomendado bajar la base y realizar un backup del controlfile como mnimo y de
los nuevos datafiles, aunque lo ideal seria hacer un backup completo.

ONLINE BACKUP

En los lugares donde la base debe estar operativa 24 horas por da, y cuando no es
posible realizar un backup offline, entonces Oracle ofrece la alternativa de realizar backups
fsicos mientras la base esta operativa y los usuarios estn consultando y modificando la
informacin. Para este tipo de backup la base debe estar trabajando en modo archivelog. En
este caso solo es necesario realizar backup de los datafiles, del controlfile y de los redo logs
archivados. La unidad de backup es el tablespace, por lo que distintos tablespaces pueden
tener distintas frecuencias de backup, es decir podemos realizar un backup de cada uno en
tiempos distintos, por lo que podemos realizar backups completos de la base de datos o
parciales.

De todas las transacciones se guarda un log (online redo log) tanto sea que la base
trabaje en modo archivelog o no. Cuando se trabaja en modo archivelog, Oracle permite
aplicar estos logs luego de recuperar los archivos que se daaron (a menos que el archivo
daado sea un online redo log activo, en cuyo caso solo se perdern los cambios almacenados
en este redo log).

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
Nota: Tanto se trate de backup online u offline es sumamente importante tomar la
informacin de que es lo que hay que realizar backup del diccionario de la base, de esta
forma no ocurre que cada vez que agregamos un datafile tenemos que modificar el script de
backup. Este debera ser un script que consultando el diccionario (v$controlfile, v$logfile,
v$datafile) generara un script de backup, de esta forma cuando modificamos la estructura
de la base, el backup automticamente toma el cambio.

BACKUP LGICO

Consiste en realizar un export full de la base. Es un mecanismo simple, pero su

principal desventaja es el tiempo de recuperacin que tiende a ser mucho mas que en
cualquiera de los dos casos anteriores.

Es til combinar el backup lgico con el fsico (casos anteriores) a los efectos de estar
mejor preparados. Por ejemplo si el error es que un usuario borro accidentalmente una tabla
puede ser mas fcil recuperar de un export que de un backup completo.

En caso de tener que hacer una recuperacin completa a partir de un export la solucin
es crear una nueva base de datos, y luego realizar el import.

FRECUENCIA DE BACKUPS ONLINE

Para determinar cuan frecuentemente deben realizarse los backups de los archivos de
la base, se debe tener en cuenta la cantidad de tiempo que lleva realizar el backup, y la
cantidad de tiempo que lleva recuperar del backup. El tiempo de la recuperacin depende de
cuan viejo sea el backup de los archivos daados, cuanto ms viejo el backup mas largo ser
el tiempo de recuperacin.

Un punto muy importante es que la estrategia de backup debe ser testeada antes de ser
usada para proteger un sistema en produccin. Hay que asegurarse que se estn backupeando
todos los archivos de la base, y que se estn guardando todos los redo logs necesarios, y que
luego se pueda leer el backup sin inconvenientes.

BACUPS EN BASES DE DATOS DISTRIBUIDAS (O REPLICADAS)

Si la base de datos es un nodo en un ambiente de bases de datos distribuidas, todas las

bases en el sistema distribuido deben en el mismo modo de archiving, teniendo en cuenta lo
siguiente:

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
 Si ambas bases trabajan en modo ARCHIVELOG, entonces los backups en cada nodo
pueden realizarse en forma autnoma, es decir, individualmente y sin coordinacin de
hora.
Si ambas bases trabajan en modo NOARCHIVELOG, entonces se debe realizar un backup
consistente de las bases de datos en su totalidad, a la misma hora global, para planificar
una recuperacin global de las bases de datos. Por ejemplo, si una base de Miami es
backupeada a la medianoche de Miami, la base en Rep. Dominicana debe ser backupeada
al mismo tiempo, teniendo en cuenta las diferencias horarias, si las hubiera.

RECUPERACIN

Pueden haber dos tipos de falla, falla de instancia y falla del medio. Ante una falla de
instancia (corte de energa por ejemplo) la base recupera automticamente.

En el caso de falla del medio, o sea falla en el hardware, software, o fallas en el

sistema que no permiten leer o escribir en archivos requeridos de la base, es necesaria la
intervencin del DBA para la recuperacin.

Si la base esta operando en modo noarchivelog y ocurre una falla en el medio,

entonces la nica forma de recuperacin que existe es restaurar el ultimo backup offline, con
lo cual se perdern todos los cambios realizados entre este y el momento de la falla.

Si la base trabaja en modo archivelog y ocurre una falla, entonces recuperando el

ultimo backup de los archivos mas los redo logs generados desde el backup hasta el momento
de la falla, se puede recuperar la misma sin perder ningn cambio.

RECUPERACION COMPLETA

Consiste en recuperar toda la base o parte de la base, hasta el ltimo momento, no

perdiendo ninguna transaccin. Podemos recuperar toda la base de datos (datafiles) o en caso
que tengamos un archivo daado que no sea del tablespace system o rollback, podemos
recuperar ese archivo solo (esto en caso de estar trabajando en modo archivelog).

RECUPERACION INCOMPLETA

No siempre podemos o queremos recuperar la base hasta el ultimo punto en el tiempo,

por ejemplo podemos querer recuperar hasta un punto en el pasado, previo a una mala
actualizacin de un dato particular, o al borrado accidental de una tabla por parte de un
usuario.

Tambin puede ocurrir que ante la perdida del current online redo log, tengamos que
hacer una recuperacin incompleta, es decir recuperamos y no aplicamos el ltimo redo log,

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
donde existen transacciones, o que ante la perdida de algn redo log archivado, tengamos que
recuperar hasta un redo anterior (no es posible saltearse un redo en un proceso de
recuperacin).

En caso de recuperacin incompleta, el DBA tiene la potestad de especificar hasta que

punto recuperar, por ejemplo until time, donde especifica una hora y fecha, until cancel,
donde el dba rige hasta donde recuperar, until <scn>, donde especificamos un scn puntual al
cual recuperar.

RECUPERACION CON BASES DE DATOS DISTRIBUIDAS

La arquitectura de bases de datos distribuidas de Oracle es autnoma. Por lo tanto,

dependiendo del tipo de operacin de recuperacin seleccionada para una base daada, se
puede tener que coordinar la operacin de recuperacin globalmente entre todas las bases de
un sistema distribuido.

En la siguiente tabla se resumen diferentes tipos de recuperacin y si es necesaria o no

la coordinacin entre los distintos nodos de un ambiente distribuido:

Si se est......
Recuperando un backup completo (full
offline backup) de una base que nunca fue
accedida desde un nodo remoto
Recuperando un backup completo (full
offline backup) de una base que fue accedida
desde un nodo remoto
Realizando recuperacin completa de una o
mas bases en un sistema distribuido
Realizando recuperacin incompleta de una
base de datos que nunca fue accedida desde
un nodo remoto
Realizando recuperacin incompleta de un
nodo que fue accedido por un nodo remoto
Entonces.....
Usar recuperacin no coordinada
Bajar todas las bases y recuperarlas
utilizando el mismo backup completo
coordinado
Usar recuperacin no coordinada
Usar recuperacin no coordinada
Usar recuperacin incompleta coordinada
de bases de datos distribuidas, al mismo
punto global de tiempo para todos los nodos
del ambiente distribuido

Nota: Antes de realizar cualquier tipo de recuperacin es muy importante realizar un

backup completo de la base. Esta es una medida de seguridad que nos permitir intentar
otro tipo de recuperacin si algo va mal en el primer intento.

RECUPERACION COORDINADA DE BASES DE DATOS DISTRIBUIDAS

En situaciones especiales, un nodo de un sistema de bases de datos distribuidas, puede

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
requerir recuperacin a un punto en el pasado. Para preservar la consistencia global de los
datos, es frecuente tener que recuperar todos los otros nodos en el sistema al mismo punto en
el tiempo. A esta operacin se la llama recuperacin incompleta coordinada de bases de
datos distribuidas. Para esto se debe realizar lo siguente:

1. Recuperar la base que necesita recuperacin utilizando time-based recovery.

2. Despus de recuperada la base y abierta con la opcin de resetlogs, hay que mirar en el
alert donde aparece el mensaje de RESETLOGS. Si el mensaje es RESETLOGS after
complete recovery through change xxx, en este caso se han aplicado todos los cambios
a la base y por lo tanto se trato de una recuperacin completa, por lo tanto no es necesario
recuperar las otras bases del sistema distribuido. Si el mensaje es RESETLOGS after
incomplete recovery UNTIL CHANGE xxx, entonces se ha realizado recuperacin
incompleta, por lo que se debe tomar nota del scn (numero xxx) y proceder con el
siguiente paso.
3. Recuperar todas las otras bases en el sistema distribuido utilizando change-based
recovery, especificando el scn anotado en el paso anterior.

Esto de basar la recuperacin basndose en el SCN se debe a que en un sistema

distribuido, cualquier transaccin distribuida (aquella que involucra al menos dos bases)
cuando realiza un commit lo hace utilizando el protocolo de two-phase commit. En un
punto de este protocolo, se miran los scns de ambas bases, y una vez realizado el commit,
se igualan al mayor de ellos en ambas bases, por lo tanto el scn nos permite marcar puntos
de sincronizacin entre dos bases distribuidas.

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy
CONCLUSIONES

Oracle ofrece distintas formas de backup y recuperacin, dependiendo que la base

trabaje en modo archivelog o noarchivelog.

En caso de noarchivelog la nica estrategia valida es bajar la base y realizar un backup

offline, y en caso de recuperacin se pierden los cambios entre el backup y el momento de la
falla. La ventaja de este mtodo es que es fcil de usar. En caso de estar trabajando con bases
de datos distribuidas, los backups deben estar coordinados, as mismo como la recuperacin.

Si no podemos darnos el lujo de bajar la base para realizar backups, o no podemos

permitir perder informacin ante una falla, entonces tenemos que trabajar en modo
archivelog. Este modo de la base nos permite realizar backups online y recuperar la base hasta
el momento de la falla.

Otro punto importante a rescatar es el hecho tomar medidas de seguridad en el

momento de realizar los backups:

Construir un script de backup que obtenga la informacin de los archivos del

diccionario, de esta forma si se cambia la estructura de la base no hay que
modificar el script de backup.
Antes de cualquier intento de recuperacin tomar un backup completo offline de la
base, con el fin de poder intentar otros caminos en caso de falla en el primero.
Una vez abierta la base de datos con la opcin de resetlogs, es muy importante
tomar un backup completo de la base.
Antes de poner en produccin un mecanismo de backup y recovery es altamente
recomendado probarlo y comprobar su correcto funcionamiento.

Pza. Independencia 822 Piso 4

C.P. 11100 Montevideo Uruguay
TelFax (5982) 903 9313

www.tilsor.com.uy