Tablas con índice y opción IGNORE_DUP_KEY=ON problemas en los bloqueos al insertar en la tabla
-
Hola,
Tengo una aplicación en SQL Server 2008 con varias tablas que tienen índices únicos con la opción IGNORE_DUP_KEY=ON que me permite insertar masivamente datos desde otras fuentes sin provocar errores de duplicados del índice. Sin embargo esta opción del índice me da problemas a la hora de realizar inserciones en una tabla desde diferentes transacciones que hacen los diferentes usuarios. Por ejemplo un usuario agrega un registro a una tabla en cuestión dentro de una transacción y hasta que no se termina la transacción otros usuarios no pueden insertar registros en esa tabla por que se encuentra bloqueada. ¿Como puedo solucionar este problema?
Saludos,
José Antonio Muñoz
-
Antes que nada, bienvenido a este sitio.
Te recomiendo que escribas en inglés ya que así recibirás más ayuda y no te quedarás con la ayuda de sólo unos cuantos que hablamos español.
Ahora, estás hablando de 2 problemas distintos, la opción IGNORE_DUP_KEY=ON que evita que toda una operación de insert falle. Sin embargo, no estoy seguro de que se relacione con el otro detalle que comentas.
Cuando se realiza una instrucción de lectura o escritura sobre una tabla, esta (o parte de esta) queda bloqueada para mantener la integridad de las bases de datos. Para evitar problemas, te recomiendo que leas acerca de los TRANSACTION ISOLATION LEVELS para que veas si te puede ayudar a solucionar tu problema.
-
Ich habe keine Ahnung, wovon du sprichst, Luis!
(I have no idea what you're talking about, Luis!) 😀
-
LutzM (11/12/2013)
Ich habe keine Ahnung, wovon du sprichst, Luis!(I have no idea what you're talking about, Luis!) 😀
I'm just trying to help 😀
I just hope people won't rely just on me.
-
Hola Luis, gracias por tu respuesta,
pero quiero comentarte que no son problemas distintos, antes de solicitar ayuda en el foro he analizado todo lo que me comentas. He probado las diferentes configuraciones de TRANSACTION ISOLATION LEVELS pero el problema persiste. En cuanto a la opción IGNORE_DUP_KEY en la creación de índices no es por una intuición mía el hecho de que está provocando el problema en el bloqueo de la tabla en cuestión, si no por que lo he analizado haciendo diversas pruebas: he creado una tabla con un índice único clustered con la opción IGNORE_DUP_KEY=OFF, y funciona perfectamente las inserciones de registros en diferentes transacciones, no se producen bloqueos. Sin embargo la misma tabla la creo con el mismo índice y con la opción IGNORE_DUP_KEY=ON y a partir de ahí se reproducen los problemas que he comentado al principio.
Hi Luis, thanks for your answer,
but I want to tell that there are different problems, before asking for help in the forum I analyzed everything I comets. I've tried different configurations TRANSACTION ISOLATION LEVELS but the problem persists. As for the option IGNORE_DUP_KEY indexing is not my intuition that is causing the problem in locking the table in question, if not I analyzed by various tests: I created a table with a single index with the option clustered IGNORE_DUP_KEY = OFF, and works perfectly insertions in different transaction records, no blockages occur. But I think the same table with the same index and IGNORE_DUP_KEY = ON option and thereafter causes the problems I mentioned at the beginning.
-
This is an example:
Example A:
CREATE TABLE Tabla (Codigo Int, Fecha Date);
CREATE UNIQUE NONCLUSTERED INDEX X_Prueba ON Tabla (Codigo) WITH (IGNORE_DUP_KEY=ON);
(In session 1)
BEGIN TRAN
INSERT Tabla VALUES (1,'01/01/2013')
(1 rows affected)
(In session 2)
BEGIN TRAN
INSERT Tabla VALUES (2,'02/01/2013')
Error: Exceeded timeout lock request.
Example B:
CREATE TABLE Tabla (Codigo Int, Fecha Date);
CREATE UNIQUE NONCLUSTERED INDEX X_Prueba ON Tabla (Codigo) WITH (IGNORE_DUP_KEY=OFF);
(In session 1)
BEGIN TRAN
INSERT Tabla VALUES (1,'01/01/2013')
(1 rows affected)
(In session 2)
BEGIN TRAN
INSERT Tabla VALUES (2,'02/01/2013')
(1 rows affected)
as shown in the example to change the option: IGNORE_DUP_KEY=ON into IGNORE_DUP_KEY=OFF pruduce not lock in session 2.
Thanks and regards,
Jose Antonio Muñoz
-
Hi,
Your example shows that the insert with IGNORE_DUP_KEY = ON produces a much more complicated query plan because it needs to filter out the duplicates before performing the insert. This also introduces an extra Key Range Lock as seen in sp_lock.
-
What that means? What no solution? Do I have to set the option IGNORE_DUP_KEY=OFF to work well locks when inserting? Is not there another solution? :crying:
thanks and regards
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply