Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: ora 1575?

Re: ora 1575?

From: Tim Gorman <tim_at_sagelogix.com>
Date: Sat, 13 Sep 2003 15:54:24 -0800
Message-ID: <F001.005CFD2F.20030913155424@fatcity.com>


Well, regardless of Mr. Millsap's hygiene and the details of how he maintains it, you *have* seen an unretouched photograph of a lizard playing chess, with my son...

...and the lizard was cheating by taking too much time to make his first move and eventually forfeited. Never turn your back on a reptile...

on 9/13/03 4:19 PM, Mogens Nørgaard at mln_at_miracleas.dk wrote:

> Well, no I haven't seen him actually take a shower, but one must hope
> that the sound of running water for 42 minutes followed by silence for
> another 21 minutes must mean that water has run down Cary and not just
> down the drain.
> 
> And although I haven't seen him take the shower, we're many OakTable
> members who have seen him go into the bathroom and come out of bathroom
> - because we were all waiting for him to finish so the other 15 people
> could get their 42 seconds showers that they were entitled to.
> 
> Cary is, indeed, a clean guy.
> 
> Mogens
> 
> Rachel Carmichael wrote:
> 

>>> 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: Tim Gorman
  INET: tim_at_sagelogix.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 - 18:54:24 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US