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:
- Iniciar
una transacción con el uso de la sentencia BEGIN.
- Actualizar,
insertar o eliminar registros en la base de datos.
- 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.
- 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:
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;
Exception
When
Others Then
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;
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;
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;
r_dat.dv, r_dat.nombre, r_dat.edad, r_dat.direccion);
end loop;
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.
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;
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:
- 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
- Poner los segmentos de rollback online.
- Importar el fichero de exportación completa
más reciente:
5.
$ imp
userid=sys/passwd inctype=restore full=Y file=filename
- 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
- 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
No hay comentarios:
Publicar un comentario