Tuning PGA_AGGREGATE_TARGET in Oracle 9i

Brian Peasland http://www.peasland.net

Oracle 9i introduced the PGA_AGGREGATE_TARGET parameter to help better manage session working areas in a session’s Program Global Area (PGA). This paper discusses available methods to help tune this new Oracle 9i parameter.

Each Oracle session needs memory set aside for it to perform certain work operations. For instance, if the application requests a sorting operation by using certain SQL statements, like GROUP BY or ORDER BY, the application’s session can perform this sort in memory, provided enough memory has been reserved for that sort operation. If there is not enough reserved memory, then the sort operation is done in pieces using a temporary holding area on disk in the TEMP tablespace. Before Oracle 9i, the DBA configured a session’s working areas by configuring a number of parameters such as BITMAP_MERGE_AREA_SIZE, CREATE_BITMAP_AREA_SIZE, HASH_AREA_SIZE, and SORT_AREA_SIZE. Collectively, these parameters are referred to as the *_AREA_SIZE parameters. The problem with this approach is that one often reserved memory that was never used. If I set SORT_AREA_SIZE=1M and HASH_AREA_SIZE=5M, then I have allocated at least 6MB of working area. What if I needed 2MB for sorting and I am not going to perform any hash joins? I have 5MB of allocated working area that is sitting there idle that I would like to use to assist my sort operation. The pre-9i Oracle DBA had to carefully determine how to allocate the best working area sizes so that optimal performance could be achieved, without using up too much of the server’s physical memory. To address this type of situation, Oracle created a way to let the instance automatically manage the working areas of the database sessions. Oracle 9i now has the ability to reserve a large chunk of working area space in memory and to let the instance dynamically change the working area allocations depending on the session’s operations. One session that needs 1MB of sort space and 4MB of hash area space would fit well into an allocation as defined above. A second session that needs 4MB of sort space and 1MB of hash area space would also fit well into a similar allocation since Oracle 9i now has the capability to dynamically change these working area

This parameter can be set to zero to turn off dynamic working area memory management. You can see an example of this in Figure 1. I will initially set my PGA_AGGREGATE_TARGET initialization parameter.----------. – Setting PGA_AGGREGATE_TARGET With this parameter set. Oracle will now automatically perform dynamic working area memory management. The acceptable range of values is between 10MB and 4096GB – 1. . you need to set the PGA_AGGREGATE_TARGET initialization parameter. not for each server process. Oracle recommends initially setting this parameter to 16% of your server’s physical memory for OLTP systems and 40% of your server’s physical memory for DSS systems. ORA9I SQL> alter system set pga_aggregate_target=160M.--------------------------pga_aggregate_target big integer 167772160 Figure 1. My server has 1GB of physical memory. ORA9I SQL> show parameter pga_aggregate_target NAME TYPE VALUE -----------------------------------. This parameter can be set without restarting the Oracle instance. Oracle 9i uses the PGA_AGGREGATE_TARGET initialization parameter to define the total amount of PGA reserved memory. this is just a starting place. Like any other memory configuration guidelines from Oracle Corp. Using the above guidelines. As a guideline. Initial Setup To begin using this new Oracle 9i feature. Please note that the amount of memory set aside for the PGA_AGGREGATE_TARGET is for all server processes. System altered.allocations depending on the usage. You will most likely want to tune this setting depending on the usage of your system’s resources.

