If you take an export you are getting a binary logical file of the
data contained in the database. If you truncate the table you remove
the data and it will not show up in the export file. The only logical
explaination is that there was not much data in the 70 meg table. If
you fill a 70 meg table and delete 60 megs, you still have a 70 meg
table while you would only have 10 megs of data. exporting that table
should only yield the export equivalent of 10 megs of data, while a
trunacate will only reduce it by the export equivalent of 10 megs.
Follow? Exports are "logical", ie. they just contain data, metadata,
etc., no whitespace from the high water mark.
On Apr 3, 7:45 pm, "Joe" <joe1..._at_tlen.pl> wrote:
> I am making database backup by export all scheme. the size did not
> change after removing 70mb table (it is 60% of whole database). just
> wondering if ora does not work slower (well.. .the file is bigger than
> it should be (all data was from 70mb table was truncated))
>
> On Apr 3, 6:06 pm, "joel garry" <joel-ga..._at_home.com> wrote:
>
>
>
> > On Apr 3, 6:49 am, "Joe" <joe1..._at_tlen.pl> wrote:
>
> > > hi. I've just dropped table (approx 70mb) from our tablesystem by
> > > truncate, however dump file still keeps "old" file size. Is there any
> > > oracle optimizer or defragmation tool (hehe) that if one truncate big
> > > chunk of data, you can run it to get all the bits and bytes better
> > > organized?
>
> > I'm wondering what exactly you mean by "dump file?" Are you talking
> > about the exp utility? How exactly are you checking this file size?
>
> > jg
> > --
> > @home.com is bogus.http://www.toonopedia.com/today.htm- Hide quoted text -
>
> - Show quoted text -
Received on Tue Apr 03 2007 - 20:45:27 CDT
