johnm@vaxc.cc.monash.edu.au (John Mann) (10/05/88)
I am looking for anyone willing to share their knowledge of RMS Journaling. We are looking at using it for a large database enquiry/update system to decide whether to buy RMS Journaling or do some simpler home-brew transaction logging and recovery procedures. (1) Does anyone out there actually use RMS Journaling? (2) How many extra disk I/O operations does RMS Journaling cause? Assume a simple example: two database files with After Image Journaling (to the same journal file), and Recovery Unit Journaling (to per-process files). 1. $START_RU 2. $GET file 1 3. $GET file 2 4. $UPDATE file 1 5. $UPDATE file 2 6. $END_RU I assume copies of the unmodified records will be written to the RU journal, then copies the modified buckets will be written to the AI journal, and then the buckets will be updated in the database. Which lines of code above generate I/O operations to which files? It is allowable for modified database buckets to sit in memory for a while, but journal files should get written out sooner. Can you tune the delays before writing? Do writes to the journal file happen asynchronously, or does the process wait until the write has completed? Does a write to a journal file involve writing the data to the file, and another write to update the EOF pointer in the journal file's header? I could imagine RMS Journaling causing the disk I/O load to double, or worse :-(. (3) Does Recovery Unit Journaling provide enough protection? The RMS Journaling, Version 5.0 SPD states: > RMS Recovery Unit Journaling does not provide recovery from the > following scenarios when a multi-block bucket write to an indexed file > is in progress, leaving a bucket in the indexed file in a corrupt state: > > + Failure of the VAX host during a multi-block write operation (e.g. VMS > crash, halt, powerfailure, or system shutdown) > ... > In such a case, after-image (AI) Journaling must be used to recover > from these errors. How common is indexed file corruption due to a system crash? Having RU Journaling quickly undo incomplete transactions after some failures was one of its major appeals. We were hoping to have to apply the AI journal to a backup copy of the database only in drastic situations like disk failure. Having to do a complete database recovery after a system crash would lead to lots of down-time and would be inconvenient to the users (they might forget what they were doing, go home etc.). If we assume that the RU Journal has copies of data that was about to be changed in the database, then surely an indexed file is only vulnerable to failures during writes to the index buckets? Can we work around the crash-during-multi-block-write problem by doing silly things like making the index use single block buckets? (4) Are we going to see Audit Trail Journals (soon)? I haven't seen RMS Journaling mentioned in comp.os.vms before, so perhaps there isn't much interest in it. If you mail your responses to me, I will summarize to the net. John Mann --- John Mann, Systems Programmer, Computer Centre, Monash Uni. VIC 3168, Australia Internet: johnm@vaxc.cc.monash.edu.au Phone: +61 3 565 4774 ACSnet: johnm@vaxc.cc.monash.oz