ESPECIALIZACIÓN EN GESTIÓN Y SEGURIDAD DE BASES DE DATOS

FASE DE EJECUCIÓN

AA10 – EVIDENCIA 2

Manejo de transacciones, bloqueos y control de concurrencia ejecutando la

práctica propuesta

Presentado por: Carlos Julio Mesa G.

Instructor: Nelson Ruíz Gamba

SERVICIO NACIONAL DE APRENDIZAJE

SENA

-2019-

CENTRO DE SERVICIOS FINANCIEROS

 INTRODUCCIÓN

El rendimiento de un servidor. Una supervisión eficaz implica tomar

instantáneas periódicas del rendimiento actual para aislar procesos que causan
problemas y recopilar datos de forma continua a lo largo del tiempo para
realizar el seguimiento de las tendencias de rendimiento. Microsoft SQL Server
y el sistema operativo Microsoft Windows 2008 R2 proporcionan herramientas
que le permiten ver las condiciones actuales de la base de datos y realizar un
seguimiento del rendimiento a medida que éstas cambian. El objetivo de
supervisar Bases de Datos, es evaluar el rendimiento de un Sistema Manejador
de Base de Datos (SMBD), para responder a las transacciones realizadas por
los usuarios que solicitan datos a través de un Sistema Computacional.
La Evaluación de una Base de Datos, es una de las tareas más importantes de
un Administrador de Base de Datos. Este profesional es el encargado de
analizar constantemente el funcionamiento del SMBD, para optimizar el uso de
los recursos, como CPU, Memoria, Disco y Red, para ver su desempeño. El
análisis constante de un SMBD, permite ver su desempeño en todo momento.
Si se detecta que las transacciones no son respondidas con la rapidez que se
necesita o se pierden datos, el Administrador de la Base de Datos, debe aplicar
las medidas correctivas para solucionar las fallas, analizando su
comportamiento a través de herramientas gráficas provistas por el fabricante
de la aplicación.
 MANEJO DE TRANSACCIONES, BLOQUEOS Y CONTROL DE CONCURRENCIAS

DESARROLLO DE LOS PUNTOS DEL LABORATORIO 10

Abrir una consulta nueva en SQL Server 2014 y escribir el siguiente comando
COMMIT TRANSACTION y verificar de nuevo la cantidad de transacciones
activas y determinar que hace este comando en la base de datos SecSalud.
R/ el resultado es:

Mens. 3902, Nivel 16, Estado 1, Línea 9

La solicitud COMMIT TRANSACTION no tiene la correspondiente BEGIN TRANSACTION.

Este comando por sí solo no hace nada, debe ser acompañado de otras
cláusulas, dado que este comando se utiliza para Finalizar la transacción si no
se han encontrado errores.

Que sucede al hacer una consulta de todos los datos de la tabla EPS si
anteriormente se ejecuta el siguiente comando:

BEGIN TRANSACTION INSERT

INTO EPS (ideps, nombre, estadoeps)
VALUES (15,’confisena’,1)’

R/ el resultado es:

Mens. 544, Nivel 16, Estado 1, Línea 2

No se puede insertar un valor explícito en la columna de identidad de la tabla 'EPS'
cuando IDENTITY_INSERT es OFF.

Esto ocurre porque SQL server no permite insertar datos a llaves primarias de
forma normal

Para la cancelación de la transacción anterior ¿qué comando se debe utilizar?

Es necesario utilizar el comando SET IDENTITY_INSERT EPS ON

para que deje insertar datos de forma de inserción explicita en la tabla a una
pk.
Ejemplo:
BEGIN TRANSACTION
SET IDENTITY_INSERT EPS ON
INSERT INTO EPS (ideps, nombre, estadoeps)
VALUES (15,’confisena’,1)

Al utilizar el comando ya se puede hacer los insert en la tabla EPS.

Que le falta a la siguiente transacción para que se efectúen los cambios en la
base de datos Secretaria de Salud?

