LABORATORIO 10. Concurrencia y bloqueos en el SMBD Postgre SQL

LABORATORIO 10. Concurrencia y bloqueos en el SMBD Postgre SQL GUÍA DE LABORATORIO Nº 10 Actividad de Proyecto No. 5: Desarrollar mantenimiento preventivo, correctivo o proactivo para garantizar niveles de servicio requeridos por la organización.

Estructura de contenidos. 1. Introducción...3 2. Objetivos...4 3. Consideraciones...5 4. Procedimiento...6 4.1. Herramientas del SMBD PostgreSQL...6 4.1.1. Server Status...6 4.1.2. Control del comportamiento de las transacciones y bloqueos desde la herramienta Server Status...7 4.2. Gestión de transacciones en el SMBD PostgreSQL...7 4.2.1. Creación de transacciones en el SMBD PostgreSQL...7 4.2.2. Deshacer transacciones en el SMBD PostgreSQL...8 4.2.3. Consulta de la información de las transacciones en SMBD PostgreSQL...11 4.3. Gestión de bloqueos...12 4.3.1. Afinamiento del SMBD PostgreSQL para el control de bloqueos:...12 4.4. Tipos de Bloqueos...14 4.4.1. Bloqueos a nivel de tabla...14 4.4.2. Bloqueos a nivel de fila...18 4.5. JMeter...21 5. Evidencias a entregar...24 2

1. Introducción. En este laboratorio se realizaran actividades en las que se aborda situaciones problemáticas que le ayudaran al administrador de bases de datos (DBA) a desarrollar habilidades que le permitan realizar un control adecuado sobre la concurrencia y bloqueos en la base de datos. Los DBA tienen la responsabilidad de mantener disponibles los servicios que presta la base de datos, para ello deben controlar el comportamiento de los procesos que acceden de forma concurrente sobre datos compartidos y los bloqueos que estos generan sobre los mismos. 3

2. Objetivos. Objetivo General. Supervisar y realizar ajustes sobre los parámetros que permiten controlar el comportamiento de los procesos concurrentes y bloqueos, con el fin de mantener disponible la base de datos y optimizar el desempeño del SMBD PostgreSQL. Objetivos Específicos. Identificar las herramientas que son útiles para la supervisión de transacciones y bloqueos en el SMBD PostgreSQL. Utilizar las herramientas de supervisión para monitorear el comportamiento de las transacciones y bloqueos en el SMBD PostgreSQL. Administrar los recursos utilizados por las transacciones y bloqueos para mantener disponible los servicios de la base de datos. 4

3. Consideraciones. Antes de realizar los procedimientos planteados en este laboratorio, se sugiere revisar los siguientes aspectos: Ítem Soporte Teórico Productos requeridos Herramientas SW Descripción Previo al desarrollo de este laboratorio debe haber revisado el objeto de aprendizaje Concurrencia, transacciones, accesos y bloqueos. También el Manual de Instalación y ejecución de Apache Jmetter. Manejo de sentencias SQL. El aprendiz antes de comenzar a realizar este laboratorio debe tener los siguientes productos: Base de datos de la Secretaria de salud de la alcaldía de San Antonio del SENA o en su defecto el script de construcción de esta base de datos. Script de consultas suministrado, para ejecutar en el Apache Jmeter. Se requiere tener instaladas y configuradas las siguientes herramientas para desarrollar este laboratorio. Maquina virtual proporcionada en la plataforma, con el SMBD PostgreSQL instalado. Apache Jmeter, el enlace de descarga se encuentra en el manual suministrado en la carpeta del laboratorio. JDBC de PostgreSQL para la configuración del Apache Jmeter. 5

4. Procedimiento. 4.1. Herramientas del SMBD PostgreSQL. 4.1.1. Server Status. Ingrese al administrador gráfico pgadmin3 de PostgreSQL y conéctese a la base de datos secsalud, verifique que esta se encuentra correctamente creada. En el explorador de objetos de la ventana principal del pgadmin3 seleccione la base de datos de la secsalud, posteriormente diríjase al menú tools y seleccione la opción Server Status. La ventana principal de la herramienta Server Status esta dividida en cuatro secciones en las que Locks y Prepared Transactions suministran información importante para la administración de bloqueos y transacciones en PostgreSQL. La sección Locks suministra información sobre los bloqueos que están activos en PostgreSQL. La sección Prepared Transactions suministra información sobre las transacciones activas en PostgreSQL. Minimice la ventana de la herramienta Server Status y abra una interfaz para ejecutar sentencias SQL, para ello pulse el botón que tiene de icono una lupa con la sigla SQL. Ilustración 1: Base de datos secsalud vista desde el pgadmin3 6

