I have found a rather strange behavior in Progress but I'm not sure whether it's a bug or not: the queries running by remote clients are reading the master block. The single-table queries read the master block once per query. For example:
find first customer no-lock.
or
for each customer no-lock: end.
Progress translates the joins into multiple single-table queries. So the query below will read the master block twice:
for first customer no-lock, first order of customer no-lock: end.
A server receives many messages from its remote clients but it reads the master block only when it receives a message with a single-table query. The same queries executed by self-service clients are NOT reading the master block.
It's not a performance issue: the master block is not on LRU chain and "DB Buf S Lock" is used to read the block (no buffer lock waits). On the other hand this extra db request creates the contention on the BHT latch. And from a logical point of view the master block does not store any information needed to run a query.
Is that an expected behavior?
Tested with Progress V10.2B08/11.6 on Windows and 11.6 on Linux
I just looked it up. This is to get the schema time stamp from the master block in support of server side field maps and online schema changes.
Is it expected behavior? Yes and no. This validation is required but I would think there could be a lighter weight way to do it.
Thanks, Richard!
the master block is permanently fixed into the buffer pool and is not on the lru chain.
yes, there is a bit of overhead to get a share lock on it, but no reading from disk or lru operations.
I was mainly wondering why there is a difference between the self-service and remote clients.
The similar situation exists with promon and ACO (Area Control Object) blocks. Updating the activity counters in promon will read ACO blocks from all data areas. The _AreaStatus VST and prostrct statistics read them too. But the information stored in these blocks seems to be already stored in some structure in shared memory. At least "find by recid" where recid is higher than area's HWM will not create db request. And it will not read ACO block either.
promon/R&D/5. Adjust Monitor Options/7. Change working area
I can choose 3. Primary Recovery Area
In this case promon will NOT read ACO blocks. Can I still rely on data reported by the activity screens? I don't see any problems with that data. Then why promon is reading ACO blocks by default? They are on LRU chain. Promon does have the problems when there is the contention on LRU latch.
What is the best solution to avoid these problems? To set Primary Recovery Area as a working area? Or to put ACO blocks into the dynamically allocated "alternate buffer pool"? Both solutions seem to work. A solution with working area is simplier but I feel less comfortable with it because I don't know why promon reads ACO blocks.