Kbase P73885: What is the limit of counters in virtual system tables?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/27/2009 |
|
Status: Unverified
GOAL:
What is the limit of counters in virtual system tables?
GOAL:
Why are the values of the counters in the virtual system tables different than the values displayed by PROMON?
GOAL:
Why are there negative values in counters in virtual system tables?
GOAL:
Why are the values of virtual system tables limited to 2147483647?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
FIX:
Several facts are relevant and provide answers:
- internally, the database server stores these counters as 64-bit integers. These 64-bit values are the ones used by PROMON.
- in order to make these counters accessible from the AGL, a field from the virtual table maps to the internal counter.
- In version 9 of the product, as well as versions up to and including OpenEdge 10.1A, this fields uses the data type INTEGER which is always 32-bit wide.
- because the 4GL data type is smaller than the internal data type, data loss may occur during the conversion.
- In Progress 9, the conversion is done by extracting the low-order 32 bits from the 64-bit counters. This can cause overflow to negative values when the counters exceed 2^31-1 (2147483647).
- In OpenEdge 10 up to 10.1A, the conversion will "saturate" the fields. When the internal 64-bit values exceed 2^31-1, the value in the virtual system table will stay fixed at 2^31-1.
- since there is no 64-bit integer type in Progress 9 and OpenEdge 10 up to 10.1A, it is not possible to retrieve the complete values from the AGL.
- a new 64-bit integer type, INT64, was introduced in OpenEdge 10.1B. The virtual tables are now using this type to map to 64-bit counters in the database engine to the ABL.