Re: storage in import

Hi Sybrand,

Having thougt about it, I think you are right.

And I would never use that method even NEAR a production, pre-production or testing environment. I should have stated that instead of just "be careful".

In a development environment where you sometimes have to establish some things quickly, the limits are different (I think). If the method just works, it can make life easier for some developers. If not, too bad, you must find another method.

But since this group is not split into a "prod" and a "dev" part, I think you are right in letting it stay a "prod" group.

Then we can later establish a group like

"comp.databases.oracle.server.dirty.tricks.not.to.use.in.production"

 ;-)

Regards,
Kenneth Koenraadt
Systems Consultant
Oracle DBA
plovmand@<no-spam>hotmail.com

"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message news:<tqskcil2hnjd6f_at_news.demon.nl>...
> "Kenneth Koenraadt" <plovmand_at_hotmail.com> wrote in message
> news:3bae4a80.5165261_at_news.mobilixnet.dk...
> > On Sun, 23 Sep 2001 20:09:53 +0100, "Niall Litchfield"
> > <Niall.Litchfield_at_btinternet.com> wrote:
> >
> > >I think Sunday evening is a record even for me but there's nothing on the
> > >telly anyway.
> > >"Kenneth Koenraadt" <plovmand_at_hotmail.com> wrote in message
> > >news:3bacc043.2026555_at_news.mobilixnet.dk...
> > >> On Sat, 22 Sep 2001 12:10:13 GMT, bettati_at_infinito.it (andy) wrote:
> <snip>
> > >> Hi Andy,
> > >>
> > >> A table always has a minimal size of it's INITIAL extent size, even if
> > >> it is empty. That is of course also true regarding an import.
> <true>
> > >>
> > >> Look inside the export dump file and the INITIAL storage parameter of
> > >> the tables listed in it. You may change/reduce them by editing
> > >> directly in the export dump file..... but be careful.
> > >
> > >Be careful!!!! Be careful!!! Be out of your mind more like. export files
> > >are not for editing. Ever. Nope not even with a hex editor.
> Not to discuss. Some people edit export files and are happy with it.
> > >
> > >On the other hand the initial and next extents of an imported table can
> be
> > >readily controlled using any of the highly attractive options below.
> > >
> > >1. exp compress=n. this leaves initial and next as originally defined. I
> > >have said before and I'll say again this should be the default.
> behaviour.
> > Great option and the preferred choice. But what if the originally
> > defined initial value is 100M ?
> > >2. pre create the tables with whatever storage parameters you like and
> then
> > >import with ignore=y.
> > Good idea....if there are not > 1000 tables.
> >
> > >3. As of 8i and up. precreate your tablespaces as locally managed with
> > >uniform extent sizes of whatever you like.Oracle will then ignore the
> extent
> > >allocation clause during the import. however I think (i'm not going to
> look
> > >it up on technet that'd just be too sad for words) that it will allocate
> a
> > >number of extents sufficient to allocate the space specified in the dump
> > >file. This is not what the original poster wanted.
> > >
> > >you may of course mix and match options 2 & 3.
> > >
> > >Niall Litchfield
> > >Oracle DBA
> > >Audit Commission UK
> > >
> > >
> >
>
> OK, I was considering making these comments yesterday, and refrained from
> doing so, but as you seem to be quite stubborn about the issue, here goes:
>
>
> I think your advice is to discuss, as it is *outright dangerous*.
> It's OK if *you* are happy with it, and you see no problem in performing any
> trick (like directly updating the dictionary tables) once you screwed up
> your own database, yet I still believe this advice shouldn't be recommended
> to *anyone*.
> There are too many people out here who don't know what they are doing, who
> don't know what they should edit, who might save the file in ascii format
> etc, etc. I think they are entitled to sue you, when they screw up their
> database following your advice.
> It seems you are quite well aware your method is dangerous, why do you
> continue to recommend it?
>
> Regards,
>
> Sybrand Bakker, Senior Oracle DBA
Received on Sat Oct 06 2001 - 02:31:01 CDT