Copias de seguridad y recuperación en Oracle

ADMINISTRACIÓN DE ORACLE 11G
Conceptos sobre copias de seguridad y recuperación
1Carmen Soler Chorro - http://www.linkedin.com/in/casoch

INTRODUCCIÓN
 Los puntos y conceptos que trataremos en
esta sesión serán:
 Identificar qué tipos de fallos pueden ocurrir en
una base de datos Oracle.
 Ver las formas de ajustar la recuperación de la
instancia.
 Ver la importancia de los checkpoints, redo log
files y archive log files.
 Configurar el Flash Recovery Area.
 Configuración del modo Archivelog.

INTRODUCCIÓN
 Una de las responsabilidades más
importantes de un DBA es asegurar que los
datos no se pierden:
 Veremos que a través de los mecanismos de
redo y undo es imposible que un dato se
corrompa, haga lo que haga el DBA.
 Todo esto asumiendo que no exista fallo físico
 Sin embargo, si no se toman las precauciones
adecuadas, se pueden llegar a perder datos.

TIPOS DE FALLO
 Los fallos se pueden categorizar en:
 Fallos de sentencia (statement failure)
 Fallos de proceso de usuario (user process
failure)
 Fallos de red (Network failure)
 Errores de usuario (User Errors)
 Fallos de hardware (Media Failure)
 Fallos de la instancia (Instance Failure)

STATEMENT FAILURE (FALLOS DE SENTENCIA)
 Fallos que no dependen del DBA:
 Que el usuario no haga un rollback cuando una sentencia
falla. Sino la sentencia queda intacta pero no validada.
 Que se intenten insertar datos de un tipo en otro tipo
 Que se viole la integridad referencial.
 Fallos que sí dependen del DBA:
 La gestión del espacio. Se debe prever antes de que ocurra.
 Para ello tenemos los: undo advisor, segment advisor y ADDM
 Además podemos utilizar el servicio de alertas para solventar el
problema antes de que ocurra.
 Fallo de permisos:
 Es posible que los permisos dados a los usuarios no sean los
adecuados.
 En este caso, el DBA se tendría que poner en contacto con la
organización.

TALLER 1
Corregir errores de statement.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 6

USER PROCESS FAILURE
Un proceso de usuario puede colgarse por
numerosos motivos: Salida anormal sin logout, reboot,…
 El proceso PMON es el que se encarga de
eliminar a este proceso: si se estaba en medio de una
transacción hace un Rollback, liberando así posibles bloqueos.
 Este tipo de problema escapa del control del
DBA. Este debe investigar quién o que lanza
estos procesos para que no ocurran.

NETWORK FAILURE
Este tipo de error tiene tres puntos considerar:
 Listener: Si hay mucho volumen de tráfico se pueden
configurar varios listener en diferentes puertos y
direcciones.
 Los interfaces de red: La red puede caer. Lo ideal es
tenerla redundada. Crear un listener en para cada
interfaz de red.
 Las rutas:Si con varios adaptadores de red, separar
las redes en subredes. Para ello se ha de tener en
cuenta en enrutamiento. En la parte del cliente se
indica en la sección ADDRESS_LIST del fichero de
configuración TNS_NAMES.ORA.

USER ERRORS
 Históricamente eran los peores errores, los más
difíciles de localizar dad su naturaleza (Ya que
realmente para Oracle no son errores).
 Ejemplo: Tenemos 1M de clientes y un alguien hace un
UPDATE sin WHERE y después hace COMMIT. Se da
cuenta del error y llama al DBA para solucionarlo.
 El DBA no puede hacer un ROLLBACK de esta instrucción,
así que tendrá que recurrir a técnicas como:
 Flashback query: Extrae los datos de undo
 Flashback drop: deshace drops de tablas.
 Log Miner: Herramienta que extrae información de los
online y archived redo logs. Puede volver hacia atrás
indefinidamente.

TALLER 2
Corregir error de usuario con flashback query y con
flashback drop.

MEDIA FAILURE
 El DBA no es responsable de los errores de
hardware, pero debe saber cómo recuperar
los datos:
 El control file y los online redo logs pueden estar
