From granaman@home.com Wed, 09 May 2001 16:58:14 -0700 From: Don Granaman Date: Wed, 09 May 2001 16:58:14 -0700 Subject: Re: Rollback Segments Message-ID: MIME-Version: 1.0 Content-Type: text/plain I can think of no practical(?) use except for parallel server. In parallel server an instance will aquire private rollback segments specified in init.ora. If none (or too few) are specified, it will aquire public rollback segments. Public rollback segments are, in my opinion, only useful in an OPS environment in an active/passive configuration. (I prefer private, even then.) I have seen an OLTP OPS system with activity on both nodes and public rollback segments all around - and crippling pinging on rollback. The huge disadvantage is the OPS overhead if two instances obtain two rollback segments where some set of blocks in one is covered by the same PCM lock as some set of blocks in the other. Since rollback segments are so write intensive, overhead can be tremendous. It is easy to avoid this altogether. Simply create two distinct tablespaces (for the sake of discussion, call them RBS1 & RBS2) with two distinct datafiles for rollback. Create private rollback segments for one instance in RBS1 and the other in RBS2. Assign very few fixed locks to these datafiles. Real Application Clusters are going to be a new ball game with system managed rollback and default releasable locks. Fixed fixed locks are not really eliminated, but it seems that using them will disable cache fusion entirely. It will be interesting. -Don Granaman Jenner Mike wrote: > > Isn't the concept of a private RBS only applicable to parallel server > setups? > - Mike. > > -----Original Message----- > Sent: 09 May 2001 16:21 > To: Multiple recipients of list ORACLE-L > > Hi all, > This brings me to a stupid question then. What is the true > difference > between a public and a private rollback segment? Because if I just think > about it like a normal human being I would think that if a user made a > Private rollback segment then only that user could use it, but of course I > know that can't be the case. > Kev > > -----Original Message----- > Sent: Wednesday, May 09, 2001 10:26 AM > To: Multiple recipients of list ORACLE-L > > Nixon, > > While SET TRANSACTION can be used to assign a rollback > segment to a transaction, it cannot be assigned exclusively to > that transaction as you have found. > > The ability to assign a rollback segment to a transaction and > make it read-only for all others is something I've wanted myself > for many years, and I know it's been on the official 'wish list' of > requested changes by IOUG for some time. > > Maybe 9i? Anyone know? > > Jared > > On Wednesday 09 May 2001 01:40, Nixon_Villanueva@manulife.com wrote: > > Hi All, > > > > Here is my environment; > > > > NT v4 > > Db Oracle Workgroup v8.1.6 > > > > Rollback Segments > > SEGMENT_NAME OWNER TABLESPACE_NAME > > ------------------------------ ------ ------------------------------ > > SYSTEM SYS SYSTEM > > RBS0 PUBLIC RBS > > RBS_P1 SYS RBS > > RBS_P2 SYS RBS > > RBS_P3 SYS RBS > > RBS_P4 SYS RBS > > RBS_P5 SYS RBS > > > > > > Is it possible to assign one public rollback segment explicitly to one > > particular transaction? I tried using SET TRANSACTION USE ROLLBACK SEGMENT > > but other users I found out can still use it. So, I guess the best > > alternative is to set that RB segment to OFFLINE after using and set > ONLINE > > before executing the SET TRANSACTION ... Do you know how it can be done > > inside Forms? > > > > Thanks in advance! > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Jared Still > INET: jkstill@cybcon.com > > 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: ListGuru@fatcity.com (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: Kevin Kostyszyn > INET: kevin@dulcian.com > > 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: ListGuru@fatcity.com (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: Jenner Mike > INET: M.Jenner@southampton.gov.uk > > 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: ListGuru@fatcity.com (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: Don Granaman INET: granaman@home.com 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: ListGuru@fatcity.com (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).