Traslape de transacciones en SQL 2000

Seguramente el tema es que en 6.5 se producia la famosa contencion sobre la
ultima pagina de datos porque tienes un indice clustered con inserciones
consecutivas monotonas crecientes y como te ha explicado Adrian se puede
producir un efecto serializador sobre las transacciones debido al bloqueo de
pagina producido. Sin embargo si el segundo insert se produce en el momento
en que la pagina se llena este puede hacerse sin problemas debido a que no
hay bloqueos. Si los insert no van a parar a la misma pagina esto no se
produce. Ese era el motivo por lo que no se sugeria en ocasiones indices
clustered para columnas identity.

Si dos transacciones insertan en la misma tabla no tienen por que
serializarse en ninguna de las versiones (salvo comentario anterior).

Yo te sugiero que revises SET TRANSACTION ISOLATION LEVEL y lo cambies de
READ COMMITTED (default) a SERIALIZABLE para dichas transacciones.antes de
jugar con los HINTS

Donde dices:

> teoricamente solo debe de entrar una a la
> vez, cuando termina la primera, entra la otra, asi
> sucesivamente, esto pensando en el Begin y Commit que se
> encarga de completar la insercion, sin dejar entrar a
> otra, pero no es asi

Existe un error. Las transacciones no son para que otro proceso no logre
hacer un insert sino que son una "secuencia de operaciones realizadas como
una simple unidad logica de trabajo con cuatro propiedades llamadas ACID
(Atomicity, Consistency, Isolation, and Durability)" (del HELP)


Atomicity = atomicidad - todo o Nada
Consistency = Consistencia - los datos deben quedar consistentes
(integridad, estructuras internas de la base, etc)
Isolation = aislamiento - Las modificaciones de las transacciones
concurrentes estan aisladas y no ven estados intermedios de las otras
transacciones.
Durability - Despues de aplicados los efectos perduran

No te han aparecido deadlocks ?

Jose Mariano Alvarez
Comunidad de base de datos
Grupo de Usuarios Microsoft
www.mug.org.ar

"Adrian Garcia" wrote in message
news:%

Creo que en 6.5 tu sistema funcionaba porque esa version de SQL Server
bloquea hasta nivel de pagina. Es decir, si modifica una fila en una

pagina,

hasta que no termina no permite acceder a las demas transacciones hasta

que

ella termine.
El SQL Server 7 en adelante el nivel minimo de bloqueo es a nivel de

filas,

por ende tus transacciones no se serializan como antes sino que entran en
forma concurrente.
Lo que puedes hacer es utilizar los hints de SQL Server en las

instrucciones

SQL
Por ejemplo, si deseas actualizar una tabla y quieres que realize bloqueos

a

nivel de pagina (como SQL Server 6.5) puedes hacer

UPDATE mitabla WITH (PAGLOCK)
SET
WHERE

Tambien puedes hacer esto en SELECT, DELETES e INSERT.

Si esto no genera los resultados esperados prueba con:

UPDATE mitabla WITH (PAGLOCK, HOLDLOCK)


El HOLDLOCK mantiene los bloqueos hasta que termine la transaccion,
serializandola totalmente.

Hay que tener en cuenta de que si implementas esto vas a disminuir la
concurrencia de transacciones sobre esas tablas, con una perdida general

de

rendimiento de tu servidor.
No es posible rediseñar la transaccion de manera tal de no depender de un
bloqueo de paginas?

Saludos
Adrian D. Garcia
NDSoft

"Adolfo" wrote in message
news:671701c3e69a$8b8754c0$
> El problema que tengo es cuando dos o mas transacciones
> accesan a la misma Base de datos y tabla a insertar
> informacion , teoricamente solo debe de entrar una a la
> vez, cuando termina la primera, entra la otra, asi
> sucesivamente, esto pensando en el Begin y Commit que se
> encarga de completar la insercion, sin dejar entrar a
> otra, pero no es asi, ademas si realizo un rollback en
> cualquiera de las transacciones, realiza un rollback de
> todas, esto via codigo, y ademas me revuelve las claves
> principales que tengo en mi tabla, y se vuelve un
> desbarajuste de informacion, no se si tengo que configurar
> algo en el manejador de BD o falta algun parche, o checar
> mi tipo de conexion que reliza el sistema, ya que antes
> este sistema operaba en SQL 6.5, y sin ningun problema, y
> al migrarlo a SQL 2000 se detectaron estos problemas,
> agradeceria algun comentario que me ayude a resolver este
> problema, Gracias!!!

