Backups

Libar
20 de Octubre del 2005
Alguien me podria decir como hago backups de una base de datos oracle 9i.
Tambien como restaurar una base de datos a partir del backup.

agradezco la ayuda gracias.

eduardo
20 de Octubre del 2005
Puedo hacer un backup en frio en un Windows y restaurarlo en un Linux?

Rodolfo Reyes
20 de Octubre del 2005
Backup en Frío :
Este tipo de backup hace una copia de las estructuras físicas de las bases de datos
mientras la base de datos no este disponible a los usuarios. Esta copia de archivos
tiene que hacerse a través de utilitarios del sistema operativo como tar, cp, cpio,
backup , etc .
Para poder hacer backup en frío de una base de datos basta con seguir los
siguientes pasos:
1. Listar los datafiles, controlfiles y logfiles. Esto se hace ejecutando:
select file_name from dba_datafiles;
select name from v$controlfile;
select member from v$logfile;
2. Ejecutar un shutdown normal o inmediato de la base de datos.
3. Copiar con un utilitario del sistema operativo todos los archivos listados en el
paso 1 hacia un medio de backup preferido como cinta, disco duro, otra
máquina, etc.

Para realizar una recuperación se beben seguir los pasos:
1. Realizar un shutdown a la base de datos actual. (Asumiendo que se quiere
desechar y recuperar la del backup).
2. Copiar del medio del backup (cinta, disco, etc.) todos los datafiles,
controlfiles y logfiles al mismo lugar donde recidían antes de hacer backup.
3. Subir la base de datos.


Backup Lógico :
Este backup se refiere a hacer una copia lógica de las estructuras e información
que están dentro de la base de datos. Se llama copia lógica porque lo que se copia
es prácticamente la definición en un script de los objetos para luego poder crearlos
cuando algo falle.
Este tipo de backup se realiza con el utilitario import y export de la base de datos.
El export genera un archivo con extensión .DMP el cual contiene scripts y datos
pero también puede realizarse directamente a una cinta; esta última opción es
preferida por muchos ya que los archivos .DMP pueden ocupar mucho espacio en
disco.
Tipos de Backup Lógico:
El backup puede ser de la base de datos completa, un solo usuario o de una o
varias tablas. El backup completo de la base de datos tiene la ventaja que saca
backup de la definición de los tablespaces, usuarios, roles, permisos y de todos los
objetos de todos los usuarios. El backup de usuario permite sacar backup de todos
los objetos de un usuario determinado. El backup de tablas puede sacar backup de
una o más tablas de un usuario determinado.

Ejemplos export 1:
Se desea hacer un backup completo de base de datos a una unidad de cinta con
una capacidad máxima de 4 GB.
1. Introducir un cartucho de cinta.
2. Ejecutar la instrucción:
exp system/password_system full=y indexes=y rows=y consistent=y
file=/dev/rmt0 volsize=400000000 log=full_fecha_.log constraints=y
donde:
password_system debe ser el password del usuario system.
_fecha_ debe ser la fecha del día que se ejecuta el backup.
full=y indica que es backup completo de la base de datos.
volsize es la capacidad máxima de la cinta en bytes, esto es para que al terminarse
el espacio pida un cambio de cinta. (este parámetro no es necesario para exports a
disco).
Ejemplo export 2:
Se desea hacer backup del usuario contabilidad y todos sus objetos a un archivo
del disco.
exp system/password_system full=n owner=contabilidad indexes=y rows=y
consistent=y file=/backup/exports/conta.dmp log=conta.log constraints=y
Ejemplo export 3:
Se desea realizar backup de las tablas datos1 y datos2 del usuario contabilidad
hacia un archivo .dmp.
exp system/password_system full=n owner=contabilidad
tables=(datos1,datos2) indexes=y rows=y consistent=y
file=/backup/exports/conta_tables.dmp log=conta_tables.log constraints=y
Tipos de Recuperación Lógica:
Así como existen tres formas de hacer export, existen tres formas de hacer el
import: Base de datos completa, usuarios y tablas. Una excelente característica del
import es que se puede recuperar usando un tipo inferior de import si el archivo de
export esta hecho con un tipo superior. Por ejemplo si el export fue realizado tipo
base de datos completa, se puede hacer import de base de datos completa, por
usuario o por tablas; pero si el export se hizo por usuario, no se podría hacer un
import de base de datos completa.
Lo que siempre se debe tomar en cuenta es que al realizar una recuperación con el
import, se debe de preparar la base de datos es decir, si tenemos una falla en disco
y se pierde la base de datos completa, se debe de crear una base de datos inicial
(tablespace system, rbs, temp, users y tools) y los tablespaces de los datos antes
de ejecutar el import. Si la falla es de un solo tablespace, este se debe borrar y se
debe crear nuevamente.

