Un artículo para comprender los bloqueos de nivel 0 a 6 de Oracle (con una explicación detallada del caso)

Información de bloqueo extraída de 11g Concepts

Cerraduras de mesa (TM)

Una transacción adquiere un bloqueo de tabla, también llamado bloqueo TM, cuando una tabla se modifica mediante una instrucción INSERT, UPDATE, DELETE, MERGE, SELECT con la cláusula FOR UPDATE o LOCK TABLE. Las operaciones DML requieren bloqueos de tabla para reservar el acceso DML a la tabla en nombre de una transacción y para evitar operaciones DDL que puedan entrar en conflicto con la transacción.

Cuando una transacción modifica una tabla a través de INSERT, UPDATE, DELETE, MERGE y FOR UPDATE, se obtiene un bloqueo de tabla, también conocido como cláusula de bloqueo TM o declaración de bloqueo de tabla. Las operaciones DML requieren bloqueos de tabla para preservar el acceso DML a las tablas para las transacciones y para evitar que las operaciones DDL entren en conflicto con las transacciones.
Un bloqueo de mesa se puede mantener en cualquiera de los siguientes modos:

Fila compartida (RS)

Este bloqueo, también llamado bloqueo de tabla de subparticipación (SS), indica que la transacción que mantiene el bloqueo en la tabla tiene filas bloqueadas en la tabla y tiene la intención de actualizarlas. Un bloqueo de fila compartida es el modo menos restrictivo de bloqueo de tabla y ofrece el mayor grado de simultaneidad para una tabla.

Este bloqueo, también conocido como bloqueo de tabla subcompartida (SS), indica que la transacción que mantiene el bloqueo de tabla ha bloqueado filas en la tabla y tiene la intención de bloquearlas y actualizarlas. Los bloqueos de filas compartidas son el modo menos restrictivo de los bloqueos de tablas y proporcionan el mayor grado de simultaneidad para las tablas.

Bloqueo de mesa exclusivo de fila (RX)

Este bloqueo, también llamado bloqueo de tabla subexclusivo (SX), generalmente indica que la transacción que contiene el bloqueo ha actualizado las filas de la tabla o ha emitido SELECCIONAR... PARA ACTUALIZAR. Un bloqueo SX permite que otras transacciones consulten, inserten, actualicen, eliminen o bloqueen filas simultáneamente en la misma tabla. Por lo tanto, los bloqueos SX permiten transacciones múltiples para obtener bloqueos de tabla SX y subshare simultáneos para la misma tabla.

Este bloqueo, también conocido como bloqueo de tabla subexclusivo (SX), generalmente indica que la transacción que mantiene el bloqueo ha actualizado una fila de la tabla o ha emitido una SELECCIÓN... PARA ACTUALIZAR. Los bloqueos SX permiten que otras transacciones consulten, inserten, actualicen, eliminen o bloqueen filas simultáneamente en la misma tabla. Por lo tanto, los bloqueos SX permiten que varias transacciones adquieran bloqueos SX sincronizados y de tablas subcompartidas para la misma tabla.

Bloqueo de mesa compartida (S)

Un bloqueo de tabla compartida mantenido por una transacción permite que otras transacciones consulten la tabla (sin utilizar SELECCIONAR... PARA ACTUALIZAR), pero las actualizaciones solo se permiten si una sola transacción mantiene el bloqueo de tabla compartida. Debido a que varias transacciones pueden mantener un bloqueo de tabla compartida al mismo tiempo, mantener este bloqueo no es suficiente para garantizar que una transacción pueda modificar la tabla.

Un bloqueo de tabla compartido mantenido por una transacción permite que otras transacciones consulten la tabla (excepto SELECT...FOR UPDATE ), pero solo permite actualizaciones si una transacción mantiene un bloqueo de tabla compartido. Dado que varias transacciones pueden mantener un bloqueo de tabla compartido al mismo tiempo, mantener este bloqueo no es suficiente para garantizar que las transacciones puedan modificar la tabla.

Bloqueo de mesa exclusivo de Share Row (SRX)

