use of Journal Transaction Level
search cancel

use of Journal Transaction Level


Article ID: 100175


Updated On:




What will Journal Transaction Level help, and what possible problems could it cause?


Release: IDADSO00100-18.5-ADS-for CA-IDMS


  Journal Transaction Level is a method to attempt to cause disk journal blocks to be as fully utilized as possible.
  All active update transactions write to the same journal buffer page until it is full or is forced to be written to the Disk Journal. 

  With Journal Transaction level off (set to 0) any active update transaction that has done one or more updates and issues a COMMIT or FINISH will force the current journal buffer to be written to the active disk journal regardless of how full the journal buffer is.  
  Short transactions that update few DB records can cause the current journal buffer page to be written when it is far from full, thus not fully utilizing the disk journal blocks.

  When you set Journal transaction level to a non-zero number here is what occurs.

  When any active update transaction issues COMMIT or FINISH, IDMS will check the JTL setting. 
  IF there are an equal or greater number of active update transactions, the writing of the journal buffer required by the COMMIT/FINISH is delayed until the buffer is full, with the expectation that the other active update transactions will do enough updates to fill the journal buffer.
  If there are fewer active update transactions than the JTL setting the Journal buffer is written when any of the active update transactions issue the COMMIT/FINISH regardless of how full the journal buffer is.
  Implementation of JTL implies that you are willing to see an increase in the duration of journal write waits in exchange for better utilization of your journal blocks.  In a system with constant database updates this increase in the duration of journal write waits is very minimal.  

  There is no general recommendation as far as the number to set for JTL.
  What will work best depends on the size of the journal buffer (size of the Disk Journal blocks) and the types of transactions running at any given time and how much work they do.
  This is a feature with which you must experiment to see what works for your CV.

  The goal is to find a number that will get you the most fully utilized disk journal blocks BUT does not cause any unacceptable increases in the duration of the waits on Journal Write I/O.

  Each ARCHIVE JOURNAL job will present a histogram of how fully utilized each Disk journal block was at Archive time (PERCENTAGE DISTRIBUTION PER PAGE histogram).

  Typically, a JTL number between 5 and 10 is best for most CVs but as mentioned, there are many factors that may influence this.

  A recommended method for determining if enabling JTL is needed at all is to look at the  PERCENTAGE DISTRIBUTION PER PAGE histogram in each ARCHIVE JOURNAL job.

  If this shows that the majority of pages are full or mostly full then there is no need to enable JTL.

  If you see that most pages are less than 50% full you may benefit from enabling JTL.

  Before enabling JTL get as good a picture as possible of the number and duration of Journal Write waits.
  PMARPT36 and PMIRPT25 are good reports for this.  Realtime monitoring with PMRM can show if any tasks are waiting journal I/O. 

  Recommended starting value is 10.  After running this way for a number of journal archives check the PERCENTAGE DISTRIBUTION PER PAGE histogram to see if the utilization has improved.
  Also, you do not want to see any significant increase in the duration of waits for Journal Write I/O.

  If the journal block fill is still not where you want it to be, decrease JTL by one and continue to monitor.

  If you set the JTL too high then we may not ever delay the writing of the journal buffer and this will provide no help in better utilization of the disk journal blocks.

*NOTE*   If you set JTL too low you could cause a situation where ALL active update transactions have issued a COMMIT or FINISH, BUT the journal buffer is not full and no additional update transactions are running that can fill the buffer.

  In such a case these transactions could end up Stalling on JRNL I/O (DC001003 abend code) and their updates rolled out. 
  While such transaction are waiting they continue to hold all Locks and other CV resources and therefore can cause performance problems.

  You set JTL to 4.  There are currently 4 active update transactions and ALL of them have issued COMMIT or FINISH but the Journal Buffer page is not yet full.
   Those 4 tasks will wait on JRNL Write I/O and if no additional tasks execute and fill the journal buffer those tasks will stall when they exceed INACTIVE INTERVAL and in the meantime will be holding all locks and other CV resources thus  causing a performance problem.