1. ADMINISTRACIÓN DE ORACLE 11G
Conceptos sobre copias de seguridad y recuperación
1Carmen Soler Chorro - http://www.linkedin.com/in/casoch
2. 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.
2Carmen Soler Chorro - http://www.linkedin.com/in/casoch
3. 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.
3Carmen Soler Chorro - http://www.linkedin.com/in/casoch
4. 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)
4Carmen Soler Chorro - http://www.linkedin.com/in/casoch
5. 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.
5Carmen Soler Chorro - http://www.linkedin.com/in/casoch
7. 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.
7Carmen Soler Chorro - http://www.linkedin.com/in/casoch
8. 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.
8Carmen Soler Chorro - http://www.linkedin.com/in/casoch
9. 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.
9Carmen Soler Chorro - http://www.linkedin.com/in/casoch
10. TALLER 2
Corregir error de usuario con flashback query y con
flashback drop.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 10
11. 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.
11Carmen Soler Chorro - http://www.linkedin.com/in/casoch
12. 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.
12Carmen Soler Chorro - http://www.linkedin.com/in/casoch
13. 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.
13Carmen Soler Chorro - http://www.linkedin.com/in/casoch
14. 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.
14Carmen Soler Chorro - http://www.linkedin.com/in/casoch
15. 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.
15Carmen Soler Chorro - http://www.linkedin.com/in/casoch
16. 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.
16Carmen Soler Chorro - http://www.linkedin.com/in/casoch
17. MEJORAR LA RECUPERACIÓN DE LA INSTANCIA
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.
17Carmen Soler Chorro - http://www.linkedin.com/in/casoch
18. MEJORAR LA RECUPERACIÓN DE LA INSTANCIA
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.
18Carmen Soler Chorro - http://www.linkedin.com/in/casoch
19. 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.
19Carmen Soler Chorro - http://www.linkedin.com/in/casoch
20. TALLER 3
Monitorizar el tiempo de recuperación de la
instancia.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 20
21. 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:
21Carmen Soler Chorro - http://www.linkedin.com/in/casoch
23. 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.
23Carmen Soler Chorro - http://www.linkedin.com/in/casoch
24. PROTEGIENDO LOS FICHEROS DE ONLINE REDO
LOG
24Carmen Soler Chorro - http://www.linkedin.com/in/casoch
25. PROTEGIENDO LOS FICHEROS DE ONLINE REDO
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.
25Carmen Soler Chorro - http://www.linkedin.com/in/casoch
26. 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.
26Carmen Soler Chorro - http://www.linkedin.com/in/casoch
27. TALLER 4
Investigar la configuración de los Redo Log.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 27
28. 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.
28Carmen Soler Chorro - http://www.linkedin.com/in/casoch
29. TALLER 5
Investigar la configuración de la Flash Recovery
Area.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 29
30. CONFIGURAR ARCHIVELOG
El proceso es:
Clean shutdown
Startup mount.
ALTER DATABASE ARCHIVELOG;
Abrir la base de datos
Podemos hacer un full backup.
30Carmen Soler Chorro - http://www.linkedin.com/in/casoch
31. TALLER 6
Activar el modo Archivelog.
Carmen Soler Chorro - http://www.linkedin.com/in/casoch 31