Este bloqueo, también llamado bloqueo de tabla subexclusiva compartida (SSX), es más restrictivo que un bloqueo de tabla compartida. Solo una transacción a la vez puede adquirir un bloqueo SSX en una tabla determinada. Un bloqueo SSX retenido por una transacción permite que otras transacciones consulten la tabla (excepto SELECCIONAR... PARA ACTUALIZAR) pero no actualizar la tabla.

Este bloqueo, también conocido como bloqueo de tabla subexclusiva compartida (SSX), es más restrictivo que un bloqueo de tabla compartida. Solo se puede adquirir un bloqueo SSX de transacción en una tabla determinada a la vez. Un bloqueo SSX retenido por una transacción permite que otras transacciones consulten la tabla (excepto SELECT... FOR UPDATE ), pero no actualizar la tabla.

Bloqueo de mesa exclusivo (X)

Este bloqueo es el más restrictivo, ya que prohíbe que otras transacciones realicen cualquier tipo de declaración DML o coloquen cualquier tipo de bloqueo en la tabla.

Este bloqueo es el más restrictivo y prohíbe que otras transacciones ejecuten cualquier tipo de declaración DML o coloquen cualquier tipo de bloqueo en la tabla.
Debido a que Oracle tiene que manejar diferentes funciones de concurrencia, una vez que no puede manejar tanta concurrencia, necesita hacer cola. Para garantizar la equidad de la cola, aparecerán varias prioridades, por lo que se derivan muchos modos de bloqueo para admitir los requisitos de concurrencia de diferentes capas de negocio.

在同一个session里面,你执行一个UPDATE语句,在表上有DML锁,那自己能去做DDL语句吗,比如DROP?

Debido a que es la misma sesión, no implica concurrencia.También es posible hacer una actualización sin enviarla y luego descartar la tabla.

nivel de bloqueo

Cerraduras de fila: 0 y 6 tipos de cerraduras

Cerradura de mesa: 0, 1, 2, 3, 4, 5, 6 siete tipos de cerraduras

0 (ninguno)
1 (nulo)
2 (RS)
3 (RX)
4 (S)
5 (SRX)
6 (X)

R significa FILA, S significa COMPARTIR y X significa bloqueo exclusivo exclusivo eXclusive.

0: nulo
SELECCIÓN general vacía, tanto en las tablas como en las filas son bloqueos de nivel 0

1: nulo
Bloqueos vacíos de nivel 1: Select aparece a veces en v$locked_object.

2: Fila-S uso compartido de filas (RS): bloqueo de tabla compartida, subcompartición
Los bloqueos de nivel 2 incluyen: Bloqueo de fila compartida, creación de índice en línea

En el caso de bloqueos de tablas:
el modo bloqueado 2 no afecta las sesiones de los siguientes modos bloqueados 2, 3, 4 y 5. Si el modo bloqueado de la última sesión es 6, la operación de la última sesión generará un error ora-00054 .
ORA-00054: recurso ocupado y adquisición con NOWAIT especificado o tiempo de espera vencido

En el caso de los bloqueos de fila:
el modo_bloqueado 2 corresponde a los bloqueos de nivel 0 de bloqueo de fila y no afecta a otras sesiones.

3: Fila-X fila exclusiva (RX): se utiliza para la modificación de filas, los bloqueos de 3 niveles subexclusivos
incluyen: Insertar, Actualizar, Eliminar, Seleccionar para actualizar, Bloquear fila exclusiva

En el caso de bloqueos de tabla:
el modo_bloqueado 3 no afecta la sesión del último modo_bloqueado 3, pero si el modo_bloqueado de la última sesión es 4, 5, 6, la última operación de sesión generará un error ora-00054.
ORA-00054: recurso ocupado y adquisición con NOWAIT especificado o tiempo de espera vencido

En el caso de bloqueos de fila:
El bloqueo de tabla de modo_bloqueado 3 corresponde a los bloqueos de nivel 6 de bloqueo de fila, y dos sesiones afectan a la misma fila.