all executions should be in the optimal statistic and the statistics for onepass and multipass should be zero. NAME VALUE UNIT ---------------------------------------. Oracle 9i has added a few statistics to V$SYSTAT and V$SESSTAT. The optimal executions are those operations that were performed entirely in memory. this is the most favorable type of execution. If the operation was too big to be performed in memory. We want to determine when the PGA_AGGREGATE_TARGET is too low to give optimal performance and too high so as to not waste allocated memory. were performed in the work areas. ORA9I SQL> select * from v$pgastat. From the query in Figure 2.Tuning PGA_AGGREGATE_TARGET To illustrate how to tune this parameter. then this execution is noted in the onepass statistic. As the name suggests.---------workarea executions .value from v$sysstat 2> where name like 'workarea executions%'. These executions fall into three categories.optimal 510 workarea executions .---------. or executions.-----------aggregate PGA target parameter 10485760 bytes aggregate PGA auto target 4248576 bytes global memory bound 524288 bytes total PGA inuse 5760000 bytes total PGA allocated 10342400 bytes maximum PGA allocated 42925056 bytes total freeable PGA memory 65536 bytes . Ideally. This view can give you additional statistics on how well the dynamic working area memory management is performing. If only one pass was needed on disk. If more than one pass was needed on disk. 10MB and run a load simulation on my instance. then part of the operation spills onto disk.onepass 1 workarea executions . – V$SYSTAT with 10MB PGA Target The query in Figure 2 shows us how many operations. I can see that my value for PGA_AGGREGATE_TARGET is too small. I will set my PGA_AGGREGATE_TARGET to the minimum value allowed. ORA9I SQL> select name. NAME VALUE ---------------------------------------.multipass 4 Figure 2. Oracle 9i includes a new view called V$PGASTAT. then this execution is noted in the multipass statistic. Oracle 9i gives us many different views to query to see how well our dynamic working area memory management is performing.

The rest of the PGA memory footprint is dynamically tunable and is indicated by the aggregate PGA auto target statistic. If Oracle determines that it cannot honor the setting for PGA_AGGREGATE_TARGET. one-pass. 9306112 0 631808 0 529408 9201 55100416 159971328 25. They are over allocation count and cache hit percentage. Some parts of the PGA are used for non-tunable information such as session context information and other overhead. V$PGASTAT with 10MB PGA Target The first line of output in Figure 3 shows that my PGA_AGGREGATE_TARGET is currently set to 10MB. optimal. The number of times Oracle detects this condition since instance startup is noted by the over allocation count statistic. Let’s look at Figure 4 to see what advice Oracle can give us if we change our PGA_AGGREGATE_TARGET to a different value. The question that remains is how much to increase this parameter to obtain optimal performance without wasting allocated memory? Oracle 9i includes a new V$PGA_TARGET_ADVICE view to help us answer this question.PGA memory freed back to OS total PGA used for auto workareas maximum PGA used for auto workareas total PGA used for manual workareas maximum PGA used for manual workareas over allocation count bytes processed extra bytes read/written cache hit percentage 16 rows selected. then Oracle does not have enough memory to dynamically adjust. The value in the second line of output of Figure 3 should not be significantly smaller than the value in the first line. this value should be zero. and multipass. In order to use this view.61 bytes bytes bytes bytes bytes bytes bytes percent Figure 3. . If all executions where optimal. one needs to ensure that the STATISTICS_LEVEL initialization parameter is set to TYPICAL or ALL. Oracle 9. The cache hit percentage statistic shows a hit ratio on the number of bytes where optimal executions were performed compared the total number of bytes for all executions. If this value is too small.2 includes two additional rows of output to V$PGASTAT. Ideally. as it is above. then this statistic should be 100%. It should be obvious from the queries in Figures 2 and 3 that the PGA_AGGREGATE_TARGET is under allocated. then it needs to allocate additional memory.

------------10 51766272 80197632 39 4 12 51766272 79773696 39 3 14 51766272 79773696 39 3 16 51766272 79773696 39 2 18 51766272 79773696 39 2 20 51766272 79773696 39 2 30 51766272 19943424 72 0 40 51766272 19943424 72 0 60 51766272 19943424 72 0 80 51766272 19943424 72 0 10 rows selected. 3> estd_pga_cache_hit_percentage as est_hit_pct. but a few one-pass executions remain. 2> bytes_processed. Using this information. Figure 4.estd_extra_bytes_rw as est_rw_extra_bytes. NAME VALUE ---------------------------------------. – V$PGA_TARGET_ADVICE with 10MB PGA Target The output in Figure 4 shows us statistics that Oracle estimates would happen under our current workload if the PGA were changed to a different target size.----------.multipass 0 Figure 5. and looking at the target advice. ORA9I SQL> select name. I can see that this is true from the query in Figure 5. . Notice that as we increase the target size.optimal 511 workarea executions . we should first attempt to reduce the estimated over allocations to zero. Let’s now check the results in V$PGASTAT show in Figure 6. Knowing that I need to increase this value.ORA9I SQL> select round(pga_target_for_estimate/1024/1024) as target_size_MB. and the estimated number of bytes read and written in one-pass or multi-pass executions falls as well. – V$SYSTAT with 80MB PGA Target I have eliminated the multi-pass executions. the estimated cache hit percentage increases. I’ll then rerun the same simulated load on the database.--------------. The first target size listed where this value is eliminated is 30MB. After restarting the instance and running the simulated load. I expect that I will still have some executions that will require reads and writes to disk since the read/write estimate show in Figure4 is non-zero for a 80MB PGA target. 4> estd_overalloc_count as est_overalloc 5> from v$pga_target_advice.value from v$sysstat 2> where name like 'workarea executions%'.-----------------.---------workarea executions . TARGET_SIZE_MB BYTES_PROCESSED EST_RW_EXTRA_BYTES EST_HIT_PCT EST_OVERALLOC -------------.onepass 4 workarea executions . I’m going to set PGA_AGGREGATE_TARGET to 80MB and restart the instance to clear all statistics.