En la ventana que se carga, seleccione la pestaña SQL Editor y escriba la sentencia que aparece en la siguiente imagen, posteriormente pulse el botón Execute query para ejecutar la sentencia. Vuelva a la ventana del Server Status y pulse el botón Refresh que tiene el siguiente icono. Inmediatamente se visualizara en la sección Locks la información sobre los bloqueos que ha generado esta sentencia. Importante: Nótese que la transacción se ha dejado abierta intencionalmente para observar sus efectos sobre la tabla que esta accediendo. 4.1.2. Control del comportamiento de las transacciones y bloqueos desde la herramienta Server Status. En la ventana de la herramienta Server Status seleccione en la sección Locks los bloqueos que desea terminar, luego pulse el botón Terminate backend que tiene de icono la siguiente imagen. Mantenga la tecla Shift oprimida para seleccionar varios bloqueos o transacciones a la vez. 4.2. Gestión de transacciones en el SMBD PostgreSQL. Las transacciones es uno de los aspectos más importantes en el SMBD PostgreSQL puesto que permiten manejar la concurrencia asegurando la integridad de los datos y la consistencia de las operaciones realizadas aun cuando existan múltiples conexiones intentando acceder a la misma información. 4.2.1. Creación de transacciones en el SMBD PostgreSQL. Para crear una transacción se coloca el conjunto de operaciones SQL que queremos ejecutar como una unidad, dentro de las clausulas BEGIN TRANSACTION y COMMIT, la sintaxis es la siguiente:... operación 1... operación 2... operación 3 COMMIT; si las operaciones de la transacción son consistentes los cambios se confirman. 7

En el pgadmin3 abra una ventana del SQL Editor y consulte los registros de la tabla estadopersona, posteriormente ejecute la sentencia de la siguiente transacción desde otra ventana del SQL Editor : Sentencia No.1: SELECT * FROM estadopersona WHERE descripcion = Cesante FOR UPDATE; UPDATE estadopersona SET descripcion = En Mora WHERE descripcion = Cesante ; INSERT INTO estadopersona (descripcion) VALUES ( Registrado ); INSERT INTO estadopersona (descripcion) VALUES ( N/R ); COMMIT; Consulte de nuevo los registros de la tabla estadopersona e inmediatamente se visualizara que todos los cambios que se ordenaban con las operaciones escritas dentro de la transacción se realizaron correctamente. 4.2.2. Deshacer transacciones en el SMBD PostgreSQL. Las operaciones que están dentro de una transacción tienen la característica que al ejecutarse se completan todas o ninguna, para verificar esto realice una consulta sobre los registros de la tabla estadoeps posteriormente ejecute la sentencias de la siguiente transacción en una ventana del SQL Editor : Sentencia No.2: SELECT * FROM estadoeps WHERE idestadoeps=1 FOR UPDATE; UPDATE estadoeps SET descripcion = Operando WHERE descripcion = Activa ; SELECT * FROM estadoeps WHERE idestadoeps=2 FOR UPDATE; UPDATE estadoeps SET descripcion = Suspendida WHERE descripcion = Desactivada ; INSERT INTO estadoeps (idestadoeps, descripcion) VALUES (1, Prueba ); COMMIT; 8

