Hi JayJay The transaction processing will not write incomplete transactions to the disk file at the time of suspend.file protecting transactional integrity. I believe that the dbpause completes any writes before pausing.
However one area I am not sure of is the data in buffers. The suspend program mentions checking buffers are flushed. This could be an issue for sequential writing. Regards David Jordan > However, I too am curious about the Server 2003 VSS (not *nix, > sorry!). Running it cannot cause corruption to the Unidata files even > while people are logged in -- is that correct? > > From what I've read, Server 2003 lets the processes finish their disk > writes, pauses the processes on an OS level, writes the disk branching > information, and then resumes the processes. Programs wouldn't even > known it's happening. > > Even deleting the VSS restore point is a safe operation as far as I > know in that it simply writes the new file indexes stored in the > restore points into the master file table, right? > > That's where the VSS awareness comes in, right? Programs that are > aware could ensure data integrity through transactional logs. I'm > guessing it's the restore that would be the issue. Although the > processes would finish their writes, that would just be for one block > of data and you could be missing part of a record in a file or even > have inconsistencies between files if you tried to restore. Risky, > risky... > > I guess my question now is: *on Windows*, do the dbpause/dbstart or > SUSPEND.ON/SUSPEND.OFF commands ensure structural integrity to some > extent, like Martin Phillips said earlier? If I start to write array > variable ABC containing 10,000 items 1000 characters each in length to > a file, and that file is only valid if ABC is completely written, will > it let ABC finish writing to that file? Will I have to check after > the restore if only 9,999 items were written? ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
