TEMA 8

ÍNDICES Y TRANSACCIONES
8.1 ÍNDICES

8.2 FINALIDAD DE UN ÍNDICE

8.3 ACTUALIZACIÓN DE UN ÍNDICE

8.4 TIPOS DE ÍNDICES

8.5 ¿ÍNDICE AGRUPADO O NO AGRUPADO?

8.6 ÍNDICES EN VISTAS

8.7 CREACIÓN IMPLÍCITA DE ÍNDICES

8.8 CREACIÓN DE ÍNDICES CON CREATE INDEX

8.9 MODIFICAR ÍNDICES

8.10 ELIMINAR ÍNDICES

8.11 TRANSACCIONES

8.121 PROPIEDADES ACID DE LAS TRANSACCIONES

8.13 BEGIN TRANSACTION

8.14 COMMIT TRANSACTION

8.15 ROLLBACK TRANSACTION

8.16 MODOS DE TRANSACCIÓN

8.17 CAMBIO ENTRE MODOS DE TRANSACCIÓN

8.18 TRANSACCIONES ANIDADAS

8.19 VARIABLES DE CONTROL ASOCIADAS A LAS TRANSACCIONES

8.20 RESUMEN

Pilar García López SQL

Tema 8

8.1 ÍNDICES

A diferencia de las tablas y las vistas, que son objetos de primer nivel en una base de
datos, los índices son estructuras que van indivisiblemente unidas precisamente a una tabla
o a una vista. Puede haber más de un índice por tabla.

Es conceptualmente similar a un índice encontrado al principio de cualquier libro de

texto. De la misma forma que el lector de un libro acudiría a un índice para determinar en
qué páginas se encuentra un determinado tema, un SGBD leerá un índice para determinar
las posiciones de las filas seleccionadas por una consulta SQL.

8.2 FINALIDAD DE UN ÍNDICE

Los índices son estructuras creadas partir de datos que existen en una o más
columnas de una tabla o vista, es decir, contienen los mismos datos que ya hay en la base
de datos, lo que les hace útiles, sin embargo, no son los datos contenidos sino el orden en
que éstos se almacenan. Un orden que acelera las operaciones de búsqueda y selección.
Para comprenderlo mejor tan solo hay que pensar en cómo actúa una consulta sobre una
cierta tabla.

Ejemplo: Supongamos que un cliente de una librería solicita un cierto libro facilitando
su ISBN, por lo que se efectúa una consulta en la tabla LIBROS similar a la siguiente:

Select titulo, editorial, precio

From libros
Where ISBN=’11-222-3333-4’

¿Qué ocurre en la base de datos al efectuar esta consulta?

Si el ISBN no se ha asociado a un índice, se recorre la tabla LIBROS entera, desde

la primera fila, hasta dar con aquella que contenga el ISBN solicitado, o bien hasta
el final, en caso de que no exista. Si en la tabla hay catalogados unos miles de
libros, no cabe duda de que el proceso no será precisamente instantáneo.

Si tomamos el ISBN de cada uno de los libros existentes en la tabla LIBROS y los
almacenamos en una lista debidamente ordenada, creando un índice con los ISBN
similar al índice de un libro, el proceso de búsqueda se simplificaría
considerablemente. Al ejecutar la misma consulta anterior, el gestor de base de
datos detectaría el índice y realizaría la búsqueda en él. Al estar ordenado, sin
embargo, no tiene por qué recorrerlo secuencialmente de principio a fin, sino que
bastan unas cuantas lecturas basadas en un algoritmo más eficiente (el de los
Árboles B) para encontrarlo rápidamente.
Lógicamente, esta lista ordenada con los ISBN debe mantener, además, un enlace o
apuntador a la fila correspondiente de la tabla LIBROS, de tal forma que sea
posible acceder al resto de los datos son tener que duplicarlos todos.

Pilar García López SQL Pág. 1

Tema 8

Se crean índices en tablas para acelerar el proceso de recuperación de datos, aunque

ocupan un espacio adicional y consumen tiempo de mantenimiento. Es decir, se consigue
más rapidez en las consultas, a costa de bajar el rendimiento en las inserciones y
actualizaciones.

8.3 ACTUALIZACIÓN DE UN ÍNDICE

