Transacciones perdidas en SQL 2000

Tengo el siguiente drama, trabajo en SQL 2000 y Delphi 7: Abro una conexión realizo algunos insert hago COMMIT, cierro la transacción, abro una nueva consulto y me imprime los datos, osea los registro están en ese momento, pasado un tiempo, consulta nuevamente y los registros YA no existen. Todas las consultas tienen el with (nolock), son de tablas que tienen concurrencia de 150 usuarios en promedio y cada usuario genera 2 o 3 registros por minutos, en algún lugar de leí que sugerían minimizar la concurrencia pero... Eso no es como muy factible. Pareciera como que del Buffer al disco, pierde los datos.
Respuesta
1
Lo que me decís es muy pero muy raro.
Te cuento en el momento de hacer un commit, la transacción se almacena en el transaction log de forma asincronica. Una vez que pasa un determinado tiempo o el transaction log almacena una determinada cantidad de operaciones o se fuerza un CHECKPOINT todas las operaciones se almacenan en el disco rígido de forma sincrónica (esto depende mucho de la estructura de discos utilizadas).
¿Este problema que me comentas lo tienes con todas las transacciones o solamente con algunas?
Te recomendaría forzar el proceso de CheckPoint a ver que es lo que sucede, para esto ejecuta varias veces la instrucción CHECKPOINT. Tienes algún tipo de error en el log del SQL SERVER.
Si seguís teniendo el mismo problema, podrías de mover el transaction log de disco, para ver si el problema viene por ese lado
La seguimos,
Leandro
El problema no son en todas, en realidad se da cuando por algún motivo se queda bloquea la base (porque alguna tabla se bloqueo) no es frecuente, 2 o 3 registros por semana algunas ninguno, pero si me causa problemas. Lo que leí del CHECKPOINT me parece interesante seria bueno probar, solo que no encuentro ningún ejemplo de uso de la instrucción, si me lo podes pasar estaría muy agradecido...
Como te va, te comento que para usar esta instrucción lo único que tendrías que hacer, es ejecutar CHECKPOINT seguido de la instrucción GO para mayor seguridad.
Igualmente te paso una página de Microsoft donde se explica todo el procedimiento de CheckPoint en detalle
http://msdn2.microsoft.com/en-us/library/ms188748.aspx
La seguimos,
Leandro

1 respuesta más de otro experto

Respuesta
1
¿Abres una transaccion con BEGIN TRAN <tutransaccion> y luego haces COMMIT TRAN <tutransaccion>?
Si la verdad es que para ver si lograba solucionar en vez de insertar directamente los registros (cosa que hacia anteriormente y me daba error) pase a un procedimiento almacenado la inserción que tienen begin transaction y commit o rollback después hago un commit, CIERRO LA CONEXIÓN abro una nueva donde se consultan los datos según una variable que recupero a OTRO procedimiento que me da resultados y entonces se imprime el recibo (ventas, cobranzas, etc) y se imprime sin problemas, al hacer el cierre los registros no existen pero la impresión la TENGO en la mano, cree registros de auditoria pero obviamente los mismos tampoco están. Si tienes sugerencias las ESCUCHO.
Gracias.
Es muy extraño tu caso, ¿Ya has establecido alguna traza con PROFILER para ver donde anda el problema?
La verdad que el problema no es frecuente (3 vez por semana en promedio), pero me ocurre cuando tengo muchos usuarios conectados a la misma tabla (200) y lo complicado es que me ocurre lo mismo en 3 servidores distintos con SQL Server 2000. Logre identificar que eso ocurre cuando se queda bloqueada la tabla por otro usuario, hacer un traze es difícil porque no es una constante, incluso estoy pensando en conectarme desde la aplicación a OTRA base de datos (motor firebird) y que guarde ahí los registros para ver que datos genero, en las tablas tengo las claves por generadores, no se si eso le jode pero no se más que hacer. Mi propuesta final fue CAMBIAR de motor, pero no puedo creer que así de problemático sea el SQL. Me imagino que tiene que ser alguna configuración de la instalación o algo por el estilo pero me leí todos los documentos que encontré en internet y no dice nada de como solucionarlo. No soy el único con ese problema, cuando tiene pocos usuarios 50 - 70 sin problema. Pero cuando es concurrencia masiva de usuarios a la misma tabla con muchas transacciones por minuto mata. Lo que se pensé es que el hace un commit pero guarda en el buffer de paginación, y no en disco y al bajar a disco es el problema pero no se si eso puede ser... escucho sugerencias.
Obs: la Tabla tiene como 3.000.000 de registros (que no es mucho en teoría)
Gracias por la Atención
Yo tuve un caso de al menos unas 500 transacciones por segundo y nunca llegue a perder información, me parece que es más de programación.

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas