Where does the instance tuning fit if we use the below-mentioned order
implementation.
1. Tune the design.
2.Tune the application.
3. Tune memory.
4. Tune I/O.
5. Tune contention.
6. Tune the operating system.

On Jun 21, 12:48 pm, sd2611 <sd2...@gmail.com> wrote:
> Where does the instance tuning fit if we use the below-mentioned order
> implementation.
> 1. Tune the design.
> 2.Tune the application.
> 3. Tune memory.
> 4. Tune I/O.
> 5. Tune contention.
> 6. Tune the operating system.

Ummm this doesn't look like any kind of mensa test ( not that I would
know ) so the answer is kind of obvious.

Where did you get this multiple choice test item?

Which of the 6 answers do you think is the best choice for your
"Where" question?

As far as I am concerned, anything with such limited context is pretty
useless anyways IMHO.

sd2611 <sd2611@gmail.com> wrote in news:1182444501.818580.220700
@x35g2000prf.googlegroups.com:

> Where does the instance tuning fit if we use the below-mentioned order
> implementation.
> 1. Tune the design.
> 2.Tune the application.
> 3. Tune memory.
> 4. Tune I/O.
> 5. Tune contention.
> 6. Tune the operating system.
>

IMO, #3 & #4 are the only 2 which can be tuned by throwing money at the
problem; more hardware, more better.

How does one "tune contention" WITHOUT tuning 1 of the other 5 listed?

STUPID LIST!

On Thu, 21 Jun 2007 09:48:21 -0700, sd2611 wrote:

> Where does the instance tuning fit if we use the below-mentioned order
> implementation.
> 1. Tune the design.
> 2.Tune the application.
> 3. Tune memory.
> 4. Tune I/O.
> 5. Tune contention.
> 6. Tune the operating system.

It doesn't fit. One never tunes instance, I/O contention or the OS. One
can only tune the application. One does that by adjusting application,
instance parameters, OS parameters and all the rest, as needed.
Instance without application system running against it never needs
tuning.

--
http://www.mladen-gogala.com

On Fri, 22 Jun 2007 20:47:58 GMT, Mladen Gogala
<mgogala.SPAM_ME.NOT@verizon.net> wrote:

>On Thu, 21 Jun 2007 09:48:21 -0700, sd2611 wrote:
>
>> Where does the instance tuning fit if we use the below-mentioned order
>> implementation.
>> 1. Tune the design.
>> 2.Tune the application.
>> 3. Tune memory.
>> 4. Tune I/O.
>> 5. Tune contention.
>> 6. Tune the operating system.
>
>It doesn't fit. One never tunes instance, I/O contention or the OS. One
>can only tune the application. One does that by adjusting application,
>instance parameters, OS parameters and all the rest, as needed.
>Instance without application system running against it never needs
>tuning.

Usually one can't tune the application as it has been developed by an
ISV and they don't know how to tune.
This is the point where the Burlesons and Aults of this world come in,
and start throwing iron at the problem.

--
Sybrand Bakker
Senior Oracle DBA

Ana C. Dent wrote:
> sd2611 <sd2611@gmail.com> wrote in news:1182444501.818580.220700
> @x35g2000prf.googlegroups.com:
>
>> Where does the instance tuning fit if we use the below-mentioned order
>> implementation.
>> 1. Tune the design.
>> 2.Tune the application.
>> 3. Tune memory.
>> 4. Tune I/O.
>> 5. Tune contention.
>> 6. Tune the operating system.
>>
>
> IMO, #3 & #4 are the only 2 which can be tuned by throwing money at the
> problem; more hardware, more better.

Really? Maybe I read it differently.

Tuning memory can involve making sure you SGA components are sized
correctly. And tuning I/O can involve making sure that you have spread
out your highly active segments among multiple disks and controllers.
This doesn't necessarily mean throwing more hardware at the problem.

Cheers,
Brian




--
================================================== =================

Brian Peasland
dba@nospam.peasland.net
http://www.peasland.net

Remove the "nospam." from the email address to email me.


"I can give it to you cheap, quick, and good.
Now pick two out of the three" - Unknown