Como es lógico, un índice debe actualizarse constantemente ya que, de lo contrario,

perdería su utilidad.

Tras crear el índice basado en la columna ISBN de la tabla LIBROS, es lógico pensar
que en algún momento se añadirán nuevos libros a dicha tabla, lo cual, indirectamente,
significa que habrá que insertar nuevas entradas en el índice. Insertar y no añadir, puesto
que aunque la nueva fila se añada al final de la tabla, la entrada correspondiente en el
índice, por el contario, deberá insertarse en la posición adecuada para seguir teniendo una
lista de ISBN ordenada.

Si suponemos que la tabla LIBROS ya contase con un índice, el correspondiente a la

clave primaria IdLibro, al añadir el índice basado en la columna ISBN sería preciso
actualizar dos índices cada vez que se añadiesen o modificasen filas de dicha tabla. Como
es fácil de imaginar, esto supone una mayor necesidad de espacio en la base datos, así
como más tiempo para realizar las tareas de manipulación de datos.

Pueden existir tablas con dos, tres o incluso más índices. Lo que hay que analizar,
para buscar un equilibrio entre el rendimiento de las consultas y el de las demás
operaciones con las tablas, es cuándo se necesita el índice y cuándo éste no mejora de
forma apreciable el trabajo con la base de datos.

Por regla general:

en tablas que cuentan con pocas filas los índices NO mejoran mucho el tiempo en
que se ejecuta una consulta.

En tablas que tienen muchas filas, por el contrario, el índice adquiere mucha más
importancia, sobre todo si las consultas a la tabla son frecuentes.

8.4 TIPOS DE ÍNDICES

Los índices pueden ser de varios tipos:

Índice único/no único. Un índice único es aquel índice que no permite que 2
filas tengan el mismo valor en la columna o columnas que forman el índice,
incluyendo el valor nulo (NULL). Un índice no único sí admite valores del índice
iguales en distintas filas.

Índice simple/compuesto. Un índice es simple cuando está formado por una

Pilar García López SQL Pág. 2

Tema 8

columna. Es compuesto cuando está formado por dos o más columnas.

Índice agrupado o CLUSTERED /No agrupado o NONCLUSTERED. Se

amplía aquí lo ya tratado sobre estos tipos de índices en temas anteriores.

o Cada tabla puede contar con un índice agrupado (clustered), aunque no

es algo obligatorio, así como con ninguno, uno o más índices no
agrupados (non-clustered). Dicho de otra forma, una tabla puede tener
los índices que sean necesarios, pero sólo uno de ellos puede ser un
índice agrupado.

o Además de tener la utilidad de cualquier otro índice, un índice

agrupado establece el orden físico de las filas en la tabla a la que
pertenece. Similar a una guía telefónica, donde cada elemento (con
todos sus datos) está ordenado alfabéticamente por apellidos y nombre.
Si no existe un índice agrupado, las filas se almacenan en el orden en
que se van añadiendo, sin más.

o Por defecto, el índice agrupado de una tabla será el asociado a su clave

principal, si es que se ha definido una.

o Lógicamente, un índice agrupado hace más fáciles las búsquedas en la

tabla pero, también, implica que las operaciones en ésta ya no pueden
efectuarse simplemente añadiendo filas, sino que es necesario
insertarlas en el orden adecuado y, en caso de modificación, incluso
cambiar el orden en el que estaban.

o Los índices no agrupados hacen referencia (es decir, tienen punteros)

a las filas correspondientes de datos basándose en el lugar que ocupan
en la tabla. Algo similar al índice de un libro, que está ordenado por los
temas y en cada uno figura la página del libro en la que comienza dicho
tema.

o Puede haber hasta 249 índices no agrupados en cada tabla.

8.5 ¿ÍNDICE AGRUPADO O NO AGRUPADO?

La diferencia es importante, ya que el uso de índices agrupados es más eficiente

que el de índices no agrupados, al ahorrar a SQL Server hacer un salto para leer las filas
de datos.

Entonces ¿por qué no usar siempre índices agrupados o clustered? En primer lugar,
lamentablemente solo puede haber un índice agrupado por tabla. La razón es muy sencilla
y lógica: Los datos de la tabla están físicamente ordenados según el índice agrupado y,
obviamente, una tabla no puede estar físicamente ordenada de dos maneras diferentes a la
vez.

