Copias de seguridad y recuperación en Oracle

3,733 views

Published on

Oracle 11g r2 - Copias de seguridad y recuperación

Published in: Education
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,733
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Copias de seguridad y recuperación en Oracle

  1. 1. ADMINISTRACIÓN DE ORACLE 11G Conceptos sobre copias de seguridad y recuperación 1Carmen Soler Chorro - http://www.linkedin.com/in/casoch
  2. 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. 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. 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. 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
  6. 6. TALLER 1 Corregir errores de statement. Carmen Soler Chorro - http://www.linkedin.com/in/casoch 6
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. TALLER 3 Monitorizar el tiempo de recuperación de la instancia. Carmen Soler Chorro - http://www.linkedin.com/in/casoch 20
  21. 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
  22. 22. CHECKPOINTING 22Carmen Soler Chorro - http://www.linkedin.com/in/casoch
  23. 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. 24. PROTEGIENDO LOS FICHEROS DE ONLINE REDO LOG 24Carmen Soler Chorro - http://www.linkedin.com/in/casoch
  25. 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. 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. 27. TALLER 4 Investigar la configuración de los Redo Log. Carmen Soler Chorro - http://www.linkedin.com/in/casoch 27
  28. 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. 29. TALLER 5 Investigar la configuración de la Flash Recovery Area. Carmen Soler Chorro - http://www.linkedin.com/in/casoch 29
  30. 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. 31. TALLER 6 Activar el modo Archivelog. Carmen Soler Chorro - http://www.linkedin.com/in/casoch 31

×