Realice de nuevo la consulta sobre los registros de la tabla estadoeps y observe que ninguno de los cambios indicados por las operaciones que se encuentran dentro de la transacción se realizaron, debido a que la operación INSERT esta violando la llave primaria de la tabla, lo que produce que se reversen todas las operaciones de la transacción que se han ejecutado. Deshacer parte de los cambios de una transacción en el SMBD PostgreSQL En situaciones de concurrencia sobre una o varias tablas es necesario deshacer parte de los cambios realizados por las operaciones de una transacción, esto es posible utilizando la sentencia ROLLBACK, la sintaxis es la siguiente:... operación 1... operación 2 ROLLBACK; los cambios de las operaciones 1 y 2 no serán confirmadas porque causan problemas de consistencia o conflicto en los objetos que esta modificando en la base de datos.... operación 3 los cambios de esta operación se confirmaran en la base de datos COMMIT; La utilización del ROLLBACK dentro de una transacción solo tiene sentido en situaciones de concurrencia en las que se debe garantizar a los usuario el acceso y la modificación de los registros de forma consistente. Ejecute la siguiente transacción en una ventana del SQL Editor : Sentencia No.3: SELECT * FROM estadoeps WHERE idestadoeps=1 FOR UPDATE; UPDATE estadoeps SET descripcion = Operando WHERE descripcion = Activa ; INSERT INTO estadoeps (descripcion) VALUES ( N/R ); ROLLBACK; SELECT * FROM estadoeps WHERE idestadoeps=2 FOR UPDATE; UPDATE estadoeps SET descripcion = Suspendida 9

WHERE descripcion = Desactivada ; COMMIT; Posteriormente realice una consulta sobre la tabla estadoeps y observe que las operaciones UPDATE e INSERT que están antes del ROLLBACK no fueron confirmadas, mientras que los cambios indicados por la operación UPDATE que esta después del ROLLBACK fueron escritos correctamente en la tabla. Deshacer selectivamente los cambios de una transacción en el SMBD PostgreSQL Con la instrucción SAVEPOINT es posible controlar selectivamente los cambios que producen las operaciones de una transacción, esto debido a que permite anular operaciones especificas de una transacción cuando sucede un error y confirmar las que han sido procesadas correctamente, la sintaxis es la siguiente:... operaciones1 SAVEPOINT retorno;... operaciones2 ROLLBACK TO retorno;... operaciones3 COMMIT; Ejecute la siguiente transacción en una ventana del SQL Editor : Sentencia No.4: --Creamos una nueva transacción --Agregamos un nuevo servicio INSERT INTO tiposervicio (descripcion) VALUES ( Oncologia ); --Agregamos una nueva eps y definimos un primer punto de retorno SAVEPOINT retorno1; INSERT INTO eps (nombre, estadoeps) VALUES ( SANITAS,1); --El nombre de la eps ingresada es COLSANITAS y no SANI- TAS esta ya existe en la base de datos, por tanto usamos el retorno1 para deshacer la operación INSERT. ROLLBACK TO retorno1; --Ingresamos el nombre de la eps como es correcto. 10

INSERT INTO eps (nombre, estadoeps) VALUES ( COLSANITAS,1); --Finalmente agregamos el servicio de oncología a las EPS que lo prestan INSERT INTO servicioeps VALUES (1,11, A,300000, Unidad de medicina especializada ); INSERT INTO servicioeps VALUES (4,11, A,250000, Unidad de medicina especializada ); COMMIT; Verifique los cambios realizando una consulta sobre las tablas que intervienen en la transacción. 4.2.3. Consulta de la información de las transacciones en SMBD PostgreSQL. 4.2.3.1. Información de transacciones almacenada en el catalogo del sistema. En una ventana del SQL Editor escriba y ejecute la siguiente transacción: Sentencia No.5: SELECT * FROM estadoeps WHERE idestadoeps=1 FOR UPDATE; UPDATE estadoeps SET descripcion = En Operacion WHERE descripcion = Activa ; SAVEPOINT retorno; INSERT INTO estadoeps (descripcion) VALUES ( N/R ); ROLLBACK TO retorno; INSERT INTO estadoeps (descripcion) VALUES ( No Registra ); Nota: Observe que la transacción no se ha confirmado sin COMMIT intencionalmente para que podamos visualizar sus datos consultado el catalogo del sistema. En otra ventana del SQL Editor escriba y ejecute la siguiente consulta: Sentencia No.6: select * from pg_stat_activity psa RIGHT JOIN pg_stat_database psd USING(datid); 11

