Why Oracle Works the Way it Does (7) -

The PGA
Last time, we discussed some of the shared memory components in Oracle. This time
we'll talk about Oracle's private parts (hey! get your mind out of the gutter). Specifically,
let's talk about the Program Global Area (PGA).

We are going to assume a dedicated server connection to the database (like last time).

So, it's easy to see where we'll get some increases in performance and scalability by using
the SGA properly. Can we get similar benefits from the PGA?

Well, kinda. It depends on if your developers and designers know what they're doing or
not.

Design obviously affects shared resources as well, but shared resources don't keep
copying the same mistake(s) for every server process!

First let me just name a few pieces of the PGA:

-Oracle code (the size of this is OS specific and the only thing you can do to affect it is
change OS's)
- a persistent area (once allocated sticks around for the life of that session or you CLOSE
some things)
- a runtime area (deallocated after the execution phase is complete)

Oracle Code

Since there's nothing you can do about this piece other than migrating to another OS, all
you can really do is be aware of it. BUT, if you investigate this in your OS-specific
documentation, you could find that Oracle software code area on your OS is 2 megs per
dedicated server. On another OS, you may find it is only 1 meg per dedicated server.

So, depending on your OS, you could be doubling the startup size of your PGA. This is
memory that is allocated from the OS for the private use of that PGA.

-----------------------------------
Two things to think about here if you need to scale to a high number of users: consider
using SHARED SERVERS (formerly MTS) to greatly reduce the size (by reducing the
number) of the PGA; or, if you prefer to/must use DEDICATED SERVERS, install on an
OS that has a smaller code area requirement.

Just think about it, don't use it as a rule of thumb.

-----------------------------------

Persistent Area

This part of the PGA does not go away until you tell it to. It holds things like bind
variables. You DO know what a bind variable is, right?

What's the difference between these two statements:

select * from table where name='Dratz';

and
select * from table where name= :b1;

The first one is only "sharable*" when someone wants to limit the name to 'Dratz', the
second one can be reused for any name by just plugging in the name at runtime.

That's a bind variable. And it doesn't change the execution plan, so it can be reused by
everyone. We'll get into this when we discuss SQL.
--------------------------------------
* Oracle is making it easier and easier to share cursors, but it's good to know what's
really happening.
--------------------------------------

When does it go away? When you close the cursor. People run into this problem (and
complain "cursors are bad") with EXPLICIT CURSORS a lot. That's because they leave
a lot of cursors open that just keep taking up space. Just CLOSE them and you'll be fine
(unless your design is so poor that you can't finish your transaction without opening
dozens of cursors).

---------------------------------------

CURSORS AND THEIR CURSERS (I'm going to get sucked into a long SQL or
PL/SQL discussion here. If you're not interested in cursors now, GOTO Runtime Area
below)

The word CURSOR has a very long history that I think is interesting, but "beyond the
scope of this blog." For the last 30 or 40 years or so, databases have used the term 'cursor'
and many people have been confused about them ever since. Here, I will explain just
about everything you'll ever need to know about cursors.

For one thing, most people (including me?) that try to explain cursors don't know what
they're talking about and confuse personal preference with fact.

To understand database cursors, I go back to the original Latin where the word cursor is
used to "express the idea of someone or something that runs."
Now I'll tell you the big secret about cursors in Oracle: all SQL statements are cursors!
Be careful who you tell that to, because some people will think you're an idiot for saying
that, that you don't understand how complicated databases are, etc. Then they'll probably
tell you they've got some kind of certification that proves they know what they're talking
about.

But the reality is that when a SQL statement is parsed, it is functioning as a cursor. Some
people think that cursors are limited to only PL/SQL and many more people only think of
cursors in their EXPLICIT incarnation.

When I type in a DML statement and run it, I am running an IMPLICIT CURSOR. I have
really no control over it other than what I put into the statement itself (like maybe a
TO_DATE() or a GROUP BY). So, whatever I asked it to do, really acts on the whole
result set. This is an example of a set-based operation.

If I wanted more control over the set of rows I get back from a SELECT (like I want to
evaluate a certain column or two in each row and decide what to do with that row based
on the actual data values) then I could use EXPLICIT CURSORS. Explicit cursors are a
type of row-based operation and give me a lot of control over how I handle the results I
get back.

Another difference between implicit and explicit cursors is how they are handled. For
implicit cursors, Oracle handles them for you, meaning that the declare, open, fetch, and
close all happen behind the scenes.

For explicit cursors, Oracle expects you to tell it how to handle it (since you're taking
explicit control of it). That means you have to explain how you want Oracle to open,
fetch, and close the cursor. Not closing cursors is a common mistake that is easily fixed
(if you just investigate).

Is that everything you NEED to know about cursors? Yes and no. Yes because that's
basically what they are; no because there's still lot's more to know to really make good
design decisions.

These other things will be covered in a later post and will show you how you don't really
have to use the keywords OPEN,FETCH, CLOSE to control explicit cursors (what? but
you said...) and go into more appllication focused issues like cursor variables (ref cursors)
and cursor types like STATIC, FOWARD-ONLY, KEYSET-DRIVEN, etc.

You'll find people who swear by explicit cursors and people who swear they'll never use
them. Avoid both types of people and be your own person. Keep reading these posts,
understand how Oracle really works, then pick a solution that fits your needs. And don't
let some clown tell you that "standards" force you to use one or the other.

++ blame/credit alexisl for getting me to add this sidebar to this post

--------------------------------------

RUNTIME AREA

This area stores things that are required during the execution phase of a transaction. In
fact, as soon as you get to the EXECUTE phase, the first thing Oracle does is build a
runtime area.

The thing I want you to be aware of about the runtime area is what makes this piece big
(or small).

Say I want to get a list of names from my table in alphabetical order. I issue the following
statement:

SELECT NAME FROM MYTABLE ORDER BY NAME;

Let's say it is the very first statement run after opening up the database (might as well
refresh ourselves on earlier posts).

