Re: Commitment Control Overhead

[ywexler@xxxxxxx]

Karen Bellecci wrote:
> 
> Can someone steer me in the direction of statistics about using Commitment 
>Control.  I have only found the Advanced Backup and Recovery text talking 
>about CC, so far.
> 
> It looks like there will be at least two added disk I-Os for journaling the 
>before and after images of each record; two added disk I-Os for journaling the 
>start and end commitment boundary for each logical unit of work (LUW).  If I 
>use OMTJRNE on my journal definition, I may avoid the writing of journal 
>entries for the history of LUW resources and save on those I-Os.
> 
> So, for example, if I have two write statements in my LUW, I increase the 
>disk I-Os by 4 + 2, or 3 times as many disk I-Os as without CC.
> 
> What other things do I need to factor in?   Is something published on this?
> 
> Thanks.  Karen Bellecci
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
Karen,
We use CC for a long time and our opinion here is the overhead caused by
CC is justified by the advanteges of CC.
To your question - under CC the transaction is written first to a
temporary place on the disk, then to the journal and only at last to the
DB files. The temporary space on the disk assumed to be placed on a fast
disk, meanning the system disk.
The reason of the sequence is that in case your job fails befor the end
of commit cycle (COMMIT command) entire transaction or the part already
written is ROLLBACKed.
Yossi Wechsler
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---