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.

I will explain just about everything you'll ever need to know about cursors. but it's good to know what's really happening. Here. If you're not interested in cursors now. 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). right? What's the difference between these two statements: select * from table where name='Dratz'. and select * from table where name= :b1. so it can be reused by everyone. We'll get into this when we discuss SQL. --------------------------------------CURSORS AND THEIR CURSERS (I'm going to get sucked into a long SQL or PL/SQL discussion here. That's a bind variable. most people (including me?) that try to explain cursors don't know what they're talking about and confuse personal preference with fact. GOTO Runtime Area below) The word CURSOR has a very long history that I think is interesting. And it doesn't change the execution plan. -------------------------------------* Oracle is making it easier and easier to share cursors." . databases have used the term 'cursor' and many people have been confused about them ever since. That's because they leave a lot of cursors open that just keep taking up space. but "beyond the scope of this blog. It holds things like bind variables.----------------------------------Persistent Area This part of the PGA does not go away until you tell it to. the second one can be reused for any name by just plugging in the name at runtime. To understand database cursors. People run into this problem (and complain "cursors are bad") with EXPLICIT CURSORS a lot. I go back to the original Latin where the word cursor is used to "express the idea of someone or something that runs. -------------------------------------When does it go away? When you close the cursor." For the last 30 or 40 years or so. You DO know what a bind variable is. The first one is only "sharable*" when someone wants to limit the name to 'Dratz'. For one thing.

) and go into more appllication focused issues like cursor variables (ref cursors) and cursor types like STATIC. Avoid both types of people and be your own person. Oracle expects you to tell it how to handle it (since you're taking explicit control of it). no because there's still lot's more to know to really make good design decisions. For explicit cursors. When I type in a DML statement and run it.. etc. Not closing cursors is a common mistake that is easily fixed (if you just investigate). it is functioning as a cursor. that you don't understand how complicated databases are. KEYSET-DRIVEN. etc. So. Keep reading these posts. Another difference between implicit and explicit cursors is how they are handled. 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. whatever I asked it to do. open. really acts on the whole result set. 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. because some people will think you're an idiot for saying that.. 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). But the reality is that when a SQL statement is parsed. then pick a solution that fits your needs. CLOSE to control explicit cursors (what? but you said. Is that everything you NEED to know about cursors? Yes and no. Then they'll probably tell you they've got some kind of certification that proves they know what they're talking about. 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. and close all happen behind the scenes. meaning that the declare. understand how Oracle really works. ++ blame/credit alexisl for getting me to add this sidebar to this post . fetch. Some people think that cursors are limited to only PL/SQL and many more people only think of cursors in their EXPLICIT incarnation. and close the cursor. fetch. You'll find people who swear by explicit cursors and people who swear they'll never use them. For implicit cursors. Oracle handles them for you. I am running an IMPLICIT CURSOR. And don't let some clown tell you that "standards" force you to use one or the other. That means you have to explain how you want Oracle to open.FETCH. This is an example of a set-based operation.Now I'll tell you the big secret about cursors in Oracle: all SQL statements are cursors! Be careful who you tell that to. FOWARD-ONLY. Yes because that's basically what they are.

Our query process reads the data in the buffer cache and does what? a. Where I put these processed (and processing) rows is in the SORT AREA within the runtime area. not blocks? d. but since we're talking about the runtime area of the PGA. I know as soon as I'm done and get those . Right now. We check the buffer cache (it's empty) 3. Because it's in the runtime area. as soon as you get to the EXECUTE phase. I'm not as interested in what does the sorting as much as I am in WHERE this sorting is done. I get the next value. I issue the following statement: SELECT NAME FROM MYTABLE ORDER BY NAME. The statement is parsed (we haven't really gone over that yet) 2. I have to mention sorting. copy the blocks from the SGA to our PGA? b. What happens: 1. copy all of the rows to the PGA. 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.-------------------------------------- RUNTIME AREA This area stores things that are required during the execution phase of a transaction. 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). does the second value belong above or below the first value. get next value. In fact. Say I want to get a list of names from my table in alphabetical order. copy only the rows we asked for to our PGA? c. I've read the rows from the blocks in the buffer cache and now I do a standard sort operation: I have a value. Let's say it is the very first statement run after opening up the database (might as well refresh ourselves on earlier posts). something has to SORT the results and put the values in the right order. but as rows. repeat. Because I want my result set delivered alphabetically. We read data blocks from disk and put them into the buffer cache (part of the SGA) 4.

a fixed-size footprint that is OS specific 2. you know more than 1/2 of what you need to know about how Oracle really works. . but the basics are the most important pieces. You see. Then I'll show you how you can fill in the rest of the pieces as you need to. ******************************************** I hope I haven't rushed through the SGA and PGA too quickly. I don't want to jump any further into sort areas now. I can reduce the sort area size (basically). a runtime area that holds notes about the current execution and provides space for things like sorting and hashing. I'm not going into the details here. I will teach you the easiest thing to do with an Oracle database: back it up and recover it. The good news is that if you understand these first 7 posts.). So. etc. 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. in summary. I'm teaching you all the hard stuff first.the stuff you really need to know. Everything else will easily fall into place in context. a "persistent" area that holds things like logon information and bind variables 3. After I explain some important Oracle processes (little specific engines designed to do limited things very well). The most important things to know are the basics. I know there's a lot more things to discuss with each of them. because they fit best elsewhere and because Oracle has moved away from those settings anyway to allow more flexible management of PGA resources (memory). I'm just making it easy by focusing on the basics-.rows delivered. 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. See PGA_AGGREGATE_TARGET if you just can't wait. I'm tricking you. there's more to consider than just the PGA (like when it goes from memory to disk. But it is important to know about because with older versions of Oracle. the PGA has 3 basic pieces: 1.

Sign up to vote on this title
UsefulNot useful