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).
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).