OT: Locally managed tablespaces - ST enque

Steve,

Slightly off the LMT topic, but what is an ST enque problem? I'm at home at the moment, and don't have any references to look at - but I have a thirst for knowledge tonight, the misses is out, nothing on telly, so I'm sat at my PC trying to learn what my sales life doesn't allow.. Oracle Oracle Oracle..

I don't mind a back channel response but any insight would be greatly appreciated :)

Regards

Mark

-----Original Message-----
Sent: Wednesday, January 31, 2001 06:47
To: Multiple recipients of list ORACLE-L

Hi Ross,

The 2% was elapsed wall clock time for the batch process that we were tuning. Of
course, "your mileage may vary" because it depends so heavily on how bad the problem that you are fixing is. In this case we had a 2% problem and fixed it.
You may have a 5% problem with the ST enqueue, in which case the gain would be
5%. However, if you don't have an ST enqueue problem, then there will be no such
gain from migrating to local.

@   Regards,
@   Steve Adams
@   http://www.ixora.com.au/
@   http://www.christianity.net.au/

-----Original Message-----
Sent: Thursday, 1 February 2001 1:41
To: Multiple recipients of list ORACLE-L

"The gain from that change was about 2%." Steve, What metric did you use?
Did you use a task or customer-specific metric (in which case the 2% gain does not necessarily map over to anyone else's site) or a generic "benchmark" you picked up in your travels ( in which case it might be of general use to us listers <g> ) - Ross

-----Original Message-----
Sent: Tuesday, January 30, 2001 6:10 PM
To: Multiple recipients of list ORACLE-L

Hi All,

I was working on a tuning assignment last week where one of the more minor changes made was to migrate their "scratch" tablespace to locally managed. The
gain from that change was about 2%. That saving was due to the elimination of ST
enqueue contention associated with multiple processes trying to create scratch
tables at the same time.

It is only certain data dictionary queries that are slower with locally managed
tablespaces, and that's only really bad if you have too many extents per segment. See http://www.ixora.com.au/tips/creation/extents.htm for why. The performance of SELECT and DML statements against user data is unchanged. The performance of space management transactions is slightly improved, and greatly
if ST enqueue contention was otherwise a problem.

@   Regards,
@   Steve Adams
@   http://www.ixora.com.au/
@   http://www.christianity.net.au/

-----Original Message-----
Sent: Wednesday, 31 January 2001 5:11
To: Multiple recipients of list ORACLE-L

Has anyone taken a PROD DB and changed it to using LMTSs and then noticed a perf
change + or -?

---
TheOracleDBA
theoracledba_at_lycos.com



On Tue, 30 Jan 2001 10:30:29
 Bunyamin K.Karadeniz wrote:


>  But some had claimed  that  Locally managed tablespaces are slower. I do

>not know if it is correct  but you must consider it .

> And I wonder the performance results too.

>

>----- Original Message -----

>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>

>Sent: Tuesday, January 30, 2001 3:35 PM

>

>

>> I have always been concerned with fragmentation of tablespaces, whether

it


>> be lots of extents, honeycomb or

>> bubble fragmentation. Now I am reading that in Oracle 8i with the use of

>> locally-managed table spaces,

>> these concerns are a thing of the past as Oracle now uses bit maps within

>> the tablespaces themselves to

>> do space management. This seems foreign to me that even though Oracle

will


>> use up all the space in

>> the tablespaces with no coalescing,  it is OK that extents will go into

>the

>> thousands with no performance degradation.

>> Could folks who are currently using locally managed tablespaces please

>> comment on how well it

>> is working for them and if they have experienced any problems in using

>them.

>> Thanks

>> Skip


--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steve Adams
  INET: steve.adams_at_ixora.com.au

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: Mark Leith
  INET: mark_at_cool-tools.co.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).