Para conseguir un funcionamiento seguro de la BD y una pronta recuperación ante fallos se necesita planear una estrategia de copias de seguridad, backup, y de recuperación, recovery, ya que de nada sirve pensar que estamos a salvo de tales circunstancias, y que eso no me puede pasar a mí. Y el primer paso a dar es definir las características fundamentales de la implantación, porque mal vamos a conseguir unos objetivos si se desconocen o están indefinidos. El segundo paso es establecer unos planes de copias de seguridad y recuperación que nos permitan asegurar los objetivos.
1 Introducción al Backup y a la Recuperación
Planear y comprobar los procedimientos de backup del sistema es la única garantía que existe contra fallos del sistema, del SO, del software o cualquier otro tipo de circunstancias.
Las causas de error en una sistema de BD pueden agruparse en las siguientes categorías:
- Físicas
son causadas por fallos del hardware, como por ejemplo del disco o de la CPU.
- de Diseño
son agujeros en el software, ya sea en el SO o en el SGBD.
- de Funcionamiento
son causadas por la intervención humana, debidos a fallos del DBA, configuraciones inapropiadas o mal planteamiento de los procedimientos de backup.
- del entorno
como por ejemplo desastres naturales, fallos de corriente, temperatura excesiva.
De entre todas estas posibilidades, el DBA sólo puede influir y prever los errores de funcionamiento, ya que el resto habitualmente no está dentro de sus responsabilidades y capacidades.
Dada la complejidad de los sistemas actuales y las necesidades cada vez más críticas en la disponibilidad de los sistemas, donde una BD caida puede causar pérdidas millonarias, puede ser interesante considerar los mecanismos de protección hardware y de redundancia que la tecnología nos proporciona:
- UPS o fuentes de corriente ininterrumpida,
- espejado de disco, o tecnología RAID,
- Componentes duplicados,
- Sistemas redundantes.
Una de las más importantes decisiones que un DBA debe tomar es decidir si arrancar la BD en modo ARCHIVELOG o no. Esta decisión tiene sus ventajas e inconvenientes:
- Ventajas:
- Aunque se pierdan los ficheros de datos, siempre se puede recuperar la BD con una copia antigua de los ficheros de datos y los ficheros de redo log archivados.
- Es posible realizar backups en caliente.
- Inconvenientes:
- Se necesitará más espacio en disco.
- El trabajo del DBA se incrementa al tener que determinar el destino del archivado de los redo log.
1.1 Presentación del Backup
Los backups se pueden clasificar en físicos y lógicos. Los físicos se realizan cuando se copian los ficheros que soportan la BD. Entre estos se encuentran los backups del SO, los backups en frío y los backups en caliente.
Los backups lógicos sólo extraen los datos de las tablas utilizando comandos SQL y se realizan con la utilidad export/import.
Backups del SO
Este tipo de backup es el más sencillo de ejecutar, aunque consume mucho tiempo y hace inaccesible al sistema mientras se lleva a cabo. Aprovecha el backup del SO para almacenar también todos los ficheros de la BD. Los pasos de este tipo de backup son los siguientes:
- Parar la BD y el SO
- Arrancar en modo superusuario.
- Realizar copia de todos los ficheros del sistema de ficheros
- Arrancar el sistema en modo normal y luego la BD.
Backups de la BD en Frio
Los backups en frio implican parar la BD en modo normal y copiar todos los ficheros sobre los que se asienta. Antes de parar la BD hay que parar también todos las aplicaciones que estén trabajando con la BD. Una vez realizada la copia de los ficheros, la BD se puede volver a arrancar.
Backups de la BD en Caliente
El backup en caliente se realiza mientras la BD está abierta y funcionando en modo ARCHIVELOG. Habrá que tener cuidado de realizarlo cuando la carga de la BD sea pequeña. Este tipo de backup consiste en copiar todos los ficheros correspondientes a un tablespace determinado, los ficheros redo log archivados y los ficheros de control. Esto para cada tablespace de la BD.
Backups Lógicos con Export/Import
Estas utilidades permiten al DBA hacer copias de determinados objetos de la BD, así como restaurarlos o moverlos de una BD a otra. Estas herramientas utilizan comandos del SQL para obtener el contenido de los objetos y escribirlos en/leerlos de ficheros
Una vez que se ha planeado una estrategia de backup y se ha probado, conviene automatizarla para facilitar así su cumplimiento.
1.2 Presentación de la Recuperación
Oracle proporciona diferentes modos de recuperar un fallo en la BD, y es importante que el DBA conozca como funciona cada uno de ellos para determinar cuándo ha de ser utilizado.
Una de las mayores responsabilidades del DBA consiste en tener la BD a punto, y prepararla ante la posibilidad de que se produzca un fallo. Así, ante un fallo el DBA podrá recuperar la BD en el menor tiempo posible. Los procesos de recuperación dependen del tipo de error y de las estructuras afectadas.
Así, los tipos de error que se pueden producir son:
Errores de Usuario
Como por ejemplo un usuario borrando una fila o eliminando una tabla. Estos errores se solucionan importando una tabla de una copia lógica anterior. Si no se dispone de la copia lógica, se puede recuperar la BD en una instancia auxiliar, exportar la tabla en cuestión de la instancia auxiliar e importarla en la instancia operativa.
Fallos de Sentencias
Se definen como la imposibilidad del SGBD Oracle de ejecutar alguna sentencia SQL. Un ejemplo de esto se produce cuando se intenta una selección de una tabla que no existe. Estos fallos se recuperan automáticamente mediante un rollback de la transacción que contenía la sentencia fallida. El usuario necesitará volver a ejecutar otra vez la transacción cuando se haya solucionado la causa del problema.
Fallos de Procesos
Es una terminación anormal de un proceso. Si el proceso era un proceso de usuario, del servidor o de una aplicación el PMON efectuará la recuperación del proceso. Si el proceso era alguno de los de background, la instancia debe de ser parada y arrancada de nuevo, proceso durante el cual se recupera la caida efectuando un roll forward y un rollback de las transacciones no confirmadas.
Fallos de la Red
Algunas veces los fallos en la red producen fallos de proceso, que son tratados por el PMON. Si en el error de red se ve envuelta una transacción distribuida, una vez que se reestablece la conexión, el proceso RECO resuelve los conflictos automáticamente.
Fallos de Instancia
Pueden deberse a fallos físicos o de diseño del software que hacen que algún proceso background caiga y la instancia con él. La recuperación es automática cuando se levanta la BD, tomandose más o menos tiempo en la recuperación.
Fallos del Sistema
Son los fallos más peligrosos, no sólo porque se pueden perder datos, sino porque se tarda más tiempo en recuperar que los otros fallos. Además se depende mucho de la experiencia del DBA para levantar la BD rápidamente y sin pédida (o casi) de datos.
Existen tres tipos de recuperación en Oracle: a nivel de bloque, de thread y física.
Recuperación de bloques
Es el mecanismo de recuperación más simple, y se realiza automáticamente. Se produce cuando un proceso muere justo cuando está cambiando un bloque, y se utilizan los registros redo log en línea para reconstruir el bloque y escribirlo en disco.
Recuperación de threads
Se realiza automáticamente cuando Oracle descubre que una instancia muere dejando abierto un thread, entonces se restauran los bloques de datos modificados que estaban en el cache de la instancia muerta, y cerrando elthread que estaba abierto. La recuperación se efectua automáticamento cuando la BD se levanta.
Recuperación física
Se realiza como respuesta a un comando RECOVER. Se utiliza para convertir los ficheros de backup en actuales, o para restaurar los cambios que fueron perdidos cuando un fichero de datos fue puesto offline sin un checkpoint, aplicando los fichero redo log archivados y en línea.
crdg
http://www.infor.uva.es/
