Re: storage in import

The last time someone posted here saying they'd successfully "edited" the dump file, it turned out (38 posts later) that they had done so using some hex editor or other.

Suggesting that that file can be edited is, I have to say, reckless. It's not a text file, but contains binary-encoded data. Save your edits in a text editor, and kiss goodbye to the chances of ever importing it. "Be careful..." is therefore something of an understatement.

On the DBA course, when we get to chapter 15 (the export/import one), I routinely demo opening the dump file in pico, vi and emacs (Solaris box, version 8.1.5), replace one digit in a storage clause and save. Import then proceeds to crash out without even attempting to perform any actions. Same happens on Windows 2000 and notepad.

The better approach would be to perform an import with rows=N index=N indexfile=blah.txt. The "blah.txt" file is a genuine text file, containing DDL statements for the creation of indexes and tables (though the 'create table' statements are all remm'd out). Edit that to your heart's content, making all the extent sizes puny, then run it as a normal sql script (i.e., within sqlplus, type @blah.txt).

Regards
HJR "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:
>
> >I have an Oracle database with some big tables. I need to have an
> >empty dump of tables (using exp ... rows=n).
> >In this way when i import dump on new database, i have a large amount
> >of space allocated without data.
> >I would like to have a minimal space occupation.
> >I work with 7.3.4 and 8i databases.
> >
> >Thanks in advance.
> >
> >Andy.
>
> 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.
>
> 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.
>
> ------------
> Regards,
> Kenneth Koenraadt
> Systems Consultant
> Oracle DBA
> plovmand@<no-spam>hotmail.com
>
>
>
>
Received on Sat Sep 22 2001 - 15:28:25 CDT