Pilar García López SQL Pág. 3

Tema 8

Por lo tanto, en tablas grandes y muy consultadas, tenemos que ser cuidadosos y
analizar qué columnas vamos a seleccionar para formar el índice agrupado (clustered).
Tenemos un solo índice de este tipo por tabla, ¡no hay que desperdiciarlo!

¿En qué situaciones y para qué columnas se debe utilizar un índice agrupado
(clustered) o uno no agrupado (non-clustered)? Los siguientes puntos pueden ser una guía
general para la decisión:

Campos autoincrementales (identity), conviene que sean del tipo agrupado

(clustered). La razón es reducir la fragmentación de la tabla (page Split).

La clave primaria es un buen candidato para un índice agrupado (clustered).

Pero no siempre. Por ejemplo, si tenemos una tabla de ventas, cuya clave
primaria es un identity en donde se efectúan muchas consultar por rangos de
fecha, el campo Fecha sería un mejor candidato para el clustered que la clave
primaria.

Los índices agrupados son convenientes si se va seleccionar un rango de

valores, ordenar (ORDER BY) o agrupar (GROUP BY) frecuentemente.

Para búsquedas de valores específicos, conviene utilizar un índice no

agrupadon(on-clustered).

Para índices compuestos, generalmente es mejor utilizar un índice no agrupado

(non-clustered).

8.6 ÍNDICES EN VISTAS

Los índices pueden crearse asociados no solo a una tabla, sino también es posible
usarlos para mejorar el rendimiento al trabajar con vistas. La creación de un índice en una
vista, no obstante, implica algunos cambios lógicos en la propia vista, mejorando el tiempo
de respuesta al consultarla a costa de incrementar la ocupación en la base de datos y afectar
negativamente al rendimiento de actualización de las tablas que participan en las vista.

Al tratar las vistas, decíamos que éstas no almacenan en la base de datos las filas y
columnas que la forman, sino la sentencia SQL necesaria para poder generar
dinámicamente la vista cuando sea necesario.

¿Cómo es posible, entonces, crear un índice a partir de la vista?

Es posible alterando la propia vista, haciendo que ésta almacene en la base de datos
no solamente la sentencia SQL sino también los propios datos. De esta manera, la vista
pasaría a ser como cualquier otra tabla de la base de datos, siendo posible la creación de un
índice a partir de sus columnas.

Además, hay que considerar que, para que la vista se mantenga siempre actualizada,
cada vez que insertemos, eliminemos o modifiquemos filas de las tablas que participan en
el vista, SQL Server se verá forzado a efectuar la misma operación en la vista, los índices
Pilar García López SQL Pág. 4
Tema 8

de la tabla y los índices de la vista.

Los beneficios de un índice asociado a una vista, por tanto, hay que examinarlos con
mucho detalle para decidir si realmente merece la pena el coste de espacio y rendimiento a
la hora de manipular las tablas de datos.

8.7 CREACIÓN IMPLÍCITA DE ÍNDICES

Cuando en la creación de una tabla con CREATE TABLE o en la modificación con

ALTER TABLE, se define una clave primaria o alguna clave alternativa, automáticamente
el gestor crea índices asociados a dichas claves.
Aunque esta parte ya se trató en temas anteriores, recordemos de nuevo unos
ejemplos.

En el siguiente ejemplo la definición que se hace de los índices asociados a la clave

primaria y a la clave alternativa coincide con la que se hace por defecto. Por tanto, tiene el
mismo efecto definir estas características de los índices que no definir nada de ellos:

Create table Personas

( IdPersona varchar(39) primary key clustered,
Nombre varchar(40),
Apellido varchar(40),
NumDocumento char(7) unique nonclustered )

Sin embargo, en este otro ejemplo se definen los índices al revés de como se haría por
defecto. Sería recomendable esta definición si sabemos que la mayoría de las búsquedas se
van a hacer a través del valor de NumDocumento, por eso se le asigna a esta columna el
índice agrupado, que es el más eficiente:

Create table Personas

( IdPersona varchar(39) primary key nonclustered,
Nombre varchar(40),
Apellido varchar(40),
NumDocumento char(7) unique clustered )