4: Compartir bloqueo compartido (S): evitar otras operaciones DML, compartir
bloqueos de nivel 4 incluyen: Crear índice, Bloquear compartir

5: Exclusivo de fila compartida S/Row-X (SRX): evita otras operaciones de transacción, compartir/subexclusivo Los
bloqueos de 5 niveles incluyen: Bloquear fila compartida exclusiva
Específicamente, actualizar/eliminar cuando hay restricciones de clave principal y externa; 4 pueden ser generado, 5 bloqueos.

6: Exclusivo (X): utilizado para el acceso independiente,
los bloqueos exclusivos de 6 niveles incluyen: tabla de eliminación, índice de eliminación, modificación de tabla, tabla truncada, bloqueo exclusivo.

analogía de la joyería

Las joyerías se pueden visitar gratis para todos, puedes hacer reservas, puedes probarlas y luego comprarlas si te sientes bien, o puedes comprar toda la tienda.

Personas tipo 0 , personas que visitan las joyerías de forma gratuita;

Personas tipo 1 , huéspedes mayores, débiles, enfermos, discapacitados y embarazadas que visitan las joyerías de forma gratuita;

El segundo tipo de personas , que han reservado un período de prueba, lo compran primero por unos días, y luego lo compran si se sienten bien después de la prueba;

El tercer tipo de personas , la finalidad de ir directamente a la tienda es comprar de inmediato;

El 4º tipo de personas , la joyería de toda la tienda está empaquetada para que otros la visiten y hagan reservas, pero no pueden comprar ni vender (esto se llama bloqueo de solo lectura en ORACLE, que solo permite que otros lean, es decir, solo se permite la entrada de los tipos de personas 0, 1 y 2. Las joyerías permiten que otros visiten de manera de solo lectura, y no se permite el comercio. La cuarta categoría de personas todavía está permitida, porque aunque todos quieren comprar , pero el propósito de todos es compartir, no excluyente, por lo que es compatible );

Solo hay una diferencia entre el quinto tipo de persona y el cuarto tipo de persona, es decir, después de que el quinto tipo de persona se hace cargo de toda la joyería, el otro quinto tipo de persona no puede comprar más (esto es llamado bloqueo de escritura en ORACLE), es decir, el quinto tipo de personas tiene un solo canal. Solo puede encontrar un quinto tipo de persona en la joyería, y es imposible encontrar el segundo quinto tipo de persona. Personas en las categorías 0, 1 y 2 aún se permite la visita, pero no se permite la compra y venta;

El sexto tipo de personas , deja toda la joyería, nadie puede visitar a propósito, solo se permiten visitas gratuitas, es exclusivo, solo 0,1 tipos de personas pueden visitar, y nadie más está permitido. ;

– Las 2 personas de la categoría anterior están reservadas, por lo que la 3.ª categoría es incompatible con la 6.ª categoría;
– La 3.ª categoría anterior es para comprar joyas, por lo que la 3.ª categoría no es compatible con las categorías 4, 5, 6.

Piense en una joyería como un reloj, y los gabinetes de joyería en la joyería como una joyería
. Hay 7 tipos de personas correspondientes a 7 modos, que corresponden a 7 tipos de cerraduras en el reloj, 0, 1, 2, 3, 4, 5, 6
gabinetes, abiertos o cerrados 2 estados correspondientes a 2 modos, correspondientes a 2 cerraduras de filas, 0, 6

Joyería

(Puedes entrar a la tienda al mismo tiempo, sí)
La cerradura del nivel del reloj es equivalente a la cerradura de la puerta de la joyería, que está custodiada por el guardia. Hay 0, 1, 2, 3, 4, 5, y 6 bloqueos de mesa correspondientes a 7 tipos de personas, y pueden aparecer 7 tipos de personas La situación en la que varios tipos de personas ingresan a la tienda al mismo tiempo, como 0, 1, 2, 3 tipos de personas que ingresan al mismo tiempo tiempo, o 3 tipos de personas que entran al mismo tiempo muchas personas.

Bloqueo de nivel 0 : sin bloqueo, solo declaración de selección pura
Tipo 0: visita gratuita, sin competencia con otros clientes

