LABORATORIO 10. Concurrencia y bloqueos en el SMBD Oracle

Transcripción

1 LABORATORIO 10. Concurrencia y bloqueos en el SMBD Oracle 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.

2 Estructura de contenidos. 1. Introducción Objetivos Consideraciones Procedimiento Manejo de Transacciones Bloqueos Uso de la cláusula FOR UPDATE para el Bloqueo de recursos Conflictos de Bloqueo JMeter Evidencias a entregar

3 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 SQL Server 2008 R2 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

4 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 Oracle. Objetivos Específicos. Reconocer las herramientas que son útiles para la supervisión de transacciones y bloqueos en el SMBD Oracle. Utilizar las herramientas de supervisión para monitorear el comportamiento de las transacciones y bloqueos en el SMBD Oracle. Administrar los recursos utilizados por las transacciones y bloqueos para mantener disponible los servicios de la base de datos Oracle. 4

5 3. Consideraciones. Antes de realizar los procedimientos planteados en este laboratorio, se sugiere revisar los siguientes aspectos: Ítem Soporte Teórico 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. Productos requeridos 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. Herramientas SW Se requiere tener instaladas y configuradas las siguientes herramientas para desarrollar este laboratorio. Máquina virtual proporcionada en la plataforma, con el SMBD Oracle instalado. Apache Jmeter, el enlace de descarga se encuentra en el manual suministrado en la carpeta del laboratorio. JDBC de Oracle para la configuración del Apache Jmeter. 5

6 4. Procedimiento. El laboratorio está compuesto por tres partes fundamentales que permitirán abordar los principales aspectos que deben ser tenidos en cuenta para realizar un adecuado tratamiento de los procesos concurrentes y los bloqueos que estos generan. Las actividades que se van a realizar son ejercicios prácticos para el manejo de las transacciones y bloqueos. Se debe entregar el código generado por el aprendiz para evidenciar la práctica del laboratorio Manejo de Transacciones Para el manejo de transacciones en Oracle se utilizan los siguientes comandos: Commit : Este comando da por finalizada la transacción actual y hace definitivos los cambios realizados. Las filas que estuviesen bloqueadas se liberan. Rollback: Este comando da por finalizada la transacción actual y deshace los cambios que se pudiesen haber producido en la misma, liberando las filas bloqueadas. Savepoint: Se utiliza para poner marcas en ciertos puntos para deshacer transacciones hasta el punto especifico que ha sido marcado, solo se pueden tener cinco puntos por sesión. Rollback implicito : Este comando se ejecuta cuando se produce una falla en un programa almacenado (procedimiento o función) y no se controla la excepción. En caso que existiese un commit al interior, los cambios no se desharían. Rollback to : Deshace el trabajo realizado después del punto marcado. La transacción no finaliza hasta que se ejecuta un comando de control de transacciones (commit o rollback) o hasta que finaliza la sesión Abra la máquina virtual donde tiene instalado Oracle y ejecute el SQLDeveloper, conectarse a la base de datos de la Secretaria de salud nombre Salud. 6

7 Elaborar 2 transacciones diferentes insertando, actualizando o eliminando registro de esta base de datos, todas estas transacciones deben quedar abiertas, tomar impresiones de pantalla de las consultas y copiar el código de las 2 transacciones como evidencia Abrir una sesión nueva en Oracle y escribir el comando COMMIT y verificar de nuevo la cantidad de transacciones activas y determinar que hace este comando en la base de datos SecSalud. Qué sucede al hacer una consulta de todos los datos de la tabla eps si anteriormente se ejecuta el siguiente comando?. SAVEPOINT UNO; INSERT INTO EPS (ideps, nombre, estadoeps) VALUES (15, confisena,1); Para la cancelación de la transacción anterior qué comando se debe utilizar? Que le falta a la siguiente transacción para que se efectúen los cambios en la tabla EPS pero no en la tabla persona de la base de datos de la Secretaria de Salud? 4.2. Bloqueos Debido a que el acceso simultáneo a los datos de una misma fila por parte de varios usuarios es una actividad constante, se debe establecer el orden en que estos acceden a ellos, es por esto que en Oracle se utilizan dos tipos de Bloqueo, Bloqueo Compartido y Bloqueo exclusivo, para entender mejor este concepto se desarrollaran algunas operaciones a continuación Uso de la cláusula FOR UPDATE para el Bloqueo de recursos. Abra dos sesiones en el ORACLE SQL Developer, una para el usuario sys y otra para el usuario SecSalud. Construya un nuevo usuario para la base de datos de la secretaría de Salud, denominado Usuario2_SALUD, para esto utilice la sentencia como se aprecia en la imagen 1. No olvide asignarle permisos para crear la sesión. Grant create session o to USUARIO2_SALUD 7