Posteriormente en la pestaña Data Output identifique la fila que contiene la información correspondiente a la transacción que acabamos de ejecutar e interprete los campos y datos arrojados en cada uno de ellos. En la siguiente captura de pantalla se muestra el resultado de este procedimiento. Ilustración 2: Resultado de ejecutar la Sentencia No.6 4.2.3.2. Funciones de acceso a información de transacciones. El SMBD PosgreSQL proporciona las siguientes funciones de acceso a estadísticas que permiten establecer información sobre la cantidad de transacciones completadas y abortadas en el sistema: pg_stat_get_db_xact_commit(oid): Cantidad de transacciones completas (COMMIT) pg_stat_get_db_xact_rollback(oid): Cantidad de transacciones abortadas (ROLLBACK) Consulte y explique el funcionamiento de cada una de estas funciones y realice un ejemplo. 4.3. Gestión de bloqueos. 4.3.1. Afinamiento del SMBD PostgreSQL para el control de bloqueos 1 : 4.3.1.1. Edición de parámetros que controlan los bloqueos 1 http://www.postgresql.org/docs/8.1/static/runtime-config-locks.html 12

Abra el archivo de configuración postgres.sql y modifique los siguientes parámetros como se indica a continuación, recuerde que estos definen el comportamiento de los bloqueos en el SMBD PostgreSQL: deadlock_timeout: tiempo que el servidor espera para comprobar si hay una condición de interbloqueo o punto muerto. Defina este parámetro en 800 milisegundos. max_locks_per_transaction: indica un valor medio máximo para la cantidad de bloqueos que admitirá la tabla de bloqueos compartidos. Defina este parámetro en 32. Investigue cual es un óptimo para este parámetro? max_connections: determina el numero máximo de conexiones concurrentes al servidor de base de datos. Se encuentra ubicado en la sección CONNECTIONS AND AUTHENTICATION. Establezca este parámetro en 1000 para este laboratorio max_prepared_trasaction: establece el numero máximo de transacciones que pueden prepararse simultáneamente en el SMBD. Se encuentra ubicado en la sección RESOURCE USAGE dentro del archivo postgres.sql. Defina este parámetro en 5 para este laboratorio. Entregue como evidencia el archivo postgres.sql con las modificaciones indicadas anteriormente. 4.3.1.2. Calculo del tamaño de la tabla de bloqueos en el SMBD. Con la siguiente formula se calcula la cantidad de ranuras que tendrá la tabla de bloqueos: = max_locks_per_transactions * (max_connections + max_prepared_transactions) = 32 * ( 5 + 10 ) = 480 Cada bloqueo en la tabla de bloqueos ocupa un espacio de 270 bytes de memoria por lo que debemos realizar la siguiente operación para establecer el tamaño de la tabla en MB = 480 * 270 bytes = 129600 bytes / 1024 = 126 MB Calcule el tamaño de la tabla de bloqueos compartidos en MB teniendo en cuenta los siguientes datos para cada parámetro 13

max_locks_per_transactions: valor óptimo de este parámetro consultado por usted max_connections: 100 max_prepared_trasaction: 5 Anexe al informe de evidencias el procedimiento que utilizo para calcular el tamaño de la tabla compartida. 4.4. Tipos de Bloqueos 2. Existen varios modos de bloqueos en PostgreSQL para controlar el acceso concurrente a los datos en tablas y filas, algunos de los bloqueos se adquieren automáticamente antes de la ejecución de una sentencia o inmediatamente después de que un registro sea extraído de una la fila, otros se proporcionan para que sean usados por las aplicaciones. 4.4.1. Bloqueos a nivel de tabla. En el SMBD PostgreSQL existen siete tipos de bloqueos a nivel de tabla a continuación se presenta un ejemplo de cada uno de ellos. Escriba y ejecute en una ventana del SQL Editor cada una de las siguientes sentencias, posteriormente abra el Server Status y verifique el tipo de bloqueo en la sección Locks. No olvide pulsar el botón Refresh cada vez que ejecute una nueva sentencia para que muestre los datos del bloqueos que se genero. AccessShareLock: lo adquieren automáticamente las tablas que están siendo consultadas y se libera después de que se haya ejecutado la sentencia. Sentencia No.7: SELECT * FROM historialpersona; 2 Alarcón Medina José Manuel. (2006) Administración del SGBD PostgreSQL. Capitulo 10.4 y 10.5 14

