Hello,
maybe I miss a knowledgebase entry, but why is the database always saving one record per block less than what you define in the .st file?
Binary analyse of blocks on the file system gives a result that when you define 32, 64, 256 (this is what I tested) Records/Block in the .st file of the database, always one record less is saved in the block in reality. So you get only 31 Records in a block with 32 records per block.
This was tested on 11.5, 11.6 on an area type II.
Regards
Peter
It's a good question. I am fairly certain that the missing row is taken up by the block header information. But will leave that for a Guru to confirm.
In the first block you may have RPB-1 records as it also contains the template record for the table. But you should be able to store RPB number of records in subsequent blocks.
In deed, that's interesting. Thank you.
there are other possibilities. need more data. questions:
how do you know there are 31 records?
what are the record lengths? what is the database block size?
> Binary analyse of blocks on the file system gives a result that when you define 32, 64, 256 (this is what I tested) Records/Block in the .st file of the database, always one record less is saved in the block in reality. So you get only 31 Records in a block with 32 records per block.
Use dbrpr/13. Display Block Contents
You will see that data block can store exactly up to RPB records.
right.
however, there are various circumstances in which fewer records will be stored in a block. among these are:
0) there is a rowid placeholder for a previously deleted record and the offending transaction has not committed.
1) there is insufficient free space
> On Nov 18, 2015, at 11:49 AM, George Potemkin wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> George Potemkin [https://community.progress.com/members/georgep12]
>
>> Binary analyse of blocks on the file system gives a result that when you define 32, 64, 256 (this is what I tested) Records/Block in the .st file of the database, always one record less is saved in the block in reality. So you get only 31 Records in a block with 32 records per block.
>
> Use dbrpr/13. Display Block Contents
>
> You will see that data block can store exactly up to RPB records.
>
> View online [https://community.progress.com/community_groups/openedge_general/f/26/p/21180/75443#75443]
>
> You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_general/f/26/t/21180/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_general/f/26/p/21180/75443?AbuseContentId=94913778-3cb2-4587-a827-5e7edd3496f8&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.
Sorry if it's a wrong place to put forth a riddle. ;-)
What value we will get from _TableStat-OsRead for the empty tables?
The possible answers:
1. Zero
2. One
3. Hundreds
Regards,
George
I will guess one. Because the empty table is not quite empty. It has a template record that schema reads.
4. Any of the above.
> 4. Any of the above
And this is a right answer! ;-)
Rob is a winner!
If an application does not use a table (does not define a default or explicit buffer for table) then _TableStat-OsRead will be zero - no matter how many records the table had. Progress will not read its data blocks even at database startup.
If an application uses the programs that define the buffers for a table then database will retrieve from the disk a data block with the template record. It's one OS read even for empty tables.
If we run online dbanalys then it will read the whole data cluster into a buffer pool - even if only one block in the cluster stores the records (or a template record). If the cluster size is 512 then _TableStat-OsRead returns 512 ("hundreds") for the empty tables.
Regards,
George