Re: RBO to CBO

From: DA Morgan <damorgan_at_x.washington.edu>
Date: Wed, 05 Jan 2005 19:32:49 -0800
Message-ID: <41dcb031$1_3@127.0.0.1>

Joel Garry wrote:
> DA Morgan wrote:
>

>>Jack wrote:
>>
>>
>>>"DA Morgan" <damorgan_at_x.washington.edu> wrote in message
>>>news:41db8f14$1_3_at_127.0.0.1...
>>>
>>>
>>>>Jack wrote:
>>>>
>>>>
>>>>
>>>>>>One DBA takes one day to upgrade a system. And most of that time

>
> is the
>

>>>>>>computer churning away while the DBA surfs the web. But to be

>
> generous 7
>

>>>>>>days of which DBAs time costs many tens of thousands of dollars?

>
> And if
>

>>>>>>you find that guy I want his job.
>>>>>>
>>>>>>And yes testing is required. But still the worst case scenario is

>
> a
>

>>>>>>financial break-even every time I've costed it out.
>>>>>>--
>>>>>>Daniel A. Morgan
>>>>>>University of Washington
>>>>>>damorgan_at_x.washington.edu
>>>>>>(replace 'x' with 'u' to respond)
>>>>>
>>>>>
>>>>>Daniel you are talking about theories.
>>>>>In real life there are several databases, different operating

>
> systems,
>

>>>>>new harware etc.
>>>>
>>>>In real life you are correct. But does it take me more time to

>
> upgrade a
>

>>>>Solaris database today, one on HP/UX tomorrow, on AIX on Thursday,

>
> and
>

>>>>one on Windows on Friday? I sure hope not. Nope: 4 databases ... 4

>
> days.
>

>>>>And if you have an environment such as this ... even more reason to

>
> keep
>

>>>>current with versions so that you are running on a supported

>
> platform.
>

>>>>--
>>>>Daniel A. Morgan
>>>>University of Washington
>>>>damorgan_at_x.washington.edu
>>>>(replace 'x' with 'u' to respond)
>>>
>>>
>>>Jep, it is so sipmle.
>>>And after that someboby must do: a one-month gig/database
>>>
>>>In this case it takes 4 months.
>>
>>The size of a database is close to irrelevant to applying a patch or
>>upgrade to a more recent version. To what are you making reference?

>
>
> Recall the Subject: RBO to CBO. A large dataset is more likely to
> require lots of CBO tweaking, especially if you use "how fast the users
> perceive it to be" as a work driver. Those of us who aren't [insert
> fav guru here] can take days to hack through an unfamiliar
> bug/quirk/obscure new hint/tracefile/plan instability/performance
> methodology/whatever. And aren't you the one who requires an explain
> plan for every sql statement?
> jg

Remember the word test? One tests before one patches or upgrades. Those things should be handled at that point in the process and should not significantly affect upgrade time. What are we talking about? Replaceing a few packages with identical copies except for modification of some SQL statements rewritten for the new optimizer version?

I didn't say it was free. I said it was at worst a financial breakeven from my experience. That means there will be expenses but most of them in the testing phase ... not the database modification itself.

Sorry if I was unclear.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)

Received on Wed Jan 05 2005 - 21:32:49 CST