Roger,
||The great thing about the undo, is that it's totally Oracle
||managed, you'll never have to worry about rollback segs ever again.
Are you sure, you are ready to make this statement? Are you running with
UNDO segments in a heavy production system?
Personally, I believe that UNDO segments are great, but designed for easy
management, not necessarily for high performance or systems with
inconsistent data access?
My *guess* is that DBA's with large concurrent user databases with
inconsistent query patterns will/might opt for traditional rollback
segments, especially since you can't run both simultaneously.
Also, what about the SESSIONS parameter? Are "undo_management" and
"unto_tablespace" really the only thing you need to (never :O) ) worry
about?
---Oracle
"Not all undo segments of the active UNDO tablespace are ONLINE at startup:
this depends on the SESSIONS parameter. For example, if 10 undo segments
exist and you startup the instance with a lower SESSIONS parameter value,
the existing UNDO segments are kept, but only a few of them are onlined. The
OFFLINE undo segments of the active UNDO tablespace are onlined when more
transactions require the use of offlined undo segments."
Also, what about "UNDO_RETENTION"?
---Oracle
UNDO_RETENTION = <seconds>: This value specifies the amount of time,
Undo is kept in the tablespace.
This applies to both committed and
uncommitted transactions since the introduction of FlashBack Query
feature in Oracle needs this
information to create a read consistent copy of the data in the past.
What if this is set to high can't users fill up gigs of undo tablespace. Is
there a way to force a flush, will I have too? I need answers to these
question, be *I* would say that "you'll never have to worry about rollback
segs ever again"?
More from Oracle;
---Oracle
----------------------------------------------------------------------------
-----------------------------
Rules, Restrictions & Characteristics When using Automatic Undo Management
(AUM) - UNDO_MANAGEMENT = AUTO
----------------------------------------------------------------------------
-----------------------------
* The RDBMS prohibits any manual operation on ROLLBACK SEGMENTS of any type
of tablespace, except dropping them!
* UNDO Tablespaces are(must be) locally-managed with system extent
allocation. select TABLESPACE_NAME, CONTENTS, EXTENT_MANAGEMENT,
ALLOCATION_TYPE, SEGMENT_SPACE_MANAGEMENT from dba_tablespaces where
contents='UNDO';
* You cannot use UNDO tablespaces for other purposes than UNDO SEGMENTS and
cannot do any operation on system generated undo segments.
* You can create rollback segments on an UNDO tablespace while the database
runs in manual mode, but it is useless since these rollback segments cannot
be set online when running in AUM mode.
* Only one UNDO tablespace can be used at the instance level.
* When creating an UNDO tablespace, these are automatically created:
- n undo segments (based on SESSIONS parameter value)
- named as _SYSSMUn$
- owned by PUBLIC (usable for OPS configuration)
- not manually manageable
* If you choose to use AUM, you have no chance to manage any undo or
rollback, even on an non UNDO tablespace.
* Only undo segments of the active UNDO tablespace and the SYSTEM rollback
segment are kept ONLINE. All other rollback segments and undo segments of
other UNDO tablespaces are OFFLINE.
Nevertheless, not all undo segments of the active UNDO tablespace are
ONLINE at startup: this depends on the SESSIONS parameter. For example, if
10 undo segments exist and you startup the instance with a lower SESSIONS
parameter value, the existing UNDO segments are kept, but only a few of them
are onlined. The OFFLINE undo segments of the active UNDO tablespace are
onlined when more transactions require the use of offlined undo segments.
* All instances within Real Application Cluster environments must run in the
same undo mode.
* In Real Application Cluster environments set the UNDO_TABLESPACE parameter
to assign the appropriate undo tablespace to each respective instance. Each
instance requires its own undo tablespace. If you do not set the
UNDO_TABLESPACE parameter, each instance uses the first available undo
tablespace.
hth
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"CIO’s will state they have backup plans in place. What is
surprising is how inefficient and juvenile their strategies are."
Sean Derrinton, The Meta Group - Open Magazine, Sep 2000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chris Marquez
Oracle DBA S A I C
(202) 261-9454
[Email Address Removed]Oracle LazyDBA home page