SQL en acción Introducción: comprensión del desbloqueo

Comprensión del desbloqueo

La simultaneidad es uno de los problemas más importantes en entornos multiusuario. Cuando varias sesiones leen o escriben datos en recursos disfrutados, los datos pueden perderse. su integridad. Todos los RDBMS (incluido Microsoft Access) implementan algunos mecanismos sofisticados de gestión de concurrencia. Aunque el estándar SQL establece el bloqueo de cursores, el bloqueo no es parte de SQL ni del estándar (un cursor es una estructura especial que accede a los datos fila por fila).

El mecanismo de bloqueo de Oracle es probablemente el más avanzado y complejo. La regla que sigue es que los procesos de lectura y escritura no pueden bloquearse entre sí, incluso si acceden al mismo (o casi al mismo) conjunto de datos. En Oracle, cada sesión recibe una instantánea de los datos consistente con la lectura, por lo que incluso si otro proceso ha comenzado a modificar los datos en el conjunto de datos, cada sesión posterior aún puede leer los datos originales de la instantánea siempre que no confirme esas modificaciones. . datos. Una vez que la primera sesión confirma los cambios, otras sesiones también verán los datos modificados. Los bloqueos solo son necesarios cuando se realizan cambios en la base de datos. Oracle selecciona automáticamente el bloqueo menos restrictivo o el usuario puede optar por bloquear recursos manualmente (como tablas). Tanto IBM DB como Microsoft SQL Server utilizan bloqueos. Los bloqueos en ambas bases de datos permiten que las lecturas bloqueen las escrituras o las escrituras para bloquear las lecturas. La granularidad de los bloqueos (es decir, bloqueos de tabla, bloqueos de página, bloqueos de columna o bloqueos de fila) alivia hasta cierto punto el problema del acceso simultáneo a los datos. En la gran mayoría de los casos, los usuarios no necesitan preocuparse por las cerraduras. El RDBMS selecciona automáticamente el bloqueo (o bloqueos) más apropiado para una operación determinada, y solo en el caso de una falla lógica en el programa es necesario declarar el bloqueo manualmente mediante una declaración SQL. Se basa en el motor de almacenamiento transaccional InnoDB (o IBMDB I) con soporte adicional para bloqueo a nivel de fila y soporte de transacciones. Soporte de bloqueo y transacciones PostgreSQL tiene potentes mecanismos de bloqueo a nivel de tabla y de fila, cada uno con buena granularidad

Modo de bloqueo

El modo concurrente se puede dividir en dos categorías amplias, optimista y pesimista, estos dos términos se explican por sí solos. El modelo de concurrencia optimista supone que las transacciones no son transacciones. Cuando varias transacciones trabajan en el mismo conjunto de datos, es poco probable que se produzcan conflictos de recursos (aunque los conflictos son posibles, cualquier problema potencial se dejará en manos de la base de datos para resolverlo). Las transacciones optimistas verifican posibles conflictos al confirmar cambios en la base de datos y resuelven los conflictos volviendo a enviar los datos (en este caso, la última confirmación tiene prioridad). El patrón de concurrencia pesimista supone que los conflictos existen desde el principio y los bloquea de cualquier intento de utilizar el conjunto de datos. Normalmente, RDBMS admite concurrencia optimista y pesimista y, a veces, los usuarios pueden especificar que las transacciones utilicen uno de estos modos de concurrencia. La concurrencia pesimista proporciona una mejor coherencia a expensas del rendimiento.

La granularidad de los bloqueos puede tener un impacto significativo en el rendimiento de un sistema de base de datos. El bloqueo a nivel de fila puede mejorar la concurrencia (no impide que otras transacciones accedan a la tabla), pero a menudo también crea un exceso. sobrecarga administrativa, que reduce el rendimiento de la base de datos. El bloqueo completo de la tabla tiene una pequeña sobrecarga en los recursos del sistema, pero el precio es una reducción de la simultaneidad y el rendimiento. Problema

Los bloqueos se utilizan para implementar transacciones en modo de concurrencia pesimista. Cada RDBMS tiene sus propios niveles de bloqueo, pero todos son similares. Dependiendo de cómo se utilicen los recursos, generalmente se clasifican como bloqueos de disfrute o bloqueos exclusivos

Por ejemplo, la siguiente declaración bloquea la tabla LIBROS en la base de datos BIBLIOTECA en modo exclusivo

BLOQUEAR los libros de la TABLA EN MODO EXCLUSIVO;

La transacción que emite esta declaración intentará bloquear la tabla en modo exclusivo pero permitirá que se ejecuten las declaraciones SELECT. Si cualquier otro proceso bloquea la tabla, la transacción se coloca en la cola y adquiere el bloqueo cuando obtiene prioridad, que se mantiene durante la transacción (hasta que se ejecuta la declaración MIT). La sintaxis real de esta declaración puede variar en diferentes RDBMS, pero no significativamente.

El mecanismo de bloqueo también presenta un problema potencial.

