Babu,
To answer part of your questions.
1. Yes. If you use the FULL=Y , ROWS=N you get the skeleton of the
database(tablespaces,tables,etc) check with the DataBee tool to see if
it supplies all of your needs.
2.You can simulate (time the export) by having the output file be
/dev/null. Search the mail archives for doing this.
3.To export the packages you have to export the owner of the packages
USER=BABU. This will of course export the tables that BABU ownes so use
the ROWS=N option.
4. I don't know about this one.
5. If you have the space to store the exports why not use the QUERY
option and export portions of the tables. Then you would only need to
export what has changed sence the last export query option. The import
could be controlled with a script that uses a commit=Y and buffer=xxxx
options to help with the possible redo log problems. The IMP script
could execute the imports one after another until they are all
imported.
Ron
>>> [EMAIL PROTECTED] 03/25/03 02:59PM >>>
Dear List,
I have a large unarchived decission support database of size 270gig. We
do
take coldbackup of database files every sunday. We also take export
backup
to suplement the coldbackup. Export is taking too much time which we
can't
afford now. I need to reduce the export time to fit the weekend
schedule. In
the last few weeks it is failing as the database is down for
coldbackups
while the export is running.
The database structure is as follows:
Partitioned tables size: 200gig
[static partitions(prior years) size 150 gig, and non-static
partitions(current yr) size 50gig]
non-partitioned tables: 70gig
I don't need to export static partitions every week. Once in 3/6months
is
OK. I don't think I can eliminate static partitions in one full
export
script/parameter file. Iam thinking of eliminating the static
partitions by
taking export in TABLE mode, which includes only NON-STATIC partitions
and
the remaining NON-PARTITION tables. I may have to hardcode the table
names.
The database has lots of packages/stored procs which will be stored in
the
dictionary I believe.
My questions are:
[1] How can I reconstruct a database using this type of export if
needed?
[2] How can I simulate full export in this type (Table Mode) of
export?
[3] How can I export packages/stored procs and import to new DB if
necessary?
[4] Is there any other way to export the full database and eliminate
the
static partitions in a single step?
[5] What is the best way to solve my export problem??
Any ideas are appreciated.
Thanks,
-- Babu
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Janardhana Babu Donga
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Ron Rogers
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
