Kbase 11790: Understanding performance impact of NO-UNDO and the LBI file
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Understanding performance impact of NO-UNDO and the LBI file
INTRODUCTION:
=============
One of the factors that contributes to poor performance is the way in
which program variables are handled. This Technical Support
Knowledgebase entry describes the impact of the NO-UNDO property on
procedure variables.
WHY YOU NEED TO KNOW THIS:
===========================
PROGRESS defaults to providing you with procedure variable data value
integrity in the event of an interruption to a transaction.
In many cases, however, PROGRESS's default behavior,
which updates the recorded value of program variables with each
data change, is more than you need. PROGRESS performs disk I/O to
record this information; ALL procedure variable values are written to
the local before-image file (LBI file; there is one for each user)
every time any ONE of them is updated within a transaction.
This not only generates disk I/O, but uses up disk space that may
be needed for other purposes.
PROCEDURAL APPROACH:
====================
When writing procedures that include updates to the database, whenever
possible, define variables using the NO-UNDO option. Prime
candidates for this are counters. A counter with the NO-UNDO option
tells you how many times a process has begun; a counter
without the NO-UNDO option reflects how many times that process
has completed successfully. Running totals may also be appropriate
for this attribute.
If the procedure is one that will be rerun if the system fails
during its execution, then it is likely that all the locally defined
procedure variables can take the NO-UNDO option.
When using PROGRESS built-in functions whose values are changed within
an iterating block, such as the ACCUMULATE <field> (TOTAL), use the
"DO TRANSACTION: ... END." syntax to isolate the actual changes to
record fields from the ACCUMULATE statement. If the ACCUMULATE occurs
within a transaction, its value will be written to the LBI file; if
it occurs outside a transaction, its value is not undone and no writes
to the LBI file occur.
ONLINE PROCEDURES OR UTILITIES:
===============================
/* This section shows that PROGRESS is keeping track of the change
to the accumulating total on max-credit. Press the END-ERROR (F4)
key after viewing the first five records. Note that outside the
block, the END-ERROR action caused the last increment to the
(accum total max-credit) to be backed out.
In order to keep track of what the previous value was,
PROGRESS writes to the local before image (.lbi) file
for all procedure variables that must be UNDONE.
Program variables with the NO-UNDO property
are not maintained in the .lbi file. Having many variables
monitored by the .lbi activity generates disk I/O that may not
be necessary in your application. */
DEF VAR i AS DECIMAL DECIMALS 2 NO-UNDO.
FOR EACH customer TRANSACTION WITH TITLE "BLOCK Level Transaction State":
ACCUMULATE max-credit(TOTAL).
i = i + max-credit.
DISPLAY cust-num name max-credit (ACCUM TOTAL max-credit) i.
PAUSE.
END.
DISPLAY (ACCUM TOTAL max-credit) i WITH FRAME x4.
i = 0.
/* This section also has a transaction. However, the updating
to the accum total on max-credit is performed OUTSIDE the scope
of the transaction. When the "accumulate max-credit (total)"
statement appears outside the transaction, it is not monitored
for undo processing, the value is not "undone,"
and no data is written to the LBI file. You can verify this
also by looking at the size (from the operating system)
of the LBI file during the execution of this procedure. */
FOR EACH customer WITH FRAME f2 TITLE "NARROW transaction state":
ACCUMULATE max-credit (TOTAL).
i = i + max-credit.
DISPLAY cust-num name max-credit (ACCUM TOTAL max-credit) i.
DO TRANSACTION:
UPDATE name.
END.
PAUSE.
END.
DISPLAY (ACCUM TOTAL max-credit) i WITH FRAME x3.
REFERENCES TO WRITTEN DOCUMENTATION:
====================================
PROGRESS Language Reference, the DEFINE VARIABLE Statement and
ACCUMULATE Statement reference entries
PROGRESS Programming Handbook, Chapter 8, "Transactions and Error
Processing," the sections on "PROGRESS Transaction
Mechanics" and "Doing Efficient Transaction
Processing"
Progress Software Technical Support Note # 11790