What happens:

1. The statement is parsed (we haven't really gone over that yet)
2. We check the buffer cache (it's empty)
3. We read data blocks from disk and put them into the buffer cache (part of the SGA)
4. Our query process reads the data in the buffer cache and does what?

a. copy the blocks from the SGA to our PGA?

b. copy only the rows we asked for to our PGA?
c. copy all of the rows to the PGA, but as rows, not blocks?
d. copy nothing and just present the results to the client?

That's a good homework question I'll let you ponder until we get to those topics, but since
we're talking about the runtime area of the PGA, I have to mention sorting.

Because I want my result set delivered alphabetically, something has to SORT the results
and put the values in the right order. Right now, I'm not as interested in what does the
sorting as much as I am in WHERE this sorting is done.

I've read the rows from the blocks in the buffer cache and now I do a standard sort
operation: I have a value; I get the next value; does the second value belong above or
below the first value; get next value, repeat.

Where I put these processed (and processing) rows is in the SORT AREA within the
runtime area. Because it's in the runtime area, I know as soon as I'm done and get those
rows delivered, I can reduce the sort area size (basically).

I don't want to jump any further into sort areas now, there's more to consider than just the
PGA (like when it goes from memory to disk, etc.). But it is important to know about
because with older versions of Oracle, one of the ways to control the variable size of the
PGA was to configure the settings for things like sort areas and hash join areas.

I'm not going into the details here, because they fit best elsewhere and because Oracle has
moved away from those settings anyway to allow more flexible management of PGA
resources (memory). See PGA_AGGREGATE_TARGET if you just can't wait.

The most important things to know are the basics.

So, in summary, the PGA has 3 basic pieces:

1. a fixed-size footprint that is OS specific

2. a "persistent" area that holds things like logon information and bind variables
3. a runtime area that holds notes about the current execution and provides space for
things like sorting and hashing.

********************************************

I hope I haven't rushed through the SGA and PGA too quickly. I know there's a lot more
things to discuss with each of them, but the basics are the most important pieces.
Everything else will easily fall into place in context.

The good news is that if you understand these first 7 posts, you know more than 1/2 of
what you need to know about how Oracle really works.

I'm going to start a couple of posts on Oracle processes next and then your training will
be ready for the next level: becoming a junior DBA.

You see, I'm tricking you. I'm teaching you all the hard stuff first. I'm just making it easy
by focusing on the basics-- the stuff you really need to know. Then I'll show you how you
can fill in the rest of the pieces as you need to.

After I explain some important Oracle processes (little specific engines designed to do
limited things very well), I will teach you the easiest thing to do with an Oracle database:
back it up and recover it.