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 <[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: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= 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).
