2) A caveat of using this method:
>         "Important: Incremental, cumulative, and complete Exports are
> obsolete features that will be phased out in a subsequent release"

I think this has already happened with 9i...

I would suggest going to RMAN and taking incremental cold backups and taking

weekly/daily
1. full export w/o data (to get the structure)
2. data export of non-static data using (tablespaces=(list) - a 9i feature
but i think u can install 9i anduse the exp binary against the 8i db you
have. i have not tried it though)

monthly/whatever
1. export of static data (this can be run during the day with consistent=n
to minimize downtime)

Babu

----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 3:44 PM


> Babu,
>
> First, if it were me, I'd put this thing in archive log mode.  If we
> may need to recover between full backups, that is the tried and true
> means.
> But, on to your question.  I'd look at a plan utilizing incremental
> exports.  You start with a 'base' full export (weekly, monthly,
> whichever), and do daily incremental or cumulative exports.  I'm not
> going to offer too much detail here because I've never actually used
> this and because you really should read all of the oracle documentation
> on this before implementing it ...
>
http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76955/toc.
htm
>
> Two things I'll point out from that document:
> 1) A quote which directly addresses one of your issues...
>         "You can do incremental, cumulative, and complete exports only
> in full database mode (FULL=Y). "
>
> 2) A caveat of using this method:
>         "Important: Incremental, cumulative, and complete Exports are
> obsolete features that will be phased out in a subsequent release"
>
> Please let us know how this turns out for you or if additional help is
> needed.
> Thanks,
> Darrell
>
>
>
> >>> [EMAIL PROTECTED] 03/25/03 01: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: Darrell Landrum
>   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: Babu Nagarajan
  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).

Reply via email to