multiplexados en otros discos.
 Los datafiles no. Sólo podrían estarlo utilizando
RAID a nivel de HW.
 Para solucionar este punto es importante tener
al día el sistema de backups.

INSTANCE FAILURE
 Se considera que hay un fallo de instancia cuando
ésta se cierra mal: por ejemplo con un shutdown
abort.
 Después de este fallo, la instancia puede perder:
 Transacciones confirmadas con COMMIT que no se han
guardado a disco.
 Parte de transacciones sin COMMIT todavía.
 Cuando se hace un COMMIT, es posible que el
DBWR no copie los datos a disco justo en ese
momento, pero el LGWR sí guarda el cambio a disco.
 De esta forma, tenemos la posibilidad de saber si
hemos perdido datos y poder corregir el fallo.

MEJORAR LA RECUPERACIÓN DE LA INSTANCIA
 Las reglas ACID dicen que:
 No se debe perder ninguna transacción consolidada
 Ni se debe mostrar al resto de usuarios una no
consolidada.
 Cuando hay un crash:
 Se recuperan los datos que no dieron tiempo de guardar
en los datafiles
 Se deshace cualquier transacción no consolidada.
 Este proceso es automático y no se puede inhabilitar.
 Después de haber dejado la parte de disco como
debería estar, se trata de recuperar el estado de la
instancia a como estaba antes del fallo.

MECANISMOS PARA RECUPERAR LA INSTANCIA
 La recuperación de la instancia consiste en utilizar el
contenido de los online redolog files para reconstruir el
Database Buffer Cache al estado en que se encontraba
antes del crash.
 Con esto tenemos las operaciones que se habían validado,
pero no había dado tiempo de escribir a disco.
 Después de hacer esto, la base de datos puede abrirse,
pero aún está corrupta.
 Una vez que estos datos que se han vuelto a cargar a
memoria, sean escritos a los datafiles por el DBWR,
podremos considerar que la base de datos se ha
recuperado.
 Finalmente, hay que hacer un rollback de todas las
transacciones que quedaron a medias.

MECANISMOS PARA RECUPERAR LA INSTANCIA
 La recuperación de la instancia es
automática e inevitable.
 Ocurre cuando volvemos a hacer un
STARTUP y se encarga el proceso SMON.
 Antes de pasar a OPEN, SMON chequea los
datafiles y los online redolog files y se da
cuenta si hay que hacer una recuperación.
 Cuando acaba la recuperación, se pasa a
OPEN.

CORRUPCIÓN DE DATOS
 El hecho de que LGWR escriba antes de que el
DBWR y lo haga prácticamente en tiempo real a
los commits, hace que tengamos siempre
disponible en los redo logs la información
suficiente para reconstruir la información de
cualquier transacción validada.
 Por lo tanto, es imposible que un SHUTDOWN
ABORT pueda corromper los datos.

 Estamos seguros de que no se perderán datos, pero también es
importante saber cuánto tiempo tardará la base de datos en
recuperarse: MTTR
 Este tiempo depende de:
 Cuantos redo log deben leerse
 Cuantas operaciones de read/write tienen que hacerse para
recuperar.
 Estos dos factores pueden controlarse utilizando checkpoints.
 Un checkpoint garantiza que, en un periodo de tiempo, todos los
cambios hechos se han grabado en los datafiles.
 Este periodo de tiempo viene marcado por un SCN (System
Change Number).
 Así, SMON sólo ha de recuperar los cambios hechos en un SCN
determinado.

 Si hacemos que el SCN cambie a menudo, el
tiempo de recuperación mejorará, pero también
el DBWR tendrá que hacer más accesos a
disco, con lo que penalizaremos el rendimiento.
 Hay que llegar a un compromiso entre los dos.
 MTTR nos da una idea de lo que tardaría en
recuperarse la base de datos con lo que
tenemos configurado.
 También podemos sacar esta información de
v$INSTANCE_RECOVERY.

EL MTTR ADVISOR Y EL CHECKPOINT AUTO-
TUNNING
 Viene regulado por el parámetro