Creo que en 6.5 tu sistema funcionaba porque esa version de SQL Server
bloquea hasta nivel de pagina. Es decir, si modifica una fila en una pagina,
hasta que no termina no permite acceder a las demas transacciones hasta que
ella termine.
El SQL Server 7 en adelante el nivel minimo de bloqueo es a nivel de filas,
por ende tus transacciones no se serializan como antes sino que entran en
forma concurrente.
Lo que puedes hacer es utilizar los hints de SQL Server en las instrucciones
SQL
Por ejemplo, si deseas actualizar una tabla y quieres que realize bloqueos a
nivel de pagina (como SQL Server 6.5) puedes hacer

UPDATE mitabla WITH (PAGLOCK)
SET
WHERE

Tambien puedes hacer esto en SELECT, DELETES e INSERT.

Si esto no genera los resultados esperados prueba con:

UPDATE mitabla WITH (PAGLOCK, HOLDLOCK)


El HOLDLOCK mantiene los bloqueos hasta que termine la transaccion,
serializandola totalmente.

Hay que tener en cuenta de que si implementas esto vas a disminuir la
concurrencia de transacciones sobre esas tablas, con una perdida general de
rendimiento de tu servidor.
No es posible rediseñar la transaccion de manera tal de no depender de un
bloqueo de paginas?

Saludos
Adrian D. Garcia
NDSoft

"Adolfo" wrote in message
news:671701c3e69a$8b8754c0$

El problema que tengo es cuando dos o mas transacciones
accesan a la misma Base de datos y tabla a insertar
informacion , teoricamente solo debe de entrar una a la
vez, cuando termina la primera, entra la otra, asi
sucesivamente, esto pensando en el Begin y Commit que se
encarga de completar la insercion, sin dejar entrar a
otra, pero no es asi, ademas si realizo un rollback en
cualquiera de las transacciones, realiza un rollback de
todas, esto via codigo, y ademas me revuelve las claves
principales que tengo en mi tabla, y se vuelve un
desbarajuste de informacion, no se si tengo que configurar
algo en el manejador de BD o falta algun parche, o checar
mi tipo de conexion que reliza el sistema, ya que antes
este sistema operaba en SQL 6.5, y sin ningun problema, y
al migrarlo a SQL 2000 se detectaron estos problemas,
agradeceria algun comentario que me ayude a resolver este
problema, Gracias!!!

A mi tampoco me gusta jugar con los HINTs pero en este caso creo que setear
el ISOLATION LEVEL no genera bloqueos de paginas como la solucion de los
HINTs, con lo cual su codigo no va a funcionar "a la SQL Server 6.5".

Saludos
Adrian D. Garcia
MCSD
NDSoft Consultoria y Desarrollo

"Jose Mariano Alvarez (MUG)" <jose.alvarez * *Arroba* * mug.org.ar> wrote in
message news:

Seguramente el tema es que en 6.5 se producia la famosa contencion sobre

la

ultima pagina de datos porque tienes un indice clustered con inserciones
consecutivas monotonas crecientes y como te ha explicado Adrian se puede
producir un efecto serializador sobre las transacciones debido al bloqueo

de

pagina producido. Sin embargo si el segundo insert se produce en el

momento

en que la pagina se llena este puede hacerse sin problemas debido a que no
hay bloqueos. Si los insert no van a parar a la misma pagina esto no se
produce. Ese era el motivo por lo que no se sugeria en ocasiones indices
clustered para columnas identity.