Ilustración 3: Resultado de ejecutar la Sentencia No.7 RowShareLock: lo adquieren las sentencias SELECT FOR UPDATE ó LOCK TABLE para declaraciones IN ROW SHARE MODE. Sentencia No.8: SELECT * from historialpersona WHERE idpersona = 6611537 FOR UPDATE; Sentencia No.9: Ilustración 4: Resultado de ejecutar la Sentencia No.8 LOCK TABLE historialpersona IN ROW SHARE MODE; Ilustración 5: Resultado de ejecutar la Sentencia No.9 RowExclusiveLock: lo adquieren las sentencias UPDATE, DELETE, INSERT y LOCK TABLE para declaraciones IN ROW EXCLUSIVE MODE. Sentencia No.10: UPDATE historialpersona SET estadopersona = 1, ideps =6 WHERE idpersona = 6611537; 15

Sentencia No.11: Ilustración 6: Resultado de ejecutar la Sentencia No.10 LOCK TABLE historialpersona IN ROW EXCLUSIVE MODE; Ilustración 7: Resultado de ejecutar la Sentencia No.11 ShareLock: permite a otras transacciones leer la misma información pero no escribir sobre ella, lo adquieren las sentencias CREATE INDEX y LOCK TABLE para declaraciones IN SHARE MODE. Sentencia No.12: CREATE INDEX indice ON historialpersona (idpersona); Sentencia No.13: Ilustración 8: Resultado de ejecutar la Sentencia No.12 LOCK TABLE historialpersona IN SHARE MODE; Ilustración 9: Resultado de ejecutar la Sentencia No.13 16

ExclusiveLock: evita que otros puedan leer y escribir, lo adquieren las sentencias LOCK TABLE para declaraciones IN EXCLUSIVE MODE, puede bloquear la sentencia SELECT (sin FOR UPDATE). Sentencia No.14: LOCK TABLE historialpersona IN EXCLUSIVE MODE; Ilustración 10: Resultado de ejecutar la Sentencia No.14 ShareRowExclusiveLock: lo adquieren las sentencias LOCK TABLE para declaraciones IN SHARE ROW EXCLUSIVE MODE. Presenta conflictos con los bloqueos RowExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock y AccessExclusiveLock. Sentencia No.15: LOCK TABLE historialpersona IN SHARE ROW EXCLUSIVE MODE; Ilustración 11: Resultado de ejecutar la Sentencia No.15 AccessExclusiveLock: lo adquieren las sentencias ALTER TABLE, DROP TABLE, VACUUM y LOCK TABLE. Presenta conflictos con los bloqueos RowShareLock, RowExclusiveLock, ShareLock y ShareRowExclusiveLock. Sentencia No.16: ALTER TABLE historialpersona ADD COLUMN estado VARCHAR(10); Ilustración 12: Resultado de ejecutar la Sentencia No.16 17

4.4.2. Bloqueos a nivel de fila. Los bloqueos a nivel de fila pueden ser de dos tipos exclusivos o compartidos: Bloqueos exclusivos sobre filas. Los bloqueos exclusivos sobre una fila se producen automáticamente cuando se actualizan o eliminan sus campos y se mantienen hasta que la transacción termine o se cancele. Para obtener un bloqueo exclusivo sobre una fila se utiliza la sentencia SELECT FOR UPDATE. Ejecute la siguiente sentencia en una ventana del SQL Editor, la cual realiza una consulta que crea un bloqueo exclusivo sobre una fila de la tabla persona. Sentencia No.17: SELECT * FROM persona WHERE idpersona= 110763859 FOR UPDATE ; Posteriormente abra otra ventana de SQL Editor y ejecute la siguiente sentencia que intenta actualizar la fila que tiene un bloqueo exclusivo de la consulta anterior. Sentencia No.18: UPDATE persona SET tipoidentificacion = 1 WHERE idpersona = 110763859; En una nueva ventana de SQL Editor ejecute la siguiente sentencia que comprueba, que los datos de la fila bloqueada se encuentran disponibles solo para lectura. Sentencia No.19: SELECT * FROM persona WHERE idpersona= 110763859; Lo que sucede al ejecutar esta combinación de sentencias es que la primera consulta genera un bloqueo exclusivo sobre la fila con llave primaria 110763859 que impide realizar cualquier actualización del misma, hasta que esta no finalice o se cancele, sin embargo los datos 18