En el siguiente ejemplo se define una clave primaria para la tabla AUTORES y, por
tanto, un índice asociado a ella. Se define expresamente que sea el índice agrupado:

ALTER TABLE AUTORES

ADD CONSTRAINT PK_IdAutor PRIMARY KEY CLUSTERED (IdAutor)

8.8 CREACIÓN DE ÍNDICES CON CREATE INDEX

Pilar García López SQL Pág. 5

Tema 8

La sentencia CREATE INDEX tiene muchas opciones y requiere consultar sus

opciones en el manual del gestor que estemos utilizando. Veremos ahora la sintaxis de sus
opciones principales:

CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED] INDEX nombreIndice

ON { table | view } ( column [ ASC | DESC ] [ ,...n ] )

[ WITH < index_option > [ ,...n] ]

CREATE INDEX idx_IdAutor ON AUTORES (idAutor)

Se pueden definir índices compuestos.

• Un índice compuesto está formado por varias columnas.
• Las columnas no tienen por qué tener el mismo orden que en la tabla y se
pueden combinar hasta 16 columnas, con un máximo de 256 bytes.
• Las columnas tienen que ser de la misma tabla.
• El orden de cada columna puede ser Ascendente (por defecto) o Descendente.
Se representa con ASC o DESC respectivamente.

CREATE INDEX idx_Amigos ON AMIGOS (nombre ASC, apellido DESC)

Siendo lo mismo que:

CREATE INDEX idx_Amigos ON AMIGOS (nombre, apellido DESC)

Se pueden definir índices únicos.

• Un índice único es aquel índice que no permite que 2 filas tengan el mismo
valor de índice.
• Para crear un índice único se debe especificar UNIQUE.

CREATE UNIQUE INDEX idx_DNI ON PERSONAS (DNI)

Se pueden crear índices compuestos únicos.

CREATE UNIQUE INDEX idx_Amigos ON AMIGOS (nombre, apellido)

Definir índices Agrupados/No-Agrupados.

CREATE CLUSTERED INDEX idx_Titulo ON LIBROS (idTitulo)

CREATE NONCLUSTERED INDEX idx_CPostal ON CLIENTES (codPostal)

En las opciones (index_option) podemos utilizar varias, entre ellas,

Pilar García López SQL Pág. 6

Tema 8

IGNORE_DUP_KEY para evitar que se compruebe la duplicidad de un índice, con las

siguientes limitaciones:
• IGNORE_DUP_KEY: Si intentamos insertar filas en una columna que tiene
un índice único, el comando no se ejecutará correctamente. Es posible evitar
que se cancele el comando incluyendo la opción IGNORE_DUP_KEY con
un índice UNIQUE.
• IGNORE_DUP_ROW/ALLOW_DUP_ROW: Son opciones excluyentes
que se utilizan para la creación de un índice agrupado y no único,
controlando lo que ocurre cuando se crea una fila duplicada con INSERT O
UPDATE. Si se especifica IGNORE no se permitirá insertar filas duplicadas
y tampoco actualizar filas cuyo resultado origine una duplicidad. Si se
especifica ALLOW es lo contrario, sí se permite.

8.9 MODIFICAR ÍNDICES

Se puede modificar un índice con la sentencia ALTER INDEX.

ALTER INDEX PK_Employee_EmployeeID

ON HumanResources.Employee
REBUILD;

Se puede desactivar/Activar un índice haciendo uso de DISABLE y ENABLE.

ALTER INDEX IX_Employee_ManagerID

ON HumanResources.Employee
DISABLE ;

8.10 ELIMINAR ÍNDICES

También puede eliminar un índice de la base de datos con la sentencia DROP

INDEX.

DROP INDEX Tclientes.UIX_CLIENTES_NIF

Pilar García López SQL Pág. 7

Tema 8

8.11 TRANSACCIONES

Se denomina transacción al conjunto de operaciones SQL que se tratan como un

bloque único, de tal forma que, o se ejecutan correctamente todas las operaciones, o no se
ejecuta ninguna.
El ejemplo clásico de transacción es una transferencia bancaria, en la que
quitamos saldo a una cuenta y lo añadimos en otra. Si no somos capaces de
abonar el dinero en la cuenta de destino, no debemos quitarlo de la cuenta de
origen.

