Hi Joe! How have you been! I miss working with you at Quest, but anyhow I am at GoldenGate now, replicating SQL Server databases. Quite fun!
Anyhow, to get right to the point, if you can shed light on this question of mine I will owe you a favor.
We have been struggling with an issue here for over a week that I finally resolved I think is a dirty cache in a RAID 1 or SAN driver. The symptom is that our logreader reads from the SQL Server active ldf right while SQL server is writing to it, and we end up getting a buffer that has an older part of an older VLF in the first sector(s) in our buffer followed by the new VLF they are writing in the later sectors in our buffer. They do write over the entire area of course, but we seem to miss the first sector(s) due to split IOs likely. So we have early data FIRST followed by new data later in our buffer. It is non-buffered IO, HOWEVER, (1) we call DuplicateHandle on the same handle SS has, and (2) customer has RAID 1 on a SAN. And here is the real problem...we rebuild the ldf layout (read in each VLF header in the ldf) then go back and re-read the spot that we had the "split IO" on a moment earlier (3 or 4 seconds at least) (and even verify that SS is now writing in yet the NEXT VLF) and STILL get the same problem. So my question is, is it possible that a split IO read was in progress on the SAN, and at the same time before it completed a SQL Server write came in, did not see any kernel buffer to update or make dirty yet, so passed the write through, and then finally the read completed leaving a dirty cache that the driver did not know was dirty? What do you think?
