RE: System Tablespace and Autoextend

I have read complaints about SYS.IDL% objects having PCTINCREASE 50 and space problems when they extend, in the forums. I went to check and mine are already set to 0 along with 2147483645 MAXEXTENTS. I created a TAR and verified with Oracle that altering storage options for sys/system objects was supported as long as they were not decreased below the defaults. The exception was that if you have a large MAXEXTENTS on the object then you could decrease PCTINCREASE or set it to 0. I have checked NEXTEXTENT values and there are some objects which aren't ready to extend but when/if they do (probably result of migration) they will consume 250mb which to me is obviously excessive. I haven't taken any action of course after all it is SYSTEM!, but PCTINCREASE of 50 on objects that have grown a couple times does inevitably invite space consumption issues at some point in the future.

-----Original Message-----

Sent: Thursday, November 07, 2002 12:24 PM To: Multiple recipients of list ORACLE-L

FWIW I'd go with Dennis here. I don't like AUTOEXTEND on the SYSTEM tablespace.
(In fact I'm not overenamoured of AUTOEXTEND on any datfile, except maybe on dev and sandbox databases).
If the SYSTEM tablespace isn't used for rollbacks (apart from the SYSTEM rollback) or temporary segments and the auditing information is written to it's own tablespace then I can't think of a set of circumstances that would cause the SYSTEM tablespace to rapidly fill up. System upgrade/migrations are the exception to this rule but in general a DBA would plan ahead for those occasions anyway.

-----Original Message-----

Sent: Thursday, November 07, 2002 4:29 PM To: Multiple recipients of list ORACLE-L

I've been running with autoextend on (though limited to 2Gig) and never had a problem.

-----Original Message-----

Sent: Thursday, October 24, 2002 5:26 PM

I run my SYSTEM tablesaces in autoextend, and have for some time. I run them that way from the point of database creation and have never had a problem. There were some problems with autoextend in earlier versions of 8 (and I think they managed to migrate to early 8i versions as well) with 2GB boundaries, but those have all been corrected.

RF

Robert G. Freeman - Oracle OCP
Oracle Database Architect
CSX Midtier Database Administration

-----Original Message-----

Sent: Thursday, October 24, 2002 4:46 PM

Sam -

   I haven't made the system tablespace autoextend because I can't easily recover the space if it overextends. I would rather take the risk that something hits an error from a lack of space in the system tablespace. With other tablespaces you can always rebuild the tablespace if you need to.

Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----

Sent: Thursday, October 24, 2002 1:27 PM

Hello All,

I have heard several times that if the SYSTEM tablespace runs out of space and needs to autoextend (assuming autoextend is turned on for the data file), then you run the risk of the database crashing and of data dictionary corruption. I have never personally encountered this problem, so I have no experience on what actually does happen.

I looked in metalink for documents on this, but turned up nothing. Does anybody have experience on the dangers of allowing the SYSTEM tablespace to autoextend and also any documents on Metalink or OTN that describe this problem?

We are running Oracle versions 7.3.4, 8.0.5, 8.1.7, and 9.2. All our Oracle versions are running on Windows NT (or Windows 2000).

Thanks for any feedback.

Sam Bootsma, OCP
samb_at_cpas.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Hately, Mike (NESL-IT)
  INET: Mike.Hately_at_npowernorthern.com

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: 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: Markham, Richard
  INET: RMarkham_at_hafeleamericas.com

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: 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).