8 Imagen 1. Creación de usuario para la práctica. Desde el usuario SALUD se van a bloquear de forma exclusiva las filas de la tabla Persona, añadiendo la cláusula FOR UPDATE la final de la sentencia SELECT, para esto escriba la siguiente sentencia: SELECT * FROM historialpersona FOR UPDATE; Imagen 2. Bloqueo exclusivo de la tabla con la cláusula FOR UPDATE. Ahora desde la sesión 2, se intentará acceder a los datos de la tabla que ha sido bloqueada, normalmente entraría en cola hasta que el recurso fuera liberado o el usuario cancelara la petición como se observa en la imagen 3. 8

9 Imagen 3. No se tiene acceso a los datos para modificación. Para esta práctica se añadirá la cláusula FOR UPDATE NO WAIT a una consulta para que informe si el recurso esta bloqueado y no quede en cola de espera, como se aprecia en la imagen 4. Imagen 4. Mensaje de error, recurso bloqueado Se puede especificar un tiempo después del cual no se esperará más por el recurso y se generara el mensaje de error, para esto se especificara 9

10 WAIT (en lugar de NOWAIT) junto con el número de segundos que debe esperar por el recurso. Imagen 5. Especificación de tiempo de espera. Para verificar el comportamiento del bloqueo una vez que el recurso este liberado, ejecutar en la sesión 2 una consulta con tiempo de espera de un minuto, proceder a realizar la modificación sobre los datos en la sesión 1, confirmando la transacción para liberar el recurso. Simultáneamente la tabla queda disponible y en la sesión 2 se presentan los resultados antes del tiempo de espera. Imagen 6. Proceso de liberación del bloqueo. 10

11 Conflictos de Bloqueo Los conflictos de bloqueo se presentan cuando una sesión se queda en espera para poder bloquear una fila o tabla, porque otra sesión la tiene en bloqueo exclusivo. Para evitar el bloquear un recurso, se recomienda utilizar la sentencia SET TRANSACTION READ ONLY, la cual garantiza que la sesión no vera ningún cambio reflejado por otras sesiones hasta que no finalice la transacción actual con un COMMIT o ROLLBACK. Sin embargo cuando se establece un bloqueo y el tiempo de espera parece indicar un posible error en la sesión propietaria del bloqueo, es posible terminar la sesión que esta causando el bloqueo a través del comando ALTER SYSTEM KILL SESSION. Para identificar las acciones que se pueden realizar para resolver conflictos de bloqueo, realizar las siguientes operaciones: Ejecutar una sentencia en la sesión salud que bloquee para actualización a la tabla Persona de la Base de datos Salud: SELECT * FROM persona FOR UPDATE; Ejecutar una sentencia en la sesión 2 el mismo bloqueo pero agregando un tiempo de espera máximo de dos minutos: SELECT * FROM persona FOR UPDATE WAIT 120; La ejecución de esta consulta queda en espera. Diríjase al Enterprise Manager (em) y en la ficha Rendimiento ubique el enlace bloqueo de Instancia al final de la página. Imagen 7. Enterprise Manager información de Instancias. 11

12 Observe que se debe visualizar en la lista la sesión que tiene un bloqueo bloqueante, presenta información adicional sobre las sesiones y los procesos que se encuentran en bloqueo. Imagen 8. Información de los Bloqueos bloqueantes. A continuación mate la sesión que tiene un bloqueo bloqueante con el botón correspondiente, en la confirmación se puede especificar que se realice de inmediato con lo cual se deshacen las transacciones no confirmadas o se puede esperar a que la sesión termine la transacción actual confirmándola. Imagen 9. Confirmación y opciones de terminación de la sesión. Cuál es la sentencia SQL que ejecuta este proceso? Al retornar al SQL Developer la sesión que estaba bloqueada, ya se encuentra normalizada. 12

13 Qué ocurre al tratar de ejecutar una sentencia en la primera sesión? Qué Tipo de bloqueo se genera cuando se ejecutan sentencias DDL y cuál con sentencias DML? 4.3. 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 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 13

14 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. 14

15 Plan de prueba Nº Nº de hilos Periodo de subida en (s) Nº de peticiones No. de muestras Desviación Rendimiento /Minuto Media Mediana 15

16 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 16

17 afectado su trabajo, es por eso que se debe presentar en el informe 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. 17