Modos de operación de un sgbd

 

IV.- CONTROL DE TRANSACCIONES.

 

 

Los sistemas que tratan el problema de control de concurrencia permiten que sus usuarios asuman que cada una de sus aplicaciones se ejecuten atómicamente, como si no existieran otras aplicaciones ejecutándose concurrentemente. Esta abstracción de una ejecución atómica y confiable de una aplicación se conoce como una transacción.

Un algoritmo de control de concurrencia asegura que las transacciones se ejecuten atómicamente controlando la intercalación de transacciones concurrentes, para dar la ilusión de que las transacciones se ejecutan serialmente, una después de la otra, sin ninguna intercalación. Las ejecuciones intercaladas cuyos efectos son los mismos que las ejecuciones seriales son denominadas serializables y son correctos ya que soportan la ilusión de la atomicidad de las transacciones.

El concepto principal es el de transacción. Informalmente, una transacción es la ejecución de ciertas instrucciones que accesan a una base de datos compartida. El objetivo del control de concurrencia y recuperación es asegurar que dichas transacciones se ejecuten atómicamente, es decir: Cada transacción accede a información compartida sin interferir con otras transacciones, y si una transacción termina normalmente, todos sus efectos son permanentes, en caso contrario no tiene afecto alguno.

Una base de datos está en un estado consistente si obedece todas las restricciones de integridad (significa que cuando un registro en una tabla haga referencia a un registro en otra tabla, el registro correspondientes debe existir) definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones y supresiones de información.

Por supuesto, se quiere asegurar que la base de datos nunca entre en un estado de inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción.

 

4.4.- Instrucciones COMMIT y  ROLLBACK.

SQL acoge las transacciones de base de datos mediante dos instrucciones de procesamiento de transacciones de SQL:

 

§ COMMIT: La instrucción COMMIT señala la conclusión con éxito de una transacción. Indica al SGBD que la transacción se ha completado; se han ejecutado todas las instrucciones que conforman la transacción, y la base de datos es autoconsistente.

 

§ ROLLBACK: La instrucción ROLLBACK señala el fracaso de una transacción. Indica al SGBD que el usuario no desea completar la transacción; en lugar de ello, el SGBD debe volverse atrás de las modificaciones realizadas en las BD durante la transacción. En efecto, el SGBD devuelve la base de datos a su estado previo al comienzo de la transacción.

 

 

 

Tres operaciones fundamentales:

 

§ Begin: define el inicio de una unidad de trabajo indivisible (puede ser implícito al ejecutar una operación de categoría transaction-initiating).

§ Commit: marca el término normal de la transacción, todos los cambios deben quedar reflejados en forma definitiva en la BD y se liberan todos los locks (si los hubieran).

§ Rollback: marca una situación anormal que hace necesario deshacer el camino recorrido.

                         

                         

Ø  ya sea desde el inicio o

Ø  desde un punto definido anteriormente (Savepoint)

Ø  dependiendo de esto se liberará todos los locks o solamente aquellos tomados desde el savepoint en cuestión

 

 

 

 

 

4.1.- Propiedades de la Transacción.

¿Qué es una transacción?

“Secuencia de operaciones que se ejecutan completamente o bien no se realizan”.

§ No puede quedarse en un estado intermedio.

§ Ejemplo: una transferencia entre dos cuentas no puede quedarse en un estado intermedio: O se deja el dinero en la primera cuenta o en la segunda, pero no se puede sacar el dinero de la primera cuenta, que falle algo en ese momento y no entregarlo en la segunda.

 

Es una secuencia de una o varias instrucciones de SQL que forman conjuntamente una unidad lógica de trabajo. Cuando una transacción finaliza con éxito, se graba (COMMIT). Si fracasa, se restaura el estado anterior (ROLLBACK)

 

 

Propiedades de una transacción:

§ Atomicidad: Se realizan o todas las instrucciones o ninguna.

§ Corrección (Preservación consistencia): La transacción siempre deja la BD en un estado consistente (Si no lo hace puede ser por errores lógicos o físicos)

Y además:

§ Aislamiento: Los efectos de una transacción no se ven en el exterior hasta que esta finaliza.