de la fila se mantienen disponibles para la consulta y bloqueados únicamente para escribir. La siguiente captura de pantalla del Server Status muestra la combinación de bloqueos que se genera sobre la base de datos cuando se ejecutan las sentencias 17, 18 y 19. Ilustración 13: Bloqueos que generan las sentencias No. 17, 18 y 19 vistos desde el Server Status Bloqueos compartidos sobre filas: Los bloqueos compartidos sobre una fila permiten que otras transacciones tengan el mismo tipo de bloqueo sobre la fila, pero impiden que otra transacción pueda obtener bloqueo exclusivo sobre la misma fila hasta que todos los bloqueos compartidos hallan finalizado. Para obtener un bloqueo compartido sobre una fila se utiliza la sentencia SELECT FOR SHARE. Ejecute la siguiente sentencia en una ventana del SQL Editor, la cual realiza una consulta que crea un bloqueo compartido sobre una fila de la tabla persona. Sentencia No.19: SELECT * FROM persona WHERE idpersona= 110763859 FOR SHARE; 19

Ilustración 14: Obtención de un bloqueo compartido Posteriormente abra otra ventana de SQL Editor y ejecute la siguiente sentencia que intenta obtener un bloqueo exclusivo sobre la misma fila de la sentencia anterior. Sentencia No.20: SELECT * FROM persona WHERE idpersona= 110763859 FOR UPDATE; Ilustración 15: Intento de obtención de un bloqueo absoluto En una nueva ventana de SQL Editor ejecute la siguiente sentencia con la cual se comprueba, que los datos de la fila bloqueada puede ser consultados obteniendo un bloqueo compartido sobre la misma. Sentencia No.21: SELECT * FROM persona WHERE idpersona= 110763859 FOR SHARE; Ilustración 16: Consulta del contenido de la fila bloqueada Lo que sucede al ejecutar esta combinación de sentencias es que la primera consulta genera un bloqueo compartido sobre la fila con llave primaria 20

110763859 que impide a cualquier otra sentencia obtener bloqueo exclusivo sobre la misma fila, hasta que todos los bloqueos compartidos existentes hayan finalizados. La siguiente captura de pantalla del Server Status muestra la combinación de bloqueos que se genera cuando ejecutamos las sentencias anteriores. Ilustración 17: Bloqueos generados por las Sentencias No. 19, 20 y 21 vistos desde el Server Status 4.5. JMeter. Ingrese al Apache Jmeter y cree un nuevo plan de pruebas que se denomine con su nombre y apellido nombre_apellido y que tenga por comentario Secretaria de salud. Posteriormente cree un grupo de hilos con una conexión a la base de datos secsalud y tres peticiones JBDC en las que utilice una de las siguientes consultas para cada solicitud. Consulta 1: Listado con el número de identificación, nombre y apellido de las personas, además del nombre de la EPS y la fecha de ingreso y salida. SELECT p.idpersona, p.nombre, p.apellido, e.nombre, h.fechaingreso, h.fecharetiro FROM persona p INNER JOIN historialpersona h on p.idpersona=h.idpersona INNER JOIN eps e on e.ideps=h.ideps ORDER BY p.apellido 21