FAST_START_MTTR_TARGET.
 Por defecto es cero, y con este valor maximiza
el rendimiento pero penaliza el tiempo de
recuperación.
 Cuando es un valor diferente a cero, se activa
el mecanismo de checkpoint auto-tunning, que
inspecciona las estadísticas de utilización de la
máquina para establecer los checkpoints.

TALLER 3
Monitorizar el tiempo de recuperación de la
instancia.

CHECKPOINTING
 La posición de checkpoint es el punto de los redo log
a partir del que la instancia debe recuperarse. Esto
es lo que se conoce como incremental checkpointing.
 Full checkpoint, también escribe a disco las
transacciones sin validar. Esto reduce mucho el
rendimiento.
 Podemos hacer un full checkpoint de un momento dado
escribiendo:
 ALTER SYSTEM CHECKPOINT;
 También ocurren con un shutdown correcto.
 Partial checkpoint,tiene lugar cuando ocurren
determinadas operaciones. Según la operación toma
guarda unos datos u otros:

CHECKPOINTING

PROTEGIENDO LOS FICHEROS DE ONLINE REDO
LOG
 Oracle necesita al menos 2 online redo log files para
funcionar.
 Así uno es sobre el que se guardan los cambios
 Mientras otro se está volcando a archived redo log.
 Es muy importante no perder ninguno de los ficheros
de redo log, porque:
 Después de un crash, SMON los usa para reparar la
base de datos.
 Si el fichero no está disponible, SMON no lo podrá hacer.
 Si no lo puede hacer, no se abre la base de datos.
 Por eso es importante tener los ficheros de redo log
multiplexados.

LOG

LOG
 ALTER SYSTEM SWITCH LOGFILE;
 Es para forzar un cambio de fichero de log.
 Pasamos al grupo 3 de ficheros, pero el status del 2 queda a
activo porque todavía lo necesita SMON si tuviera que
recuperar la instancia.
 Si queremos que deje de necesitarlo, sólo tenemos que
escribir:
 ALTER SYSTEM CHECKPOINT;
 En el Controlfile se determina cuantos redo log pueden
haber como máximo con la directiva: MAXLOGFILES
 La directiva MAXLOGMEMBER limita el número de
miembros que puede tener cada grupo.
 Un redo log puede ser sobrescrito con más cambios sólo
si está INACTIVO.

MODO ARCHIVELOG
 Como los online redo log files se sobrescriben cuando
ocurre un log switch.
 Si quiero poder ver todos los cambios que ha habido
desde el último backup, los online redo log no son
suficientes.
 Si trabajamos en modo archivelog, se asegura que ningún
online redo log será sobrescrito al menos que se haya
copiado a un archive log file.
 El proceso encargado es ARCn.
 La localización de estos ficheros está parametrizada.
 Por defecto trabajamos en modo noarchivelog.
 Sólo podemos pasar a modo archive log está en mount,
después de haber hecho un clean shutdown y si somos
SYSDBA.

TALLER 4
Investigar la configuración de los Redo Log.

FLASH RECOVERY AREA
 Es una parte de disco que se dedica a almacenar los
ficheros relacionados con la recuperación de datos.
 Su localización se regula con los parámetros:
 Db_recovery_file_dest y db_recovery_file_dest_size
 Podemos encontrar ficheros como:
 Los backups del gestor de recuperación.
 Los ficheros de archive redo log.
 Los database flashback logs.
 RMAN (Recovery Manager) es una herramienta que
nos permite gestionar los ficheros que hay en esta
zona.

TALLER 5
Investigar la configuración de la Flash Recovery
Area.

CONFIGURAR ARCHIVELOG
 El proceso es:
Clean shutdown
Startup mount.
ALTER DATABASE ARCHIVELOG;
Abrir la base de datos
Podemos hacer un full backup.

TALLER 6
Activar el modo Archivelog.

Copias de seguridad y recuperación en Oracle

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Copias de seguridad y recuperación en Oracle

Ähnlich wie Copias de seguridad y recuperación en Oracle (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Copias de seguridad y recuperación en Oracle