§ Persistencia: Una vez finalizada la transacción los efectos perduran en la BD.

§ Seriabilidad: La ejecución concurrente de varias transacciones debe generar el mismo resultado que la ejecución en serie de las mismas.

 

Los pasos para usar transacciones en MySQL son:

1. Iniciar una transacción con el uso de la sentencia BEGIN.
2. Actualizar, insertar o eliminar registros en la base de datos.
3. Si se quieren los cambios a la base de datos, completar la transacción con el uso de la sentencia COMMIT. Únicamente cuando se procesa un COMMIT los cambios hechos por las consultas serán permanentes.
4. Si sucede algún problema, podemos hacer uso de la sentencia ROLLBACK para cancelar los cambios que han sido realizados por las consultas que han sido ejecutadas hasta el momento.

Se ejecutarán algunas consultas para ver como trabajan las transacciones. Lo primero que tenemos que hacer es crear una tabla del tipo InnoDB e insertar algunos datos. Para crear una tabla InnoDB, procedemos con el código SQL estándar CREATE TABLE, pero debemos especificar que se trata de una tabla del tipo InnoDB (TYPE= InnoDB). Esto es aplicable a cualquier tipo de tabla, pero cuando no se especifica nada, MySQL supone que se trata de una tabla MyISAM.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

mysql> CREATE TABLE innotest (campo INT NOT NULL PRIMARY KEY) TYPE = InnoDB;

Query OK, 0 rows affected (0.10 sec)

mysql> INSERT INTO innotest VALUES(1);

Query OK, 1 row affected (0.08 sec)

mysql> INSERT INTO innotest VALUES(2);

Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(3);

Query OK, 1 row affected (0.04 sec)

mysql> SELECT * FROM innotest;

 

+-------+

| campo |

+-------+

|     1 |

|     2 |

|     3 |

+-------+

3 rows in set (0.00 sec)

 

De acuerdo, nada espectacular. Ahora se verá como usar transacciones.

 

mysql> BEGIN;

Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(4);

Query OK, 1 row affected (0.00 sec)

 

mysql> SELECT * FROM innotest;

 

+-------+

| campo |

+-------+

|     1 |

|     2 |

|     3 |

|     4 |

+-------+

4 rows in set (0.00 sec)

 

Si en este momento ejecutamos un ROLLBACK, la transacción no será completada, y los cambios realizados sobre la tabla no tendrán efecto.

 

mysql> ROLLBACK;

Query OK, 0 rows affected (0.06 sec)

mysql> SELECT * FROM innotest;

 

+-------+

| campo |

+-------+

|     1 |

|     2 |

|     3 |

+-------+

3 rows in set (0.00 sec)

 

 

Si queremos que la transacción se lleve a cabo pondremos COMMIT

4.2.- Grados de Consistencia.

Un problema que existió desde tiempo inmemorial fue el hecho de mantener la consistencia global del estado, entre todos los subsistemas, en la medida en que las aplicaciones eran utilizadas. Esto es, que no ocurra que una modifique datos sin respaldar las consecuentes equivalencias en los demás subsistemas.

 

Ejemplo, si el subsistema de recaudación informa que el cliente adeuda tres pagos, por lo que es necesario bloquearle el servicio, el subsistema de operaciones debe efectivamente bloquearle los servicios en tanto que el subsistema de legales debe generar una entrada para comenzar el proceso judicial con este cliente. Asimismo, el subsistema de CRM (Customer Relationship Management, o Administración de la Relación con Clientes) debe reflejar que el cliente está en este estado judicial y sus cuentas bloqueadas. Todo esto no puede ocurrir parcialmente, o bien ocurre completamente, o no debería ocurrir en absoluto. Pero si ocurre a medias, podría pasar que mientras el cliente tenga bloqueados los servicios, sin que exista una causa judicial en su contra.

 

Consistent (Consistente): en el durante de una transacción se permite cierto grado de consistencia en la medida en que se va ejecutando, pero una vez que se completa, el estado final debe ser consistente. O bien, si se anula (y por la propiedad anterior se debe anular todo), se retorna al estado inicial que también debe ser consistente

 

 

 

