> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [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).
