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:
1.
Utilizar la copia más
reciente del import para restaurar las definiciones del
sistema:
2.
3.
$ imp userid=sys/passwd inctype=system full=Y
file=export_filename
4.
Poner los segmentos de rollback online.
5.
Importar el fichero de
exportación completa más reciente:
6.
7.
$ imp userid=sys/passwd inctype=restore full=Y
file=filename
8.
Importar los ficheros de
exportación en modo acumulación desde la exportación completa más reciente, en
orden cronológico:
9.
10. $ imp userid=sys/passwd
inctype=restore full=Y file=filename
11.
Importar los ficheros de
exportación en modo incremental desde la exportación completa o acumulativa más
reciente, en orden cronológico:
12.
$ imp userid=sys/passwd
inctype=restore full=Y file=filename
MySQL:
¿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
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
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
|
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
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
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)
No hay comentarios:
Publicar un comentario