Los siguientes cursos se derivan del aprendizaje MOOC; consulte el curso original: Principios y aplicaciones de bases de datos
Revisión de posgrado
DBMS garantiza la atomicidad, consistencia, aislamiento y continuidad de todas las transacciones en el sistema
El DBMS debe recuperarse de fallas de transacciones, fallas del sistema y fallas de medios.
Técnicas de recuperación más utilizadas: volcado de base de datos y registro de archivos de registro
Fundamentos de la recuperación: reconstrucción de una base de datos a partir de datos redundantes almacenados en copias de seguridad, archivos de registro y creación de reflejo de la base de datos
Técnicas comunes de recuperación
Recuperación de falla de transacción (UNDO)
Recuperación de falla del sistema (UNDO + REDO)
Recuperación de fallas de medios (recargar copia de seguridad y restaurar a un estado consistente + REDO)
Tecnología de punto de control técnico para mejorar la eficiencia de recuperación (
ØPuede mejorar la eficiencia de recuperación de la falla del sistema
ØHasta cierto punto, se puede mejorar la eficiencia del uso de copia de seguridad de volcado dinámico para la recuperación de fallas de medios)
Tecnología de espejo (la tecnología de espejo puede mejorar la eficiencia de recuperación de la falla de los medios)
asuntos
Una secuencia definida de operaciones de base de datos, estas operaciones se realizan todas o no se realiza ninguna, inseparables
Cuando se deben ejecutar varias declaraciones SQL como un todo para realizar sus funciones, se debe definir una transacción
Propósito: un programa que interactúa con la base de datos para mantener la consistencia del estado de la empresa y el estado de la base de datos.
Una transacción es una unidad lógica de trabajo para un sistema de base de datos.
definir negocios
comenzar la transacción
secuencia de instrucciones sql
commit #commit la transacción, todas las operaciones en la transacción se ejecutan con éxito
rollback #Revertir la transacción, la transacción se aborta, no puede continuar ejecutándose, la operación de actualización que se ha ejecutado se cancela y se restaura el estado original
begin transaction
update accounts set bal=bal-100 where accno='A'
update accounts set bal=bal+100 where accno='b'//转账业务
commit
//只有两种结果：要么提交；要么回滚
Características de la transacción ACID
Atomicidad: Atomicidad
- Todas las operaciones de base de datos de una transacción son inseparables
- Todas las operaciones se ejecutan o no se ejecutan
Consistencia: Consistencia
- El estado actual de la instancia de la base de datos es también el estado de la base de datos.
- La operación del usuario en la base de datos es de un estado a otro
- El estado inicial de la base de datos es consistente.
- Satisfacer las restricciones de integridad de la base de datos; reflejar las operaciones del usuario en la base de datos
- Responsabilidades básicas de un programador de aplicaciones; mantener la consistencia entre el estado de la empresa y el estado de la base de datos
Aislamiento: Aislamiento
- Un sistema de base de datos multiusuario permite que múltiples transacciones se ejecuten simultáneamente
- Mejore el rendimiento de las transacciones del sistema y reduzca el tiempo de espera de las transacciones
- Las operaciones de base de datos en transacciones ejecutadas concurrentemente pueden intercalarse y pueden operar en el mismo objeto de datos
- Aislamiento significa que una transacción se ejecuta normalmente sin ser perturbada por la ejecución simultánea de operaciones de base de datos, como la captura de boletos 12306
Por ejemplo: Si en una transacción ejecutada simultáneamente, los dos resultados de la misma consulta son diferentes, ¿se debe a que la transacción no mantiene ninguna característica?
Persistencia: Durabilidad
- Una vez enviada la transacción, la operación de actualización de la transacción a la base de datos permanecerá en la base de datos de forma permanente (los datos de los depósitos bancarios no se pueden perder por corte de energía)
mecanismo de recuperación
Después de que ocurra una falla, restaure los resultados exitosos para mantener la atomicidad y la persistencia
Tipo de falla y causa
1. Fallo de transacción : se produjo un error durante el proceso de ejecución, lo que provocó la cancelación de la transacción.
- Error interno: El funcionamiento interno de la cosa está limitado [violación de las restricciones de integridad, acceso a los datos, desbordamiento de la operación]
- error del sistema:
- destruir la atomicidad
2. Fallo del sistema
- Eventos que provocan que el sistema deje de funcionar, como fallas de la CPU, errores de código DBMS, fallas del sistema operativo
- Es fácil hacer que se pierda el contenido de la memoria
- Destrucción de la atomicidad y la persistencia (los resultados actualizados aún pueden almacenarse en el búfer y no escribirse en el disco)
3. Falla de medios : una falla grave que destruye por completo el medio de almacenamiento de datos
Tales como daños en el servidor de la base de datos, interferencia transitoria de campos magnéticos, daños por colisión de cabezales, etc.
Rompe la durabilidad (los resultados actualizados no se pueden conservar en el disco)
4. Errores inconsistentes
Estrategia de gestión de búfer de robo/no cumplimiento [algoritmo de reemplazo de búfer como LRU]
1. Para ingresar los datos requeridos por la transacción B desde el disco a la memoria, primero es necesario enviar los datos procesados por la transacción A no confirmada al disco para hacer espacio para B, es decir, B roba el espacio de A
2. La transacción compromete al perro y el resultado de la actualización no llega al disco a tiempo, es decir, la operación de salida no es obligatoria
Robar/no hacer cumplir la estrategia de gestión de la reserva da como resultado:
1. Antes de que se confirme la transacción, es posible que algunos resultados de la ejecución se hayan actualizado en la base de datos
2. Después de confirmar la transacción, el resultado de la ejecución de la transacción no se actualiza en el disco inmediatamente
- Destruyendo la atomicidad y la durabilidad de las transacciones ,
Pregunta: Si el administrador del búfer no adopta la estrategia de administración de robar/no aplicar en el material didáctico, pero adopta la estrategia de actualización retrasada, es decir, el resultado de la actualización no se escribirá en la base de datos hasta que se confirme la transacción, luego ocurre una falla, habrá un error de inconsistencia en el sistema ¿Cuál es el rendimiento del estado?
Respuesta: Parte o incluso la totalidad de los resultados de la actualización de la base de datos de la transacción enviada todavía están en el búfer y no se han escrito en la base de datos del disco, lo que destruye la durabilidad de la transacción. O los resultados actualizados de la transacción enviada a la base de datos no se pueden conservar en el disco, lo que destruye la durabilidad de la transacción.
P: Actualizar registros de registro: si el administrador del búfer no adopta la estrategia de administración de robo/no forzada en el material didáctico, pero adopta una estrategia de actualización retrasada, es decir, los resultados de la actualización no se escribirán en la base de datos hasta que se confirme la transacción, entonces las entradas del registro de actualización ¿Todavía necesito incluir el valor previo a la actualización?
Respuesta: No, si hay un valor actualizado en la base de datos del disco, significa que la transacción se ha enviado correctamente, por lo que no es necesario realizar operaciones de DESHACER durante la recuperación y no es necesario almacenar el valor antes de la actualizar
estrategia de recuperación
registro
Cada base de datos mantiene un registro para registrar todas las transacciones actualizando los datos
Formato: 1. Archivo de registro en unidad de registro (ID de transacción, tipo de operación, objeto de operación, valor anterior de los datos antes de la actualización, valor nuevo de los datos después de la actualización);
2. Archivos de registro en unidades de tablas de datos (identificadores de transacciones, bloques de datos actualizados)
Contenido: 1 marca de inicio de cada transacción; 2 marcas de finalización de cada transacción; 3 operaciones de actualización de cada transacción
Función: 1. Realizar la recuperación de fallas de transacciones 2. Realizar la recuperación de fallas del sistema 3. Ayudar a la copia de respaldo en la recuperación de fallas de medios
Nota: El registro de registros de registro debe ser estrictamente de acuerdo con el orden en que se ejecutan las operaciones de cada transacción
Nota: Antes de actualizar, los registros deben escribirse en
volcado de datos
Un volcado es el proceso mediante el cual el DBA copia toda la base de datos en una cinta o en otro disco para su almacenamiento.
Los datos en espera se convierten en una copia de seguridad o copia de seguridad
Uso de volcados de datos
La copia de seguridad se puede volver a montar después de que la base de datos se haya dañado; volver a montar la copia de seguridad solo puede restaurar la base de datos al estado en el que se encontraba cuando se descargó
método de volcado
1. Descarga estática
- Operación de volcado cuando no hay transacciones en ejecución en el sistema ; las operaciones en la base de datos no están permitidas durante el volcado
- La base de datos estaba en un estado consistente cuando comenzó el volcado
- Lo que obtienes debe ser una copia de la consistencia de los datos.
Ventajas: fácil de implementar
Desventajas: 1. Reduce la disponibilidad de la base de datos 2. El volcado debe esperar a que finalice la transacción del usuario en ejecución 3. La nueva transacción debe esperar a que finalice el volcado
2. Volcado dinámico
- La operación de volcado se realiza simultáneamente con el usuario
- Se permite el acceso o la modificación de la base de datos durante el volcado
Ventajas: 1. No es necesario esperar a que finalicen las transacciones en curso 2. Permitir el acceso o la modificación de la base de datos durante el volcado
Desventajas: No hay garantía de que los datos de la copia sean correctos y válidos
**Volcado dinámico para recuperación de fallas**, necesita registrar las actividades de modificación de cada transacción en la base de datos durante el período de volcado dinámico y crear un archivo de registro; la copia de respaldo más el archivo de registro pueden restaurar la base de datos al estado correcto en cierto momento
Volcado masivo: volcar todas las bases de datos cada vez , también conocido como volcado completo
Volcado incremental: volcar solo los datos actualizados después del último volcado
Comparación de volcado masivo y volcado incremental
1. Desde la perspectiva de la recuperación, a menudo es más conveniente utilizar la copia de seguridad obtenida por volcado masivo para la recuperación.
2. Si la base de datos es grande y el procesamiento de transacciones es muy frecuente, el volcado incremental es más efectivo
Recuperación de copias de volcado estático y archivos de registro
Para ilustrar la figura anterior:
- El sistema deja de ejecutar transacciones en el momento Ta y realiza un volcado de la base de datos.
- El volcado se completa en el momento Tb y se obtiene una copia coherente de la base de datos en el momento Tb
- El sistema corre a Tf y ocurre una falla
- Para restaurar la base de datos, el DBA primero reinstala la copia de respaldo de la base de datos y restaura la base de datos al estado en el momento Tb
- Vuelva a ejecutar todas las transacciones de actualización desde el tiempo Tb~Tf para restaurar la base de datos al estado consistente antes de la falla
Los errores de inconsistencia de datos conducen a
- El resultado de la ejecución parcial de la transacción abortada ha actualizado la base de datos; necesita ser deshecho
- Para las transacciones que se han confirmado, es posible que algunos o todos los resultados de la actualización de la base de datos aún estén en el búfer y no se hayan escrito en el disco; debe ejecutarse
Deshacer transacción DESHACER
- Use el registro para deshacer la transacción para actualizar la base de datos**, escriba el valor anterior antes de la actualización**
- Mantenga la atomicidad de la transacción, y la transacción finaliza en modo de reversión
rehacer transacción REDO
- Use el registro para actualizar la base de datos y escriba el nuevo valor actualizado
- Mantenga la persistencia de la transacción, y la transacción finaliza con la confirmación
Recuperar UNDO después de una transacción fallida
Fallo de transacción: la transacción finalizó antes de llegar al punto de finalización normal
Método de recuperación: el subsistema de recuperación utiliza el archivo de registro para deshacer ( DESHACER ) los cambios realizados en la base de datos por esta transacción
Nota: el sistema completa automáticamente la recuperación de la falla de la transacción, que es transparente para los usuarios y no requiere la intervención del usuario
pasos de recuperación
- ** Escanee el registro del archivo en reversa (** escanee de atrás hacia adelante) para encontrar la operación de actualización de la transacción
- Realice la operación inversa de la operación de actualización de la transacción , es decir, escriba el "valor antes de la actualización" en el registro de la base de datos
- Continúe escaneando el archivo de registro a la inversa, buscando otras operaciones de actualización para esta transacción y haga lo mismo.
- Este proceso continúa hasta que se lee la marca de inicio de esta transacción y se completa la recuperación de falla de transacción.
Recuperación UNDO+REDO después de una falla del sistema
error del sistema:
- Las actualizaciones de la base de datos por transacciones pendientes se han escrito en la base de datos
- Las actualizaciones de la base de datos por transacciones confirmadas permanecen en la memoria caché y no han tenido tiempo de escribirse en la base de datos.
Método de recuperación:
- Transacciones que no se completaron cuando ocurrió la falla UNDO
- Rehacer transacciones completadas
Nota: el sistema completa automáticamente la recuperación de la falla del sistema cuando se reinicia, sin la intervención del usuario
Pasos de recuperación:
- Reenviar archivos de registro de escaneo (1. Agregar transacciones que se enviaron antes de la falla a la cola de rehacer (REDO), estas transacciones tienen registros de transacciones iniciales y registros de confirmación; 2. Agregar transacciones sin terminar cuando se produce la falla a la cola de deshacer (Deshacer) , solo hay registros de transacciones iniciales en estas transacciones, no hay registros de confirmación correspondientes)
- Deshacer (Deshacer) la transacción de la cola de deshacer (1. Escanee el archivo de registro al revés, invierta la operación de actualización de cada transacción de deshacer; 2. Escriba el "valor antes de la actualización" en el registro de la base de datos)
- Procesamiento de rehacer (Redo) de transacciones de cola de rehacer (Redo) (1. Reenviar archivos de registro de escaneo, volver a ejecutar operaciones de registro para cada transacción REDO; 2. Escribir el "valor actualizado" en el registro de registro en la base de datos)
Recuperación después de una falla de medios [se requiere DBA]
- reinstalar la base de datos
- Rehacer transacciones completadas
Técnicas de recuperación con puntos de control
Resolver el problema:
- Buscar en todo el registro llevará mucho tiempo
- Procesamiento REDO: reejecución, pérdida de mucho tiempo
Solución:
- Agregar registros de puntos de control a los archivos de registro
- agregar archivo de reinicio
- El subsistema de recuperación mantiene el registro dinámicamente durante el registro en el archivo de registro
Crear un punto de control:
El subsistema de recuperación puede establecer periódica o irregularmente puntos de control para guardar el estado de la base de datos
- Periódico: cree un punto de control en un intervalo de tiempo predeterminado, como cada hora
- Irregular: de acuerdo con una regla determinada, como que el archivo de registro está medio lleno para establecer un punto de control
recuperar:
T1: confirmar antes del punto de control
T2: iniciar la ejecución antes del punto de control, confirmar después del punto de control pero antes del fallo
T3: Ejecución iniciada antes del punto de control, aún no completada en el punto de falla
T4: iniciar la ejecución después del punto de control, confirmar antes del punto de falla
T5: Ejecución iniciada después del punto de control, aún no completada en el punto de falla
Pasos de recuperación usando puntos de control
- Encuentre la dirección del último registro de punto de control en el archivo de registro desde el archivo de reinicio para encontrar el último registro de punto de control en el archivo de registro
- La lista de todas las transacciones que se ejecutan en el momento del establecimiento del punto de control se obtiene del registro del punto de control ACTIVE-LIST
- Crear dos colas de transacciones
- DESHACER LISTA
- REHACER LISTA
- Ponga ACTIVE-LIST en la cola UNDO-LIST temporalmente, y la cola REDO está temporalmente vacía.
- Crear dos colas de transacciones
- Escanee el archivo de registro hacia adelante desde el punto de control hasta el final del archivo de registro
- Si hay una transacción Ti recién iniciada, coloque temporalmente a Ti en la cola UNDO-LIST
- Si hay una transacción confirmada Tj, mueva Tj de la cola UNDO-LIST a la cola REDO-LIST
- Realice una operación UNDO en cada transacción en UNDO-LIST
- Ejecute la operación REDO en cada transacción en REDO-LIST
Duplicación de datos [suplemento]
reflejo de la base de datos
-
El DBMS copia automáticamente la base de datos completa o los datos clave en otro disco
-
El DBMS garantiza automáticamente la consistencia de los datos espejo y la base de datos principal. Cada vez que se actualiza la base de datos principal, el DBMS copia automáticamente los datos actualizados, como se muestra en la figura.
Cuando ocurre una falla de medios
- Puede seguir siendo utilizado por discos duplicados
- Al mismo tiempo, el DBMS utiliza automáticamente los datos del disco reflejado para restaurar la base de datos.
- No es necesario apagar el sistema y volver a cargar la copia de la base de datos
cuando no hay fracaso
- Se puede utilizar para operaciones simultáneas.
- Un usuario agrega un bloqueo exclusivo a los datos para modificarlos, y otros usuarios pueden leer los datos en la base de datos reflejada sin esperar a que el usuario libere el bloqueo.
P: Recuperación de una falla del sistema
Si el administrador del búfer no adopta la estrategia de administración de robo/no forzada en el material didáctico, pero adopta la estrategia de actualización retrasada, es decir, el resultado de la actualización no se escribirá en la base de datos hasta que se confirme la transacción, entonces, ¿cómo recuperarse después de un sistema? se produce la falla?
Respuesta: REDO se usa para transacciones confirmadas y UNDO se usa para transacciones no confirmadas
control de concurrencia
¿Cómo ejecutar múltiples transacciones juntas?
- Ejecución en serie de transacciones: solo se ejecuta una transacción a la vez, y otras transacciones deben esperar hasta el final de esta transacción antes de poder ejecutarse. (las transacciones se ejecutan una tras otra)
- Modo de concurrencia cruzada: en un sistema de un solo procesador, las transacciones paralelas y las operaciones paralelas se ejecutan alternativamente en paralelo. Este modo de ejecución en paralelo se denomina modo de concurrencia cruzada.
- Modo paralelo simultáneo: en un sistema multiprocesador, cada procesador puede ejecutar una transacción, y múltiples procesadores pueden ejecutar múltiples transacciones al mismo tiempo, para realizar la operación paralela real de múltiples transacciones.Este modo de ejecución paralela se denomina simultáneo concurrente modo. .
La transacción es la unidad básica de control de concurrencia.Si no se considera el aislamiento, ¿qué sucederá?
Datos perdidos : dos transacciones T1 y T2 leen y modifican los mismos datos al mismo tiempo, el resultado enviado por T2 destruye el resultado enviado por T1, lo que resulta en la pérdida de la modificación de T1
Lectura no repetible : Para ciertos datos en la base de datos, múltiples consultas dentro de un rango de transacciones devuelven resultados diferentes, porque los datos son modificados y enviados por otra transacción durante el proceso de consulta.
Lectura sucia : una transacción lee datos de otra transacción confirmada mientras procesa datos.
Nota: La diferencia entre lecturas no repetibles y lecturas sucias es que las lecturas sucias leen datos no confirmados , mientras que las lecturas no repetibles leen datos confirmados por una transacción anterior .
Nota: la lectura no repetible no afecta la exactitud de los datos en algunos casos. Por ejemplo, los datos que deben consultarse varias veces también deben basarse en los datos consultados la última vez.
Nota: Los datos perdidos y las lecturas no repetibles leen otra transacción que se ha confirmado (esto es diferente de las lecturas sucias). La diferencia es que las consultas de lectura no repetibles son todas para el mismo elemento de datos, mientras que los datos perdidos son un lote de datos como un todo (como el número de datos).
Las lecturas no repetibles y las lecturas fantasma son conceptos que no son fáciles de distinguir para los principiantes. Solo lo entendí después de leer la explicación detallada. En términos generales, la solución a las lecturas no repetibles es bloquear filas, y la solución a la pérdida de datos es para bloquear mesas .
1. Datos perdidos, lectura fantasma (WW)
Dos transacciones T1 y T2 leen y modifican los mismos datos al mismo tiempo, el resultado presentado por T2 destruye el resultado presentado por T1, lo que resulta en la pérdida de la modificación de T1
2. Lectura no repetible (RW)
Después de que la transacción T1 lea un dato determinado, la transacción T2 realiza una operación de actualización, de modo que T1 no puede reproducir el resultado de la lectura anterior, incluidas tres situaciones:
⑴.T2 ejecuta la operación de modificación, y cuando T1 vuelve a leer los datos, obtiene un valor diferente al anterior
⑵.T2 ejecuta la operación de eliminación, y cuando T1 vuelve a leer los datos, descubre que algunos registros desaparecen misteriosamente
⑶.T2 realiza la operación de inserción, y cuando T1 lee los datos nuevamente, encuentra algunos registros más
(2) (3) Las lecturas no repetibles que ocurren a veces se denominan fantasmas.
3. Leer datos "sucios" (WR)
La transacción T1 modifica ciertos datos y los vuelve a escribir en el disco. Después de que la transacción T2 lea los mismos datos, T1 se revoca por alguna razón. En este momento, los datos modificados por T1 se restauran a su valor original y los datos se leen. por T2 es consistente con la base de datos Si los datos en T2 son inconsistentes, los datos leídos por T2 son datos "sucios", es decir, datos incorrectos.
¿Cómo evitar este fenómeno de inconsistencia de datos? - DBMS debe proporcionar un mecanismo de control de concurrencia
La tarea del mecanismo de control de concurrencia: programar correctamente las operaciones concurrentes, garantizar el aislamiento de las transacciones y garantizar la consistencia de la base de datos.
Las principales tecnologías de control de concurrencia son: bloqueo, marca de tiempo, método de control optimista, control de concurrencia multiversión.
Pregunta: Inconsistencia de datos: Para las tres inconsistencias de datos de "actualización perdida", "lectura sucia" y "lectura no repetible", ¿cuál se considera absolutamente prohibida? Dar razones.
Respuesta: Nunca se debe permitir que ocurra una "pérdida de actualización", porque las consecuencias de la "lectura sucia" y la "lectura no repetible" a veces son graves, pero a veces son irrelevantes y se pueden evitar controlando el nivel de aislamiento de la transacción. , pero "actualización" Una vez que se produce la "pérdida", todas las transacciones posteriores que necesitan operar en los datos perdidos se verán afectadas y deben rehacerse o restaurarse mediante la copia de seguridad de datos.
tecnología de bloqueo
El bloqueo es una medida eficaz para lograr el control de la concurrencia, entonces, ¿qué es el bloqueo?
El bloqueo es cuando una transacción T opera en un objeto de datos (como una tabla, registro, etc.) . Primero envíe una solicitud al sistema y bloquéelo. Después del bloqueo, la transacción T tiene cierto control sobre el objeto de datos. Antes de que la transacción T libere su bloqueo, otras transacciones no pueden actualizar este objeto de datos.
¿Qué tipos de bloqueos hay?
Bloqueo exclusivo : denominado bloqueo X (también conocido como bloqueo de escritura), si la transacción T agrega un bloqueo X al objeto de datos A, solo leer y modificar A , y ninguna otra transacción puede agregar ningún bloqueo a A. Hasta que T libera el candado de A.
Bloqueo compartido : denominado bloqueo S (también conocido como bloqueo de lectura). Si la transacción T agrega un bloqueo S al objeto de datos A, la transacción T puede leer A pero no puede modificar A. Otras transacciones solo pueden agregar un bloqueo S a A, pero no a X bloqueo hasta que T suelta el bloqueo S en A.
Con el tipo de bloqueo, ¿ cómo agregar un bloqueo para evitar la inconsistencia de datos en operaciones concurrentes?
Protocolo de bloqueo : Estipula una serie de reglas como cuándo aplicar el bloqueo X o el bloqueo S para los objetos de datos, la duración y cuándo liberarlos.
Ver yaunwen para bloqueo de nivel tres
P: La tecnología de bloqueo logra la serialización de conflictos: ¿Cómo realiza la tecnología de bloqueo la serialización de conflictos de transacciones concurrentes?
Respuesta: La técnica de bloqueo evita el comportamiento no serializable al mantener un "bloqueo" en el objeto de datos. La idea básica del control de concurrencia basado en bloqueos es: antes de que una transacción opere en los objetos de datos (como relaciones y tuplas) a los que necesita acceder, primero envía una solicitud al sistema para obtener el bloqueo en el objeto de la base de datos. accesos, Para evitar que otras transacciones accedan a los datos casi al mismo tiempo y así introducir la posibilidad de inviabilidad. La técnica de bloqueo permite la serialización de conflictos.
punto muerto
¿Qué problemas traerá el bloqueo?
- Livelock: si la transacción T1 bloquea los datos R, la transacción T2 solicita bloquear los datos R, por lo que T2 espera; T3 también solicita bloquear los datos R, cuando T1 libera el bloqueo en R, el sistema primero aprueba la solicitud de T3, T2 cualquiera Luego T4 solicita bloquear R, y cuando T3 libera el bloqueo en R, el sistema aprueba la solicitud de T4... T2 puede esperar para siempre, que es el caso de livelock .
Una forma sencilla de evitar los bloqueos dinámicos es utilizar una política de orden de llegada.
- Interbloqueo: si la transacción T1 bloquea los datos R1, T2 bloquea los datos R2 y luego T1 solicita bloquear R2, porque T2 bloquea R2,
Entonces T1 espera a que T2 libere el bloqueo de R2; luego T2 solicita bloquear a R1, porque T1 bloquea a R1, por lo que T2 espera a que T1 libere el bloqueo de R1. De esta manera, T1 está esperando a T2 y T2 está esperando a T1. Las dos transacciones de T1 y T2 nunca pueden terminar, formando un interbloqueo.
Formas de resolver el punto muerto: hay dos ideas
- Evitar que ocurra un punto muerto
① Método de bloqueo único: bloquea todos los datos que se utilizarán a la vez; de lo contrario, no puede continuar ejecutándose
Problemas existentes: ampliar el alcance del bloqueo y reducir la concurrencia del sistema;
② Método de bloqueo secuencial: predetermina una secuencia de bloqueo para objetos de datos y todas las transacciones se bloquean en esta secuencia.
Problemas existentes:
1. La base de datos cambia constantemente de forma dinámica y es muy difícil y costoso mantener el orden de bloqueo de dichos recursos.
2. La solicitud de bloqueo de una transacción se puede determinar dinámicamente con la ejecución de la transacción.Es difícil determinar qué objetos se bloquearán para cada transacción, por lo que es difícil aplicar el bloqueo en un orden prescrito.
- Diagnóstico y resolución de interbloqueos (método comúnmente utilizado)
① Método de tiempo de espera: si el tiempo de espera de una transacción supera el límite de tiempo especificado, se considera que se ha producido un interbloqueo
Problemas existentes:
1.时间设置太短，有可能误判死锁
2. La configuración de tiempo es demasiado larga y el interbloqueo no se puede encontrar a tiempo después de que ocurra
② Método de gráfico de espera: el gráfico de transacción en espera es un gráfico dirigido G = (T, U), T es una colección de nodos, cada nodo representa una transacción en ejecución; U es una colección de bordes, que representan la situación de espera de transacción, si Transacción T1 espera a T2, luego dibuja un borde dirigido entre T1 y T2, apuntando de T1 a T2.
El gráfico de espera de transacciones refleja dinámicamente las condiciones de espera de todas las transacciones. El subsistema de control de concurrencia periódicamente (por ejemplo, cada pocos segundos) genera y detecta gráficos de espera de transacciones. Si se encuentra un bucle en el gráfico, significa que se ha producido un interbloqueo en el sistema. Una vez que el subsistema de control de concurrencia detecta que hay un interbloqueo en el sistema, debe intentar eliminarlo. El método habitual es seleccionar una transacción con el menor costo de interbloqueo, cancelarla, liberar todos los bloqueos retenidos por esta transacción y permitir que se ejecuten otras transacciones.
Pregunta: "Si hay un ciclo en el gráfico de espera de transacciones, entonces la programación concurrente no es serializable en conflicto". ¿Cree que este juicio es correcto? razón
Respuesta: Incorrecto, un bucle en el diagrama de espera de transacciones indica que hay un interbloqueo en el sistema, es decir, las transacciones se esperan entre sí al solicitar bloqueos en los objetos de datos, pero esto no significa que la programación concurrente no sea equivalente a otro conflicto de programación en serie
Bloqueo multigranular
- Granularidad de bloqueo: el tamaño del objeto bloqueado
Es ideal para soportar múltiples granularidades de bloqueo para diferentes transacciones a elegir en un sistema al mismo tiempo, este método se llama bloqueo multi-granularidad.
- ¿Quién está bloqueado?
-
Unidad física: página (página de datos o página de índice), registro físico, etc.
-
Unidad lógica: valor de atributo, colección de valores de atributo, tupla, relación, elemento de índice, índice completo, base de datos completa
-
¿Cómo se bloquea?
Árbol de granularidad múltiple: el nodo raíz es la base de datos completa, que representa la granularidad de datos más grande, y el nodo hoja representa la granularidad de bloqueo más pequeña.
Protocolo de bloqueo multigranular
Permite que cada nodo del árbol multigrano se bloquee de forma independiente. El bloqueo de cada nodo (bloqueo explícito) significa que todos los nodos descendientes de este nodo también están sujetos al mismo tipo de bloqueo (bloqueo implícito).
Al bloquear un dato, el sistema necesita verificar si existe un conflicto con el bloqueo explícito en el objeto de datos y, al mismo tiempo, verificar si hay un bloqueo implícito hacia arriba o hacia abajo.
Bloqueo de intención: si se aplica un bloqueo de intención a un nodo, significa que el nodo inferior del nodo está siendo bloqueado; cuando cualquier nodo está bloqueado, el nodo superior debe bloquearse primero.
¿Qué tipos de bloqueos de intenciones existen?
Bloqueo IS (intento de bloqueo compartido): si se agrega un bloqueo IS a un objeto de datos, significa que su nodo descendiente tiene la intención (intención) de agregar un bloqueo S.
Bloqueo IX (intento de bloqueo exclusivo): si se agrega un bloqueo IX a un objeto de datos, significa que su nodo descendiente tiene la intención (intención) de agregar un bloqueo X.
Bloqueo SIX (bloqueo exclusivo de intención compartida): si se agrega un bloqueo SIX a un objeto de datos, significa que se le agrega un bloqueo S y se agrega un bloqueo IX, es decir, SIX = S + IX.
Al solicitar el bloqueo, se debe hacer en orden de arriba hacia abajo, y al liberar el bloqueo, se debe hacer en orden de abajo hacia arriba.
Pregunta: Según la tecnología de bloqueo de granularidad múltiple proporcionada por DBMS, en aplicaciones prácticas, ¿cuándo usar bloqueos de granularidad gruesa (como bloqueos relacionales) y cuándo usar bloqueos de granularidad fina (como bloqueos de tupla)?
R: Los bloqueos de granularidad fina deben usarse para transacciones que necesitan procesar una pequeña cantidad de tuplas, y los bloqueos de granularidad gruesa deben usarse para transacciones que necesitan procesar una gran cantidad de tuplas. Los bloqueos de granularidad fina tienen mejor concurrencia que los gruesos -bloqueos granulares, pero son más caros Se necesita más espacio para mantener información sobre bloqueos granulares, y la elección debe considerar tanto la sobrecarga de espera como el grado de concurrencia
nivel de aislamiento
¿Qué es el aislamiento de transacciones (Isolation)?
Aislamiento significa que cuando las transacciones simultáneas de múltiples usuarios acceden a la misma base de datos, las transacciones de un usuario no deben ser interferidas por las transacciones de otros usuarios, y las transacciones simultáneas múltiples deben estar aisladas entre sí.
Cuatro niveles de aislamiento de transacciones resuelven los problemas anteriores; la mayoría de ellos son adecuados para los dos intermedios
Lectura no confirmada (Lectura no confirmada): [nivel de aislamiento más bajo]**
- En este momento, la declaración de selección no está bloqueada. Se pueden leer datos inconsistentes, es decir, "leer sucio". La mayor concurrencia y la peor consistencia.
Leer comprometido: [comúnmente utilizado]
- Las lecturas sucias se pueden evitar. En escenarios con una gran cantidad de datos de Internet y alta simultaneidad, los dos niveles de aislamiento anteriores apenas se utilizan.
Lectura repetible (Lectura repetible): [usado comúnmente]
- Nivel de aislamiento predeterminado de MySql . Se pueden evitar las lecturas sucias y las lecturas no repetibles.
Serializable (Serializable): [Nivel de aislamiento más alto]
- Se pueden evitar lecturas sucias, lecturas no repetibles y lecturas fantasma; el nivel de aislamiento con la mejor consistencia pero la peor concurrencia.
Por supuesto, cuanto mayor sea el nivel, menor será la eficiencia de ejecución. Un nivel como Serializable es para bloquear la tabla (similar al bloqueo en subprocesos múltiples de Java) para que otros subprocesos solo puedan esperar fuera del bloqueo, por lo que el nivel de aislamiento a elegir debe basarse en la situación real.
P: La elección del nivel de aislamiento predeterminado: tanto SQLSever como Oracle establecen el nivel de aislamiento predeterminado en Lectura confirmada (lectura confirmada), y MySQL establece el nivel de aislamiento predeterminado en Lectura repetible (lectura repetible), en lugar de configurarlo en un nivel superior o inferior. Nivel de aislamiento, ¿en qué crees que se basa esta configuración?
d): [nivel de aislamiento más bajo]**
- En este momento, la declaración de selección no está bloqueada. Se pueden leer datos inconsistentes, es decir, "leer sucio". La mayor concurrencia y la peor consistencia.
Leer comprometido: [comúnmente utilizado]
- Las lecturas sucias se pueden evitar. En escenarios con una gran cantidad de datos de Internet y alta simultaneidad, los dos niveles de aislamiento anteriores apenas se utilizan.
Lectura repetible (Lectura repetible): [usado comúnmente]
- Nivel de aislamiento predeterminado de MySql . Se pueden evitar las lecturas sucias y las lecturas no repetibles.
Serializable (Serializable): [Nivel de aislamiento más alto]
- Se pueden evitar lecturas sucias, lecturas no repetibles y lecturas fantasma; el nivel de aislamiento con la mejor consistencia pero la peor concurrencia.
Por supuesto, cuanto mayor sea el nivel, menor será la eficiencia de ejecución. Un nivel como Serializable es para bloquear la tabla (similar al bloqueo en subprocesos múltiples de Java) para que otros subprocesos solo puedan esperar fuera del bloqueo, por lo que el nivel de aislamiento a elegir debe basarse en la situación real.
P: La elección del nivel de aislamiento predeterminado: tanto SQLSever como Oracle establecen el nivel de aislamiento predeterminado en Lectura confirmada (lectura confirmada), y MySQL establece el nivel de aislamiento predeterminado en Lectura repetible (lectura repetible), en lugar de configurarlo en un nivel superior o inferior. Nivel de aislamiento, ¿en qué crees que se basa esta configuración?
Respuesta: Al establecer el nivel de aislamiento de transacciones de la base de datos, se pueden resolver los problemas de lecturas sucias, lecturas no repetibles y lecturas fantasmas que ocurren en el caso de varias transacciones simultáneas. Los niveles de aislamiento de transacciones de la base de datos son Lectura no confirmada, Lectura confirmada, lectura repetible y serializable en orden de menor a mayor. Espere cuatro. Diferentes bases de datos admiten diferentes niveles de aislamiento de transacciones: la base de datos MySQL admite los cuatro niveles de aislamiento de transacciones anteriores y el valor predeterminado es lectura repetible; la base de datos Oracle admite dos niveles de aislamiento de transacciones, lectura confirmada y serializable, y el valor predeterminado es lectura confirmada