> information without value - there are so many things I haven't seen
> yet,
> like lizards playing chess or Cary taking a quick shower).
>
oh the questions and thoughts this brings to mind!
as in:
has Mogens SEEN Cary taking a shower? or does he infer that Cary takes
long showers by the amount of time Cary is absent from a room and the
degree of wetness of Cary's hair when he returns? How quick is a quick
shower?
and, Cary is so definitely the epitome of the cute American "boy next
door" -- too bad that I've met his wife and like her, the thoughts of
him taking a shower could be interesting!
- Mogens_Nørgaard <mln_at_miracleas.dk> wrote:
>
> I'm very sorry. By some error I never got this message sent. So here
> it
> is, over a month too late. Fantastic...
>
> Mogens
>
> ==============================================================
>
> Ah, good to be back online with Tim Gorman on the old and wonderful
> 1575.
>
> 1575 was introduced in 7.1. Not as an error, because the code that
> creates this error has been around for many years before that. 1575
> was
> introduced to signal an unpleasant wait situation for the ST
> lock/enqueue - a warning to the DBA.
>
> Used extents (in UET$) and free extents (in FET$) are managed
> "together", meaning that 1) if you want to delete a record in UET$
> and
> insert it in FET$ (that means an extent has been dropped/freed), 2)
> delete a record in FET$ and insert it in UET$ (extent has been
> allocated) or 3) delete a bunch of records in FET$ and inserting only
> one with the summary information in the same FET$ (coalescing
> extents) -
> you have to make sure that nobody else is messing with UET$/FET$ at
> the
> same time.
>
> So Oracle takes out the massive ST enqueue on both UET$ and FET$
> while
> it performs 1, 2 or 3 mentioned above (and probably some other things
> I
> don't recall). If somebody else tries to get the ST enqueue while
> it's
> still being held by another session, you'll get the 1575 signalled in
> the alert log - in order to simply notify you that there has been
> queueing on the ST lock.
>
> As long as you have DMTs you risk getting 1575. It might be possible
> to
> get it with LMTs, too, but I haven't seen it personally (which is
> information without value - there are so many things I haven't seen
> yet,
> like lizards playing chess or Cary taking a quick shower).
>
> Temporary tablespaces (in 7.3?) replaced the ST enqueue with a latch
> per
> temp tablespace (this helped a lot in OPS environments).
>
> Management manouvres of various kind, like having standard sizes of
> extents, not coalescing ever (hence the 7.1 change whereby a
> tablespace
> with pctincrease=0 didn't get coalesced), etc. also helped.
>
> But it was LMTs that finally solved it. I thought. Until this thread.
>
> So now I'm curious as to what is happening here.
>
> Mogens
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Rachel Carmichael
INET: wisernet100_at_yahoo.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).
Received on Sat Sep 13 2003 - 17:29:25 CDT
