Kbase P144567: 4GL/ABL: What explains the extra 'Record Reads' reported in the Promon Option 5 report after reading
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
15/04/2009 |
|
Status: Unverified
GOAL:
4GL/ABL: What explains the extra 'Record Reads' reported in the Promon Option 5 report after reading from a database table?
GOAL:
Why does Promon Option 5 report extra 'Record Reads' when I execute a FIND FIRST against a table that has a primary unique index?
GOAL:
Why does Promon Option 5 report more 'Record Reads' than the number of records in the table when I execute a FOR EACH against a table?
GOAL:
Does Progress / OpenEdge read some VST table records and include these reads in the Promon Option 5 report?
GOAL:
Does Progress / OpenEdge read Index Binary Tree records and include these reads in the Promon Option 5 report?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
FIX:
The extra 'Record Reads' reported by the Promon Option 5 after executing a FIND, FOR EACH or an OPEN QUERY, etc., which are more pronounced and numerous at the beginning of a 4GL/ABL session are due to the following facts:
1. When you compile a procedure, the compiler reads schema information when resolving database references. if you are running this from the Procedure Editor, record reads will account for more records then the procedure actually reads depending on where you start counting and what kinds of ABL you have.
2. When running r-code to access a table for the first time, there will also be cases that the client will read schema info and cache it in memory (such as cache for index information), or reading the template record for the table.
Specifically, the extra 'Record Reads' reported in the Promon Option 5 report are caused by the following actions:
1. When you start a 4GL/ABL session some schema information is read and cached.
2. Compiling a 4GL/ABL Procedure requires reading more schema information.
3. At runtime, the _StorageObject table is read to look up information like the location of the index root block for an index, which area is the index in, and which area is the table is in.
The VST (Virtual System Tables) records do not need to be read and consequently, do not contribute to the number of 'Record Reads' reported by the Promon Option 5 report. Also, the Index block reads are not 'Record Reads' and do not contribute to the number of 'Record Reads' reported by the Promon Option 5 report either.