Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
Share Embed Flag
Download ePaper

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

CHAPTER 4 ■ MEMORY STRUCTURES 135 PGA and UGA Wrap-Up So far, we have looked at two memory structures: the PGA and the UGA. You should understand now that the PGA is private to a process. It is the set of variables that an Oracle dedicated or shared server needs to have independent of a session. The PGA is a “heap” of memory in which other structures may be allocated. The UGA is also a heap of memory in which various session-specific structures may be defined. The UGA is allocated from the PGA when you use a dedicated server to connect to Oracle and from the SGA under a shared server connection. This implies that when using a shared server, you must size your SGA’s Large pool to have enough space in it to cater for every possible user that will ever connect to your database concurrently. So, the SGA of a database supporting shared server connections is generally much larger than the SGA for a similarly configured, dedicated server mode–only database. We’ll cover the SGA in more detail next. The System Global Area Every Oracle instance has one big memory structure referred to as the System Global Area (SGA). This is a large, shared memory structure that every Oracle process will access at one point or another. It will vary in size from a few of megabytes on small test systems, to hundreds of megabytes on medium to large systems, up to many gigabytes in size for really big systems. On a UNIX operating system, the SGA is a physical entity that you can “see” from the OS command line. It is physically implemented as a shared memory segment—a stand-alone piece of memory to which processes may attach. It is possible to have an SGA on a system without having any Oracle processes; the memory stands alone. It should be noted, however, that if you have an SGA without any Oracle processes, this is an indication that the database crashed in some fashion. It is an unusual situation, but it can happen. This is what an SGA “looks like” on Red Hat Linux: [tkyte@localhost tkyte]$ ipcs -m | grep ora 0x99875060 2031619 ora10g 660 538968064 15 0x0d998a20 1966088 ora9ir2 660 117440512 45 0x6b390abc 1998857 ora9ir1 660 130560000 50 Three SGAs are represented here: one owned by the OS user ora10g, another by the OS user ora9ir2, and the third by the OS user ora9ir1. They are about 512MB, 112MB, and 124MB, respectively. On Windows, you really cannot see the SGA as a distinct entity the way you can in UNIX/Linux. Because on the Windows platform, Oracle executes as a single process with a single address space, the SGA is allocated as private memory to the oracle.exe process. If you use the Windows Task Manager or some other performance tool, you can see how much memory oracle.exe has allocated, but you cannot see what is the SGA versus any other piece of allocated memory. Within Oracle itself, you can see the SGA regardless of platform, using another magic V$ view called V$SGASTAT. It might look as follows (note that this code does not come from the preceding system; it’s from a system with all features configured to enable viewing of all pools available):

136 CHAPTER 4 ■ MEMORY STRUCTURES ops$tkyte@ORA10G> compute sum of bytes on pool ops$tkyte@ORA10G> break on pool skip 1 ops$tkyte@ORA10G> select pool, name, bytes 2 from v$sgastat 3 order by pool, name; POOL NAME BYTES ------------ ------------------------------ ---------- java pool free memory 16777216 ************ ---------- sum 16777216 large pool PX msg pool 64000 free memory 16713216 ************ ---------- sum 16777216 shared pool ASH buffers 2097152 FileOpenBlock 746704 KGLS heap 777516 KQR L SO 29696 KQR M PO 599576 KQR M SO 42496 ... sql area 2664728 table definiti 280 trigger defini 1792 trigger inform 1944 trigger source 640 type object de 183804 ************ ---------- sum 352321536 streams pool free memory 33554432 ************ ---------- sum 33554432 buffer_cache 1157627904 fixed_sga 779316 log_buffer 262144 ************ ---------- sum 1158669364 43 rows selected.

136<br />

CHAPTER 4 ■ MEMORY STRUCTURES<br />

ops$tkyte@ORA10G> compute sum of bytes on pool<br />

ops$tkyte@ORA10G> break on pool skip 1<br />

ops$tkyte@ORA10G> select pool, name, bytes<br />

2 from v$sgastat<br />

3 order by pool, name;<br />

POOL NAME BYTES<br />

------------ ------------------------------ ----------<br />

java pool free memory 16777216<br />

************ ----------<br />

sum 16777216<br />

large pool PX msg pool 64000<br />

free memory 16713216<br />

************ ----------<br />

sum 16777216<br />

shared pool ASH buffers 2097152<br />

FileOpenBlock 746704<br />

KGLS heap 777516<br />

KQR L SO 29696<br />

KQR M PO 599576<br />

KQR M SO 42496<br />

...<br />

sql area 2664728<br />

table definiti 280<br />

trigger defini 1792<br />

trigger inform 1944<br />

trigger source 640<br />

type object de 183804<br />

************ ----------<br />

sum 352321536<br />

streams pool free memory 33554432<br />

************ ----------<br />

sum 33554432<br />

buffer_cache 1157627904<br />

fixed_sga 779316<br />

log_buffer 262144<br />

************ ----------<br />

sum 1158669364<br />

43 rows selected.

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!