--
Posted via a free Usenet account from http://www.teranews.com

Brian Peasland wrote:
> Ana C. Dent wrote:
>> sd2611 <sd2611@gmail.com> wrote in news:1182444501.818580.220700
>> @x35g2000prf.googlegroups.com:
>>
>>> Where does the instance tuning fit if we use the below-mentioned order
>>> implementation.
>>> 1. Tune the design.
>>> 2.Tune the application.
>>> 3. Tune memory.
>>> 4. Tune I/O.
>>> 5. Tune contention.
>>> 6. Tune the operating system.
>>>
>>
>> IMO, #3 & #4 are the only 2 which can be tuned by throwing money at
>> the problem; more hardware, more better.
>
> Really? Maybe I read it differently.
>
> Tuning memory can involve making sure you SGA components are sized
> correctly. And tuning I/O can involve making sure that you have spread
> out your highly active segments among multiple disks and controllers.
> This doesn't necessarily mean throwing more hardware at the problem.
>
> Cheers,
> Brian

I read it the way you did Brian. One can also tune networks, for example
with Data Guard and Streams by setting SDU at 32K, etc.

But it is not, as the OP assumed, a sequential process. You gather
metrics and you tune the identified choke-point.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

On Jun 22, 1:06 pm, "Ana C. Dent" <anaced...@hotmail.com> wrote:
> sd2611 <sd2...@gmail.com> wrote in news:1182444501.818580.220700
> @x35g2000prf.googlegroups.com:
>
> > Where does the instance tuning fit if we use the below-mentioned order
> > implementation.
> > 1. Tune the design.
> > 2.Tune the application.
> > 3. Tune memory.
> > 4. Tune I/O.
> > 5. Tune contention.
> > 6. Tune the operating system.
>
> IMO, #3 & #4 are the only 2 which can be tuned by throwing money at the
> problem; more hardware, more better.
>
> How does one "tune contention" WITHOUT tuning 1 of the other 5 listed?
>
> STUPID LIST!

It is actually the order of events described and promoted in Oracle
University's Performance Tuning course (at least the 9i version... I
don't recall the 10g version off the top of my head).

Whilst everyone's busy rubbishing it, I would point out that it
contains important truths: getting the application and database
designs right is paramount (normalisation, etc). And you have to get
those designs right before starting to tinker with SHARED_POOL_SIZE
and such instance/memory parameters (incidentally: note to the
original poster... the answer to your question is at step 3 of your
list. Tuning memory means tuning the SGA, and that means you're tuning
the instance).. And it is probably going to be more productive tuning
things like your shared pool, buffer cache and large pool before you
start worrying about I/O (on the grounds that if you get the buffer
cache right, for example, you won't be doing much by way of physical I/
O in the first place). And once you've got all those big ticket items
out of the way, then it makes sense to look at contention-induced
issues (deadlocking and long uncommitted transactions, non-indexed
foreign keys, sufficient rollback segments (largely made redundant
with automatic undo, of course), redo/archives (LGWR contending with
ARCH) and so on).

A specific answer to your first question, therefore, is "perfectly
well, provided you understand what is included in step 5 and what's
included in the first 4 steps". It always helps to have a context for
these things.

The real point that Oracle's own list makes, I think, is that if you
dive in trying to tune I/O when your design consists of non-normalised
tables with 506 columns of CHAR(2000), you're wasting your time. Take
things in the 'DAMICOS' order, however, and you stand a good chance of
doing 80% of your tuning once the first two items are dealt with.
Whether you agree with the specific items listed is a different
matter: that it makes sense to normalise appropriately before worrying
about lock contention is, I think, undoubtedly true.

Of course, back in the real world, we inherit our designs and
application code and have to start work at Step 3. And quite often,
you'll find managers expecting the DBA to work miracles at step 3 to
correct the deficiencies introduced at steps 1 and 2 -and getting
frustrated when they can't.

Anyway, before everyone dives onto the 'stupid list' bandwagon,
understand where it came from and what it's actually trying to say:
the order of event in tuning is important. That's a pretty sensible
message, actually.

