Thanks Kirti ...
Raj
__
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is
Raj,
The answer is: Yes.
You will need to edit catexp.sql to rebuild internal view to exclude
interested owner#.
This is as simple as it gets!
- Kirti
-Original Message-
Sent: Thursday, September 05, 2002 8:43 AM
To: Multiple recipients of list ORACLE-L
Is it possible to exclude
Raj - Assuming you are using an export parameter file (file.prms). Instead
of the FULL=Y parameter, use OWNER=(USER1,USER2,USER3, . . .
Unfortunately export doesn't offer the capability to say full except for
mdsys, ctxsys, if that is your question. You can also do a full export and
then
Title: RE: Export question on excluding certain schema
Dennis,
I received a reply from Kirti that by tweaking catexp81.sql file we could just achieve that. This is possible because all we have to do is tweak a view that dictates what will be exported.
It looks like that will solve my
Raj - Great! That one is beyond me, but Kirti is certainly the expert, so
were I you, I'd try his suggestion. Good luck.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Thursday, September 05, 2002 10:23 AM
To: Multiple recipients of list ORACLE-L
NO! NO! NO! Please... I am not an expert.
I just remembered this trick that I learned from the real experts (like
Anjo, X$KGopal ...)
I simply passed on what I had learned from others.
Cheers!
- Kirti
-Original Message-
Sent: Thursday, September 05, 2002 12:08 PM
To: Multiple
Title: RE: Export question on excluding certain schema
Also, by default, in Oracle 8.1.6 MDSYS and CTXSYS are already excluded from the export, so no editing of catexp.sql is needed to do what the original poster wanted to do.
# grep MDSYS $ORACLE_HOME/rdbms/admin/catexp.sql
u$.name
Title: RE: Export question on excluding certain schema
Thanks
for the info. Learned something new.
Dennis
: That proves I am no expert ;)
-
Kirti
-Original Message-From: Jacques Kilchoer
[mailto:[EMAIL PROTECTED]]Sent: Thursday, September 05, 2002
2:29 PMTo: Multiple
Title: RE: Export question on excluding certain schema
Missed that too ...
Thanks Jacques
Raj
__
Rajendra
Jamadagni
MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot
com
Any opinion expressed here is
personal and doesn't reflect
Try the following example:
TMD=`date '+%Y/%m/%d'`
TMS=`date '+%Y%m%d%H%M%S'`
sqlplus -s internal whisky
set verif off pages 0 echo off feed off term off lines 200
spool $SHELLSRCDIR/dbcontents.$TMS.log
select 'alter database rename file '''||name||''' to '''||name||''';'
fromv\$datafile;
RK - The system nicely timestamps the file automatically for you. Isn't that
good enough? Another idea - on Unix, tar several files and it will keep the
system timestamps on them.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Tuesday, December 04,
Try this:
DUMPFILE=EXPDATA_$(date '+%m%d%Y%H%M').dmp
echo $DUMPFILE
should return something like:
EXPDATA_120420011626.dmp
Which means export started on Dec. 4, 2001 at 4:26 PM.
do 'man date' to customize it further for your specific needs
HTH
Ed
__ _
Yes, I agree, but I have a valid reason for doing
this in this way.. any sugesstions..
Ramana
- Original Message -
From:
DENNIS
WILLIAMS
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, December 04, 2001 12:01
PM
Subject: RE: Export question - appending
Try exp ... file=expdat.`date +%j`.dmp ... or whatever format is
desired. Note that those are NOT quote marks, but grave marks. They
mean the result of whatever command is inside them.
You might want to do something like this in a script:
JDATE=`date +%j'
exp ... file=expdat.${JDATE}.dmp ...
file=expdata`date '+%y%m%d'`.dmp
-Original Message-From: ASCI
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, December 04, 2001 2:35
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
Export question - appending date to dmp file
Yes, I agree, but I have a valid reason
Well whaddya know...
Analyzed the table with estimates statistics (sampled 30 percent) and bingo.
My table is now reporting that it is 4.4Gb and not 330Mb. Avg row length
went from 6 bytes to 81. On a 50+ million row table that made some
difference to the calculation.
Many thanks Anita
Well back down to earth with a bang again, back to work and the weather is
miserable. I didn't see any replies to this last mail so I will repost. Any
help or insight would be greatly appreciated.
Regards
Lee
-Original Message-
Sent: 11 May 2001 15:51
To: Multiple recipients of list
Ok, I'll pretend I'm from Missouri (the Show Me State). What's the database block
size? What's the average row size? How many rows? What are the pctused and pctfree
values? Are you using any weird data types (like LONG, RAW, that kind of stuff). Are
you sure you are only exporting the
OK here goes and thanks for the response
Definitely one table and from the top :-)
DB Block size = 8192
Avg. Row Size = 6
Num Rows = 57351031
Pct free = 0
Pct Used = 40
Table definition (column names removed) =
Type
NOT NULL NUMBER(9)
NOT NULL NUMBER(9)
NOT NULL NUMBER(9)
NOT
Lee,
What version of the db is this? Bug 766095 generates
inaccurate avg_row_len for tables over 4GB (fixed in
8.0.6).
Is this a partitioned table and are you using FGAC
(fine grained access control)? There's a bug where
the entire table gets exported in the partition. I
can't remember
No kidding...it's got to be at least 38. 38 * 57351031 = 2.03 gigabytes, and I'm sure
it's bigger than that...
[EMAIL PROTECTED] 05/15/01 10:25AM
OK here goes and thanks for the response
Definitely one table and from the top :-)
DB Block size = 8192
Avg. Row Size = 6
Num Rows = 57351031
Lee,
Definitely sounds like bug 766095. It isn't listed in
the patchset readme file for 8.0.5.2.1 so it doesn't
appear to be fixed in 8.0.5, although there might be a
patchset exception for your platform (check with
support).
The workaround is to estimate statistics using a
percentage which
Many thanks, I will give this a try.
Regards
Lee
-Original Message-
Sent: 15 May 2001 15:04
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Lee,
Definitely sounds like bug 766095. It isn't listed in
the patchset readme file for 8.0.5.2.1 so it doesn't
appear to be fixed in 8.0.5,
OK,
To answer a couple of questions, I did use compute statistics to get the
stats. I did not use compress=y. The table should have been 420Mb according
to the avg_row_len*num_rows calculation. The export file came out at 5.7Gb.
When I imported it fell over at 1Gb. I set my initial extent to
You should check size of table from dba_segments like
select segment_name,bytes from dba_segment
where segment_name = 'TABLE_NAME';
HTH
Regards
Rafiq
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Date: Fri, 11 May 2001 06:51:17 -0800
OK,
To answer a
Title: RE: Export question.
-Original Message-
From: Robertson Lee - lerobe [mailto:[EMAIL PROTECTED]]
I have recently ran an analysis on a table and when calculating the table size using
num_rows*avg_row_len this came out at about 420Mb. Nothing strange about that, however
When you export it do not! use compress=Y.
When you import the table be sure to prebuild the table with the initial and
next extent sizes to be appropriate for this table.
This will reorg it unstead of putting it back the way it was.
Ruth
- Original Message -
To: Multiple recipients
27 matches
Mail list logo