Ejemplo import 1:
Se desea realizar un import completo de la base de datos.
imp system/password_system file=/backup/dmps/full_db.dmp full=y rows=y
indexes=y commit=y buffer=200000
donde:
commit=y es un parámetro que le indica al import que debe hacer commit por
grupos de registros y no esperar al final de cada tabla para hacerlo.
Ejemplo import 2:
Se tiene un archivo de export de la base de datos completa y se desea importar
una tabla llamada prueba_2.
imp system/password_system file=/backup/dmps/full_db.dmp full=y rows=y
indexes=y commit=y buffer=200000 fromuser=contabilidad touser=contabilidad
tables=prueba_2
donde:
fromuser es el parámetro que indica quien es el dueño de la tabla a importar.
touser es el nombre del usuario donde se importará la tabla
tables es el listado de tablas a importar.

Backup en Caliente :
Es una copia física de la base de datos mientras está disponible a los usuarios.
Para esto es necesario modificar la base de datos a modo ARCHIVELOG y hacer
backups por tablespace.
Modo de Archivelog
El modo de Archivelog simplemente es una configuración de Oracle que copia los
redo log files en línea a un directorio que fue creado para este propósito, esto
permite tener un histórico de todas las transacciones de la base de datos.
La metodología para realizar los backups cambia considerablemente ya que aquí la
unidad de backup es el tablespace, es decir, que se va a sacar backup por cada
tablespace que exista en la base de datos. Además se tienen que resguardar todos
los log files archivados que genera la base de datos y los control files.
La metodología de recuperación permite hacer dos tipos de recuperación:
Completa e Incompleta. La recuperación completa quiere decir que se recuperan
todas las transacciones hasta el momento exacto en que ocurrió una falla.
Recuperación incompleta significa que se recuperara hasta algún lugar en el
tiempo previo al momento de la recuperación. Esto quiere decir que si se hace
recuperación completa, no se pierde nada de información, pero si es una
recuperación incompleta se va a perder información.
La recuperación completa puede dividirse en tres métodos:
1. Recuperación de toda la base de datos: Significa traer del backup mas
reciente todos los datafiles de la base de datos y aplicar los log files
archivados que se generaron hasta el momento que ocurrió la falla.
2. Recuperación de un tablespace: Significa que si el problema involucra uno o
varios tablespaces, se pueden recuperar los datafiles de los tablespaces
dañados y luego se aplican los log files archivados que se generaron hasta
el momento que ocurrió la falla.
3. Recuperación de un datafile: Es parecido al de tablespace, pero se asume
que solo unos cuantos datafiles están dañados entonces estos son los que
se recuperan del backup mas reciente y luego se aplican los log files
archivados que se generaron hasta el momento que ocurrió la falla.
Para la recuperación Incompleta siempre debe retornarse del backup toda la base
de datos ya que no puede quedar un datafile más reciente que los demás. Esta
restricción existe porque Oracle siempre mantiene los datafiles al mismo número de
cambio. Esta recuperación puede dividirse en tres métodos:
1. Recuperación en un punto en el tiempo : Si existe una falla de un usuario o
simplemente queremos que la base de datos sea puesta hasta un día y hora
específica anterior al momento que esta trabajando la base de datos.

2. Recuperación hasta un número de secuencia : Es el mismo caso anterior,
pero no conocemos el día y hora sino que un número de secuencia de
cambio.
3. Recuperación hasta un Cancel: esto ocurre cuando se hace recuperación y
simplemente paramos la recuperación escribiendo el comando cancel.

