If an expert is done with consistent = 'N' it still must preserve some information. In the beginning export runs some selects against the data dictionary and needs that data to be consistent throughout the export. If that data changes then it needs to be reconstructed from the undo generated when the data was changed.
The undo is generated not by the export program, but by the programs which changed the data dictionary that export needs to keep consistent. Besides this undo data there is that being generated by normal transaction processing. Tables which are changing while an "export" select is being run are dependent on this rollback information for consistency. Consistent = 'N' does not stop this requirement on individual tables. It means that consistency between different tables is not enforced. There are selects being run against changing tables which are not related to the export and they too are dependent on undo information for consistent reads. What separates the needs for rollback information outlined in the second paragraph from the first is how long it must be maintained. The selects done by the export program against the data dictionary it must be maintained for the duration of the export. If your rollback segments are too small there Oracle will not be able to do so, and produce an error. How assigning a particular rollback segment would work in this case is beyond me. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -----Original Message----- Sent: Monday, May 20, 2002 2:06 PM To: Multiple recipients of list ORACLE-L On Mon, 20 May 2002, Reddy, Madhusudana wrote: > The idea of huge rollback segment is just to eliminate the contention the > rollback segment. Well its not always applicable ( possible make sure all > the other applications are not used), but we can create a big rollback > segment and bring it on line and make other rollback segments offline, and > run the export . So definitely the big rollback segment will be used. Used for what? Are you talking about constructing consistent reads? If so, then that shouldn't be necessary on any significant scale if we, as you suggest, "make sure all the other applications are not used." Even if concurrent access is allowed (as it should be) during export, why would constructing consistent reads from a variety of rollback segments cause "contention" conpared to constructing the same consistent reads from one big rollback segment? What are you trying to accomplish with the big rollback segment? What do you think the rollback segments are being used for by an export? -- Jeremiah Wilton http://www.speakeasy.net/~jwilton > -----Original Message----- > Sent: Monday, May 20, 2002 1:04 PM > To: Multiple recipients of list ORACLE-L > > > On Mon, 20 May 2002, Reddy, Madhusudana wrote: > > > Huge Buffer, commit=y, direct=y, assigning the big rollback segment > > should help you to have faster export , > > What do you mean "assigning the big rollback segment?" How do you do > that to an export and what does it accomplish? > > What does COMMIT=Y do in an export? > > If I were the original poster, I'd just look at v$session_event for > the export session after several minutes of slowness. > > -- > Jeremiah Wilton > http://www.speakeasy.net/~jwilton > > > -----Original Message----- > > Sent: Monday, May 20, 2002 3:43 AM > > To: Multiple recipients of list ORACLE-L > > > > I moved my database from Solaris 7 to Solaris 8 box (Sun Fire 4800, faster > > processors and more memory space) > > > > I create the database with the same script that I used to for my database > in > > the older machine, > > > > When I export my database from the older machine it was very fast and when > I > > import to newer machine it was fast too, > > > > and when I export from new machine it is really slow (very slow), (I am > > using same export parameters in both servers) > > Can someone help with tuning tips or anything you have... : ( > > > > > > - The no of records are the same for both machines > > - v$session_wait.seconds_in_wait is more than 10000 -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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.com -- Author: MacGregor, Ian A. INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
