Chunk files too big.
Ray Burns (11.70.FC4, RHEL 6, cooked files) twice saw a chunk file far larger on the filesystem (220GB) than onspaces reported (4GB). John Smith guessed automatic extension, which Ray ruled out. Art Kagel asked whether a support case was opened and offered two ways to reclaim the space: dd the real part to a new file, or archive, drop the chunk and restore. Cause not found.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
I wonder if anyone can shed any light on this, or if anyone has seen it before. We are running 11.70fc4 on RedHat Enterprise 6 using ext2 and ext4 (cooked) filesystems . Twice we have had instances where a chunk file has been created and the size of the chunk file on the filesystem is significantly larger than the size of the chunk file as reported by onspace. In one instance we had a dbspace with two 4 GB chunk files. The OS reported one of these files as 4GB correctly but the other was showing as 220GB (which then consumed all the space in the file system)
I'm not sure but i guess the informix 11.70 increase the chunk size automatically when needed, check the tables extent and specially next extent value
Oh sorry, should have mentioned that the DB is nowhere near the 8GB dbspace
size. There is plenty of room in the dbspace. Though even if it had extended,
onspaces would show the larger size (and doesn't)
Have you opened a support case with IBM?
Just an aside that doesn't answer the question but would solve part of the
problem. There are two alternative ways that your could relieve the wasted
space in the filesystem: I. You could 1) shut down the engine, 2) rename
the oversize chunk, 3) use dd to copy the 8GB of the chunk that is 'real'
to another file, 4) delete the oversized file and copy the 8GB file back
over it, then 5) restart the instance. OR: II. 1) take an archive, 2)
shutdown the engine, 3) drop the oversized chunk, 4) touch an empty file
with the same path, 4) restore the archive.
Art
Art S. Kagel, Principal Consultant
ASK Database Management
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Mon, Feb 10, 2014 at 1:59 AM, RAY BURNS
<ray.burns@velocityglobal.co.nz>wrote:
> Oh sorry, should have mentioned that the DB is nowhere near the 8GB dbspace
> size. There is plenty of room in the dbspace. Though even if it had
> extended,
> onspaces would show the larger size (and doesn't)
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--089e013d1d96d0f97704f20c716d