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