BEGIN TRANSACTION
INSERT INTO persona (idPersona, tipoidentificacion, nombre, apellido,
fechaNacimiento, sexo)
VALUES (1112548, 1, 'Pedro', 'Garcia', 1982-01-27, 'M');
INSERT INTO EPS (nombre, estadoeps)
VALUES ('confinacional',4);

R/ lo que hay que hacer es:

Agregar el comando SET IDENTITY_INSERT [tabla] ON, para que esta

transacción pueda correr y arreglar campos tabla persona: tipoidentifiacion,
idPersona; quedaría:

BEGIN TRANSACTION
SET IDENTITY_INSERT EPS ON
INSERT INTO Persona (idPersona, tipoidentificacion, nombre, apellido,
fechaNacimiento, sexo)
VALUES (111245548, 1, 'Pedro', 'Garcia', 1982-01-27, 'M')
INSERT INTO EPS (ideps, nombre, estadoeps)
VALUES (16,'confiacional',4)

En el siguiente cuadro especificar para cada tipo de transacción si es implícita,

explicita o automática.

Script Tipo de Transacción

BEGIN TRANSACTION
INSERT INTO cliente (cedula, nombre) Explícitas
VALUES (1,’sena’)
COMMIT TRANSACTION
INSERT INTO cliente (cedula, nombre) Automáticas
VALUES (1,’sena’)
INSERT INTO cliente (cedula, nombre)
VALUES (1,’sena’) Explícitas
COMMIT TRANSACTION
Transacciones explícitas

Por el contrario, las Transacciones explícitas son las que se define en el código
T-SQL. Hay que indicar cuando se inician (BEGIN TRANSACTION) y cuando
finalizan (COMMIT TRANSACTION), y pueden albergar un conjunto de
instrucciones dentro de la misma transacción.

Cuando se produce el COMMIT, se hacen efectivos los cambios en los ficheros

de datos (.mdf y .ndf). Mientras no se realiza el COMMIT las sentencias de los
cambios se guardan en el log de transacciones (.log), que gracias a este es
posible revertir los cambios si fuese necesario.

Automática

Es el modo de administración de transacciones predeterminado de SQL Server

Database Engine (Motor de base de datos de SQL Server). Cada instrucción
Transact-SQL se confirma o se revierte cuando finaliza. Si una instrucción
termina correctamente, se confirma; si encuentra un error, se revierte. Una
conexión a una instancia de Motor de base de datos funciona en modo de
confirmación automática siempre que no se suplante el modo predeterminado
mediante transacciones explícitas o implícitas.

BLOQUEOS

Abra una nueva consulta. Use la base de datos Secretaria de Salud En una
nueva consulta ejecute sp_lock y revise los resultados.
Use la base de datos Secretaria de Salud En una nueva consulta ejecute
sp_lock y revise los resultados.

Abra informe de transacciones de bloqueo para verificar que no hay ningún

bloqueo activo. Clic derecho en su bd -> informe -> informe estándar ->
Todas las transacciones de bloqueo.
CONCURRENCIA, TRANSACCIONES, ACCESOS Y BLOQUEOS. MANEJO DE
JMETER

TIPOS DE CONCURRENCIA DE TRANSACCIONES

 Optimista: Deja realizar modificaciones de los datos y se persisten

(commitado). Cuando se van a persistir se verifica que no se han
modificado por otras transacciones simultáneamente; en cuyo caso produce
un error.
 Pesimista: Para los datos modificados, realizar un bloqueo de los mismos.
Impendiendo que otras transacciones realicen cambios de esos datos.

TIPOS DE NIVEL DE AISLAMIENTO DE TRANSACCIÓN

 READ UNCOMMITTED: Leen valores modificados por otras transacciones no

persistidos (commitados).
 READ COMMITTED: No dejan leer valores modificados por otras
