From: Blaine S. <bla...@ad...> - 2008-02-29 23:08:04
|
Ben Grommes wrote: > ... > I noticed the missing rows before any shutdown. Agreed SqlTool and the App see > the same view of the data. So my assertion is that I know there is corruption > of the in-memory state of the database because SqlTool failed to return rows > that I knew should have been there based on what the App had done up to that > point. > I think it's very likely that at this point in time, when SqlTool shows missing records, that if your app repeated the same query, it would also show those records missing. Could you paste the tail of the *.log file before recovering it (i.e., in the state where you copied it to your other server for analysis)? If it's not too big, maybe you could email (just) me the entire *.log file, obscuring any non-public data? How are you serving your data sources? Is there connection pooling involved? I'm thinking that the transaction that adds these rows is not committing before the Connection disconnects (or is broken). > Furthermore I can duplicate this corruption by restoring the database from the > .backup and .log file and getting different in-memory results with and without > the SET AUTOCOMMIT AND COMMIT statements. Restoring the database from an > edited .log file was my attempt to reproduce the problem. > I've tested the .log files before. I have never seen a case where records showing as cleanly commiting in the .log file do not get restored by the CHECKPOINT action upon startup. I'll troubleshoot if that really is occurring. |