bkset: Extent /u48/PRODATA/mfgprotst.d122 is below size -2147483648. (647)

daveprice74

New Member
Filled extent, getting: bkset: Extent [name].d122 is below size -2147483648. (647)

This is a Test database, version 8.3A (please don't throw things at me! it's not my fault, honest!) on HP-UX 11.11, it filled up a variable extent to the 2GB limit and now it's complaining the extent is 2147483647 instead of 2147483648. I tried adding another variable extent but it issues this complaint instead. Is there any fix for this? Just wondered, we can always rebuild from Prod.

Since it's only Test and the data in this extent is mostly junk anyway, I've toyed with the insanity of manually adding a byte to the file (ok, now you can throw things at me), which I suspect won't work anyway because this version can't handle 2G.

What's really amusing is that the database has about 40G of space free in the RM blocks, built up over the last 14 years during which it was never, ever dumped and loaded. We're moving the database to 8K blocksize later this year, partly because of the hard 64GB limit, partly for user performance on big reports (OS is 8K blocksize, and the 8K database I built from Prod was waaaay faster), partly because we'd be down for a very long time if it ever had to rebuild indexes in 1K, but mostly because we're approaching the 64GB limit (and it actually takes far longer to reload into a 1K database).
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Re: Filled extent, getting: bkset: Extent [name].d122 is below size -2147483648. (647

This article may help you: System Error 647 when accessing the database.

If your file system uses 8K blocks, you're doing 8X too much physical I/O given your logical I/O. Obviously, that's bad. You need to prioritize that D&L. I hope production isn't a 1K database.
 

daveprice74

New Member
Re: Filled extent, getting: bkset: Extent [name].d122 is below size -2147483648. (647

Thanks, I've been explaining that to our DBAs as well. Fortunately, now I have benchmarks to prove it, so the move to 8K blocksize is now scheduled. Unfortunately, it requires about 12 hours of downtime even if I pre-load 90% of the data (historical data that never changes) so it will be a few months yet.
 
Top