Bloqueo de nivel 1 : de hecho, no puede desempeñar el papel de bloqueo. Solo tiene una función de notificación, que no puede evitar DDL en absoluto. Es similar a notificar el objeto en el plan de ejecución a la sesión a la que el el objeto pertenece Tipo 1: (viejo, débil, enfermo y discapacitado) visita gratis,
no No hay competencia con otros clientes, pero este cliente tiene derecho a conocer los desarrollos futuros de la tienda, por ejemplo, si será demolida .
Por ejemplo, la sesión A ejecuta select * from T, y luego guarda el plan de ejecución en la memoria.Para proteger que el plan de ejecución sea correcto, la sesión A debe disfrutar del tratamiento de ancianos, débiles, enfermos, embarazadas y jóvenes, porque si La tabla T es eliminada por otros, luego la sesión A ¿Sigue siendo útil el plan de ejecución generado? Si no notifica, ¿cómo sabe A que este objeto de la tabla ha caducado, es decir, el objeto con el bloqueo No. 1, una vez que se elimine, notificará a la sesión propietaria del objeto, este objeto se elimina, por favor vuelva a analizar su SQL, el bloqueo n. ° 1 es generado automáticamente por el sistema

Bloqueo de tabla de nivel 2 : solo entra en conflicto con X, porque los otros son bloqueos compartidos. Aunque RX y SRX también tienen X, son la fila X y la tabla aún se comparte. Los bloqueos de nivel 2 no entran en conflicto con los niveles 0-5 al mismo tiempo.
Tipos de personas del nivel 2 de la tabla: personas que tienen la intención de comprar joyas, pero ahora solo vienen a verificar si vale la pena comprar los productos, por lo que para abrir el mostrador, es solo una acción SELECCIONAR . No entrará en conflicto directamente con los clientes que tienen visitas gratuitas y tienen intenciones comerciales.
Método de generación de bloqueo de tabla de nivel 2
Generar explícitamente bloqueo de nivel de tabla (BLOQUEAR TABLA EN MODO COMPARTIR FILA, generar explícitamente un bloqueo de nivel de tabla RS)
Tenga en cuenta que la generación explícita de bloqueo de nivel de tabla solo genera bloqueo de nivel de tabla y no Ser bloqueos de nivel de fila en cascada, por lo que no habrá bloqueos de fila con otras sesiones.

Bloqueos de nivel 3 : Causas (actualizar, eliminar, seleccionar para actualizar, mostrar la tabla de bloqueo LOCK TABLE table EN FILA MODO EXCLUSIVO)
Personas de tipo 3: personas que compran joyas directamente, por lo que necesitan abrir el mostrador

La X del 6 es un bloqueo exclusivo en todo el nivel de la mesa, que muestra la mesa de bloqueo BLOQUEO DE LA TABLA DE TABLA EN MODO Exclusivo

gabinete de joyería

(¿Puede abrir el mismo gabinete al mismo tiempo? No, no existe tal concepto.)
La cerradura a nivel de fila es equivalente a la cerradura de mostrador de una joyería, que es verificada por el vendedor. Hay dos tipos de cerradura de fila bloqueos, 0 y 6, correspondientes a los dos estados del contador.

Abierto:
por lo general, si los clientes ingresan a una joyería, ¿cuáles son los propósitos de correr al mostrador?

Visita:
el estado del gabinete es cerrado: modo 0.
Los clientes que solo tienen el propósito de visitar (tipo 0, tipo 1) no tienen el problema de la competencia de recursos. ¿El vendedor todavía necesita sacar el candado y abrir? ¿el contador? No, porque no hay necesidad de bloqueos sin competencia de recursos.
El bloqueo de nivel de fila en el modo 0 es causado por los bloqueos de nivel de tabla de 0 y 1. Una declaración de selección simple es tanto un bloqueo de nivel de tabla de nivel 0 como un bloqueo de nivel de fila de nivel 0, es decir, sin bloqueo. .

