Mejorar Transacciones

Las transacciones, cuanto más cortas, mejor. Por tanto, si la lógica de ese
proceso te permite partir en "cachitos" ese proceso costoso, las conexiones
podrán acceder a los recursos antes porque no estarán bloqueados tanto tiempo.

El que se verá "afectado" será el registro de transacciones, que se verá
obligado a escribir más confirmaciones, aunque no creo que eso sea un
problema.

En cualquier caso, lo único que te va a sacar de dudas es hacer pruebas,
cómo se comporta tu sistema con transacciones largas o cortas (estas pruebas
deben incluir conexiones simultáneas, claro está)


Un saludo
-
www.navento.com
Servicios de Localización GPS


"SpoPoBiCH" wrote:

si ... en este caso no me preocupa demasiado, ya que guardo el
registro, en ese caso los que ya se ha confirmado la transacción y de
error en el 101 pues la siguiente empiezo desde el error..

Entiendo que cuantos menos registros pues.. si.. menos recursos
deberia tener... pero mi duda: ¿al motor le costara mas almacenar
datos en la transacción (aunque trague con recursos) o aceptar
transacciones mas cortas pero al escribir y confirmar esos registros
mas a menudo en las tablas tarde mas...? no se si me comprendes,
desconozco cuanto penalizaría una cosa contra la otra, aunque ya hemos
reducido considerablemente el proceso programando mejor TSQL pues me
surgió esa duda
Escritura en memoria de la transacción frente a la aceptación de la
transacción mas a menudo, teniendo en cuenta muchos miles de registros
claro..

Hola,

Por lo que he ido leyendo en este hilo yo creo que si tus necesidades a
nivel de transacción son a nivel de cliente (es lo que pareces indicar por
lo que dices) creo que la transacción la haría lo más corta posible, es
decir 1 por cliente. Lo que comentas de decidir el tamaño del "batch" es
algo que afecta más cuando estamos realizando importaciones masivas con bulk
insert o procesos similares. A nivel de cantidad de datos a escribir en el
log de transacciones no hay gran diferencia y sin embargo en hacer commits
frecuentes puede ayudarte a evitar problemas de bloqueos, lentitud en los
rollback en caso de producirse, etc.

Por tanto yo me centraría en la buena práctica de mantener las transacciones
lo más cortas posibles teniendo en cuenta las necesidades transaccionales de
tu lógica de negocio. Es decir, si tu necesitas mantener esa
transaccionalidad de tu proceso a nivel de cliente, la transacción la haría
a nivel de cliente. Otra cosa es que por las posibilidades de reinicio de tu
proceso puedas incluso prescindir totalmente de las transacciones explícitas
y eso es algo que deberías considerar también.

Un saludo,

Rubén Garrigós
Solid Quality Mentors

"SpoPoBiCH" wrote in message
news:
Hola

Tengo un procedimiento que actualiza unas 250 tablas en algunas
con muchos registros otras con menos... el caso es que hago
transacciones y me gustaria saber que es mejor o cada cuanto es mejor
hacer un commit os comento el proceso...

estos son muchos clientes y cada uno de los clientes actualiza algo en
las 250 tablas yo ahora hago un commit cada 50 clientes que viene a
ser 250 x 50 = 12500 updates de n registros cada una...

¿Se puede optimizar con las transacciones reduciendo tiempo de
ejecucion...? es decir haciendo un commit antes o despues...

Gracias por la ayuda.