Ver Mensaje Individual
  #8  
Antiguo 29-09-2012
rolandoj rolandoj is offline
Miembro
 
Registrado: abr 2007
Posts: 395
Reputación: 18
rolandoj Va por buen camino
Comentarios

Hola a todos,Perdón por la demora. Me ocuparon en otras cosas y me tocó dejar el tema de lado.Empiezo con una observación de metodología. Efectivamente, el componente que uso para Transacciones es uno solo para todas, ya que es el mismo componente de conexión a la Base de Datos. Simplemente que en cada hilo una transacción se inicia y se cierra de manera totalmente independiente de cualquier otra que esté ocurriendo en otro hilo.El borrado físico de los registro inservibles, que yo sepa y como dice Casimiro, se da solo cuando hacemos las operaciones de BackUp/Restore. Eso se evidencia porque se disminuye el tamaño de la Base de datos al hacerlo. Ese proceso, como plantea ElMug es realmente una "defragmentación" de la Base de Datos; no solo para ahorrar espacio sino para reubicar datos de tal forma que los accesos de lectura sean más eficientes.Ahora bien, cuando se marcan como inservibles y se pueden reusar los registros temporales ?. Yo siempre había pensado, como dicen ustedes, que eso era hecho al fin de cada transacción; entre otras cosas porque lo lógico es que si ya la transacción fué exitosa, se liberen los recursos. Especialmente porque al poder reusar esos espacios el crecimiento de la Base de Datos es menor, favoreciendo el rendimiento.Sin embargo, el artículo que leí es el que me ha metido la duda porque si eso sigue así, como afirman ustedes y aparentemente dicta la lógica, a que se refieren los del artículo ?. No me puedo imaginar otro tipo de recurso que no se libere en el commit suave (o commit retain) y que pueda afectar el rendimiento de la Base de Datos tamto como ellos advierten.Si a ninguno se le ocurre una explicación, hay que pensar que, o bien los del artículo están equivocados, o hay algo que nosotros no sabemos.
Responder Con Cita