4.3.- Niveles de Aislamiento.

El Nivel de Aislación (Isolation Level) tiene que ver con serializabilidad. A veces serializabilidad estricta puede ser demasiado exigente, Violaciones de Serializabilidad permitidos:

 

§ Lectura Sucia: Transacción T1 realiza una actualización de una tupla. T2 lee la tupla actualizada pero poco despues T1 termina con un Rollback (Abort). T2 ha visto información que no existe.

§ Lectura no repetible: Transacción T1 lee una tupla. T2 actualiza la misma tupla.T1 vuelve a leer la tupla ahora con diferente valor.

§  Fantasmas: T1 lee todas las tuplas que satisfacen una condición. T2 inserta una tupla que también satisface. T1 repite la lectura y aparece una tupla nueva(fantasma).

Nivel de Aislación	Sucia	No Repetible	Fantasma
READ UNCOMMITTED	SI	SI	SI
READ COMMITTED	NO	SI	SI
REPEATABLE READABLE	NO	NO	SI
SERIALIZABLE	NO	NO	NO

 

 

Ejemplo:

 

mysql> CREATE TABLE t (name CHAR(20), UNIQUE (name)) TYPE = INNODB;

 

mysql> BEGIN;

 

mysql> INSERT INTO t SET name = 'William';

 

mysql> INSERT INTO t SET name = 'Wallace';

 

mysql> COMMIT; mysql> SELECT * FROM t;

 

 

+---------+

| name    |

+---------+

| Wallace |

| William |

+---------+

 

 

mysql> BEGIN;

 

mysql> INSERT INTO t SET name = 'Gromit';

 

mysql> INSERT INTO t SET name = 'Wallace';

 

ERROR 1062: Duplicate entry 'Wallace' for key 1

 

mysql> ROLLBACK;

 

mysql> SELECT * FROM t;

 

 

+---------+

| name    |

+---------+

| Wallace |

| William |

+---------+

 

 

//que es auto commit y porke lo iguala a 0

 

mysql> DROP TABLE t;

 

mysql> CREATE TABLE t (name CHAR(20), UNIQUE (name)) TYPE = INNODB;

 

mysql> SET AUTOCOMMIT = 0;

 

mysql> INSERT INTO t SET name = 'William';

 

mysql> INSERT INTO t SET name = 'Wallace';

 

mysql> COMMIT;

mysql> SELECT * FROM t;

 

 

 

+---------+

| name    |

+---------+

| Wallace |

| William |

+---------+

 

Otro ejemplo utilizando el savepoint:

 

 

BEGIN

 

INSERT INTO student(student_id, Last_name, zip, registration_date, created_by, created_date, modified_by, modified_date)VALUES (student_id_seq.nextval, 'Sonam', 10015,'01-JAN-99', 'STUDENTA','01-JAN-99','STUDENTA','01-JAN-99');

 

 

SAVEPOINT A;

 

