Re: IO function metric.

On Dec 23, 8:00 am, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
> On Tue, 23 Dec 2008 13:22:01 +0000, Mladen Gogala wrote:
>
> Here is a typical "in your face" reply by HJR on the OTN:
>
> Re: Lgwr & dbf Files....
> Posted: Jul 8, 2008 2:10 AM   in response to: Aman.... in response to:
> Aman....                
> Click to report abuse...                Click to reply to this thread  
> Reply
> You are a multi-billion dollar corporation with a successful RDBMS
> product that is the market-leading software in its class.
>
> Your requirements are to keep on releasing new versions of your product
> to keep the market satisfied in its search for innovation and novelty.
> You are also required not to break your product when doing this, because
> otherwise you will annoy all your customers and start losing market
> share. You still remember what happened when you released version 6 of
> your product too early and in a functionally-challenged form! You do NOT
> want to repeat that mess, no siree!
>
> You have a piece of code dating from the dark ages that enables every
> background process to check for the existence of files at instance
> startup. It's pretty archaic in that it means processes which don't have
> anything to do with datafiles still end up checking for their existence
> at startup.
>
> Do you (a) remove this archaic code as part of a code cleanup or (b)
> leave it there, given that having a process check for the existence of
> files at startup doesn't take much time and doesn't do any harm, even if
> it doesn't actually server a good purpose these days?
>
> My guess is that (b) will be the option you take every time. Removing
> code like this, buried in a whole heap of startup bootstapping complexity
> is something that is (1) fundamentally unnecessary (it's doing no harm,
> after all!); (2) is fraught with the risk of breaking things. And (3) is
> a distraction when you're trying to concentrate on a whole lot of new,
> sexy stuff... bootstrap code that's worked since version 5 without
> fundamental alteration is not where your interests lie or where you're
> likely to find much motivation.
>
> Thanks Howard wherever you are!
> --
> Mladen Gogalahttp://mgogala.freehostia.com

I just ran a truss on the LGWR process for an acitve production database and found this:

open("/proc/2129936/psinfo", O_RDONLY) = 69 kread(69, "\0 \0010204\001\0\0\001".., 448) = 448

On this system process id 2129936 is the PMON process for that same database. So it appears to be reading process info for PMON ( I suppose to ensure it's still up and running, as HJR reported in your follow-up post).

David Fitzjarrell Received on Tue Dec 23 2008 - 08:20:56 CST