Title: RE: Large Export Problem ..
Yes, that was a typographical error in my response. I meant IGNORE=N.
-Original Message-
From: Janardhana Babu Donga [mailto:[EMAIL PROTECTED]]
Jacques,
Your response is helpful. Thanks for your suggestions. I think I should import
Export Problem ..
Babu
Why not try 'direct=y' option. This has limitations
regarding the platform. Not 100% sure of it.
Check with Documentation. It does export very fast.
HTH
GovindanK
--- Janardhana Babu Donga [EMAIL PROTECTED] wrote:
Dear List,
I have a large unarchived decission
]
Sent by: cc:
[EMAIL PROTECTED] Subject: RE: Large Export Problem
from the list members, I got a clear idea how to
handle the
Large Export Problem. I will break up the export into 4 types(full export
with norows, static, non-static and the rest), schedule them to fit our
schedule, and use the version control system approach for the
packages/stored procs
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Large Export Problem ..
I go even one step further here. Each object is required to have it's own
creation script. A
package will have two scripts
importing the
dump file and get a big list of errors.
After seeing the responses from the list members, I got a clear idea how
to
handle the
Large Export Problem. I will break up the export into 4 types(full
export
with norows, static, non-static and the rest), schedule them to fit our
: Large Export Problem
PROTECTED]
cc:
Subject:RE: Large Export Problem ..
FWIR, CVS doesn't handle binaries tho. We do the same thing for rdf's
(report files) and fmb's
(forms files) too.
Ron Thomas
Hypercom, Inc
[EMAIL PROTECTED]
Each new user of a new system uncovers a new class of bugs
anything by using incremental export. Nightly loads will touch
every partitioned table and so incremental export will export the complete
tables and there won't be any difference between full export and incremental
export in this case.
I need additional help in resolving my large export problem
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
Babu
Another thing to consider. Have you tried to import one of these monster
tables? A recovery that takes days may not be acceptable.
[1] How can I reconstruct a database using this type of export if needed?
Consider the real purpose of a logical backup to restore selected tables
or
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
Dennis,
Thanks for your reply. Iam not clear about exporting/importing
packages/stored procs, specifically importing them.
If I need to export packages, I could use owner=FINANCE and rows=N. It will
export the structure of the complete schema tables also.
If I need to import one package
Babu
I've never done this either. Maybe someone else on the list has.
1) You can edit the export file. Use the Unix strings and fold commands to
make it more manageable, then create a SQL procedure that will create the
object. Just did that this afternoon with a table definition.
2) If you
Babu
Why not try 'direct=y' option. This has limitations
regarding the platform. Not 100% sure of it.
Check with Documentation. It does export very fast.
HTH
GovindanK
--- Janardhana Babu Donga [EMAIL PROTECTED] wrote:
Dear List,
I have a large unarchived decission support database of
Thanks for your reply.
I encounterd lots of bugs earliar and since then not been using DIRECT=Y
option. However, exporting 150gig of static data every week will be of no
use either way.
-- Babu
-Original Message-
Sent: Tuesday, March 25, 2003 2:50 PM
To: Multiple recipients of list
]
cc:
Subject:Re: Large Export Problem ..
Babu
Why not try 'direct=y' option. This has limitations
regarding the platform. Not 100% sure of it.
Check with Documentation. It does export very fast.
HTH
GovindanK
--- Janardhana Babu Donga [EMAIL PROTECTED] wrote:
Dear List
version dependent.
Jared
Govindan K [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
03/25/2003 02:49 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Re: Large Export Problem ..
Babu
Why not try
Title: RE: Large Export Problem ..
(see comments below)
-Original Message-
From: Janardhana Babu Donga [mailto:[EMAIL PROTECTED]]
Thanks for the caution. Does any one know if I export with
owner=schema
Name rows=N, then drop a package and import from the export file
19 matches
Mail list logo