---------.----------. – V$PGASTAT with 80MB PGA Target We can see in Figure 6 that we have eliminated the over allocation count statistic. TARGET_SIZE_MB BYTES_PROCESSED EST_RW_EXTRA_BYTES EST_HIT_PCT EST_OVERALLOC -------------.--------------. NAME VALUE UNIT ---------------------------------------. ORA9I SQL> select round(pga_target_for_estimate/1024/1024) as target_size_MB.-----------------. V$PGA_TARGET_ADVICE with 80MB PGA Target .84 percent Figure 6. We will look for advice for our next setting in Figure 7. The auto target statistic is very close to the target parameter.-----------aggregate PGA target parameter 83886080 bytes aggregate PGA auto target 70290432 bytes global memory bound 4194304 bytes total PGA inuse 5790720 bytes total PGA allocated 10792960 bytes maximum PGA allocated 15750144 bytes total freeable PGA memory 196608 bytes PGA memory freed back to OS 11403264 bytes total PGA used for auto workareas 0 bytes maximum PGA used for auto workareas 4319232 bytes total PGA used for manual workareas 0 bytes maximum PGA used for manual workareas 0 bytes over allocation count 0 bytes processed 47950848 bytes extra bytes read/written 39481344 bytes cache hit percentage 54. So we are getting closer. 4 estd_overalloc_count as est_overalloc 5 from v$pga_target_advice.ORA9I SQL> select * from v$pgastat.estd_extra_bytes_rw as est_rw_extra_bytes.------------10 45456384 84205568 35 2 20 45456384 78962688 37 0 40 45456384 19740672 70 0 60 45456384 19740672 70 0 80 45456384 19740672 70 0 96 45456384 19740672 70 0 112 45456384 19740672 70 0 128 45456384 13095936 78 0 144 45456384 13095936 78 0 160 45456384 13095936 78 0 240 45456384 13095936 78 0 320 45456384 0 100 0 480 45456384 0 100 0 640 45456384 0 100 0 Figure 7. But the cache hit percentage is still far away from 100% and there are a large number of extra bytes read and written. 3 estd_pga_cache_hit_percentage as est_hit_pct. 2 bytes_processed.

We can also hit our 100% cache hit ratio. Our next step would be to change the PGA_AGGREGATE_TARGET parameter and then perform the same queries at regular intervals to ensure that we are achieving optimal performance. The DBA does not have to worry about setting each of the *_AREA_SIZE parameters correctly. Conclusion The benefit of letting Oracle 9i dynamically manage your working area memory is a great tool for the DBA to employ.1 Oracle 9i Monitoring Automated SQL Execution Memory Management Metalink Note: 223730. These settings would waste memory.The query output in Figure 7 shows that we can eliminate the extra read and write bytes if we allocate 320MB to the PGA_AGGREGATE_TARGET.1 Automatic PGA Memory Management in 9i . We can further see that allocating 640MB or even 480MB of memory would not help us achieve any better performance. New statistics to V$SYSTAT and the new V$PGASTAT and V$PGA_TARGET_ADVICE views assist the DBA in determining if this parameter is not set correctly and the best setting for the PGA_AGGREGATE_TARGET parameter. References Oracle 9i Database Reference Metalink Note: 148346.

Sign up to vote on this title
UsefulNot useful