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: Oracle 9i Articles - self tuning, launch delayed to

Re: Oracle 9i Articles - self tuning, launch delayed to

From: Paul Drake <paled_at_home.com>
Date: Thu, 10 May 2001 23:48:23 -0700
Message-ID: <F001.00300791.20010510233521@fatcity.com>

"Eric D. Pierce" wrote:
>
> "Summary
>
> Self-tuning, self-managing Oracle9i monitors your system
> to provide high availability, reliability and minimized
> downtime. Whether you are a hosting service, in-house
> data center, or IT organization, you can rely on Oracle9i
> and its system management products to provide optimal
> quality of service to all users. "
>

Eric,

I believe that I see the emergence of new BOFH "excuse of the day" material:

(I will quote from a former life - Chemical Process Control - An Introduction to Theory and Practice.
I knew that someday, Laplace Transforms would be somehow useful. Hello again, imaginary numbers.)

Windup-error

        Here the tuning interval was so large, that the disturbances experienced recently are so diluted by the non-peak time intervals that the ability to discern problems is like trying to find a bomb the size of a lipstick container in all of the purses in a New York commute morning.

        analogy - cache hit ratios when correlated subqueries are reusing cursors/code billions of times.

        concepts - autoextending datafiles that cannot reuse extents - purely capacitive process.

Dead time

        Well, if init.ora parameters are only changed when the instance is terminated,

        uptime = dead time, in a self-tuning paradigm.
        analogy #1 - unplugging the leads to the controller mechanism.
        analogy #2 - disconnecting the phone, power off the cell phone, close
the email client.
        

Phase Lag

        an offset between the input and output signals.
        analogy - a dog chasing his/her tail - but never quite catching it.
                  In further detail, the distance between the dog snout and tip of the
tail, divided by the circumference of the perimeter of the (outer) circling dog fur (in radians).

        Mmmmm ... pie.

Crossover Frequency

        This has nothing to do with bisexuals.
        It has to do with system stability once the control loop is closed.
        If the gain margin at the crossover frequency is too large, the system
will be unstable.
        In this case, the operating system and DBA will be blamed.
        Open loop tuning = advice
        Closed loop tuning = implemented advice, now put to the test.
Consultants have long since left. Run.
        "We don't actually implement solutions, we just recommend them".

Amplitude Ratio

        This has to do with a self-tuning mechanism, and rival tuning goals of server and user processes competing for resources (e.g. memory). A critically dampened tuning algorithm will overshoot the optimal target by 17% and converge on the ideal solution without a sinousoidal response signal. Most others will oscillate in a perpertual fashion. Unfortunately, a 17% overestimation in available memory will cause the paging daemon to chime in, causing the DBA and SysAdmin to disable the auto-tuning in favor of "going with what has worked for the past nn years". The Bhopal disaster (MIC) was caused when field personnel disabled 3 layers of control systems and additional safety systems. You can't optimize globally and tune locally. Maybe the holistic method has a point.

Acronyms

        P       Proportional Control
        PI      Proportional Integral Control
        PD      Proportional Derivative Control
        PID     Proportional Integral Derivative Control

Bode stability criterion

        we'll save that for the advanced session. Tune in tomorrow.

Paul
used to be a Chem Engr.
Database Blowups are far better than Chemical Process Industry plant blowups.
AFAIK, no one has died from a database crash.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Paul Drake
  INET: paled_at_home.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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 Fri May 11 2001 - 01:48:23 CDT

Original text of this message

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