Si dos transacciones insertan en la misma tabla no tienen por que
serializarse en ninguna de las versiones (salvo comentario anterior).

Yo te sugiero que revises SET TRANSACTION ISOLATION LEVEL y lo cambies de
READ COMMITTED (default) a SERIALIZABLE para dichas transacciones.antes de
jugar con los HINTS

Donde dices:

> > teoricamente solo debe de entrar una a la
> > vez, cuando termina la primera, entra la otra, asi
> > sucesivamente, esto pensando en el Begin y Commit que se
> > encarga de completar la insercion, sin dejar entrar a
> > otra, pero no es asi

Existe un error. Las transacciones no son para que otro proceso no logre
hacer un insert sino que son una "secuencia de operaciones realizadas como
una simple unidad logica de trabajo con cuatro propiedades llamadas ACID
(Atomicity, Consistency, Isolation, and Durability)" (del HELP)


Atomicity = atomicidad - todo o Nada
Consistency = Consistencia - los datos deben quedar consistentes
(integridad, estructuras internas de la base, etc)
Isolation = aislamiento - Las modificaciones de las transacciones
concurrentes estan aisladas y no ven estados intermedios de las otras
transacciones.
Durability - Despues de aplicados los efectos perduran

No te han aparecido deadlocks ?

Jose Mariano Alvarez
Comunidad de base de datos
Grupo de Usuarios Microsoft
www.mug.org.ar

"Adrian Garcia" wrote in message
news:%
> Creo que en 6.5 tu sistema funcionaba porque esa version de SQL Server
> bloquea hasta nivel de pagina. Es decir, si modifica una fila en una
pagina,
> hasta que no termina no permite acceder a las demas transacciones hasta
que
> ella termine.
> El SQL Server 7 en adelante el nivel minimo de bloqueo es a nivel de
filas,
> por ende tus transacciones no se serializan como antes sino que entran

en

> forma concurrente.
> Lo que puedes hacer es utilizar los hints de SQL Server en las
instrucciones
> SQL
> Por ejemplo, si deseas actualizar una tabla y quieres que realize

bloqueos

a
> nivel de pagina (como SQL Server 6.5) puedes hacer
>
> UPDATE mitabla WITH (PAGLOCK)
> SET
> WHERE
>
> Tambien puedes hacer esto en SELECT, DELETES e INSERT.
>
> Si esto no genera los resultados esperados prueba con:
>
> UPDATE mitabla WITH (PAGLOCK, HOLDLOCK)
>
>
> El HOLDLOCK mantiene los bloqueos hasta que termine la transaccion,
> serializandola totalmente.
>
> Hay que tener en cuenta de que si implementas esto vas a disminuir la
> concurrencia de transacciones sobre esas tablas, con una perdida general
de
> rendimiento de tu servidor.
> No es posible rediseñar la transaccion de manera tal de no depender de

un

> bloqueo de paginas?
>
> Saludos
> Adrian D. Garcia
> NDSoft
>
> "Adolfo" wrote in message
> news:671701c3e69a$8b8754c0$
> > El problema que tengo es cuando dos o mas transacciones
> > accesan a la misma Base de datos y tabla a insertar
> > informacion , teoricamente solo debe de entrar una a la
> > vez, cuando termina la primera, entra la otra, asi
> > sucesivamente, esto pensando en el Begin y Commit que se
> > encarga de completar la insercion, sin dejar entrar a
> > otra, pero no es asi, ademas si realizo un rollback en
> > cualquiera de las transacciones, realiza un rollback de
> > todas, esto via codigo, y ademas me revuelve las claves
> > principales que tengo en mi tabla, y se vuelve un
> > desbarajuste de informacion, no se si tengo que configurar
> > algo en el manejador de BD o falta algun parche, o checar
> > mi tipo de conexion que reliza el sistema, ya que antes
> > este sistema operaba en SQL 6.5, y sin ningun problema, y
> > al migrarlo a SQL 2000 se detectaron estos problemas,
> > agradeceria algun comentario que me ayude a resolver este
> > problema, Gracias!!!
>
>