Showing posts with label SGA (System Global Area). Show all posts
Showing posts with label SGA (System Global Area). Show all posts

Saturday, July 4, 2020

Large Pool And JAVA Pool

Large Pool : 

Large Pool is an optional area in SGA. It relieves the burden of the Shared pool also.

It provides an area of memory from which large allocations can be made. Oracle's backup and restore utilities typically allocate buffers that are hundreds of kilobytes in size. These will be allocated in the large pool if the large pool memory allocation is present.

Large Pool Reduces the overhead of the shared pool, in case of shared server connection mode.

A large Pool is used for the following :
  • Session memory for the shared server and the Oracle XA Interface when distributed transactions are involved
  • I/O server processes
  • Backup and restore operations for RMAN
  • Parallel execution message buffers
              PARALLEL_AUTOMATIC_TUNING set to TRUE

Large Pool does not use an LRU list. It is sized by LARGE_POOL_SIZE and can be resized dynamically.

For shared server or parallel query buffers, Oracle uses the shared pool primarily for caching shared SQL statements. For a shared server or parallel query buffers, Oracle Uses the large pool memory when we set below Parameter value to TRUE.

PARALLEL_AUTOMATIC_TUNING=TRUE

Allocating session memory from the large pool for a shared server or parallel query buffers, Thus relieving the burden on the area within the shared pool.

By allocating session memory from the large pool for shared SQL, the database avoids performance overhead caused by increasing and shrinking the shared SQL cache in shared pool memory.

By allocating memory in large buffers for RMAN operations, I/O server processes, and parallel buffers, the large pool can satisfy large memory requests better than the shared pool.

By allocating memory form the large pool, for caching SQL parse tree in favor of shared server session information, I/O, and backup and recovery processes, The shared pool does not have to give up own memory for these processes. So the Performance gain happens from the reduction of overhead from increasing and shrinkage of the shared SQL cache in the shared pool.

The multi-threaded server will also take advantage of the large pool, allocating session memory there instead of in the shared pool, thus leaving more of the shared pool open for SQL statements and execution plans.

Below is t use Cases of Large Pool:

Backup And Restore :

Recovery Manager (RMAN) uses the large pool when the parameter set as below.
  • BACKUP_DISK_IO = n
  • BACKUP_TAPE_IO_SLAVE = TRUE
If the large pool is configured but is not large enough, the allocation of memory from the large pool fails. RMAN writes an Error message to the alert log file and does not use I/O slaves for backup and restore.

Parallel Execution :

Large Pool is used for Parallel execution when the below parameter is set to TRUE, Otherwise,  these buffers are allocated and use the shared pool memory.

PARALLEL_AUTOMATIC_TUNING=TRUE

Sizing The LARGE POOL :

A large pool area will only be available if the parameter has set in the initialization parameter. For example, to allocate a large pool of 10 megabytes, you would add the following line to your database's initialization parameter file.

LARGE_POOL_SIZE = 10M

The large pool is sized in bytes defined by the LARGE_POOL_SIZE  Parameter. This Parameter can be dynamically resized using the ALTER SYSTEM SET command.

ALTER SYSTEM SET LARGE_POOL_SIZE=50M;

Large Pool and LRU List :

The large Pool does not have an LRU list.  It is different from reserved space in the shared pool, which uses LRU List.


JAVA POOL :

The java pool is a RAM region within the Oracle SGA and the java pool RAM is used to provide:
  • Services Parsing of Java code and scripts. 
  • Installation tasks related to Java applications with Oracle versions. 
  • Java stored procedure code parsing.
  • Sized by JAVA_POOL_SIZE Parameter

The JAVA pool is an optional setting but is required if you are installing and using JAVA. Its Size is set in Bytes using the JAVA_POOL_SIZE. The Default Size of the JAVA POOL  is 24MB (Oracle 9i)



Thank You !!

Monday, June 29, 2020

Redo Log buffer

What is Redo Log ?

Redo Log plays the most important role in Recovery operations. It consists of two or more preallocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.

Redo Log Buffer :  Redo Log Buffer provide the fallowing functions.
  • Records all changes made to the database data blocks
  • Primary Purpose  is recovery
  • Changes recorded within are called redo entries
  • Redo entries contain information to reconstruct or redo changes
  • Size defined by Log_buffer Initialization Parameter

The redo log buffer is an area of memory within the SGA and it is a circular buffer that holds the changes made to the datafile blocks. This Information is called redo entries. Redo Entries contains the information necessary to re-create the data prior to the made by INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations.

Server process generates the redo data (redo entries ) into the redo log buffer as any changes occurs to the data blocks using DMLs in the Database buffers.  LGWR (log Writer) database background process writes the redo log buffers (redo entries)  to the Active online Redo Log File on the disk.

Oracle will eventually flush the redo log buffer by transferring the redo entries to Active inline redo log Files on disk. This can happen in a number of special cases.
  • Every commit transaction occurs.
  • When redo Log buffer Fills even though some redo records may not be committed.
  • Until Unless All redo entries are transferred to the active online redo log files on disk.
Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.

Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a active online redo log files on the disk , even though some redo records may not be committed. If necessary, the database can roll back these changes.

Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.


Sizing the Redo Log buffer:

The size of the redo log buffer is defines by the LOG_BUFFER initialization parameter.

The default value of this size is four times the DB_BLOCK_SIZE, but it is often desirable to set this value higher, particularly if there are many or long transactions generating high rates of redo generation.


Thank You !!