Compra:
El estado del gabinete está abierto: Modo No. 6
Tipo 2 personas, período de prueba (no puede ser utilizado por otros durante el período de prueba)
Tipo 3 personas, compra de inmediato (equivalente a nuestra actualización, eliminar, seleccionar para actualizar, BLOQUEAR TABLE tabla IN ROW EXCLUSIVE MODE declaración)
Resumen: actualizar, eliminar, seleccionar para actualizar todo genera bloqueos exclusivos en la fila.

Los bloqueos compartidos permitirán que existan otros bloqueos compartidos, es decir, compartir no entra en conflicto con compartir.
Por ejemplo, el usuario A ejecuta ACTUALIZAR la línea 1 en la tabla T, luego hay un bloqueo compartido a nivel de tabla en la tabla t, luego el usuario B ejecuta ACTUALIZAR la línea 2 en la tabla T, luego también habrá una tabla en la tabla t Bloqueos compartidos de nivel , aunque las filas son todos bloqueos exclusivos, pero no la misma fila, por lo que no tienen conflicto en la fila ni en la tabla.
Por ejemplo, si el usuario A ejecuta LOCK TABLE T IN ROW EXCLUSIVE MODE, el usuario B puede ejecutar simultáneamente LOCK TABLE T IN ROW EXCLUSIVE MODE o LOCK TABLE T IN ROW SHARE MODE