transacciones no persisitidos (commitados). READ COMMITTED al releer
datos que se han comitado por otra transacción durante la ejecución de la
propia; obtiene valores diferentes.
 READ_COMMITTED_SNAPSHOT: Evita el problema del READ COMMITED.
Crea un estado en la base de datos; de esta manera la transacción lee los
datos referidos a ese estado. No impide que otras transacciones modifiquen
los datos leídos por la nuestra.
 REPEATABLE READ: Evita el problema del READ COMMITED. REPEATABLE
READ evita que otra transacción modifique los datos modificados por
 nuestra transacción. Dado que los datos leídos; pueden depender de lo
realizado en la otra transacción.
 SERIALIZABLE: REPEATABLE READ que además se extiende para
inserciones.

TRANSACCIONES EN SQL SERVER

En SQL Server el tipo de concurrencia es pesimista. El bloqueo se activa al

modificar los datos; no al leerlos. Si queremos activarlo en su lectura debemos
usar la cláusula WITH UPDLOCK.

SELECT * FROM TABLE WITH (UDPLOCK) WHERE ID = 1

El nivel del Aislamiento en SQL SERVER se indica con la instrucción SET

TRANSACTION ISOLATION LEVEL. Por defecto es READ COMMITTED.

En SQL SERVER cuando indicamos READ COMMITTED, puede ser READ

COMMITTED o READ COMMITED SNAPSHOT. Esto se determina en función de
la configuración de la base de datos:

 READ COMMITED SNAPSHOT: La base de datos se encuentra con la

configuración SET READ_COMMITTED_SNAPSHOT ON.
 READ COMMITTED: La base de datos se encuentra con la configuración
SET READ_COMMITTED_SNAPSHOT OFF.

En SQL AZURE solo existe READ COMMITTED SNAPSHOT. No se puede

desactivar con la configuración SET READ_COMMITTED_SNAPSHOT OFF.

TRANSACCIONES EN OTROS ENTORNOS

En Entity Framework, LINQ, DataSet,… el tipo de concurrencia es optimista.

En NHibernate, por defecto tiene concurrencia optimista. Pero se puede

habilitar concurrencia pesimista.

En general, se recomienda el uso del TransactionScope, para determinar el

nivel de aislamiento con TransactionScopeOption.
 RENDIMIENTO CON JMETER

Se ha permitido desarrollar una herramienta de análisis de resultados similar a

la que proporcionan las herramientas comerciales. Las principales ventajas que
aporta son:

 Permite generar un informe de pruebas de resultados de manera

automática sin necesidad de tratar los datos en hojas de cálculo.
 Permite estudiar de manera gráfica la relación de los diferentes
indicadores de las pruebas, generando automáticamente gráficas de
rendimiento.
Facilita la Identificación de los posibles puntos de saturación para
detectar "cuellos de botella".
 Desenmascara los posibles errores de la aplicación por la aplicación de
concurrencia.
 Permite recuperar de manera íntegra los resultados de pruebas
anteriores, o almacenarlos en un histórico para posibles comparaciones
de resultados.

El objetivo final es dotar al ingeniero de pruebas de una herramienta que

aumente su productividad, y también la capacidad de análisis para dotar de
mayor calidad las pruebas de rendimiento.

MANEJO DE TRANSACCIONES Y CONTROL DE CONCURRENCIA, JMETER -

PRÁCTICA

Para este laboratorio, se Utilizaron parámetros de configuración en el base de

datos, los cuales por motivo de facilidad y configuración de mi equipo pueden
diferir de los recomendados por el Tutor, por ello los detallo.

Nombre de la variable = sqlvariable

Transation isolation = TRANSATION_REPETEABLE_READ
URL BD = jdbc: sqlserver: //localhost:1433;databaseName=SecSalud
Query de validación = Select 1
JDBC clase Driver = com.microsoft.sqlserver.jdbc.SQLServerDriver
Usuario = servidor
Password = *******
Primero damos un nombre al Plan de Prueba y agregamos el conector JDBC

