Kbase P110422: Getting error 210 starting database.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/24/2008 |
|
Status: Verified
SYMPTOM(s):
Getting error 210 starting database.
SYSTEM ERROR: unable to read block <number> which does not exist (210).
Example of error message
SYSTEM ERROR: Attempt to read block 2147483649 which does not exist. (210)
mprosrv died at with these calls
dsmFatalMsgnCallBack() +0xac from: $DLC/bin/_mprosrv
bmLockBuffer() +0x17c from: $DLC/bin/_mprosrv
bkMakeBlock() +0x1fc from: $DLC/bin/_mprosrv
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.0x
OpenEdge 10.1A
CAUSE:
The database has hit a Progress limit on area size.
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 Size Records Per Block Maximum Area Size
8192 bytes (8K) 1 16TB
8192 bytes (8K) 2 8TB
8192 bytes (8K) 4 4TB
8192 bytes (8K) 8 2TB
8192 bytes (8K) 16 1TB
8192 bytes (8K) 32 512GB
8192 bytes (8K) 64 (default) 256GB
8192 bytes (8K) 128 128GB
8192 bytes (8K) 256 &nbs.p; 64GB
4096 bytes (4K) 1 8TB
4096 bytes (4K) 2 4TB
4096 bytes (4K) 4 2TB
4096 bytes (4K) 8 1TB
4096 bytes (4K) 16 512GB
4096 bytes (4K) 32 (default) 256GB
4096 bytes (4K) 64 128GB
4096 bytes (4K) 128 64GB
4096 bytes (4K) 256 32GB
2048 bytes (2K) 1 4TB
2048 bytes (2K) 2 &.nbsp; 2TB
2048 bytes (2K) 4 1TB
2048 bytes (2K) 8 512GB
2048 bytes (2K) 16 256GB
2048 bytes (2K) 32 (default) 128GB
2048 bytes (2K) 64 64GB
2048 bytes (2K) 128 32GB
2048 bytes (2K) 256 16GB
1024 bytes (1K) 1 2TB
1024 bytes (1K) 2 1TB
1024 bytes (1K) 4 . 512GB
1024 bytes (1K) 8 256GB
1024 bytes (1K) 16 128GB
1024 bytes (1K) 32 (default) 64GB
1024 bytes (1K) 64 32GB
1024 bytes (1K) 128 16GB
1024 bytes (1K) 256 8GB
Example:
proutil <dbname> -C tabanalys indicates that the average record size for a given table is 30 bytes.
If the database block size is 1k it would be possible to fit about 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.
When this storage area was designed in the database .st file an arbitrary value was picked for records per block that wasn't realistic based on size of records and block size. It is possible to exhaust the limit of blocks per area without reaching the total number or records permissible to an area.
Example continued:
If a storage area is defined 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 typically 19 records would fit into the block.
However, by defining that the database will expect to put 256 records in every block the database has been configured by the .st file to reserve 256 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 all of those recids within that block could not be used eventually the area will 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 because less records could fit into the block..
FIX:
Data from the area which has reached the area limit must be moved to a different area.
Dump and Load or use the Table Move function of proutil to move the data to a new area.
Consider creating a new area with a more appropriate setting for records per block relative to this tables average record size.