Re: SGA

From: joel garry <joel-garry_at_home.com>
Date: Thu, 5 Feb 2009 16:12:10 -0800 (PST)
Message-ID: <87fc93b8-277e-4226-aa02-2d246eab180b_at_x16g2000prn.googlegroups.com>



On Feb 5, 11:43 am, Mtek <m..._at_mtekusa.com> wrote:
> On Feb 5, 9:15 am, Mark D Powell <Mark.Pow..._at_eds.com> wrote:
>
>
>
>
>
> > On Feb 5, 2:17 am, Robert Klemme <shortcut..._at_googlemail.com> wrote:
>
> > > On 05.02.2009 01:42, mrdjmag..._at_aol.com wrote:
>
> > > > I'm looking for a book that is dedicated to the SGA.  Explaining how
> > > > the different parts work together, how changing a parameter affects
> > > > the different parts fo the SGA and the performance.  PGA, Buffer
> > > > Cache, etc........  Already know how to program.  Do not need a PLSQL
> > > > review.  Just interested in the SGA in great detail.......
>
> > > Did you read this?
>
> > >http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/memory...
>
> > >http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory...
>
> > >http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/manpro...
>
> > > If not, it's a good starting point.
>
> > > Cheers
>
> > >         robert
>
> > Robert, your response lists the same three manuals that came to mind.
>
> > Mrdjmag, you cannot go wrong by starting with Concepts, moving to DBA
> > Administration, and then accessing the Performance and Tuning manual
> > as your starting point.  Then you can search Oracle support and/or the
> > web for articles written on specific latches, enqueues, and issues.
>
> > The full title for the book hpuxrac mentioned is probably:
> > Expert Oracle Database Architecture by Tom Kyte.
>
> > HTH -- Mark D Powell --
>
> Thanks for all your replies.  One thing I am looking for is how to
> identify certain situations and what effect it has when you change a
> certain memory parameter, on the situation, on the entire database?
>
> Examples:
>
> I have some issues with my sort area.  So I increase that.  What
> effect would have on the SGA, PGA, UGA, etc.......I think that kind of
> information can be quite useful.....

Try variations on http://www.google.com/search?hl=en&q=%22jonathan+lewis%22+%22tanel+poder%22&btnG=Search

http://www.juliandyke.com/Presentations/Presentations.html http://www.tusc.com/oracle/download/available.html And so much more.

The most important point: You need to do things yourself, such as learn how to use various debug and dump facilities to see what these people are talking about.

(wtf, my readme-cdos is 404...)

>
> OR
>
> Certain packages are executed hundreds of time.  Should they be
> pinned?  If yes, again, what effect on everything.....

Depends on whether you have a problem with the shared pool being too small. If the shared pool is sized correctly, something that is used often will be there. On some older versions, it was common that large packages not used much might have problems because of fragmentation of the pool as different sized things came and went. On some newer versions, memory can get thrashed as auto-tuning goes nuts. There are really too many variables to reliably predict the effect on everything, that's why you have to state a particular configuration and measure a representative load. Yes, this can be done in a scientific manner, but it's expensive. A troll through the fixed bugs lists of various patch sets (especially the early to middle 9.2 Oracle) shows that even Oracle has a hard time figuring this stuff out.

>
> That kind of info is a good tool to have.....

Is it now? You need to be solid with the basics before it can be useful at all. Then it is arguable. And as Jonathan Lewis and others have pointed out, the docs and anything else on the intertubes can be just plain wrong. I'm to the point of "distrust, then verify."

It is very interesting, though.

jg

--
_at_home.com is bogus.
“Young people in particular conclude that if it's so easy, it can't be
wrong.” - Richard Cotton
http://www3.signonsandiego.com/stories/2009/feb/05/1n5piracy23823-digital-pirates-winning-battle-holl/?uniontrib
starrrrrrrrrrheamin
Received on Thu Feb 05 2009 - 18:12:10 CST

Original text of this message