Hi Everyone, Thanks for all the replies. I'm afraid that I don't have any pre-restore files left but when I compared ls with du on the restored files I was surprised how large the difference was (e.g. 400kbytes for a ~20Gb datafile). I had assumed that the difference would at most be one O/S block (which is partly filled). Obviously I don't understand how the blocks of a file work on JFS2 - could anyone enlighten me please on the source of this size difference? Many thanks! Charlotte (ps. I did confirm with fuser after shutting the database that no processes were accessing the files) ________________________________ From: David Roberts <big.dave.roberts@xxxxxxxxxxxxxx> To: charlottejanehammond@xxxxxxxxx Cc: oracle-l@xxxxxxxxxxxxx Sent: Tue, August 24, 2010 8:59:14 PM Subject: Re: RMAN restore into nearly full file system NB, files other than tempfiles can become sparse, although not under normal operation and oracle doesn't support databases that include sparse files. Essentially it would take the intervention of an operating system command that produced sparse files (like backup and restore on AIX). If you have any of the pre-restore files available, then run ls -al and du against the files to see if the space occupied on disk (du) matches the size of the file (ls -l). Dave On Tue, Aug 24, 2010 at 7:43 PM, Niall Litchfield <niall.litchfield@xxxxxxxxx> wrote: Fuser will tell you if the files or inodes are in use. Anything else is an assertion. >On 24 Aug 2010 18:02, "Charlotte Hammond" <charlottejanehammond@xxxxxxxxx> >wrote: >> >>Hi All, >> >>Thank you all very much for the comments and suggestions. >> >>Just to clarify - the file system in question had ONLY 5 data files. There >were >>no tempfiles (so no sparse files), controlfiles, redo logs or anything else on >>the file system. The data files were not autoextensible and had not been >>re-sized since backed up. >> >>I did not delete the original files before I restored over them (I'll try this >>next time I get the opportunity to set up a test - original problem resolved by >>SET NEWNAME) but I'm curious as to why this might make a difference versus just >>overwriting them (the database was definitely down so no processes were holding >>the files open). >> >>Thank you! >> >>Charlotte >> >> >> >> >>----- Original Message ---- >>From: "Dunbar, Norman (Capgemini)" >>norman.dunbar.capgemini@xxxxxxxxxx .... >> >>If you are doing a full restore, I'd be tempted to wipe out the >> >>destination disc space of any files... >>-- >>//www.freelists.org/webpage/oracle-l >> >>