File Space on LVM when restoring the LVol

[Ian Dennison_1]

I have VxFS and HFS File Systems that are 100% allocated with Oracle Datafiles. When I delete the contents and restore them using Tape backups, the File System keeps filling up.

I know that it is something to do with Inodes or the File System Structure, but my DBAs are unwilling to stick to the new '95%' rule unless I can give them a concrete reason why this is occuring.

Anyone know the specific reason why this would occur?

Share and Enjoy! Ian

[James R. Ferguson]

Hi Ian:

Are you restoring the files as 'root' or as 'oarcle'? About 10% of an HFS filesystem is reserved by default ('minfree'), and once the file system capacity reaches this limit, only users with appropriate privileges can allocate disk blocks.

With VxFS filesystems, some space is reserved for the JFS log. While inodes are unlimited for VxFS filesystems, they too require space, of course.

Regards!

...JRF...

[Jeff Schussele]

Hi Ian,

It's possible that these Oracle files are temp files & exist as sparse files. Basically just allocated space that's unformatted except for header & last block. The space management bitmaps are there, but the space is used on-the-fly.
These LVs will always *look* full but actual usage could be minimal at any given time.
You need to verify with the DBAs just what kind of space they're using for these particular LVs & question whether they actually need more space.

Rgds,
Jeff

[Paula J Frazer-Campbell]

Ian

Minor point which you may say "I know that" but:-


HFS - An older HP system, which uses Metadata -synchronous writes - (Potential loss of data if server crash).

Vxfs (JFS)- Uses and intent log (Journal) - if the system crashes during writes then the Journal is used to complete the write.



Paula

[Tom Geudens]

Hi Ian,
For one (being an ex-DBA myself) I would not like the filesystems to be 100% filled. Especially not when my tablespaces are auto-extend. I presume you do not have tablespaces like that ?
Further I do not completely understand your question. Let's see ... the filesytem is filled for 100% with datafiles (but working), you backup the files, you delete the files, you restore the files and this restore fills the filesystem for more than 100% (not working). Is this what's happening or did I misunderstand ?

Regards,
Tom

[Stefan Farrelly]

I have the same problem here at my current site.

We run our JFS (VxFS) filesystems at around 99% full with Oracle tables and indexes. Whenever we need to restore them to say a test server then if we make the lvols the exact same size (and JFS) then we *CANNOT* restore all our filesystems - we get file system full messages before the last file(s) come down on some of them. This is very puzzling.

Weve had to make our filesystems slightly larger when restoring to ensure we can bring them all down, and advise the customer not to let their oracle filesystems get above about 97% full in future in order to guarantee and easy restore - should one be necessary.

The questions is why cant a filesysem which isnt full (but almost full) be restored to the exact same filesystem using fbackup/frecover without filling it up!? Weve tried using other backup methods and they seem fine - in my opinion its an fbackup/frecover issue.

[Ian Dennison_1]

James, Restoring as root with files owned by Oracle.

Jeff, these are ordinary files created by Oracle with the ???add datafile??? command.

Tom has stated the problem precisely.The file system is 100% but not complaining (ie. bdf says 100% with 2 MB free, dmesg says nothing about overflowing the file system). Once I empty (by using an ???rm??? command) and restore the contents of the file system, I get the file system overflow message in dmesg and my restore aborts.
All Oracle Database Files are manually allocated by the DBAs as and when required (no auto-extend).

I have found some notes on ITRC that say that there can be up to 8 % overhead on the VxFS File System, but I am not sure if this problem is the HP-UX File System or VxFS.

Thanks for everyones input so far, I might just have to say ???Just because!??? to the DBAs for now and research the problem later.

Cheers, Ian

[Jon Finley]

You may want to try using lsof to see if there are any inodes still in use within the deleted directories.

If so, find and kill the processes keeping the inodes open (stop Oracle if need be), then retry the restore.


Jon

[Duncan Edmonstone]

Ian,

I wonder if this is the result of fragmentation? If you have Online JFS you could try defragmenting the filesystem (man fsadm_vxfs for more info).

If you don't have Online JFS, do you get the same problem if you just newfs the filesystem?

HTH

Duncan

[Volker Borowski]

Hi Ian,

well for SAP I can say :
brrestore will refuse to restore, if it calculates a filesystem usage over 98%. Guess they had a reason for this ?

Could it be, that this has to do with the type of restore-tool and its blocking factor (5k, 32k 64k) ? Normaly I'd expect a files padded with empty blocks upon save if you need to fill the blocksize. Upon restore, I'd expect that these empty blocks should be detected and NOT written to the filesystem, but may be this is not possible for the OS (?). May be it MUST write the padded blocks to disk and releases them afterwards. If you go to 100%, you might be trapped ?

Is it possible in your case to restore n-1 files to the target location and one file elsewhere and move it over afterwards ?

I did this more than once with brrestore, because of the mentioned 98% problem.

Volker