Release Oracle memory

Question

Hi All,
After searching from internet, I found that the maximum memory allowed for 32 bit Linux on Oracle is 2GB. Actually I don't know what the components are included in the 2GB ! But when I mistakenly set the PGA_AGGREGATE_TARGET to 7GB, Oracle still allow me to set it! (I just want to set to 700MB only)
After I set it to 700MB, I found that total PGA inuse and total PGA allocated from v$pgastat are continuously growing and then died. I also checked the values generated by this SQL are growing too! It died after total PGA inuse is around 1.7GB.
SELECT ROUND(pga_target_for_estimate /(1024*1024)), estd_pga_cache_hit_percentage, estd_overalloc_count
FROM v$pga_target_advice;1. Will Oracle release memory? (after I performed lots of INSERT with GROUP BY statements)
2. How to prevent Oracle to die after several LGWR switch (Alert Log message: "ORA-04030: out of process memory when trying to allocate 8512 bytes (pga heap,kgh stack)")
Thanks!

Answer 1

linuxos wrote:
Do you mean each non-SGA process (PMON, SMON, LGWR) can have 2GB, and all Oracle memory processes may be over 2GB in total, e.g. 20GB, 40GB?No. There are two basic memory areas that are used by "+Oracle+" - which is a collection of processes.
The "+brains+" of Oracle is a shared memory segment called the SGA. Each Oracle process, will attach itself to it. Depending on the process listing you do (and how it displays memory utilisation), it may look like there is 20GB of memory being used. Make sure to differentiate between what is shared memory (single global shared memory structure) and what is not.
The second basic memory area is the process image loaded by the kernel. This has a code segment (fixed for that executable) and data segment. The latter can be dynamic - depending on whether or not the process dynamically allocates memory to itself. This memory allocated is private process memory - not shared with any other process. In Oracle terminology this is referred to as the PGA.
But, how can I make the large amount of DML to run slowly, or recycle the memory, so that the memory can be released instantly? Actually, the PGA cannot go above 1.7GB!You can't. What you can and should do is size the memory areas for Oracle correctly given the available resources of the server and the expected utilisation of Oracle.
For example, if you service a lot of data warehouse type processes (complex and slow running queries), that would mean using Oracle dedicated server - and if there are a 100 of these processes, you will have a 100 PGAs to cater for. Otoh, if you have a 500 users all running short and fast OLTP transactions, you would rather want to use shared server processes where perhaps 50 shared server processes can service 500 concurrent session - thus you would need to size for 50 PGAs.
Perhaps you cannot cater for 50 PGAs without reducing the SGA (and in turn the size of the db buffer cache and various other caches). This can affect performance.
Thus there is a balance ito of performance when deciding on how much memory you should assign to the SGA and how much can be reserved (as free kernel memory) for PGA usage.
As for running large DMLs... that should not place heavy strain on memory at all - as that will be using the db buffer cache, residing in the SGA. This is a fixed memory area sized up front. Not something that can grow by itself. Obviously a buffer cache plays a role in reducing physical I/Os - and that needs to be sized accordingly if you want to reduce PIOs and increase performance.
However, if these DMLs are a result of poorly written PL/SQL code that attempts to "better performance" by bulk processing, this code can seriously dent memory growth as this processing (by the Oracle server process running that PL/SQL code) will require to increase PGA to cater for bulk processing.
Get the bulk processing wrong and run just a couple of these bad bulk processes, and the kernel can spend over 90% of its time on swapping.
I suggest that you read Memory Architecture in the [Oracle® Database Concepts|http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/memory.htm#i12483] guide.