Como pasar a modo Archivelog
El modo de archive log puede ser especificado desde el momento que se crea la
base de datos, o bien, se puede alterar si ya esta creada. En el segundo caso, se
aconseja realizar un backup en frío de la base de datos completa antes de pasarse
al modo de archive log.
Los parámetros que deben estar colocados en el respectivo init<SID>.ora para el
método de archivelog son:
LOG_ARCHIVE_DEST
Directorio destino donde se harán las copias de
los log files en línea.
LOG_ARCHIVE_FORMAT
Formato del nombre de los archivos. %t significa
el número de thread y el %s significa número de
secuencia de log.
LOG_ARCHIVE_START
Debe estar en TRUE para que el proceso de
archivación sea automático cada vez que se
reinicia la instancia.
Ejemplo de los parámetros de inicialización:
LOG_ARCHIVE_DES=/u01/oracle/archives/
LOG_ARCHIVE_FORMAT=log_%t_%s.arc
LOG_ARCHIVE_START=TRUE
Luego que los parámetros ya están bien colocados se procede a ejecutar las
siguientes instrucciones desde el server manager:
SVRMGRL> connect internal;
SVRMGRL> shutdown normal; ( si la base de datos esta arriba )
SVRMGRL> startup mount;
SVRMGRL> alter database archivelog;
SVRMGRL> alter database open;
SVRMGRL> log archive all;
SVRMGRL> shutdown;
Ahora la base de datos esta en modo de archivelog, se recomienda en este
momento realizar un backup completo en frío ya que este será nuestro punto inicial
para realizar una recuperación en caso de falla.
Ahora abriremos la base de datos para su operación normal con usuarios:

Como realizar los backup en línea
Ahora que la base de datos esta modo de Archivelog se pueden planificar los
backups de tablespaces inclusive cuando existan transacciones sobre ellos. Para
esto utilizaremos el comando "Alter tablespace", como en el siguiente ejemplo:
SQL> ALTER TABLESPACE DATOS1 BEGIN BACKUP;
En este momento Oracle realiza un checkpoint para todos los datafiles en línea que
pertenecen al tablespace y se escribe en su cabecera que se encuentra en proceso
de backup. El DBA es el encargado de realizar con comandos del sistema
operativo la copia física de todos los data files que pertenecen al tablespace. Esta
copia puede ser realizada a disco, cinta, otro servidor, etc.
Durante el tiempo en que el sistema operativo este realizando la copia de los
datafiles, Oracle hace copias de los bloques de datos que son modificados en los
redo log files (before image logging). Esta es la razón por la cual se genera mucha
información en los redo log files en un backup en caliente. Se recomienda que los
backups de los tablespaces se realicen en las horas de menor actividad en la base
de datos por las razones antes mencionadas.
Al terminar la copia de los datafiles respectivos el DBA debe indicarle a Oracle que
el backup termino y que ahora ya debe utilizarlo normalmente, esto se hace con la
instrucción "Alter tablespace" como se puede ver a continuación:
SQL> ALTER TABLESPACE DATOS2 END BACKUP;
En este momento Oracle quita el tablespace del modo de backup, se deshabilita la
copia de los bloques a los log files, se registra en el log file el fin del backup y por
último se realiza un checkpoint para grabar todos los bloques que no fueron
escritos al datafile durante el backup.
Se deben hacer backups de todos los tablespace incluyendo el SYSTEM,TEMP,
RBS, etc. Esto es porque al momento de ocurrir una falla se deben retornar todos
los tablespaces hasta llegar al mismo momento del tiempo.
Después de hacer el backup de cada tablespace se debe hacer un backup de los
control files con el comando:
ALTER DATABASE BACKUP CONTROLFILE TO '/u01/oracle/backup_control.ctl';
este backup también es recomendable después de hacer un cambio a la estructura
de la base de datos, por ejemplo al agregar datafiles, agregar o borrar tablespaces,
agregar o borrar online log files, agregar o borrar online log groups.

