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!!!