A little more info from the customer:
This was originally a 7.3.4 database which was MIGRATED to 8.1.6. The
decision was taken to export/import the full database. Before this was done,
it was copied over to become the "Training" database.
The storage parameters for OBJ$ and its sibling in it cluster where set at
PCTINCREASE 50. After the database was imported, the PCTINCREASE was set to
0. Comparing training and live showed the difference.
Two things happened. Obviously the number of extents in OBJ$ (and siblings)
went up. Secondly, they experienced a more than tripling of the time to
export and import from 14 hours to 46 hours, for an "unknown" reason, which
makes for a very long weekend.
The users have not commented on adverse performance now the application is
up, but the points that worry the site DBA are:
1. Does having such a fragmented OBJ$ (etc) adversely affect performance?
2. Even if another export/import is effected will it only do the same thing
again? (thanks Rachel for the response earlier on the sql.bsq file, but will
changing it survive any Oracle internals burning desire to do it its own
way?)
All help appreciated!
Mark
-----Original Message-----
Carmichael
Sent: Thursday, February 15, 2001 02:07
To: Multiple recipients of list ORACLE-L
you can change the storage parameters. I had heard from oracle support that
you could edit the storage parameters (but nothing else!) in the sql.bsq
file before creating the database... so if you can edit it there, it stands
to reason (okay, sits, I'm tired this morning) that you can change the
storage parameters once it has been created.
but....... I would, of course, confirm this with Support :)
Rachel
>From: "Mark Leith" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
>Subject: OBJ$ - PCTINCREASE 0
>Date: Thu, 15 Feb 2001 04:05:24 -0800
>
>Hi guys & gals,
>
>Looking in to the system tablespace I have noticed that in 8.1.6, the
>SYSTEM
>tablespace has a default PCTINCREASE of 50%, BUT OBJ$ has one specified of
>0! Now, on 7.3.4 if "my" memory serves me right, this was also set to the
>default of 50%.
>
>My problem is that on a database running a number of apps this could, and
>is
>at a customer site, leading to high fragmentation of the OBJ$ table. Does
>anybody with an "inside knowledge" know why this has changed on 8i?
>
>Is it a huge NO NO to chance the storage characteristics of this table
>also?
>The customer has done a full database export/import form 7.3.4 > 8.1.6, and
>has ended up with pretty bad fragmentation..
>
>Any insight would be appreciated.
>
>Mark
>
>
><< MarkLeith.vcf >>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
INET: [EMAIL PROTECTED]
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: [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.com
--
Author: Mark Leith
INET: [EMAIL PROTECTED]
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: [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).