Si una transacción tiene éxito, todas las modificaciones de los datos realizadas
durante la transacción se confirman y se convierten en una parte permanente de la
base de datos.

Si una transacción encuentra errores y debe cancelarse o deshacerse, se pueden

borran todas las modificaciones de los datos realizadas desde el comienzo de la
transacción.

8.12 PROPIEDADES ACID DE LAS TRANSACCIONES

Las transacciones se identifican por cuatro propiedades que responden a las iniciales
ACID: Atomicidad, Coherencia, Aislamiento y Durabilidad.

Atomicidad.- Es la forma de decir que una transacción es una unidad de trabajo.

Cuando se acaba la transacción o se han ejecutado todas las instrucciones o no se
ha hecho nada.

Coherencia.- Cuando una transacción se confirma o se deshace, debe dejarse la

base de datos en un estado coherente, si el gestor detecta que las instrucciones
dejarían la base de datos en un estado incoherente, la transacción no podría
confirmarse.

Aislamiento.- Si dos o más transacciones se intentasen ejecutar a la vez, una de

ellas comenzará primero y luego el resto, nunca se podrán ejecutar a la vez. Cada
transacción posterior podrá encontrar la base de datos modificada o no, según
hubiese transcurrido la transacción anterior.

Durabilidad.- Una vez que se confirma una transacción, sus efectos son
permanentes.

8.13 BEGIN TRANSACTION

BEGIN TRANSACTION inicia el proceso de transacción. El formato básico es:

BEGIN [TRAN | TRANSACTION] [nombreTransacción | @nombreVariable]

Pilar García López SQL Pág. 8

Tema 8

Donde:
nombreTransacción | @nombreVariable. Opcional, se utiliza para dar un
nombre a la transacción, es una forma de documentar el código para
facilitar el mantenimiento posterior. Puede ser un nombre o ser un nombre
contenido en una variable.

8.14 COMMIT TRANSACTION

El formato básico de COMMIT TRANSACTION es:

COMMIT [TRAN | TRANSACTION ] [nombreTransacción | @nombreVariable]

Cuando se ejecuta esta instrucción se confirma la transacción y los cambios se

escriben en la Base de Datos. Una vez que se ha ejecutado COMMIT los cambios no se
pueden deshacer.

8.15 ROLLBACK TRANSACTION

El formato básico de ROLLBACK TRANSACTION es:

