Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Oracle Internal Architecture

Oracle Internal Architecture

Ratings: (0)|Views: 98|Likes:
Published by fztechno
Uploaded from Google Docs
Uploaded from Google Docs

More info:

Published by: fztechno on Nov 01, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less





Oracle Internal Architecture
ORACLE Internal Architecture
Program Global Area - PGA
The Program Global Area, or PGA, is a variable sized buffer of non-shared memory which islimited in growth only by the physical hardware. Basically, a separate PGA is allocated bythe Oracle server when a user connects to the database and a session is created. SeparatePGA's are also allocated for each Oracle background process. The PGA is exclusive to thatserver process and is read and written only by Oracle code acting on behalf of that process.
The PGA consists of three components: a Stack Area, a Data Area and a Sort Area. TheStack Area is always present in each PGA and holds information such as a session's
variables and arrays. The Data Area, as its name suggests, is used to store data at asession level. The Sort Area is memory allocated to store data being sorted.
The initial size of the PGA is fixed depending on the operating system and the databaseinitialization parameter settings. However the size of the PGA is variable once users startconnecting. If sufficient PGA memory is not available when a user attempts to connect to anOracle database their connection will be rejected with an Oracle error message. However, if a user connection is successful, they can never run out of PGA space. The overall size of thePGA can be affected by using Multi Threaded Server, as well as by Oracle initializationparameters such as open_links, db_files and sort_area_size. As the use of Multi ThreadedServer (MTS) has the biggest impact on the sizing of the PGA, please refer to that sectionfor more detailed information regarding PGA sizing including information on the initializationparameters as well as MTS is covered in the relevant sections of this paper.
An Oracle database can be configured in either a dedicated server mode or in a MultiThreaded Server (or MTS) mode. Using Multi Threaded Server gives an Oracle database theability to support tens of thousands of concurrent users. Oracle is able to accomplish this bymoving user processes and memory components from the individual user processes into theSGA. This added overhead does require an increase in total SGA sizing but this is minimalcompared to the overall memory reductions from the would-be dedicated user processes.Also, growth of the database memory is in a linear fashion and not exponential as would bethe case in a dedicated server mode. In an MTS configuration the SGA is split into anadditional segment of memory called the User Global Area (or UGA). Instead of having adedicated process for each client request there is only one process per shared server. Also,the number of shared servers can be controlled and the number of processes is much lessthan with a dedicated server configuration. The process space previously used by eachdedicated server process is no longer required as there are now fewer processes. As aresult, there is substantial resource saving. Parameters to setup:
- mts_dispatchers
- mts_servers
- mts_max_dispatchers
- mts_max_servers
System Global Area - SGA
Also referred to as the Shared Global Area, the System Global Area, or SGA is a dynamicallyallocated segment of memory which is allocated when a database starts up. Conversely, it isde-allocated when a database instance is shut down. Unlike the PGA there is only one SGAper database instance.
The SGA consists of several memory structures each of which can independently have amajor impact on overall system performance. It is because of this that a majority of tuninginformation concentrates on the components of the SGA. Some basic rules of thumb toconsider when configuring the SGA for performance are:
It is usually best to keep the entire SGA in real memory (or non-virtual memory).
On platforms which support it, you should lock the SGA into real memory using theLOCK_SGA parameter.
The size of the SGA should typically be sized so as to occupy around 60% of the totalavailable memory.
To approximate size of the SGA (Shared Global Area), use following formula:
Components of the SGA:
a) REDO LOG BUFFER (controlled by LOG_BUFFER)
The Redo Log Buffer is an area of allocated memory within the SGA for buffering redoinformation prior to being written to the redo log files. The redo buffers are a crucialcomponent of the Oracle recoverability process and are accessed for almost every databaseprocess and transaction. Even uncommitted transactions access the Redo Log Buffer.
The Redo Log Buffer helps to absorb processing spikes caused by the memory to memorytransfer of data (SGA to Redo Buffer) verses the memory to disk transfer of data (RedoBuffer to Redo Log). As the buffer fills up, the output process (LGWR) is awakened to emptythe buffer to the redo log files. The LGWR process requires some lead time, since it ispossible that a large transaction could generate redo faster than the LGWR process canwrite to disk. To help alleviate this possible bottleneck, once the redo buffer becomes onethird full, the LGWR process will be awakened into action. Otherwise the LGWR process willawaken every 3 seconds or during a checkpoint process.
The size of this buffer is specified in bytes using the
parameter. In general, alarger redo buffer size reduces redo log file I/O, particularly if transactions are long ornumerous. In a busy system, the value 65536 or higher is not unreasonable, howevervalues above 1Mb are unlikely to yield any significant benefit. The default size of the redolog buffer is dependant on the hardware and operating system platform. The size of theredo log buffer can be viewed with the following query:
select * from v$sgastat where name = 'log_buffer';
----------- ------------------- ---------
log_buffer 31457280
When an Oracle database instance is started up, the size of 'Redo Buffers' shown can differfrom the value of the log_buffer size specified in the parameter file. This is due to memoryset aside for what is known as "guard" pages which help to protect the redo buffer.
NOTE: If you have small transactions each COMMIT causes redo to be flushed to disk beforethe COMMIT returns control to the user.
Tips for Tuning Redo
- Locate Redo Log files on a separate disk to data if at all possible
- Use larger Redo Log Files if necessary
- Increase the number of Redo Log Groups (& files)
- Use NOLOGGING where possible (Remeber: SQL statements such as UPDATE, DELETE,conventional path INSERT, and various DDL statements not listed above) are unaffected bythe NOLOGGING attribute)
- It is more effective to size Redo Logs larger and set LOG_CHECKPOINT_INTERVAL to ahigher number (ie. 9999999 - 7x9).
- Init Parameters:
- LOG_BUFFER - (Increase - Evaluate)

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->