Se produce un punto muerto si una transacción que ya tiene un bloqueo en una tabla intenta adquirir un bloqueo en otro recurso que ya está bloqueado por la segunda transacción (consulte la siguiente sección)

Algunas bases de datos (especialmente Microsoft SQL Server) no están diseñados para bloquearse. Algunas bases de datos (en particular, Microsoft SQL Server e IBM DB) implementan un mecanismo llamado "eliminación de bloqueos", un término que se refiere a convertir muchos bloqueos de grano fino en bloqueos de alto nivel más gruesos para reducir la sobrecarga de administración de bloqueos del sistema Oracle g. /g quiere lograr una mejor simultaneidad en los recursos del sistema y, por lo tanto, nunca libera el bloqueo. Además, MySQL (que utiliza el motor de almacenamiento InnoDB) y PostgreSQL no admiten el bloqueo.

Todos los bloqueos están determinados por el RDBMS (no configurable por el usuario). El bloqueo predeterminado es un bloqueo a nivel de fila. el nivel de bloqueo se puede aumentar mediante un bloqueo a nivel de fila. Es un bloqueo a nivel de tabla. El nivel de bloqueo se puede aumentar mediante la instrucción LOCKTABLE anterior, y el umbral de bloqueo lo configura el DBA

Oracle. g/g no admite bloqueos de alta granularidad porque espera que los recursos del sistema tengan una mejor simultaneidad.

Los bloqueos de alta granularidad (es decir, bloqueos a nivel de fila) tienen un costo porque SQL Server necesita asignar más recursos para las operaciones de bloqueo a nivel de fila, lo que reduce el costo del rendimiento de SQL Server y aumenta las posibilidades. de interbloqueo

Para obtener una comparación de los diferentes tipos de bloqueos admitidos por varios RDBMS, consulte el sitio web del libro wrox o visite agilitator

Procesamiento de interbloqueo

Un punto muerto generalmente ocurre cuando dos (o más) sesiones están esperando adquirir un bloqueo en un recurso disfrutado, pero debido a que la primera sesión La sesión tiene un bloqueo en el recurso solicitado por la sesión, y la segunda sesión también tiene un bloqueo en otro recurso solicitado por la primera sesión, por lo que ninguna sesión puede continuar.

Normalmente, los RDBMS resuelven los problemas de interbloqueo de esta manera: matan automáticamente uno de los procesos y revierten cualquier operación que haya realizado.

Oracle implementa la resolución de interbloqueos eliminando automáticamente un proceso y deshaciendo todas las operaciones que ha realizado.

Oracle implementa un mecanismo complejo para hacer cumplir la regla de que los procesos de lectura y escritura no deben bloquearse entre sí. La idea detrás de esta regla es proporcionar a cada proceso una imagen consistente de los datos que no contenga cambios no confirmados, pero a pesar de esto, aún pueden ocurrir interbloqueos en Oracle y dependerá del RDBMS resolver el interbloqueo manualmente y allí. Hay casos raros en los que esto es necesario. Los tipos más comunes de interbloqueos son ORA (interbloqueo de cola) y ORA (interbloqueo de caché de biblioteca), que pueden evitarse declarando una cláusula NOWAIT o estableciendo un tiempo de espera de sesión. Además, existen muchas otras técnicas que se pueden utilizar para evitar interbloqueos, como el bloqueo explícito y los niveles de aislamiento de transacciones, que se pueden resolver manualmente a través de la interfaz de Oracle. DB ejecuta un detector de interbloqueos de procesos en segundo plano para detectar y resolver interbloqueos. Las sesiones seleccionadas como víctimas de interbloqueo se revertirán y se generará un error especial (SQLCODE SQLSTATE). IBM recomienda utilizar herramientas de monitoreo del sistema para recopilar información sobre situaciones de interbloqueo, ya sea optimizando el sistema o rediseñando la aplicación que causa el interbloqueo.

Microsoft SQL Server utiliza un algoritmo patentado de detección de interbloqueos que los resuelve de una manera similar a la que se encuentra en otros RDBMS.

Manejo de interbloqueos automáticamente Los usuarios también pueden manejar interbloqueos manualmente a través de la consola de Enterprise Manager configurando el parámetro DEADLOCK_PRIORITY en la sesión, y Microsoft SQL Server puede encontrar sesiones que sean víctimas voluntarias de interbloqueos (consulte la discusión sobre sesiones anteriormente en este capítulo)

PostgreSQL y MySQL intentan resolver interbloqueos abortando una de las transacciones competidoras

En resumen, las mejores prácticas para evitar interbloqueos incluyen ejecutar transacciones más pequeñas primero, lo más rápido posible. Ejecutar el comando de confirmación, reconstruir el lógica de la tabla de acceso, reducir el uso de comandos de bloqueo explícitos, etc.

? Volver al directorio de operaciones para principiantes de SQL

?Recomendación del editor

?Oracle tecnología de índice

?MySQL de alto rendimiento lishixinzhi/Article/program/SQL/201311/16446 ?