Mejorar Transacciones

No, la única manera de "optimizar las transacciones" es optimizando los
objetos que se acceden dentro de esa transacción. Es decir, si se accede a
una tabla, que exista un índice útil para recueperar los datos más
rápidamente; si se ejecuta un procedimiento almacenado, que su código sea lo
más eficiente posible, y así con todo.

Por supuesto, si hay cosas que no es necesario que se ejecuten dentro de la
transacción, sácalas de ella. Comprueba también el orden de acceso de las
tablas para que no se produzcan deadlocks

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


"SpoPoBiCH" wrote:

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.

si bueno el rendimiento en las tablas mediante indices y utilizando
las mejores instrucciones en las sentencias tambien he mirado. Pero
recuerdo que una vez lei algo de microsoft que decia que los commits
es mejor ejecutarlos cada cierto numero de registros ya que no es lo
mismo en rendimiento lo que pasa es que no me acuerdo cuantos
eran o que era lo idóneo

Hombre, ten en cuenta que cuanto menos registros abarque la transacción,
menos recursos tendrá que tener bloqueados. Sin embargo, eso depende más del
aspecto funcional que del rendimiento; es decir, si necesitas que todos los
registros se actualicen en bloque o no, no puedes ir confirmando
transacciones cada 100 registros afectados (por poner un ejemplo) porque si
falla en el 101, ¿qué haces con el resto que sí se actualizaron (y se
confirmó la transacción)?


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


"SpoPoBiCH" wrote:

si bueno el rendimiento en las tablas mediante indices y utilizando
las mejores instrucciones en las sentencias tambien he mirado. Pero
recuerdo que una vez lei algo de microsoft que decia que los commits
es mejor ejecutarlos cada cierto numero de registros ya que no es lo
mismo en rendimiento lo que pasa es que no me acuerdo cuantos
eran o que era lo idóneo

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, cada cuanto es mejor hacer un commit? no es una respuesta simple, a
ver, debes hacerlo cuando realmente lo necesites, si tu proceso por logica
requiere de hacer mil transacciones y si una falla volver todo atras
entonces tu transaccion sera grande. Lo que debes definir cuan atomico
necesitas el proceso, lo ideal y como buena practica es que las
transacciones sean cortas, eso no quiere decir pocas lineas ni mucho menos,
la cosa es no poner dentro de la transaccion cosas que no van , eso es lo
sumamente importante y hara que tengas menos lokeos.

Por ejemplo, si abris una transaccion, guardas las cabecera, el detalle y
ademas mandas a imprimir eso estaria mal, deberias abrir la transaccion l
guardar la cabecera el detalle, hacer el commit y luego imprimir.

Esa es la idea, y no hay un numero de registros recomendado por transaccion

"SpoPoBiCH" escribió en el mensaje de
noticias:

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.