Re: Rollback Segments

I think that is essentially what I said ... with a lot less detail. I seem to have muddied it up a bit by not saying "but only for Oracle7". The specific case in point for the first "correction" was indeed Oracle7. Later, in the discussion of rollback segments, you say "that can't happen", then later say "except with Oracle7". I guess this sin of omission is because my experience with OPS is almost exclusively with Oracle7 and 8.1.6/7- very, very little with 8.0.x. As for "releasable locks being the "default" in any 8.x, its true, but "default" takes on a whole new level of meaning in 9i since overriding it disables the main new advantage of RAC over OPS. However, the clarification is useful.

It seems that we agree on the "best practices" though and if they are followed, the points of "contention" (pun intended) are largely moot.

Don Granaman <OraSaurus>

PS: Now that we have put everyone else to asleep,

    we have the place to ourselves!

sheisey_at_att.net wrote:
>
> Don, I hate to be a stick in the mud but there are some
> things I think need to clarified.
>
>
> > 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.)
>
> This can't happen unless you specify both public and private
> rollback segments in the database. If you have only private
> RBS in the database and you don't have ROLLBACK_SEGMENTS
> set to a value, the instance won't start. You will get the
> error message unable to acquire non-system RBS. If you only
> have public RBS then you will acquire the rollback segments
> based on the parameter TRANSACTIONS/TRANSACTIONS_PER_ROLLBACK_SEGMENT.
> If you use the IBM RS6000/SP I would not use public rollback
> segments. The SP has non-shared disks and using public RBS
> could cause performance problems across the switch. If you
> use SET TRANSACTION USE ROLLBACK can cause problems if you
> use public rollback segments. SET TRANSACTION USE ROLLBACK
> can cause problems with private RBS in OPS but at least with
> private RBS you know which node is owns the RBS. There is
> just general I/O issues using public RBS as well. If you use
> private RBS you can at least spread out the I/O. As far as combing
> public and private RBS in the same database, I would say don't.
> Combining public and private can cause problems in OPS. If a person
> puts the a public RBS in ROLLBACK_SEGMENTS and another instance
> acquires the RBS before you start the 2nd instance then the 2nd instance
> won't start. You get an error message that the RBS is in use. So
> the statement "If none (or too few) are specified, it will aquire
> public rollback segments" can only happen if you use both public and
> private RBS in the database, which I would strongly discourage.
>
> >
> > 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.
>
> This can't happen. Rollback segments get there own PCM locks. This means
> 2 rollback segments can't share the same PCM locks. This statement is true
> if you use Oracle7 but since Oracle8 rollback get their own PCM locks. Oracle8i
> also eliminates the need to write the undo information back to disk for the
> other node to generate CR images. All CR images are handled by cache fusion in
>Oracle8i.
>
> >
> > 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.
>
> I agree with this regarding the tablespaces. You should do this your
> rollback tablespaces whether you have OPS or not. However you don't
> assign PCM to datafiles containing Rollback segments. Rollback
> segments get assigned PCM locks. The parameter
> GC_ROLLBACK_LOCKS="1-5=500REACH" assigns the PCM locks to the segment
> not the file. "1-5" are the Undo segment numbers and if you specify a
> range then you have to specify the EACH keyword. This ensures each rollback
> segment gets it own PCM lock. If GC_ROLLBACK_LOCKS is not specified in the
> init.ora then if defaults to 1:N releasable for each RBS. If you set
> GC_ROLLBACK_LOCKS=0 the you get 1:1 releasable.
>
>
> >
> > Real Application Clusters are going to be a new ball game
> > with system managed rollback and default releasable locks.
> > Fixed locks are not really eliminated, but it seems
> > that using them will disable cache fusion entirely.
> > It will be interesting.
> This is also correct. Releasable is the default in Oracle9i, however
> it is the default as well in Oracle8 and Oracle8i. You have to use
> releasable locks in Oracle9i to get write - write cache fusion for pinging.
> If you use fixed locks in Oracle9i then you get writes back to disk
> for pinging.
>
> Thanks,
>
> Scott
>
> >
> > -Don Granaman <OraSaurus>
> >
> >
> > 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_at_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_at_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_at_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_at_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_at_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_at_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_at_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_at_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_at_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:
> INET: sheisey_at_att.net
>
> 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_at_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_at_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_at_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).