Kbase P110106: Program which reads from database getting error SYSTEM ERROR: Attempt to read block 2147467008 which
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/24/2008 |
|
Status: Verified
SYMPTOM(s):
Program which reads from database getting error SYSTEM ERROR: Attempt to read block 2147467008 which does not exist. (210)
SYSTEM ERROR: Attempt to read block 2147467008 which does not exist. (210)
Running database analysis fails with error SYSTEM ERROR: Attempt to read block 512 which does not exist. (210)
Database analysis stops on specific area.
Using a version of Progress / OpenEdge lower than 10.1B.
** Save file named core for analysis by Progress Software Corporation. (439)
FACT(s) (Environment):
Progress 9.x
All Supported Operating Systems
Progress 6.x
Progress 7.x
Progress 8.x
Progress 9.x
OpenEdge 10.0x
OpenEdge 10.0B
OpenEdge 10.1A
CAUSE:
The database has hit a Progress limit on area size.
FIX:
Upgrade to 10.1B when Progress introduced 64-bit record id structures within the database.
Prior to 10.1B Progress has a programmed limit to the number of records for one area: 2147483648.
No matter how the records per block is defined (1,2,4,8,16,32,64,128,256) the limit is still the same.
No matter what the database blocksize is (1,2,4,8k) the limit is still the same.
Based on the defined limit of 2147483648 depending on how an area is defined for the value of records per block a finite number of blocks are available for an area.
Database Block Records Per Block Maximum Area Size
Size
(8K) 1 16TB
(8K) 2 8TB
(8K) 4 4TB
(8K) 8 2TB
(8K) 16 1TB
(8K) 32 512GB
(8K) 64 (default) 256GB
(8K) 128 128GB
(8K) 256 &.nbsp; 64GB
(4K) 1 8TB
(4K) 2 4TB
(4K) 4 2TB
(4K) 8 1TB
(4K) 16 512GB
(4K) 32 (default) 256GB
(4K) 64 128GB
(4K) 128 64GB
(4K) 256 32GB
(2K) 1 4TB
(2K) . 2 2TB
(2K) 4 1TB
(2K) 8 512GB
(2K) 16 256GB
(2K) 32 (default) 128GB
(2K) 64 64GB
(2K) 128 32GB
(2K) 256 16GB
(1K) 1 2TB
(1K) 2 1TB
(1K) 4 512GB
(1K) &.nbsp; 8 256GB
(1K) 16 128GB
(1K) 32 (default) 64GB
(1K) 64 32GB
(1K) 128 16GB
(1K) 256 8GB
Progress reserves 1 GB of space for areas that have a database block size of (1024 KB or 2048 KB) and large numbers for records per block (128 and 256). For all other combinations we reserve 5 GB of space.
This reserved space is used to guarantee space to perform crash recovery within an area. This additional reservation of space was first introduced in 9.1E03; 10.0B04; 10.1A and will be standard in all later releases.
Take as an example that information gathered thru a dbanalys report
(proutil <dbname> -C dbanalys>db.txt)
indicates that for a given table the average record size is 30 bytes.
If the database block size is 1k it would be possible to fit approximately 25 records in the block after overhead considerations are factored in to the amount of space usable within the block.
If records were smaller it might be possible to fit more records in a block.
If records were large it would be likely that less records would fit in the block.
If, when you designed this storage area in the database .st file, you arbitrarily picked a value for records per block that wasn't realistic based on size of records and block size you might run in to problems.
Example:
If you defined the area as:
d "My Storage Area":7,256 /usr1/db/dbfile_d7.d1 f 128000
If the database blocksize were 8k (8192 bytes) and the average record size were 400 bytes you could typically fit 19 records into the block.
However, by defining that the database will expect to put 256 records in every block you have forced the database to reserve record IDs for each of those blocks.
Every block will have 256 distinct record IDs (recids) titled to that block and that block only.
There would be a wasting of 237 recids.
If you don't use all of those. recids within that block you will eventually run out of available recids (since there is a finite number of 2147483648 possible in one area.
If larger records were put into the area there would be more recids wasted.
It is possible to run out of blocks available for an area purely because the size of the records is so great that realistically only 1 record could fit in a block. If the records per block definition for the area were set at 256, it would only take 8388608 records to use the total number of blocks available for the area which is 8388608 in this case.
Even though our limit for number of recids is 2147483648, based on the records per block setting in this example we expect 256 records per block. If only 1 record can fit then the total number of recids is reduced commensurately. 2147483648 / 256 = 8388608.
Care should be taken when defining records per block for an area.
Once created, the records per block of an area can not be redefined. A new area, or new areas must be created and the tables must be moved to the new areas to allow more records within those tables to be created if a limit has been reached.
.