On Jun 26, 12:57 am, hjr.pyth...@gmail.com wrote:

> > sd2611 <sd2...@gmail.com> wrote in news:1182444501.818580.220700
> > @x35g2000prf.googlegroups.com:
>
> > > Where does the instance tuning fit if we use the below-mentioned order
> > > implementation.
> > > 1. Tune the design.
> > > 2.Tune the application.
> > > 3. Tune memory.
> > > 4. Tune I/O.
> > > 5. Tune contention.
> > > 6. Tune the operating system.
>


>
> It is actually the order of events described and promoted in Oracle
> University's Performance Tuning course (at least the 9i version... I
> don't recall the 10g version off the top of my head).

There was not a 10g version of that course until recently. Oracle
finally decided that too many people were asking about a 10g course in
that area that they could not turn that money down. The 10g course is
heavily slanted to basic tasks chiefly oriented around working the OEM
GUI. ( The message from oracle seems to be "we can build a better
machine if you just know how to click around on the GUI that's all you
need to know" ).

The 9i course was just pathetic IMHO. Perhaps marginally better than
earlier versions as oracle finally admitted that wait events and
understanding what was contributing to response time might be useful.

>
> Whilst everyone's busy rubbishing it, I would point out that it
> contains important truths: getting the application and database
> designs right is paramount (normalisation, etc). And you have to get
> those designs right before starting to tinker with SHARED_POOL_SIZE
> and such instance/memory parameters (incidentally: note to the
> original poster... the answer to your question is at step 3 of your
> list. Tuning memory means tuning the SGA, and that means you're tuning
> the instance).. And it is probably going to be more productive tuning
> things like your shared pool, buffer cache and large pool before you
> start worrying about I/O (on the grounds that if you get the buffer
> cache right, for example, you won't be doing much by way of physical I/
> O in the first place). And once you've got all those big ticket items
> out of the way, then it makes sense to look at contention-induced
> issues (deadlocking and long uncommitted transactions, non-indexed
> foreign keys, sufficient rollback segments (largely made redundant
> with automatic undo, of course), redo/archives (LGWR contending with
> ARCH) and so on).

Personally I think an approach as documented and advocated by Cary
Millsap in "Optimizing Oracle Performance" is the way to go.

Database design is crucial as well as the knowledge of how to write
scalable applications. If that doesn't happen from the get go then
Cary's methodology is about all we have left to work with.

>
> A specific answer to your first question, therefore, is "perfectly
> well, provided you understand what is included in step 5 and what's
> included in the first 4 steps". It always helps to have a context for
> these things.
>
> The real point that Oracle's own list makes, I think, is that if you
> dive in trying to tune I/O when your design consists of non-normalised
> tables with 506 columns of CHAR(2000), you're wasting your time. Take
> things in the 'DAMICOS' order, however, and you stand a good chance of
> doing 80% of your tuning once the first two items are dealt with.
> Whether you agree with the specific items listed is a different
> matter: that it makes sense to normalise appropriately before worrying
> about lock contention is, I think, undoubtedly true.
>
> Of course, back in the real world, we inherit our designs and
> application code and have to start work at Step 3. And quite often,
> you'll find managers expecting the DBA to work miracles at step 3 to
> correct the deficiencies introduced at steps 1 and 2 -and getting
> frustrated when they can't.
>
> Anyway, before everyone dives onto the 'stupid list' bandwagon,
> understand where it came from and what it's actually trying to say:
> the order of event in tuning is important. That's a pretty sensible
> message, actually.

The original list as presented without any additional context was not
worthwhile.

The original question as asked yes had an obvious answer. I asked the
OP which one they would choose and hever heard back.

It did appear as is someone was just trying to do some homework using
cdos IMHO.

hjr.pythian@gmail.com wrote:

>> STUPID LIST!
>
> It is actually the order of events described and promoted in Oracle
> University's Performance Tuning course

Which explains why there is such a large demand for books by those
who know what they are doing like Jonathan Lewis, Cary Millsap, and
Gaja Krishna Vaidyanatha.

Did I say that out loud?
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org