Dick,
Have you considered the size and placement of the tables in like LMT's
to allow the planned use of equal extents?
I use LMT's and have set my own sizeing to the sizes of the tables and
the table activity. Some LMT's are 4K for small tables and others are
40M for large tables. When I look at the free space in the tablespace
there is almost always zero free. The next major insert allocates an
extent and that is used up in a short time. When the year end functions
are performed the partition is changed to read only and I do not have to
resize to keep wasted space to a minimum.
Usinf LMT's and partitioning is a combination that I find invaluable
compared to the confusion created with the different next extent sizing
that was used here on 7.3.4.
Ron
>>> [EMAIL PROTECTED] 05/29/03 06:51PM >>>
Thomas,
With the exception of temp and rollback tablespaces I have not
user locally managed tablespaces just because all objects must have the
same sized extents. I do not see most tables sharing an equal need for
storage and using dictionary management allows one to do that, at a cost
I'll admit, but one that is much easier to swallow.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
Sent: Thursday, May 29, 2003 3:25 PM
To: Multiple recipients of list ORACLE-L
After reading the documents I've recommended using LOCAL, UNIFORM, AUTO
as
the options for tablespace management. Does anyone have any bad
experiences with these? AUTOALLOCATE seems to come up with extents
that
are much smaller than I want and MANUAL segment management requires the
use
of FREELISTs (and I know that there are problems with freelists freeing
up
space correctly, especially in a parallel environment).
I can't find any basis for making a decision between UNDO and ROLLBACK
SEGMENTS. Does anyone have any experience or recommendations about
UNDO
usage?
The database will be a materialize view replication of a transaction
master
that is being used for decision support and has a 15 minute
update/refresh
cycle. Basically, people can run queries against the snapshot without
impacting the master.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Thomas Day
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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.net
--
Author: Goulet, Dick
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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.net
--
Author: Ron Rogers
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