Media Recovery
Se le conoce como media recovery al hecho de recuperar la base de datos de un
backup y aplicar todas las transacciones recientes si ocurre una falla. La
recuperación puede ser completa e incompleta. Recuperación completa es la que
al terminar el proceso se aplicaron el 100% de las transacciones desde el backup
más reciente hasta la fecha y hora actual.
Recuperación incompleta es la que no se puede aplicar el 100% de las
transacciones y la base de datos debe quedar en un punto del tiempo anterior al
momento de la falla.
Ejecutando el Comando Recover
El comando "recover" del server manager esta diseñado para poder realizar
recuperaciones con la base de datos abierta o montada. Este comando puede
hacer recuperación de la base de datos completa, de un tablespace o de un
datafile.
Recover Database: Ente comando revisa todos los datafiles de la base de datos y
determina cuales necesitan recuperación.
Recover Tablespace: En este caso solo se revisan los datafiles del tablespace
especificado para determinar cuales necesitan recuperación.
Recover Datafile: Al utilizar este comando se debe especificar el nombre del
datafile a recuperar y si es necesaria la recuperación se inicia solamente en dicho
datafile.
Antes de ejecutar el comando "recovery" se debe de restaurar los datafiles que
sufrieron un daño ya sea corrupción o perdida total. Esta restauración se debe de
hacer con comandos del sistema operativo.
Sin importar la forma del comando "recovery", si Oracle detecta que es necesaria
una recuperación, es necesario tener a la mano todos los "redo log archived" (las
copias de los redo log files) ya que el server manager los necesita para aplicar
todas las transacciones que ocurrieron desde el backup hasta el momento de la
falla o el momento actual.
Ejemplo:
Vamos a simular que tenemos una base de datos en modo de archive log con los
tablespace SYSTEM, TEMP, RBS y DATOS1. Tenemos un backup en línea que
inicio el día 1/7/2001 a las 22:00 horas y finalizo el mismo día a las 23:45 horas de
los tablespaces SYSTEM y TEMP. Tenemos también un backup en línea que inicio
el día 2/7/2001 a las 22:00 horas y finalizo el mismo día a las 23:04 horas de los
tablespaces RBS y DATOS1.

Si existe una falla en el sistema y sufren daños los tablespaces TEMP y DATOS1 a
las 10:00 horas del día 3/7/2001 se deben ejecutar los siguientes pasos:
• Recuperar los datafiles del tablespace TEMP del backup del día 1/7/2001.
• Recuperar los datafiles del tablespace DATOS1 del backup del día 2/7/2001.
• Recuperar los archived redo log files cuya fecha sea mayor o igual a
1/7/2001 a las 22:00.
• Iniciar el proceso de recuperación:
SVRMGR> startup mount;
SVRMGR> recover database;
SVRMGR> alter database open;
Perdida de control files
Si el fallo incluye la perdida de todos los control files se debe recuperar el control
file de backup y copiarlo al path original, este path puede ser visto en el parámetro
CONTROL_FILES del init<SID>.ora o en el config<SID>.ora. En este caso el
comando "recover" del ejemplo anterior cambia al siguiente:
SVRMGR> recover database using backup controlfile;

Todo lo anterior fue sacado de un PDF.


Andrea
20 de Octubre del 2005
Hola porfa queria preguntarte si el articulo q respondiste de backups, son los respaldos q son gestionados por el usuario.. porq me mandaron una consulta y queria seciorarme de q lo que respondiste de resplados eran los q necesito. No quiero los respaldos asistidos, sino los gestionados por el usuario...De antemando te agradezco mucho

Jorge
20 de Octubre del 2005
Tengo unas dudas frente a esto:

Suponemos que comienzo ha hacer backup de mis tablespaces, y mientras se van ejecutando transacciones en mi BBDD:

alter tablespace datos1 begin backup;
cp datos1.dbf /backup/datos1.dbf
alter tablespace datos1 end backup;

alter tablespace datos2 begin backup;
cp datos2.dbf /backup/datos2.dbf
alter tablespace datos2 end backup;

alter tablespace indices1 begin backup;
cp indices1.dbf /backup/indices1.dbf
alter tablespace indices1 end backup;

alter tablespace indices2 begin backup;
cp indices2.dbf /backup/indices2.dbf
alter tablespace indices2 end backup;

así con todos mi data-files, control, tmp, rollback...

Mientras se hace todo esto entiendo que mis ficheros de datos son inconsientes puesto que se han realizado
transacciones en unos ficheros que otros no reflejan (debido al tiempo entre copia) entiendo que esto se
soluciona con los archived redo log que imagino tendré que copiar al final, ¿no?, por tanto hago

alter system switch logfile;

y ahora hacer una copia de todos, pero se me plantea el mismo problema, mientras copio se me
generan otros archived redo log nuevos, si me los llevo a mi copia de seguridad tendré cambios que no tiene
niguno de mis tablespaces

No se si me entendeis, no se cual es el punto en el que lo que me llevo es completamente consitente y tener
la seguridad de que si los borro no pierdo ninguna transacción que se haya realizado mientras estaba
haciendo las copias...

Se que puedo mostrar

archive log list;

y me saca el fichero anterior y el actual que está escribiendo, pero esto me dificulta para hacerlo
automático mediante un script.


Espero haberme explicado !!

Un saludo