Re: RMAN restore into nearly full file system

From: Charlotte Hammond <>
Date: Thu, 26 Aug 2010 11:57:24 -0700 (PDT)
Message-ID: <>

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!


(ps. I did confirm with fuser after shutting the database that no processes were 
accessing the files)

From: David Roberts <>
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).


On Tue, Aug 24, 2010 at 7:43 PM, Niall Litchfield <> 

Fuser will tell you if the files or inodes are in use. Anything else is an 

>On 24 Aug 2010 18:02, "Charlotte Hammond" <> 
>>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 
>>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 
>>SET NEWNAME) but I'm curious as to why this might make a difference versus 
>>overwriting them (the database was definitely down so no processes 
were holding
>>the files open).
>>Thank you!
>>----- Original Message ----
>>From: "Dunbar, Norman (Capgemini)" 
>>norman.dunbar.capgemini_at_environ... ....
>>If you are doing a full restore, I'd be tempted to wipe out the
>>destination disc space of any files...


Received on Thu Aug 26 2010 - 13:57:24 CDT

Original text of this message