ROLLBACK [TRAN | TRANSACTION ] [nombreTransacción | @nombreVariable

Cuando se ejecuta ROLLBACK se desestiman los cambios, quedando la base de

datos en el estado inicial, es decir, tal como estaba justo antes del comienzo de la última
transacción.

8.16 MODOS DE TRANSACCIÓN

SQL Server funciona en los siguientes tres modos de transacción:

Transacciones de confirmación automática

TRANSACCIONES IMPLÍCITAS o de comienzo implícito
Transacciones explícitas

Transacciones de confirmación automática

SQL Server funciona por defecto con Transacciones de confirmación

automática, es decir, cada instrucción individual es una transacción y se confirma
automáticamente.

UPDATE PRODUCTOS

Pilar García López SQL Pág. 9

Tema 8

SET STOCKMINIMO=100, STOCKMAXIMO=200

WHERE IDPRODUCTO=10

Para SQL la orden anterior incluye una transacción automática, es decir, cuando se
ejecuta la actualización SQL Server asume que se deben hacer los dos cambios y si por
alguna circunstancia se produjese un error, no se actualizará ninguna de las dos columnas.

Supongamos ahora que dividimos la orden anterior en dos, que hacen lo mismo, es
decir:
UPDATE PRODUCTOS
SET STOCKMINIMO=100
WHERE IDPRODUCTO=10
UPDATE PRODUCTOS
SET STOCKMAXIMO=200
WHERE IDPRODUCTO=10

Ahora cada una de las sentencias es una transacción automática pudiendo

ejecutarse una de forma independiente de la otra. Si una actualización falla y la otra no, la
que no ha fallado actualiza la tabla de la base de datos.

Transacciones implícitas o de comienzo implícito

Se inicia implícitamente una nueva transacción cuando se ha completado la anterior,

pero cada transacción se completa explícitamente con una instrucción COMMIT o
ROLLBACK.

Transacciones explícitas

Cada transacción se inicia explícitamente con la instrucción BEGIN

TRANSACTION y se termina explícitamente con una instrucción COMMIT o
ROLLBACK.

Es posible crear nuestros propios bloques de transacciones, declarando

explícitamente el comienzo y el final de la transacción. Es lo que se conoce como
transacciones explicitas.

La instrucción para declarar el comienzo de una transacción explícita es BEGIN

TRANSACTION o BEGIN TRAN. Indica el inicio del lote de instrucciones que deben
considerarse como «un todo».

La instrucción para confirmar una transacción explícita es COMMIT

TRANSACTION o COMMIT. Indica que todo se ha procesado de forma correcta y que
se guarde todo el trabajo realizado por la macroinstrucción.

La instrucción para anular una transacción explícita es ROLLBACK

TRANSACTION o ROLLBACK. Indica que se ha producido algún problema y que todo
debe cancelarse.

Pilar García López SQL Pág. 10

Tema 8

-- Ejemplo de transacción explícita:

DECLARE @MIN_ERR INT, @MAX_ERR INT -- Variables para capturar el estado de una
operación
BEGIN TRANSACTION
UPDATE PRODUCTOS -- Operación de actualización del stock mínimo
SET STOCKMINIMO=100
WHERE IDPRODUCTO=10
SET @MIN_ERR = @@ERROR -- Captura del estado de la última operación
realizada
UPDATE PRODUCTOS -- Operación de actualización del stock máximo
SET STOCKMAXIMO=200
WHERE IDPRODUCTO=10
SET @MAX_ERR = @@ERROR -- Captura del estado de la última operación
realizada
-- Si ambas operaciones han sido correctas (estado cero) se confirman las operaciones
IF (@MAX_ERR = 0 AND @MIN_ERR = 0)
COMMIT TRANSACTION -- Confirmación de la operación
-- Si alguna, o las dos, operaciones han fallado
ELSE
ROLLBACK TRANSACTION -- Se cancelan las operaciones

8.17 CAMBIO ENTRE MODOS DE TRANSACCIÓN

La siguiente instrucción set permite establecer el modo de transacción a utilizar.

SET IMPLICIT_TRANSACTIONS { ON | OFF }

Establece el modo de transacción implícita para la conexión.

Cuando SET IMPLICIT_TRANSACTIONS es ON, establece la conexión al modo

de transacción implícita. Cuando es OFF, restablece la conexión al modo de
transacción con confirmación automática.

Cuando una conexión está en modo de transacción implícita y no se está ejecutando

ninguna transacción, la ejecución de cualquiera de las instrucciones siguientes inicia una
transacción:

ALTER TABLE FETCH REVOKE

BEGIN
GRANT SELECT (vea la excepción a continuación)
TRANSACTION
CREATE INSERT TRUNCATE TABLE
DELETE Abrir UPDATE
DROP

El modo de transacción implícita permanecerá activo hasta que la conexión ejecute

una instrucción SET IMPLICIT_TRANSACTIONS OFF, que restablece el modo de
confirmación automática en la conexión.

Pilar García López SQL Pág. 11

Tema 8

8.18 TRANSACCIONES ANIDADAS

Se pueden anidar transacciones

-- Inicio de una transacción

BEGIN TRANSACTION BEGIN TRANSACTION
-- Se actualiza la tabla de productos
UPDATE PRODUCTOS SET UPDATE PRODUCTOS
STOCKMINIMO=100 WHERE SET STOCKMINIMO=100
IDPRODUCTO=10 WHERE IDPRODUCTO=10

-- Se inicia una segunda transacción

BEGIN TRANSACTION BEGIN TRANSACTION
-- Se actualiza de nuevo la tabla de
UPDATE productos
PRODUCTOS UPDATE PRODUCTOS
SET SET STOCKMAXIMO=200
STOCKMAXIMO=200 WHERE IDPRODUCTO=10
WHERE -- Se confirma la transacción interna.
IDPRODUCTO=10 -- Hay pendiente una transacción
-- (la externa), no se graban aún
-- los datos en la base de datos,
-- se hace en el registro de transacciones
COMMIT TRANSACTION
-- Se cancela la transacción externa.
COMMIT --No se graban en la base de datos
TRANSACTION --los cambios del registro de transacciones.
ROLLBACK TRANSACTION

ROLLBACK TRANSACTION

¿Qué pasaría en la situación anterior?

Aunque la transacción interna tuviera éxito, la base de datos no cambiaría porque la

transacción externa se cancela.

Pilar García López SQL Pág. 12

Tema 8

8.19 VARIABLES DE CONTROL ASOCIADAS A LAS

TRANSACCIONES

Asociadas a las transacciones, podemos encontrar varias variables de control, entre

ellas:
@@ERROR.- Es una variable del sistema que contiene el número de error de la
sentencia T-SQL ejecutada más recientemente.. Siempre que se ejecuta una
transacción y que no se produzca un error, la variable se carga con el valor 0.
@@TRANCOUNT.- Indica el número de transacciones anidadas que están
pendientes de ser ejecutadas. Si no existe ninguna su valor es 0.

DECLARE @MIN_ERR INT, • La instrucción DECLARE declara 2 variables

@MAX_ERR INT
• BEGIN TRANSACTION inicia la transacción
BEGIN TRANSACTION
• UPDATE actualiza el valor de
UPDATE PRODUCTOS STOCKMINIMO del IDPRODUCTO 10
SET STOCKMINIMO=100
WHERE IDPRODUCTO=10
• Se guarda el valor de @@ERROR en una de
SET @MIN_ERR = @@ERROR las variables declaradas.

• UPDATE actualiza el valor de

UPDATE PRODUCTOS STOCKMAXIMO del IDPRODUCTO igual a
SET STOCKMAXIMO=200 10
WHERE IDPRODUCTO=10

SET @MAX_ERR = @@ERROR • Se guarda el valor de @@ERROR en una de

las variables declaradas.
IF (@MAX_ERR = 0 AND • Si no se ha producido NINGUN un error la
@MIN_ERR = 0) transacción se confirma-
COMMIT TRANSACTION • Si se ha producido cualquier error la
ELSE instrucción ROLLBACK deshace todo el
ROLLBACK TRANSACTION trabajo.

Pilar García López SQL Pág. 13

Tema 8

8.20 RESUMEN

• Se crean índices en tablas para acelerar el proceso de recuperación de datos,

aunque ocupan un espacio adicional y consumen tiempo de mantenimiento. Es decir, se
consigue más rapidez en las consultas, a costa de bajar el rendimiento en las
inserciones y actualizaciones.

• Por regla general, en tablas que cuentan con pocas filas los índices NO mejoran mucho
el tiempo en que se ejecuta una consulta. Por el contrario, en tablas que tienen muchas
filas el índice adquiere mucha más importancia, sobre todo si las consultas a la tabla
son frecuentes.

• Un índice no único sí admite valores del índice iguales en distintas filas.

• Cada tabla puede contar con un índice agrupado (clustered), aunque no es algo
obligatorio, así como con ninguno, uno o más índices no agrupados (non-
clustered). Dicho de otra forma, una tabla puede tener los índices que sean
necesarios, pero sólo uno de ellos puede ser un índice agrupado.

• El uso de índices agrupados es más eficiente que el de índices no agrupados.

• Para crear índices se utiliza la orden CREATE INDEX, aunque también se pueden
crear índices con las restricciones de seguridad UNIQUE y PRIMARY KEY de la
sentencia CREATE TABLE, aunque estos últimos presentan algunas limitaciones.

• Se denomina transacción al conjunto de operaciones SQL que se tratan como un

bloque único, de tal forma que, o se ejecutan correctamente todas las operaciones, o no
se ejecuta ninguna.

• SQL Server funciona en los siguientes tres modos de transacción:

Transacciones de confirmación automática

TRANSACCIONES IMPLÍCITAS o de comienzo implícito
Transacciones explícitas

• Cuando SET IMPLICIT_TRANSACTIONS es ON, establece la conexión al modo de

transacción implícita. Cuando es OFF, restablece la conexión al modo de transacción
con confirmación automática.

• Las transacciones se pueden anidar.

Pilar García López SQL Pág. 14