Consulta 2: Listado en que se visualiza las EPS con el nombre de los servicios que presta y el costo de cada uno ellos. BEGIN; SELECT e.nombre, t.descripcion, s.detalle, s.valor FROM eps e INNER JOIN servicioeps s on e.ideps=s.ideps INNER JOIN tiposervicio t on s.idtiposervicio=t.idtiposervicio ORDER BY e.nombre COMMIT; Consulta 3: Listado con el número de identificación, nombre y apellido de las personas, además del tipo de afiliación que tiene. BEGIN; SELECT p.idpersona, p.nombre, p.apellido, t.descripcion FROM persona p INNER JOIN historialpersona h ON p.idpersona=h.idpersona INNER JOIN tipoafiliado t ON h.tipoafiliado=t.idtipoafiliado ORDER BY t.descripcion; COMMIT; Por ultimo cree un receptor gráfico de resultados y comience a variar los valores de entrada del plan de pruebas de acuerdo con la siguiente tabla. Ejecute cada plan de prueba y registre los datos que se solicitan en la tabla. Importante: Cuando este ejecutando cada plan de prueba mantenga las mismas condiciones en cuanto a hardware y aplicaciones en memoria, esto influye en la obtención de datos consistentes de la prueba. Realice un análisis de los datos registrados en la tabla en donde establezca la cantidad de usuarios concurrentes que puede atener el sistema computacional sin degradar su rendimiento. Analice cual es la mejor estrategia a seguir, frente a un posible aumento de usuarios en los limites en que el sistema comienza a comprometer su rendimiento. Algunas que puede considerar son: Limitar cantidad de usuarios concurrentes. Aumento de la capacidad del servidor. Aumento del tamaño de la tabla de bloqueos. 22

Plan de prueba Nº Nº de hilos Periodo de subida en (s) Nº de peticiones 1 10 10 5 2 25 10 5 3 50 10 5 4 100 10 5 5 250 10 5 6 500 10 5 7 1000 10 5 8 1500 10 5 9 2000 10 5 10 3000 10 5 11 4000 10 5 No. de muestras Desviación Rendimiento /Minuto Media Mediana 23

5. Evidencias a entregar. Informe que contenga los siguientes puntos: 1. Script con nueve (9) transacciones que definan sentencias SQL de tipo DML inherentes a las tablas de la base de datos de la secretaría de salud de la alcaldía San Antonio del Sena. Las tres (3) primeras transacciones reunirán cada una no menos de cinco (5) sentencias, que deberán ser confirmadas en su totalidad. Las siguientes tres (3) transacciones ejecutarán las acciones programadas y sin que sean confirmadas se deberán deshacer. Las transacciones restantes guardarán parcialmente el resultado de sus operaciones ante la presencia de errores que no permitan una ejecución completa. 2. Análisis de cuatro de las transacciones elaboradas en el punto anterior con el apoyo de las herramientas del SMBD Oracle, identificando los objetos que se bloquean, los tipos de bloqueos y los usuarios, transacciones o procesos causantes de estos bloqueos. 3. Apreciaciones del rendimiento de Oracle a través de la base de datos de la alcaldía evaluando el comportamiento del sistema a través de las simulaciones con el utilitario Apache Jmeter y las herramientas del SMBD. Este punto debe tratar situaciones como: Número de usuarios concurrentes hasta generar bloqueos en el sistema: en este punto usted debe verificar en qué momento el sistema se bloquea a causa de superar los límites por número de peticiones de usuarios procesadas en un mismo instante de tiempo. Se debe mostrar en el informe las capturas de pantallas que evidencian las acciones asociadas al plan de prueba con Jmeter modificando el número de usuarios y explicando por cada una el comportamiento derivado. Manifestaciones de bloqueos: en este ítem se debe documentar la forma como se muestran los bloqueos y los informes que genera Jmeter indicando la no respuesta del sistema. De acuerdo a lo convenido en los planes de prueba, presentar apreciaciones de cada una de las variables analizadas y el resultado obtenido. Qué acciones se pueden emprender una vez se producen bloqueos? Los bloqueos generan el aumento en los tiempos de respuesta del sistema, provocando inconformidad en los usuarios que pueden ver afectado su trabajo, es por eso que se debe presentar en el informe 24

las acciones de tipo preventivo y correctivo a seguir por el DBA de la Secretaría de Salud una vez se generan bloqueos, o en su defecto la forma de validar los mismos indicando el tiempo máximo que podría estar un usuario sin respuesta del sistema, manteniendo coherencia con los acuerdos de niveles de servicio establecidos. Limitar cantidad de usuarios: En este ítem del informe se debe presentar una política de manejo del sistema indicando a los usuarios lo que puede suceder si se superan los límites para recibir peticiones y entregar respuestas en un instante de tiempo determinado. De igual forma se requiere exponer con claridad los límites y las recomendaciones a usuarios finales. 25