Luego se define el grupo de hilos a trabajar o usuarios a concurrir:

Luego se define la conexión con el controlador JDBC, quien permitirá acceder
al SQL server:
Luego se define la conexión JDBC, se ingresan los parámetros de conexión a la
bases de datos SecSalud.

 Configuración que se utilizará = sqlvariable.

 Transation isolation = TRANSATION_REPETEABLE_READ
 Query de validacion = Select 1
 URL BD = jdbc:sqlserver://localhost:1433;databaseName=SecSalud
 JDBC clase Driver = com.microsoft.sqlserver.jdbc.SQLServerDriver
 Nombre de Usuario = servidor
 Contraseña = ******

Los otros campos en la pantalla se puede dejar con los valores

predeterminados.
A continuación se definen las peticiones a la base de datos y se agrega la
consulta
Luego se anexa el componente gráfico y el Reporte Resumen que permite
verificar varianza de datos y concurrencia.
Aquí damos clic en Play para ejecutar el Plan de Pruebas SecSalud y vemos
como el grafico comienza a tener cambios y ver los resultados de las
transacciones o consultas de forma graficas definida en los hilos de conexión.
Anexo el diagrama de rendimiento en el monitor de recursos del sistema
Anexo el monitor de rendimiento de SQL server en función, dentro del menú
performance tool, programas del Pack de instalación de SQL server, server
profile

Para más detalle en el Server Profile, Menú tools, performance monitor.

 CONCLUSIONES

Los límites de las transacciones de la base de datos o el sistema son siempre

necesarios. Ninguna comunicación con la base de datos puede darse fuera de
una transacción de la base de datos (esto parece confundir a muchos
desarrolladores acostumbrados al modo auto-commit). Siempre use límites de
transacción claros, incluso para las operaciones de sólo lectura. Dependiendo
del nivel de aislamiento y las capacidades de la base de datos, esto podría
requerirse o no, pero no hay inconvenientes si siempre demarca explícitamente
las transacciones. Con seguridad, una transacción única de base de datos va a
funcionar mejor que muchas transacciones pequeñas, inclusive para leer datos.
 BIBLIOGRAFÍA

http://basesdedatosatope.blogspot.com.co/2013/04/estrategias-para-el-
control-de.html

https://unpocodejava.wordpress.com/2011/01/10/tecnicas-de-bloqueo-sobre-
base-de-datos-bloqueo-pesimista-y-bloqueo-optimista/

https://grimpidev.wordpress.com/2011/02/08/control-de-concurrencia-
multiversion-mvcc/

https://msdn.microsoft.com/es-es/library/jj856598%28v=sql.120%29.aspx

http://www.monografias.com/trabajos96/manejo-transacciones/manejo-
transacciones.shtml

http://copro.com.ar/Aislamiento_%28sistemas_de_base_de_datos%29.html

http://www.programandoamedianoche.com/2009/04/transacciones-y-modos-
de-aislamiento-en-sql-server-y-adonet/

http://es.slideshare.net/dantoniocruz/transacciones-27511077

https://msdn.microsoft.com/es-es/library/ms188929%28v=sql.120%29.aspx

http://www.devjoker.com/contenidos/catss/292/Transacciones-en-Transact-
SQL.aspx

http://www.campusmvp.es/recursos/post/Fundamentos-de-SQL-
Transacciones.aspx

https://msdn.microsoft.com/es-es/library/ms187749%28v=sql.120%29.aspx

http://www.forosdelweb.com/f87/concurrencia-sql-server-519836/

https://www.fdi.ucm.es/profesor/fernan/DBD/apuntestema07.pdf

https://social.msdn.microsoft.com/Forums/es-ES/e785b566-aa9e-4765-8574-
4bf83af65374/control-de-concurrencia?forum=vcses

http://ell-jh-sena.blogspot.com.co/