有行级锁,必有表级锁(3级表锁引起6级行锁)
有表级锁,可以没有行级锁(显式锁,2,3,6号显示锁对应的表级锁
6号模式的行级锁是因为2、3号的表级锁造成的

Los bloqueos de ORACLE se colocan en los bloques DATABASE BUFFER y LIBRARY CACHE, y no ocupan otra memoria. En otros db2 e informix, los bloqueos ocuparán memoria, por lo que los bloqueos de fila de db2 se actualizarán a bloqueos de tabla.

El tipo de bloqueo se divide en tres categorías según el objeto del bloqueo:
· bloqueo DML
· bloqueo DDL
· bloqueo interno o LATCH

DML y DDL implican objetos SCHEMA visibles.
DML es nuestra declaración DELETE, UPDATE, INSERT, que opera tablas, vistas, etc., y es un objeto SCHEMA visible.

Las declaraciones DDL son ALTER TABLE, CREATE TABLE y otras declaraciones, y los mismos objetos son tablas, vistas, procedimientos almacenados, etc., que también son objetos SCHEMA visibles.

Los bloqueos internos o LATCH son invisibles para los usuarios, y los objetos encapsulados son invisibles para los usuarios. Son bloqueos internos (BIBLIOTECA CACHE, BÚFER DE BASE DE DATOS), porque estos objetos son compartidos y los objetos compartidos involucran competencia de recursos. Por lo tanto, los bloqueos deben usarse para limitar el acceso a los recursos. A los bloqueos de bajo nivel que protegen la memoria, los llamamos pestillos. Su mecanismo es similar al de los semáforos. Una carretera es pública, por lo que debemos configurar semáforos. Si es privado, entonces no hay necesidad de establecer semáforos, por lo que PGA no tiene pestillo.

DML es un bloqueo de mantenimiento de datos, que se utiliza para controlar los datos a los que acceden varios usuarios en paralelo para garantizar la coherencia. SELECT no tiene ningún bloqueo, y solo la selección para actualizar tiene bloqueos.
select...for update bloqueará la fila de resultados, lo que hará que otras sesiones no puedan actualizarse.

Un bloqueo DML es para garantizar que los datos modificados durante una determinada transacción no permitan que otras transacciones los modifiquen.
Los bloqueos DML garantizan que otras transacciones no puedan realizar DDL en la tabla mientras la transacción de la tabla que se está modificando no haya finalizado.
(Por supuesto, la sesión actual del usuario no envía la actualización de la tabla. La sesión actual del usuario puede hacer ddl directamente a la tabla. El usuario no puede hacer ddl a la tabla después de volver a abrir una sesión, y otros los usuarios no pueden hacer ddl a la mesa).

Los bloqueos DML se clasifican según diferentes niveles de objeto:
· Bloqueo TM de nivel de tabla (actúa sobre objetos de tabla, administrador de tablas)
· TX de bloqueo de nivel de fila (actúa sobre objetos de fila, Transaction eXclusive)

ORACLE no actualiza los bloqueos de nivel de fila a bloqueos de nivel de tabla.
Esto es como un patio, donde cuatro puertas forman un patio, la puerta del patio es la cerradura de la mesa y cada habitación es la cerradura de la fila.
Si en la base de datos de sqlserver, cuando hay 3 puertas para cerrar, cerraré la puerta directamente, porque la llave de bloqueo es muy costosa en la base de datos de sqlserver, para guardar las llaves, hay una actualización de bloqueo, de fila- bloqueos de nivel a bloqueos de nivel de página y luego actualice de bloqueos de nivel de página a bloqueos de nivel de tabla.

Ver el sid de la sesión actual:

SQL> select distinct sid from v$mystat;

Consulta la información de bloqueo de dos sesiones:

SQL> select sid,id1,id2,type,lmode,request from v$lock where sid in (sid1,sid2) order by sid;

El significado específico del tipo de bloqueo de consulta:


SQL> select * from V$LOCK_TYPE where type in ('TX','AE','TM','TO','OD');
TYPE  NAME           ID1_TAG           ID2_TAG           IS_USE DESCRIPTION
----- -------------- ----------------- ----------------- ------ ----------------------------------------------------------------------
TM    DML            object #          table/partition   YES    Synchronizes accesses to an object
TX    Transaction    usn<<16 | slot    sequence          YES    Lock held by a transaction to allow other transactions to wait for it
AE    Edition Lock   edition obj#      0                 NO     Prevent Dropping an edition in use
OD    Online DDLs    object #          0                 NO     Lock to prevent concurrent online DDLs
TO    Temp Object    object #          1                 NO     Synchronizes DDL and DML operations on a temp object

el caso

Caso 1

El sid de la sesión 1 es 161 y el sid de la sesión 2 es 189

sid1 no se compromete


SQL> update test set id=11;1 row updated

sid2 se ha creado sin éxito

SQL> alter table test add hid3 number;

resultados de la consulta sid3, encontraron que los bloqueos de nivel de tabla de sid1 y sid2 son ambos 3

SQL>  select sid,id1,id2,type,lmode,request from v$lock where sid in (161,189) order by sid;       
SID        ID1        ID2 TY      LMODE    REQUEST
---------- ---------- ---------- -- ---------- ----------       
161      65547       1930 TX          6          0       
161      88539          0 TM          3          0 --sid1的表级锁为3      
161        100          0 AE          4          0       
161      79833          1 TO          3          0       
189     196612       2185 TX          6          0       
189      88539          0 TM          3          0  --sid2的表级锁为3       
189        100          0 AE          4          0       
189      88539          0 OD          6          0       
189      65547       1930 TX          0          4       
189      79833          1 TO          3          0

SQL> select sid,FINAL_BLOCKING_SESSION,event from v$session where state='WAITING' and FINAL_BLOCKING_SESSION_STATUS='VALID';       
SID                FINAL_BLOCKING_SESSION   EVENT      
-----------------   ----------------------   -----------       
189                161                      enq: TX - row lock contention

Caso 2

El sid de la sesión 1 es 161 y el sid de la sesión 2 es 189


sid1不commit
SQL> update test set id=11;
1 row updated
sid2,直接报错
SQL> drop table test;
drop table test
           *
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

Después de que sid3 modifica el ddl, sid2 se ejecuta de nuevo y los resultados de la consulta sid

SQL> alter system set ddl_lock_timeout=60
SQL> select sid,id1,id2,type,lmode,request from v$lock where sid in (161,189) order by sid;
       SID        ID1        ID2 TY      LMODE    REQUEST
---------- ---------- ---------- -- ---------- ----------
       161      88539          0 TM          3          0 --sid1的表级锁为3
       161        100          0 AE          4          0
       161      79833          1 TO          3          0
       161     458768       1934 TX          6          0
       189      88539          0 TM          0          6 --sid2当前表级锁为0,但是请求表级锁6
       189        100          0 AE          4          0
       189          0          1 AE          4          0
       189      79833          1 TO          3          0

SQL> select sid,FINAL_BLOCKING_SESSION,event from v$session where state='WAITING' and FINAL_BLOCKING_SESSION_STATUS='VALID';
       SID      FINAL_BLOCKING_SESSION     EVENT
       ---      ----------------------    -------------
       189                    161          enq: TM - contention

CREATE INDEX ONLINE no ejecuta la actualización primero y luego no envía, y luego ejecuta create index online sin error, pero create index online siempre está bloqueado. Primero ejecute crear índice en línea, luego ejecute la actualización para actualizar normalmente, pero si no se envía la actualización, siempre se bloqueará la creación de índice en línea.
create index online会堵塞update吗?


Comprender: crear índice en línea está en proceso de crear un índice fila por fila. No significa que el índice se haya creado para esta fila. Al actualizar esta fila, debe esperar hasta que se completen todas las filas antes de que se cree el índice en línea. actualizado normalmente Si la actualización es anterior o posterior a la creación de índice en línea, la creación de índice en línea no afecta la actualización, pero si la actualización no se envía, afectará la creación de índice en línea.

El sid de las siguientes dos sesiones experimentales 1 es 161, y el sid de la sesión 2 es 189

Experimento 3

Ejecute create index online primero. Después de la mitad de la creación, actualice la línea con el ID de fila más pequeño. Es lógico que create index online debería haber pasado esta línea y debería bloquear la sesión de actualización. De hecho, no está bloqueada. La actualización es igual de rápida, y luego la última consulta encontré que la actualización bloqueó el índice de creación en línea.

ejecución sid1

SQL> select object_id from test1 where rowid in (select min(rowid) from test1); 
OBJECT_ID
----------
4559

sid2 se ejecuta, y por lo general toma 6 segundos para crear

SQL> create index ind_obd on test1 (OBJECT_ID) online;
Index created.Elapsed: 00:00:06.06SQL> drop index ind_obd;Index dropped.Elapsed: 00:00:00.14SQL> create index ind_obd on test1 (OBJECT_ID) online;

Durante los 6 segundos de ejecución de sid2, se ejecutó en sid1 inmediatamente, y se encontró que sid1 se ejecutó rápidamente y no bloqueó


SQL> update test1 set object_id=1 where OBJECT_ID=4559;
32 rows updated.

sid3 se ejecuta de la siguiente manera, y se encuentra que sid1 161 bloquea sid2 189

SQL> select sid,FINAL_BLOCKING_SESSION,event from v$session where state='WAITING' and FINAL_BLOCKING_SESSION_STATUS='VALID';
       SID    FINAL_BLOCKING_SESSION    EVENT
       ----   ----------------------   -------------------------
       189                    161      enq: TX - row lock contention

SQL>  select sid,id1,id2,type,lmode,request from v$lock where sid in (161,189) order by sid;
       SID        ID1        ID2 TY      LMODE    REQUEST
---------- ---------- ---------- -- ---------- ----------
       161      79833          1 TO          3          0
       161     262151       1938 TX          6          0
       161      88544          0 TM          3          0
       161        100          0 AE          4          0
       189        100          0 AE          4          0
       189      79833          1 TO          3          0
       189     131075       2139 TX          6          0
       189      88544          0 DL          3          0
       189     262151       1938 TX          0          4
       189      88552          0 TM          4          0
       189      88544          0 DL          3          0
       189      88544          0 OD          4          0
       189      88544          0 TM          2          0
13 rows selected.

Experimento 4

Ejecute create index online primero, y después de la mitad de la creación, actualice la línea con el ID de fila más grande. Es lógico que create index online no llegue a esta línea, y no bloqueará la sesión de actualización. El experimento también encontró que esto es así, la actualización es muy rápida y se realizará la última consulta. La desventaja es que la actualización bloqueó el índice de creación en línea.

ejecución sid1


SQL>  select object_id from test1 where rowid in (select max(rowid) from test1);
 OBJECT_ID
----------
      85998

sid2 se ejecuta, y por lo general toma 6 segundos para crear

SQL> create index ind_obd on test1 (OBJECT_ID) online;
Index created.
Elapsed: 00:00:06.06
SQL> drop index ind_obd;
Index dropped.
Elapsed: 00:00:00.14
SQL> create index ind_obd on test1 (OBJECT_ID) online;

Durante los 6 segundos de ejecución de sid2, se ejecutó en sid1 inmediatamente, y se encontró que sid1 se ejecutó rápidamente y no bloqueó


SQL> update test1 set object_id=1 where OBJECT_ID=85998;
32 rows updated.

sid3 se ejecuta de la siguiente manera, y se encuentra que sid1 161 bloquea sid2 189

SQL> select sid,FINAL_BLOCKING_SESSION,event from v$session where state='WAITING' and FINAL_BLOCKING_SESSION_STATUS='VALID';
       SID    FINAL_BLOCKING_SESSION    EVENT
       ----   ----------------------   -------------------------
       189                    161      enq: TX - row lock contention
SQL> select sid,id1,id2,type,lmode,request from v$lock where sid in (161,189) order by sid;
       SID        ID1        ID2 TY      LMODE    REQUEST
---------- ---------- ---------- -- ---------- ----------
       161      79833          1 TO          3          0
       161      88544          0 TM          3          0
       161     393242       2315 TX          6          0
       161        100          0 AE          4          0
       189      79833          1 TO          3          0
       189      88544          0 TM          2          0
       189      88546          0 TM          4          0
       189     458777       1936 TX          6          0
       189        100          0 AE          4          0
       189      88544          0 DL          3          0
       189      88544          0 DL          3          0
       189     393242       2315 TX          0          4
       189      88544          0 OD          4          0
13 rows selected.

Consulte qué tabla es el objeto de bloqueo y qué fila es el SQL para
averiguar primero el SID de la sesión bloqueada y luego consulte qué tabla está bloqueada y qué fila es la fila de la siguiente manera

select a.sid, a.row_wait_obj#, a.row_wait_file#, a.row_wait_block#, a.row_wait_row#,b.owner,b.object_name from v$session a,dba_objects b where a.row_wait_obj#=b.object_id and sid in (XX);

select sid, row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row# from v$session where sid in (XX);--此次查询到row_wait_obj#=-1表示是持有锁的会话

row_wait_obj#:被等待的这行在哪个对象上
row_wait_file#:被等待的这行在哪个文件上
row_wait_block#:被等待的这行在哪个块上
row_wait_row#:被等待的这行在哪行上

Bloqueos encontrados por la recopilación de estadísticas


DBMS_STATS: GATHER_STATS_JOB encountered errors
ORA-04021: timeout occurred while waiting to lock object

Al recopilar información estadística, debe bloquear la definición de la tabla o el índice. De hecho, el bloqueo aquí es un bloqueo/pin de caché de biblioteca~
no para bloquear el objeto, pero al recopilar la información estadística de un objeto, se encuentra que el objeto requerido ha sido bloqueado Otras sesiones están bloqueadas, y después de esperar un cierto período de tiempo, otras sesiones aún no han liberado los bloqueos que se han mantenido en el objeto, lo que resulta en que la sesión de estadísticas no puede obtener el bloqueo sobre el objeto

La recopilación de información estadística mantendrá el bloqueo de la memoria caché de la biblioteca del modo X (la representación de la tabla en la memoria caché de la biblioteca), por lo que habrá un bloqueo, pero no es un bloqueo de puesta en cola que normalmente entendemos.
Otros usuarios deben solicitar el bloqueo de caché de biblioteca del objeto de caché de biblioteca de tabla en modo S al analizar el SQL que usa esta tabla, y habrá conflictos/bloqueos en este momento.

Supongo que te gusta

Origin blog.csdn.net/Ruishine/article/details/129205963
Recomendado
Clasificación