SUMM: vrestore takes more space than before

From: Guy Dallaire <dallaire_at_total.net>
Date: Wed, 30 Apr 1997 10:09:31 -0400

Thanks to the many who replied:

"Robert L. McMillin" <rlm_at_syseca-us.com>
"Dwight Walker (PSS)" <Dwight_Walker_at_pacstar.com.au>
BigRedDog <ckrieger_at_latrade.com>
alan_at_nabeth.cxo.dec.com (Alan Rollow)

If I forgot someone, you know who you are and I thank you also.

For some strange reason, when I came back to work this morning, the
situation was normal, the fileset was back at 92% full. The only thing that
happened during the night were the full backups of the system and the
bouncing of the oracle databases. I suspect that the bouncing of the
databases has something to do with it. As someone suggested, maybe a file
was open but it was not showing in the 'ls' but still occupied some space.
Is suspect that when I started the restore last night, the database was not
completely shut down, maybe that's the problem. So BigRedDog was probably
right.

Some people suggested that my oracle files are "sparse files". If I
remember well, I've read somewhere that oracle 7.2.x for DU does not create
sparse files, also, considering the time it takes to add a datafile to the
database, I presume that the file is physically allocated and formetted in
some way, it not just an open(), lseek() close().



---------------- Here is the original post: --------------------------------

Hello,

I've just restored a bunch of oracle data files unto a disk (restored at
the same place they were before they got destoyed) and the disk usage
increased !

The disk was 92% full at the time I took the backup. After restoring the
files, the disk is 97% full. No files other than what I backed up and
restored are on that fileset. It's a bit of a pain because I can no longer
use clonefset to backup this fileset because it is more than 95% full.

Any Idea ?

NOTE: During the vrestore, the disk went full, I had to remove all the
files I was restoring/overwriting to make some space. Could this be the
problem ? Would a defragment help ?

-----------------------------------------------------------------------------


I think you hit the nail on the head with this one. From what (little)
I know about advfs, it doesn't exactly throw out rm'd stuff. A defrag
will *not* help. I believe you need to flush your volume's trashcan
directory using rmtrashcan. All this is strictly hearsay, though, and
not to be taken that seriously.

Good luck...

-- 
Robert L. McMillin | Not the voice of Syseca, Inc. | rlm_at_syseca-us.com
	   Personal: rlm_at_helen.surfcty.com | rlm_at_netcom.com
-----------------------------------------------------------------------------
Guy,
I've experienced this problem before,  and after a great deal of 
investigation and testing,  the only conclusion was that oracle 
datafiles are what is known as a sparse file.
When you think that a oracle datafile upon creation occupies x amount 
of disk space but it is basically an empty file.  As a tablespace 
becomes fragmented,  so does the datafile.  This is what is known as a 
sparse file - a file that takes up space but contains empty space.
A defrag will help  after the file is restored but does not really 
help in the restoration.  To combat this on tight filedomains I used 
to add a single disk to the filedomain using addvol - ( even to RAID 
sets ).  When the restoration was complete I then did a defrag and a 
rmvol,  to remove the volume.  The remove volume command moves the 
data from the ( temporary ) volume I had added back onto the RAID set 
and then removes itself from the filedomain.  If there was not enough 
space for this I could fire up the database and relocate a datafile or 
two, and then remove the volume.
All this can be done on line.  Obviously there will be a large IO 
performance hit. And you don't really want to remove the volume  with 
the database up or at least no heavy transactions in those 
tablespaces.
Dwight Walker
--------------------------------------------------------------------------
If you deleted a file that had an open file handle, it would be removed
from the directory listing, but the space would still be allocated until
that file handle was closed.  You might try rebooting.
-cliff
--------------------------------------------------------------------------
If some of the files were sparse before and the restored expanded
them, that could account for the usage.  Fragmentation could cause
additional space usage in the form of more space used for the
extra extents, but I wouldn't think it would be much.
-Alan
Guy Dallaire
dallaire_at_total.net
"God only knows if god exists"

Received on Wed Apr 30 1997 - 16:32:16 NZST