INSERT INTO student(student_id, Last_name, zip, registration_date, created_by, created_date, modified_by, modified_date) VALUES (student_id_seq.nextval, ‟Tashi', 10015, '01-JAN-99', 'STUDENTB', '01-JAN-99','STUDENTB', '01-JAN-99');

 

SAVEPOINT B;

 

INSERT INTO student(student_id, Last_name, zip, registration_date, created_by, created_date, modified_by, modified_date)VALUES (student_id_seq.nextval, 'Norbu', 10015,'01-JAN-99', 'STUDENTB', '01-JAN-99','STUDENTB', '01-JAN-99');

 

SAVEPOINT C;

ROLLBACK TO B;

SELECT * FROM student WHERE last_name = 'Norbu';

 

ROLLBACK TO A;

 

SELECT last_name FROM student WHERE last_na me = 'Tashi';

 

COMMIT;

END;

 

 

 

 

Panorámica de InnoDB

 

InnoDB dota a MySQL de un motor de almacenamiento transaccional (conforme a ACID) con capacidades de commit (confirmación), rollback (cancelación) y recuperación de fallas. InnoDB realiza bloqueos a nivel de fila y también proporciona funciones de lectura consistente sin bloqueo al estilo Oracle en sentencias SELECT.

 

Estas características incrementan el rendimiento y la capacidad de gestionar múltiples usuarios simultáneos. No se necesita un bloqueo escalado en InnoDB porque los bloqueos a nivel de fila ocupan muy poco espacio. InnoDB también soporta restricciones FOREIGN KEY. En consultas SQL, aún dentro de la misma consulta, pueden incluirse libremente tablas del tipo InnoDB con tablas de otros tipos.

 

InnoDB se diseñó para obtener el máximo rendimiento al procesar grandes volúmenes de datos. Probablemente ningún otro motor de bases de datos relacionales en disco iguale su eficiencia en el uso de CPU. A pesar de estar totalmente integrado con el servidor MySQL, el motor de almacenamiento InnoDB mantiene su propio pool de almacenamiento intermedio para tener un cache de datos e índices en la memoria principal.

 

 

InnoDB almacena sus tablas e índices en un espacio de tablas, el cual puede consistir de varios ficheros (o particiones disco). Esto difiere de, por ejemplo, el motor MyISAM, donde cada tabla se almacena empleando ficheros separados. Las tablas InnoDB pueden ser de cualquier tamaño, aún en sistemas operativos donde el tamaño de los ficheros se limita a 2GB.

 

 

En MySQL 5.0, InnoDB viene incluido por defecto en las distribuciones binarias. El instalador Windows Essentials configura a InnoDB como el tipo de base de datos MySQL por defecto en Windows. InnoDB se utiliza en muchos grandes sitios de bases de datos que necesitan alto rendimiento. El famoso sitio de noticias de Internet Slashdot.org corre sobre InnoDB. Mytrix, Inc. almacena más de 1TB de datos en InnoDB, y otros sitios manejan una carga promedio de 800 inserciones y actualizaciones por segundo en InnoDB.

 

 

InnoDB se publica bajo la misma licencia GNU GPL Versión 2 (de Junio de 1991) que MySQL. Para más información sobre el licenciamiento de MySQL, consultar la siguiente dirección http://www.mysql.com/company/legal/licensing/.

 

 

 

Ejemplo:

mysql> create database x;

Query OK, 1 row affected (0.20 sec)

 

mysql> use x;

Database changed

 

mysql> create table transac (clave int primary key, nombre varchar (20)) type= innodb;

Query OK, 0 rows affected, 1 warning (0.38 sec)

 

mysql> select * from transac;

Empty set (0.00 sec)

 

mysql> insert into transac values(4, "compas"), (2,"lapiz");

Query OK, 2 rows affected (0.08 sec)

Records: 2 Duplicates: 0 Warnings: 0

 

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

 

mysql> select * from transac;

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     2 |  lapiz |

|     4 | compas |

+-------+--------+

2 rows in set (0.00 sec)

 

 

mysql> delete from transac where clave=2;

Query OK, 1 row affected (0.02 sec)

 

 

mysql> select * from transac;

 

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     4 | compas |

+-------+--------+

1 row in set (0.00 sec)

 

 

 

mysql> rollback;

Query OK, 0 rows affected (0.06 sec)

 

 

mysql> select * from transac;

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     2 |  lapiz |

|     4 | compas |

+-------+--------+

2 rows in set (0.00 sec)

 

 

mysql> commit;

Query OK, 0 rows affected (0.00 sec)

 

 

mysql> select * from transac;

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     2 | lapiz  |

|     4 | compas |

+-------+--------+

2 rows in set (0.00 sec)

 

 

mysql> delete from transac where clave=2;

Query OK, 1 row affected (0.03 sec)

 

 

mysql> select * from transac;

 

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     4 | compas |

+-------+--------+

1 row in set (0.00 sec)

 

 

mysql> rollback;

Query OK, 0 rows affected (0.00 sec)

 

mysql> select * from transac;

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     4 | compas |

+-------+--------+

1 row in set (0.00 sec)

 

 

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

 

 

mysql> insert into transac values(6, "ooooo"), (2,"lapiz");

Query OK, 2 rows affected (0.00 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql> savepoint a;

Query OK, 0 rows affected (0.00 sec)

 

 

mysql> delete from transac where clave=4;

Query OK, 1 row affected (0.02 sec)

 

mysql> savepoint b;

Query OK, 0 rows affected (0.00 sec)

 

 

mysql> update transac set nombre='rrrrr'where clave=2;

Query OK, 1 row affected (0.00 sec)

Rows matched: 1 Changed: 1 Warnings: 0

 

 

mysql> select * from transac;

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     2 | rrrrr  |

|     6 | ooooo  |

+-------+--------+

2 rows in set (0.00 sec)

 

 

mysql> rollback to a;

Query OK, 0 rows affected (0.00 sec)

 

mysql> select * from transac;

 

+-------+--------+

| clave | nombre |

+-------+--------+

|     2 | lapiz  |

|     4 | compas |

|     6 | ooooo  |

+-------+--------+

3 rows in set (0.00 sec)

 

 

 

 

 

 

 

 

Oracle:

 

RollBack:

ROLLBACK te permitirá mantener la consistencia de la información dentro de tu Base de Datos.

La sentencia ROLLBACK te permite deshacer todas las modificaciones que se han realizado a la Base de Datos pero que no han sido escritas en el Disco Duro por la sentencia COMMIT, es decir, elimina de la memoria todos los cambios realizados en la Base de Datos hasta el ultimo COMMIT que fue realizado.

La sentencia ROLLBACK generalmente se usa cuando ocurren errores en los procesos para dejar los datos consistentes como estaban al principio del proceso, veamos un ejemplo de cómo se utiliza:

/* Procedures en Oracle */

Procedure Prc_Cambiar_Departamento(pin_id_departamento in number) Is

Begin

For r_Dat In (Select emp.id_empleado, emp.rut, emp.nombre, emp.estado_civil From T_Empleado emp Where emp.id_depatamento = pin_id_departamento and emp.estado_civil = 1 — 1= Soltero

) Loop

Update T_Empleado Set id_departamento = 25 Where id_empleado =  r_Dat.id_empleado;

End Loop;

Commit;

Exception

When Others Then

Rollback;

lst_error:= ‘Ha ocurrido un error en el proceso’;

End Prc_Cambiar_Departamento;

En este ejemplo se puede apreciar que si ocurre algún error que no permita procesar todos los empleados no se permite hacer el COMMIT y en la excepción del proceso se realiza unROLLBACK para deshacer todos los cambios que se habían realizado.

 

Commit:

Saber usar correctamente el COMMIT en los Packages en Oracle te  permitirá desarrollar procesos que guarden la información mucho más rápido y que los datos se manipulen de forma más eficiente cuando el proceso sea ejecutado por el usuario.

El comando COMMIT permite guardar en el disco duro del servidor todos los datos que han sido modificados y que se encuentran en la memoria desde el último COMMITrealizado. El trabajo de vaciar los datos desde la memoria y escribirlos en el disco duro es una tarea lenta y costosa, por eso el COMMIT se debe utilizar con precaución, es decir, grabar los datos después de cierta cantidad de datos procesados y no por cada dato que sea modificado. Revisemos un ejemplo para entender mejor estos conceptos.

Ejemplo #1: Supongamos que tenemos un proceso que debe insertar registros en una tabla, veamos primero el commit usado de forma errónea.

Procedure Prc_Guardar(pst_error out varchar2) Is

Begin

For r_dat in (select emp.rut,emp.dv,emp.nombre,emp.edad,emp.direccion from

t_empleado emp where ind_estado = 0 ) — 0=pendiente

loop

update t_empleado set ind_estado=1 — 1= procesado

where rut = r_dat.rut;

            commit;

insert into t_empleado_resp(rut,dv,nombre,edad,direccion) values (r_dat.rut,

r_dat.dv, r_dat.nombre, r_dat.edad, r_dat.direccion);

            commit;                                               

end loop;

exception

when others then pst_error:= ‘ha ocurrido un error en el proceso’;

End Prc_Guardar;

En este ejemplo después de cada update y cada insert se esta realizando un commit, esta acción esta correcta pero es un proceso demasiado lento ya que por cada modificación de datos se están guardando los cambios en el servidor de la base de datos. Veamos como se usa el commit de forma correcta:

 

Procedure Prc_Guardar(pst_error out varchar2) Is

Begin

For r_dat in (select emp.rut,emp.dv,emp.nombre,emp.edad,emp.direccion from

t_empleado emp where ind_estado = 0 ) — 0=pendiente

loop

update t_empleado set ind_estado=1 — 1= procesado

where rut = r_dat.rut;

insert into t_empleado_resp(rut,dv,nombre,edad,direccion) values (r_dat.rut,

r_dat.dv, r_dat.nombre, r_dat.edad, r_dat.direccion);

end loop;

      commit;                                               

exception

when others then pst_error:= ‘ha ocurrido un error en el proceso’;

End Prc_Guardar;

el commit solo se realiza una vez cuando el proceso termina, este proceso es mucho más rápido y eficiente que el anterior.

 

Recovery:

Métodos de Recuperación

Existen varios métodos de recuperación, pero todos ellos se basan en la aplicación de los registros de redo log.

Aplicación de Redo Log

Cuando una BD se arranca con el comando startup, la BD pasa por los estados nomount, mount y open. En este tercer estado, se verifica que se pueden abrir todos los ficheros de log y de datos. Si la BD se arranca por primera vez después de una caida, se necesitará efectuar una recuperación que consiste en dos pasos: avanzar la BD hacia adelante aplicando los registros redo log, deshacer las transacciones no confirmadas.

Cada fichero de datos tiene en su cabecera el último checkpoint efectuado, así como el fichero de control también lleva esa cuenta. El checkpoint lleva incluido el SCN. Este es conocido como SCN de inicio de fichero. Asociado a cada fichero de datos el fichero de control tiene el SCN de final, puesto inicialmente a infinito. El SCN de inicio se incrementa con cada checkpoint.

Cuando la BD se para en modo normal o inmediato iguala el SCN de parada para cada fichero de datos al SCN almacenado en cada fichero de datos. Cuando se abre otra vez la BD se realizan dos comprobaciones. La primera es mirar si el contador de checkpoints en la cabecera de los ficheros de datos coincide con el correspondiente del fichero de control. Si es así, se compara el SCN de inicio de cada fichero de datos con el SCN de final almacenado en el fichero de control. Si son iguales no se necesita recuperación en este fichero de datos. Como parte de la apertura se pone a infinito el SCN de final para ese fichero de datos.

Si la BD se paró con en modo abort no se ejecutó el checkpoint y el SCN de fin para los fichero de datos está a infinito. Así, durante la BD se abre, y suponiendo que el contador de checkpoints coincide, se comparan los SCN de inicio y de final, y como el último es infinito se efectura una recuperación aplicando los cambios almacenados en los ficheros redo log en línea para avanzar la BD, y los registros de roll back de los segmentos de roll back para deshacer las transacciones no confirmadas.

Si después de parar la BD se reemplaza un fichero de datos por su copia de seguridad, al arrancar la BD Oracle detecta que el contador de checkpoints del fichero de datos no coincide con el almacenado en el fichero de control. Así, se tendrá que echar mano a los ficheros redo log archivados, empezando por aquel cuyo número de secuencia aparece en la cabecera del fichero de datos.

Recuperación Física

La utilización de una copia de backup de ficheros de datos siempre necesita de una recuperación física. También es así cuando un fichero de datos se pone offline sin un checkpoint.

Oracle detecta que se necesita una recuperación física cuando el contador de checkpoints de la cabecera del fichero de datos no coincide con el correspondiente contador de checkpoints del fichero de control. Entonces se hace necesario el comando recover. La recuperación comienza en el SCN menor de los ficheros de datos en recuperación, aplicando los registros de redo log a partir de él, y parando en el SCN de final mayor de todos los ficheros de datos.

Existen tres opciones para realizar una recuperacion física. La primera es una recuperación de BD donde se restaura la BD entera. La segunda es una recuperación de tablespace donde, mientras una parte de la BD está abierta, se puede recuperar un tablespace determinado. Esto significa que serán recuperados todos los ficheros de datos asociados al tablespace. El tercer tipo es la recuperación de un fichero de datos específico mientras el resto de la BD está abierta.

Requisitos para Utilizar Recuperación Física

La primera condición que se ha de poner para poder recuperar físicamente una BD es que ésta se esté utilizando en modo ARCHIVELOG. De otro modo, una recuperación completa puede que no sea posible. Si trabajamos con la BD en modo NOARCHIVELOG, y se hace una copia semanal de los ficheros de la BD, se debería estar preparado para perder, en el peor de los casos, el trabajo de la última semana si sucede un fallo. Ya que los ficheros de redo log contendrían un agujero y no se podia avanzar la BD hasta el intante anterior al fallo. En este caso el único medio para reconstruir la BD es hacerlo desde un exportcompleto, recreando el esquema de la BD e importando todos los datos.

Recuperación de la BD

La BD debe estar montada pero no abierta. El comando de recuperación es el siguiente:

 

RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD]

   [UNTIL CANCEL]

   [UNTIL TIME fecha]

   [UNTIL CHANGE entero]

[USING BACKUP CONTROLFILE]

Las opciones entre corchetes son opcionales:

• AUTOMATIC hace que la recuperación se haga automáticamente sin preguntar al DBA por el nombre de los ficheros redo log. También se puede utilizar para este cometido el comando set autorecovery on/off. Los ficheros redo log deben estar en la localización fijada en LOG_ARCHIVE_DEST y el formato del nombre de los ficheros debe ser el fijado en LOG_ARCHIVE_FORMAT.
• FROM se utiliza para determinar el lugar donde están los ficheros redo log, si es distinto del fijado en LOG_ARCHIVE_DEST.
• UNTIL sirve para indicar que se desea realizar una recuperación incompleta, lo que implica perder datos. Solo se dará cuando se han perdido redo log archivados o el fichero de control. Cuando se ha realizado una recuperación incompleta la BD debe ser abierta con el comando alter database open resetlogs, lo que produce que los redo log no aplicados no se apliquen nunca y se inicialice la secuencia de redo log en el fichero de control. Existen tres opciones para parar la recuperación:
• UNTIL CANCEL permite recuperar un redo log cada vez, parando cuando se teclea CANCEL.
• UNTIL TIME permite recuperar hasta un instante dado dentro de un fichero de redo log
• UNTIL CHANGE permite recuperar hasta un SCN dado.
• USING BACKUP CONTROLFILE utiliza una copia de seguridad del fichero de control para gobernar la recuperación.

Recuperación de un tablespace

La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando de recuperación es el siguiente:

 

RECOVER [AUTOMATIC] [FROM 'localizacion']

   TABLESPACE nombre_tablespace [, nombre_tablespace]

Recuperación de un Fichero de Datos

La BD debe estar abierta o cerrada, dependiendo del fichero a recuperar. Si el fichero a recuperar es de un tablespace de usuario la BD puede estar abierta, pero con el fichero a recuperar offline. Si el fichero es del tablespace SYSTEM la BD debe estar cerrada, ya que no puede estar abierta con los ficheros delSYSTEM offline. El comando de recuperación es el siguiente:

 

RECOVER [AUTOMATIC] [FROM 'localizacion']

   DATAFILE nombre_fichero [, nombre_fichero]

Creando un Fichero de Control

Si el fichero de control ha resultado dañado y se ha perdido se puede utilizar una copia de seguridad del mismo o crear uno nuevo. El comando de creación de un nuevo fichero de control es CREATE CONTROLFILE. Este comando se puede ejecutar sólo con la BD en estado nomount. La ejecución del comando produce un nuevo fichero de control y el montaje automático de la BD.

Un comando interesante que ayuda a mantener los ficheros de control a salvo es el siguiente:

 

SVRMGR> alter database backup controlfile to trace;

que produce un script que puede ser utilizado para generar un nuevo fichero de control y recuperar la BD, en caso necesario. El fichero de traza generado es el siguiente:

 

Dump file /opt/app/oracle/admin/demo/udump/demo_ora_515.trc

Oracle7 Server Release 7.3.2.3.0 - Production Release

With the distributed, replication and Spatial Data options

PL/SQL Release 2.3.2.3.0 - Production

ORACLE_HOME = /opt/app/oracle/product/7.3.2

System name:    SunOS

Node name:      cartan

Release:        5.5

Version:        Generic

Machine:        sun4m

Instance name: demo

Redo thread mounted by this instance: 1

Oracle process number: 7

Unix process pid: 515, image: oracledemo

 

Fri May 15 11:41:19 1998

Fri May 15 11:41:19 1998

*** SESSION ID:(6.2035) 1998.05.15.11.41.19.000

# The following commands will create a new control file and use it

# to open the database.

# No data other than log history will be lost. Additional logs may

# be required for media recovery of offline data files. Use this

# only if the current version of all online logs are available.

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "DEMO" NORESETLOGS NOARCHIVELOG

    MAXLOGFILES 16

    MAXLOGMEMBERS 2

    MAXDATAFILES 30

    MAXINSTANCES 1

    MAXLOGHISTORY 100

LOGFILE

  GROUP 1 '/export/home/oradata/demo/redodemo01.log'  SIZE 2M,

  GROUP 2 '/export/home/oradata/demo/redodemo02.log'  SIZE 2M,

  GROUP 3 '/export/home/oradata/demo/redodemo03.log'  SIZE 2M

DATAFILE

  '/export/home/oradata/demo/system01.dbf',

  '/export/home/oradata/demo/rbs01.dbf',

  '/export/home/oradata/demo/rbs02.dbf',

  '/export/home/oradata/demo/rbs03.dbf',

  '/export/home/oradata/demo/temp01.dbf',

  '/export/home/oradata/demo/tools01.dbf',

  '/export/home/oradata/demo/users01.dbf'

;

# Recovery is required if any of the datafiles are restored backups,

# or if the last shutdown was not normal or immediate.

RECOVER DATABASE

# Database can now be opened normally.

ALTER DATABASE OPEN;

Recuperación Lógica

Oracle dispone de la herramienta import para restaurar los datos de una BD a partir de los ficheros resultados de un export. Import lee los datos de los ficheros de exportación y ejecuta las sentencias que almacenan creando las tablas y llenándolas de datos.

Parámetros del Import

Parámetro	Defecto	Descripción
USERID	indefinido	el username/password del usuario que efectua el import.
BUFFER	dependiente del SO	El tamaño en bytes del buffer utilizado.
FILE	expdat.dmp	el nombre del fichero de exportación a importar.
SHOW	No	indica si se muestran los contenidos del fichero de exportación, sin importar ningún dato.
IGNORE	Yes	indica si ignorar los errores producidos al importar un objeto que ya existe en la BD.
GRANTS	Yes	indica si se importan también los derechos.
INDEXES	Yes	indica si se importan también los índices.
ROWS	Yes	indica si se importan también las filas de las tablas.
FULL	No	indica si se importan el fichero entero.
FROMUSER	Indefinido	una lista de los usuarios cuyos objetos se han exportado.
TOUSER	Indefinido	una lista de los usuarios a cuyo nombre se importan los objetos.
TABLES	indefinido	la lista de tablas a importar.
RECORDLENGTH	dependiente del SO	la longitud en bytes del registro del fichero.
INCTYPE	indefinido	el tipo de import incremental (SYSTEM o RESTORE).
COMMIT	No	indica si se efectua un commit después de importar cada fila. Por defecto, import efectua un commit después de cargar cada tabla.
PARFILE	indefinido	el fichero de parámetros.

Para importar un export incremental se puede efectuar la siguiente secuencia de pasos:

1. Utilizar la copia más reciente del import para restaurar las definiciones del sistema:

 

2.      $ imp userid=sys/passwd inctype=system full=Y file=export_filename

3. Poner los segmentos de rollback online.
4. Importar el fichero de exportación completa más reciente:

5.      $ imp userid=sys/passwd inctype=restore full=Y file=filename

6. Importar los ficheros de exportación en modo acumulación desde la exportación completa más reciente, en orden cronológico:

 

7.       $ imp userid=sys/passwd inctype=restore full=Y file=filename

8. Importar los ficheros de exportación en modo incremental desde la exportación completa o acumulativa más reciente, en orden cronológico:

$ imp userid=sys/passwd inctype=restore full=Y file=filename