############################################################################################### Topic Name : UNIXORACLE## Author Name : Aalok Dixit (Oracle DBA)## Creation date: 16-11-2001 ###############################################################################################PurposeThe following table documents Unix kernel parameters that should be monitored andpossibly increasedafter changes are made to the related init.ora parameter. Please check with yourOperating Systemdocumentation for specific details on the parameter changes.Init.ora Parameter Unix Kernel Parameterdb_block_buffers shmmaxdb_files (maxdatafiles) nfile, maxfileslarge_pool_size shmmaxlog_buffer shmmaxprocesses nproc, semmsl, semmnsshared_pool_size shmmaxCommon Unix Kernel Parameter DefinitionsThe following Kernel Parameters tend to be generic across most Unix platforms.However,their names may be different on your platform. Consult your Installation andConfiguration Guide (ICG)for the exact names.maxfiles - Soft file limit per process.maxuprc - Maximum number of simultaneous user processes per userid.nfile - Maximum number of simultaneously open files systemwide at any giventime.nproc - Maximum number of processes that can exist simultaneously in thesystem.shmmax - The maximum size(in bytes) of a single shared memory segment.shmmin - The minimum size(in bytes) of a single shared memory segment.shmmni - The number of shared memory identifiers.shmseg - The maximum number of shared memory segments that can be attached by aprocess.semmns - The number of semaphores in the system.semmni - The number of semaphore set identifiers in the system; determines thenumber of semaphore sets that can be created at any one time.semmsl - The maximum number of sempahores that can be in one semaphore set. Itshould be same size as maximumnumber of Oracle processes.
References:Note:1010913.6 - Unix Configuration Parameters: Where to set Semaphores and SharedMemoryProblem Description:====================This entry covers the Unix configuration parameters, and where to setsemaphores and shared memory for various Unix platforms.Search Words: kernel, tuning, SHMMAX, SHMMIN, SHMMNI, SHMSEG, SEMMNS, SEMMNI, SEMMSL, fileUnix Version Kernel Configuration File=================================================ATT 3000 SVR4/386 /etc/conf/cf.d/stuneData General 88K (Motorola) /usr/include/sys/param.hDEC Alpha OSF/1 /usr/sys/include/sys/param.hDEC RISC Ultrix /usr/sys/conf/mips/[KNLNAME]DG Aviion /var/Build/system.aviionHP 9000/3xx /etc/conf/dfileHP 9000/8xx V9.0.x /etc/conf/gen/S800HP 9000/8xx V10.x /stand/systemIBM RS/6000 AIX automatically configuredISC Unix /etc/conf/cf.d/stuneOlivetti SVR4 v2.x /etc/conf/cf.d/stunePyramid OSX /usr/sys/kernel/[KNLNAME]SCO Unix /etc/conf/cf.d/stuneSequent Dynix /usr/sys/conf/[KNLNAME]Sequent Dynix/ptx /usr/conf/uts/symmetry/site.[KNLNAME]Silicon Graphics V4.x /usr/var/sysgen/mtune/shmSilicon Graphics V5.x /var/sysgen/mtune/shmSilicon Gorphics IRIX v5.x /usr/var/sysgen/stuneSolbourne /usr/sys/kbus/conf/[KNLNAME]Sun Solaris /etc/systemSun SunOS 4c/Sparc /usr/kvm/sys/sun4c/conf/[KNLNAME]
Unisys SVR4/386 /etc/conf/cf.d/stune.Note:1008866.6 - How to determine SGA Size (7.x, 8.0, 8i)PURPOSE The following explains how to approximate the size of the SGA (System Global Area).SCOPE & APPLICATION It is very difficult and time consuming to exactly calculate the SGA size based on values of init.ora parameters. It is difficult because of different port specific sizes of data structures that are allocated in the SGA. It is time consuming because there are so many parameters that influence the SGA size. For example, any parameter that configures a number of resources, such as PROCESSES and SESSIONS, will have an impact on the SGA size. This article will concentrate on: - Showing size of the SGA once connected to a running database. - Present a brief overview on different sub-divisions of the SGA - How to ESTIMATE the size of the SGA based on values of init.ora parameters.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~How to Approximate the Size of the SGA in in 8.0.X, 8i, and 9i:===============================================================This section discusses Oracle8, Oracle8i, and Oracle9i. Oracle7 is discussedat the end of this note.Showing size of the SGA-----------------------SGA size information are displayed upon startup of the database. It can also bedisplayed using svrmgrl or sqlplus. See examples below. 8.0.X - svrmgrl connect internal show sga 8.1.X - svrmgrl or sqlplus /nolog connect internal show sga 9.X - sqlplus SQL*Plus: Release 22.214.171.124.0 - Production on Thu Aug 23 15:40:29 2001 (c) Copyright 2001 Oracle Corporation. All rights reserved. Enter user-name: sys as sysdba Enter password:
Connected to: Oracle9i Enterprise Edition Release 126.96.36.199.0 - Production With the Partitioning option JServer Release 188.8.131.52.0 - Production SQL> show sga Total System Global Area 72123504 bytes Fixed Size 279664 bytes Variable Size 67108864 bytes Database Buffers 4194304 bytes Redo Buffers 540672 bytesDifferent sub-divisions of the SGA----------------------------------Sample from svrmgrl SHOW SGA: Total System Global Area 23460696 bytes Fixed Size 72536 bytes Variable Size 22900736 bytes Database Buffers 409600 bytes Redo Buffers 77824 bytes Total System Global Area - Total in bytes of all the sub-divisions that makes up the SGA. Fixed Size - Contains general information about the state of the database and the instance, which the background processes need to access. - No user data is stored here. - This area is usually less than 100k in size. Variable Size - This section is influenced by the following init.ora parameters shared_pool_size large_pool_size java_pool_size - See Approximating Size of the SGA section of this article for version specific information. Database Buffers - Holds copies of data blocks read from datafiles. size = db_block_buffers * block size Redo Buffers - A circular buffer in the SGA that holds information about changes made to the database. - Enforced mininum is set to 4 times the maximum database block size for the host operating system.Approximating size of the SGA-----------------------------8.0.X To approximate size of the SGA (Shared Global Area), use the following
formula: ((db_block_buffers * block size) + (shared_pool_size + large_pool_size + log_buffers) + 1MB8.1.X To approximate size of the SGA (Shared Global Area), use the following formula: ((db_block_buffers * block size) + (shared_pool_size + large_pool_size + java_pool_size + log_buffers) + 1MB9.X In Oracle9i, the SGA can be configured as in prior releases to be static, or can now be dynamically configured. The size of the dynamic SGA is determined by the values of the following database initialization parameters: DB_BLOCK_SIZE, DB_CACHE_SIZE, SHARED_POOL_SIZE, and LOG_BUFFER. Beginning with Oracle9i, the SGA infrastructure is dynamic. This means that the following primary parameters used to size the SGA can be changed while the instance is running: Buffer cache ( DB_CACHE_SIZE) -- the size in bytes of the cache of standard blocks Shared pool ( SHARED _POOL_SIZE) -- the size in bytes of the area devoted to shared SQL and PL/SQL statements Large pool (LARGE_POOL_SIZE) (default is 0 bytes) -- the size in bytes of the large pool used in shared server systems for session memory, parallel execution for message buffers, and by backup and restore processes for disk I/O buffers. The LOG_BUFFER parameter is used when buffering redo entries to a redo log. It is a static parameter and represents a very small portion of the SGA and can be changed only by stopping and restarting the database to read the changed value for this parameter from the initialization parameter file (init.ora). Note that even though you cannot change the MAX_SGA_SIZE parameter value dynamically, you do have the option of changing any of its three dependent primary parameters: DB_CACHE_SIZE, SHARED_POOL_SIZE, and LARGE_POOL_SIZE to make memory tuning adjustments on the fly. (NOTE: LARGE_POOL_SIZE cannot be dynamically changed in Oracle 9.0.1, it is anticipated to be made dynamic in the next release). To help you specify an optimal cache value, you can use the dynamic DB_CACHE_ADVICE parameter with statistics gathering enabled to predict behavior with different cache sizes through the V$DB_CACHE_ADVICE performance view. Use the ALTER SYSTEM...SET clause... statement to enable this parameter. See Oracle9i Database Performance Guide and Reference for more information
about using this parameter. Beginning with Oracle9i, there is a concept of creating tablespaces with multiple block sizes and specifying cache sizes corresponding with each block size. The SYSTEM tablespace uses a standard block size and additional tablespaces can use up to four non-standard block sizes. The standard block size is specified by the DB_BLOCK_SIZE parameter. Its cache size is specified by the DB_CACHE_SIZE parameter. Non-standard block sizes are specified by the BLOCKSIZE clause of the CREATE TABLESPACE statement. The cache size for each corresponding non-standard block size is specified using the notation: DB_nK_CACHE_SIZE parameter, where the value n is 2, 4, 8, 16, or 32 Kbytes. The standard block size, known as the default block size, is usually set to the same size in bytes as the operating system block size, or a multiple of this size. The DB_CACHE_SIZE parameter, known as the DEFAULT cache size, specifies the size of the cache of standard block size (default is 48M bytes). The system tablespace uses the standard block size and the DEFAULT cache size. Either the standard block size or any of the non-standard block sizes and their associated cache sizes can be used for any of the other tablespaces. If you intend to use multiple block sizes in your database storage design, you must specify at least the DB_CACHE_SIZE and one DB_nK_CACHE_SIZE parameter value. You must specify all sub-caches for all the other non-standard block sizes that you intend to use. This block size/cache sizing scheme lets you use up to four different non-standard block sizes for your tablespaces and lets you specify respective cache sizes for each corresponding block size. Because the DB_BLOCK_SIZE parameter value can be changed only by re-creating the database, the value for this parameter must be chosen carefully and remain unchanged for the life of the database. To approximate size of the SGA (Shared Global Area), use following formula: DB_CACHE_SIZE + DB_KEEP_CACHE_SIZE + DB_RECYCLE_CACHE_SIZE + DB_nk_CACHE_SIZE + SHARED_POOL_SIZE + LARGE_POOL_SIZE + JAVA_POOL_SIZE + LOG_BUFFERS + 1MB NOTE: ADD IN EACH DB_nk_CACHE_SIZE. THERE CAN BE UP TO 4 DB_nk_CACHE_SIZE (2, 4, 8, 16, 32k) DEFINED. ONE OF THE BLOCK SIZES IS THE DEFAULT BLOCK SIZE AND ITS CACHE SIZE IS DEFINED BY DB_CACHE_SIZE.Additional Information:------------------------ Redo Buffers in SHOW SGA does not match init.ora:log_buffer parameter setting.- Enforced mininum is set to 4 times the maximum database block size for the host operating system. For more details, see: <Note 30753.1> Init.ora Parameter "LOG_BUFFER" Reference Note- Java_pool_size not accounted for in SHOW SGA or v$sga. This is a bug that is fixed in 8.1.6.- Java_pool_size restrictions in 8.1.5. The default is 20000K. If specifying in the init.ora, must it must be greater than 1000K, or you will receive an ORA-01078 "failure in processing initialization parameters"
error on startup. - Java_pool_size restrictions in 8.1.6. The default is 20000K. This parameter can be set in the init.ora, but the enforced mininum is 32768.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Approximating SGA Size and Showing Existing SGA in Oracle7:===========================================================To approximate the size of the SGA (Shared Global Area), use the followingformula: ( (db_block_buffers * block size) + shared_pool_size + log_buffers) /.9Example (from 7.0.16 on PORT 2 HP-UX 9000): From the init<SID>.ora DB_BLOCK_BUFFERS = 200 LOG_BUFFERS = 8192 SHARED_POOL_SIZE = 3500000Default Block Size = 2048 bytesThe Block Size is an Operating System specific default. db_block_buffers * block size + shared_pool_size + log_buffers ( (200 * 2048) + 3500000 + 8192 ) / .9 409600 + 3500000 + 8192 = 3917792 bytesdividing by 0.9 = 4,353,102 bytes or 4MThe division by .9 is used to take into account the variable portion ofthe SGA -- this is only an approximation of the actual value.Our calculations come up to 4353102 but the actual value is 4504072(see below).To check the actual size of the SGA, issue these commands using eithersqldba or svrmgrl:7.0.X - 7.2.X % sqldba lmode=y SQLDBA> connect internal SQLDBA> show sga7.1.X - 7.3.X % svrmgrl SVRMGR> connect internal SVRMGR> show sgaExample of Output:
Total System Global Area 4504072 bytes <-- total size loaded into memory Fixed Size 37704 bytes Variable Size 4048576 bytes Database Buffers 409600 bytes Redo Buffers 8192 bytes (log buffers)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~References:=========== [NOTE:30753.1] PARAMETER: INIT.ORA: LOG_BUFFER [NOTE:1058897.6] WHAT DO V$SGASTAT AND V$SGA INDICATE AND DO THEY RELATE?Note:1012819.6 - Operation System Tuning issues on UnixProblem Description:====================This document discusses operating system performance issues on Unix. Subjectswhich are particularly addressed include memory management and tuning your SGAand OS kernel parameters.Solution Description:===================== Operating System Performance Issues on UnixThe shared memory feature of the Unix operating system is required by Oracle.The System Global Area (SGA) resides in shared memory; therefore, enoughshared memory must be available to each Oracle process to address the entireSGA.Refer to PRE 1008866.6 SGA SIZE AND CONFIGURATION for details on how tocalculate the size of your SGA.If you create a large SGA and a large portion of your machines physicalmemory is devoted to the shared memory, it will resulting in poorperformance. However, there are also performance benefits to having yourentire SGA located in shared memory. Therefore, when sizing your SGA, youneed to balance Oracle performance needs with the demands your machine andoperating system can meet without suffering performance degradation.For information on recommended Unix shared memory kernel parameters, seePRE 1011658.6 SHARED MEMORY REQUIREMENTS ON UNIX.As a general rule, the total size of the SGA (or SGAs if you have more thanone Oracle instance) on a machine should not exceed RAM minus the memory theoperating system is using. If you are running other programs andapplications, then you must take into account the additional memory theyrequire..Note:1011658.6 - Shared Memory requirements on UnixPURPOSE Oracle uses shared memory and semaphores to communicate between processes and the SGA (System Global Area). There are certain requirements for shared memory and the semaphores. When the Oracle instance comes up, it allocates a
certain portion of the main memory to create the SGA. If the shared memory or the semaphores are not set properly, then it gives an error related to shared memory or semaphores. The following are the recommended values for shared memory and semaphores for running a SMALL size Oracle database. These values are set at the Unix kernel level.SCOPE & APPLICATION This entry lists shared memory requirements for Unix systems.Shared Memory Requirements on Unix:===================================The shared memory feature of the UNIX operating system is required by Oracle.The System Global Area (SGA) resides in shared memory; therefore, sharedmemory must be available to each Oracle process to address the entire SGA. Definitions of Shared Memory and Semaphore ParametersSHMMAX = The maximum size(in bytes) of a single shared memory segment.SHMMIN = The minimum size(in bytes) of a single shared memory segment.SHMMNI = The number of shared memory identifiers.SHMSEG = The maximum number of shared memory segments that can be attached by a process.SEMMNS = The number of semaphores in the system.SEMMNI = The number of semaphore set identifiers in the system; determines the number of semaphore sets that can be created at any one time.SEMMSL = The maximum number of sempahores that can be in one semaphore set. It should be same size as maximum number of Oracle processes (The PROCESSES parameter in the init.ora file). Recommended Semaphore and Shared Memory ParametersOperating System Shared Memory Parameters Semaphore---------------- ------------------------ ---------Sun OS SHMSIZE = 32768 SEMMNS = 200 SHMMNI = 50 SEMMNI = 50TECH: Unix Semaphores and Shared Memory ExplainedType: BULLETINStatus: PUBLISHED Content Type: TEXT/PLAINCreation Date: 06-OCT-1994Last Revision Date: 26-APR-2001PURPOSE Shared memory and semaphores are two important resources for an Oracle instance on Unix. An instance cannot start if it is unable to allocate what it needs. This paper primarily discusses the process Oracle goes through to
allocate shared memory and semaphores at instance startup. Other important points unrelated to startup as well as some troubleshooting information will be touched upon.SCOPE & APPLICATION Understanding Oracle and Shared Memory/Semaphores.Unix Semaphores and Shared Memory Explained===========================================General======= Shared memory is exactly that - a memory region that can shared between different processes. Oracle uses shared memory for implementing the SGA, which needs to be visible to all database sessions. Shared memory is also used in the implementation of the SQL*Net V1 Fast driver as a means of communicating between the application and shadow process. On the RS/6000, each shadow process stores its PGA in a shared memory segment (however, only the shadow attaches this segment). In the latter two cases, Oracle allocates the shared memory dynamically as opposed to the allocation of the SGA, which occurs at instance startup. This allocation will not be discussed in this paper. Semaphores can be thought of as flags (hence their name, semaphores). They are either on or off. A process can turn on the flag or turn it off. If the flag is already on, processes who try to turn on the flag will sleep until the flag is off. Upon awakening, the process will reattempt to turn the flag on, possibly suceeding or possibly sleeping again. Such behaviour allows semaphores to be used in implementing a post-wait driver - a system where processes can wait for events (i.e. wait on turning on a semphore) and post events (i.e. turning of a semaphore). This mechanism is used by Oracle to maintain concurrency control over the SGA, since it is writeable by all processes attached. Also, for the same reasons, use of the Fast Driver requires additional semaphores. However, these semaphores will be allocated dynamically instead of at instance startup. This allocation will not be discussed in this paper.Instance startup================ On instance startup, the first things that the instance does is: -Read the "init<SID>.ora" -Start the background processes -Allocate the shared memory and semphores required The size of the SGA will be calculated from various "init.ora" parameters. This will be the amount of shared memory required. The SGA is broken into 4 sections - the fixed portion, which is constant in size, the variable portion, which varies in size depending on "init.ora" parameters, the redo block buffer, which has its size controlled by log_buffers, and the db
block buffer, which has its size controlled by db_block_buffers. The size of the SGA is the sum of the sizes of the 4 portions. There is unfortunately no simple formula for determining the size of the variable portion. Generally, the shared pool dominates all other parts of the variable portion, so as a rule of thumb, one can estimate the size as the value of shared_pool_size (in v6, one can ignore the size of the variable portion). The number of semphores required is much simpler to determine. Oracle will need exactly as many semaphores as the value of the processes "init.ora" parameter. Note that the recommended kernel parameter values in the ICG are enough to support the default database (4M SGA, 50 processes), but may be insufficient to run a larger instance. With the above estimations and the information which follows, a DBA should be able to build a kernel with appropriate settings to support the instance.Shared memory allocation======================== Oracle has 3 different possible models for the SGA - one-segment, contiguous multi-segment, and non-contiguous multi-segment. When attempting to allocate and attach shared memory for the SGA, it will attempt each one, in the above order, until one succeeds or raises an ORA error. On other, non-fatal, errors, Oracle simply cleans up and tries again using the next memory model. The entire SGA must fit into shared memory, so the total amount of shared memory allocated under any model will be equal to the size of the SGA. This calculated value will be referred to below as SGASIZE. The one-segment model is the simplest and first model tried. In this model, the SGA resides in only one shared memory segment. Oracle attempts to allocate and attach one shared memory segement of size equal to total size of the SGA. However, if the SGASIZE is larger than the configured SHMMAX, this will obviously fail (with EINVAL). In this case, the SGA will need to be placed in multiple shared memory segments, and Oracle proceeds to the next memory model for the SGA. If an error other than EINVAL occurs when allocating the shared memory with shmget(), Oracle will raise an ORA-7306. If the segment was received (i.e. if SHMMAX > SGASIZE), Oracle attempts to attach it at the start address defined in ksms.o. An error on the attach will raise an ORA-7307. With multiple segments there are two possibilities. The segments can be attached contiguously, so that it appears to be one large shared memory segment, or non-contiguously, with gaps between the segments. The former wastes less space that could be used for the stack or heap, but depending on alignment requirements for shared memory (defined by SHMLBA in the kernel), it may not be possible. At this point, Oracle needs to determine SHMMAX so it can determine how many segments will be required. This is done via a binary search algorithm over the range [1...SGASIZE] (since Oracle is trying this model and not the one segment model it must be that SHMMAX<SGASIZE) The value of SHMMAX calculated will then be rounded to an even page size (on some machines, possibly to an even 2 or 4 page block).
In the contiguous segment model, Oracle simply divides the SGA intoSGASIZE/SHMMAX (rounded down) segments of size SHMMAX plus another segmentof size SGASIZE modulo SHMMAX. If more than SS_SEG_MAX segments arerequired total, an ORA-7329 is raised. It then allocates and attachesone segment at a time, attaching the first segment at the start addressdefined in "ksms.o". Subsequent segments are attached at an address equalto the previous segments attach address plus the size of the previoussegment so that they are contiguous in memory.For example, if SHMMAX is 2M, SGASIZE is 5M, and the start address is0xd0000000, there would be 3 segments, 2 of 2M and 1 of 1M. They would beattached at 0xd0000000, 0xd0000800 (0xd0000000+2M), and 0xd0001000(0xd0000800+2M). If Oracle receives an error allocating a shared memorysegment, an ORA-7336 is raised.If an error is raised on attaching a shared memory segement, Oracle checksthe system error returned. If it is EINVAL, the attach address used is mostlikely badly aligned (not a mulitple of SHMLBA). In this case, Oracle triesthe next model for SGA allocation, non-contiguous segments. Otherwise, anORA-7337 is raised.The last model Oracle will try is the non-contiguous model. Here,things become a bit more complicated. After calculating SHMMAX, Oraclefirst checks to see if it can put the fixed and variable portion intoone shared memory segment just large enough to hold the two portionsIf it can, it allocates a segment just big enough to hold both portions.If it cannot, it will put them each into their own seperate segment justlarge enough to hold each portion. If the fixed portion is larger thanSHMMAX, an ORA-7330 will be raised. If the variable portion is largerthan SHMMAX, an ORA-7331 will be raised. Then Oracle computes the numberof redo block buffers it can fit in a segment (rounded down to anintegral number of buffers - buffers cannot overlap segments). An ORA-7332is raised is SHMMAX is smaller than the size of a redo block.Similarly, the number of db block buffers per segment is calculated, with anORA-7333 raised if SHMMAX is too small to hold one db block. Then Oracle cancompute the total number of segments required for both the redo and databaseblock buffers. This will be buffers/buffers per segment (rounded down) segmentsand one (if necessary) of buffers modulo buffers per segment size, calculatedseperately for both the redo and db block buffers. These segments will beof a size just large enough to hold the buffers (so no space is wasted).The total number of segments allocated will then be the number needed forthe fixed and variable portions (1 or 2) plus the number needed for theredo block buffers plus the number of segments needed for the database blockbuffers. If this requires more than SS_SEG_MAX segments, an ORA-7334 israised.Once the number of segments and their sizes is determined, Oraclethen allocates and attaches the segments one at a time; first the fixedand variable portion segment(s), then the redo block buffer segment(s),then the db block buffer segment(s). They will be attached non-contiguously,with the first segment attached at the start address in "ksms.o" and followingsegments being attached at the address equal to the attach address of theprevious segment plus the size of the previous segment, rounded up to amulitple of SHMBLA.
If Oracle receives an error allocating a shared memory segment, an ORA-7336 is raised. If an error is raised on attaching a shared memory segement, Oracle checks the system error returned. If it is EINVAL, normally another model would be tried, but as there are no more models to try, an ORA-7310 is raised. Other attach errors raise an ORA-7337. At this point, we have either attached the entire SGA or returned an ORA error. The total size of segments attached is exactly SGASIZE; no space is wasted. Once Oracle has the shared memory attached, Oracle proceeds to allocating the semaphores it requires.Semaphore allocation==================== Semaphore allocation is much simpler than shared memory. Oracle just needs to allocate a number of semaphores equal to the processes parameter in "init.ora". PROCESSES will be used to refer to this value. Note on machines with a post-wait kernel extension, Oracle does not need to allocate semaphores (because it doesnt need to implement its own post-wait mechanism). Oracle uses semaphores to control concurrency between all the background processes (pmon, smon, dbwr, lgwr, and oracle shadows). Semaphores are also used to control two-task communication between the user process and shadow process if the fast (shared memory) driver is used. And in the Unix ports based on MIPS RISC processors, Oracle uses a special semaphore to perform basic test & set functions that are not provided by the processor. Typing "ipcs -sb" will show you what semaphores are allocated to your system at the moment. This will display all the semaphore sets allocated, their identifying number, the owner, the number of semaphores in each set, and more. Occasionally, unexpected termination of Oracle processes will leave semaphore resources locked. If your database is not running, but "ipcs -sb" shows that semaphore sets owned by oracle are still in use, then you need to deallocate (free) them. If you dont do this, then you may not be able to allocate enough semaphores later to restart your database. Freeing semaphore sets is done with the "ipcrm" command. For each set that oracle has allocated, type "ipcrm -s ID" where ID is the set number you see from the "ipcs" output. Semaphores can also be freed by rebooting the system. ORA-7250, ORA-7279, ORA-27146 If the environment variable ORANSEMS is set, Oracle will use that value as the number it will allocate per set. Oracle will attempt to allocate one set of size ORANSEMS. If this fails, an ORA-7250 is raised. If ORANSEMS is not set, Oracle tries to determine the maximum number of semaphores allowed per set (SEMMSL). It does this by first trying to allocate a set of PROCESSES semaphores. If this fails with EINVAL, it tries again, this time trying to get one fewer semaphore. If this fails an ORA-7279 or ORA-27146 on 8.1.X or higher is raised. This process continues until either the semget() succeeds, or when the number of semaphores Oracle is attempting to allocate drops to zero. Increase the kernel parameter SEMMNS if an ORA-7279 or ORA-27146 is generated.
ORA-7251 If the latter case occurs, an ORA-7251 will be raised. Now Oracle begins allocating sets of size SEMMSL (or ORANSEMS, as the case may be) until it has at least PROCESSES semaphores. ORA-7252, ORA-7339 All semaphore sets will be the same size, so if PROCESSES is not a multiple of SEMMSL (or ORANSEMS), there will be additional semaphores allocated that will not be used (or in other words, PROCESSES/SEMMSL, rounded up, sets of SEMMSL semaphores will be allocated). Should an error occur trying to allocate a semaphore set, ORA-7252 will be raised. If more than SS_SEM_MAX semaphore sets would be required, an ORA-7339 occurs. At this point, Oracle has either allocated at least PROCESSES semaphores or returned an ORA error. All IPC resources required by Oracle on Unix have been allocated and the related information can be written into the sgadef file for this instance for later use by other processes which connect to the instance.Connecting to an instance========================= All shadow processes, when starting, attempt to attach the SGA. Shadows will be started whenever there is a logon attempt (the connect command includes an implicit logoff, so it produces a new shadow). The only exception is SQL*Dba in version 7 which immediately spawns a shadow process and where connect commands do not spawn a new shadow. Also, since SQL*Dba is used to start up the database, errors encountered in attempting to attach the SGA will be discarded because the SGA may not have been allocated yet. When a startup command is issued later, the SGA and semaphores will be allocated. Note that this applies only to version 7 and sqldba. What Oracle does when attempting to connect to the SGA depends on the version of Oracle. In version 6, the "sgadef<SID>.dbf" file is used to get the necessary information. In version 7, the SGA itself contains the information about the shared memory and semaphores (how the bootstrap works will be explained later). In either case, the information stored is the same - the key, id, size, and attach address of each shared memory segment and the key, id, and size of each semaphore set. Note that we need not do anything special to initialize the semaphores. We can use them with the data structure we read in on connecting. The version 6, approach is rather simple. It first tries to open the "sgadef<SID>.dbf" file. If it cannot, an ORA-7318 is raised. Once opened, the data written earlier on startup is read. If an error occurs for some reason on the read, an ORA-7319 occurs. Once all the data is read in, Oracle attaches each segment in turn. First, it generates what it believes the key for the segment should be. It then gets that segment, returning ORA-7429 if it fails. The key used and the key stored are then compared. They should be equal, but if not, an ORA-7430 occurs. Once the key is verified, the segment is attached. A failure to attach the segment raises an ORA-7320. If the segment is attached, but not at the address we requested, an ORA-7321 occurs. This process is repeated for all segments until the entire SGA is attached.
Version 7 differs only in the first part, when the shared memory and semaphore data is read. Once that data is read in, Oracle proceeds in the same manner. To fetch this data, Oracle generates what it thinks should be the key for the first segment of the SGA and attaches it as if it were the only segment. Once it is attached, the data is copied from the SGA. With this data, Oracle attaches any remaining segments for the SGA. There is one possible problem. If somehow two instances have a key collision (i.e. they both generate the same key for their first segment), it is possible to only have one of the two instances up at a time! Connection attempts to either one will connect a user to whichever instance is up. This is rare, but can happen. Development is currently working on a better key generation algorithm.Attaching shared memory======================= As seen in previous sections, shared memory must be received (this may mean allocating the shared memory, but not necessarily) and then attached, to be used. Attaching shared memory brings the shared memory into the process memory space. There are some important things about attach addresses. For one thing, they may need to be alligned on some boundary (generally defined by SHMLBA). More importantly, shared memory must mapped to pages in the process memory space which are unaccounted for. Every process already has a text, a data, and a stack segment laid out as follows (in general): +---------+ high addresses | stack | |---------| -+ | | | | | v | | |---------| | | shm seg | |- unused portion |---------| | These are valid pages for shared memory | ^ | | Pages are allocated from this area | | | | as both the stack and heap(data) grow |---------| -+ | data | |---------| | text | +---------+ low addresses So, valid attach addresses lie in the unused region between the stack and the data segments (a shared memory segment is drawn in the diagram to aid in visualization - not every process has shared memory attached!). Of course, the validity also depends on the size of the segment, since it cannot overlap another segment. Note that both the stack and data segments can grow during the life of a process. Because segments must be contiguous and overlapping is not allowed, this is of some importance. Attaching shared memory creates a limit on how much the stack or data segment can grow. Limiting the stack is typically not a problem, except when running deeply recursive code. Neither is limiting the data segment, but this does
restrict the amount memory that can be dynamically allocated by a program. It is possible (but seldom) that some applications running against the database may hit this limit in the shadow (since the shadow has the SGA attached). This is the cause of ORA-7324 and ORA-7325 errors. How to deal with these is discussed in the troubleshooting section. The SGA is attached, depending on the allocation model used, more or less contiguously (there may be gaps, but those can be treated as if they were part of the shared memory). So where the beginning of the SGA can be attached depends on the SGAs size. The default address which is chosen by Oracle is generally sufficient for most SGAs. However, it may be necessary to relocate the SGA for very large sizes. It may also need to be changed if ORA-7324 or ORA-7325 errors are occuring. The beginning attach address is defined in the file "ksms.s". Changing the attach address requires recompilation of the Oracle kernel and should not be done without first consulting Oracle personnel. Unfortunately, there is no good way to determine what a good attach address will be. When changing the address to allow a larger SGA, a good rule of thumb is taking the default attach address in "ksms.s" and subtracting the size of the SGA. The validity of an attach address can be tested with the Oracle provided tstshm executable. Using: tstshm -t <size of SGA> -b <new attach address> will determine if the address is usable or not.Troubleshooting=============== Errors which might have multiple causes are discussed in this sections. Errors not mentioned here generally have only one cause which has a typically obvious solution. ORA-7306, ORA-7336, ORA-7329 Oracle received a system error on a shmget() call. The system error should be reported. There are a few possibilities: 1) There is insufficient shared memory available. This is indicated by the operating system error ENOSPC. Most likely, SHMMNI is too small. Alternatively, there may shared memory already allocated; if it is not attached, perhaps it can be freed. Maybe shared memory isnt configured in the kernel. 2) There is insufficient memory available. Remember, shared memory needs pages of virtual memory. The system error ENOMEM indicates there is insufficient virtual memory. Swap needs to be increased, either by adding more or by freeing currently used swap (i.e. free other shared memory, kill other processes) 3) The size of the shared memory segment requested is invalid. In this case, EINVAL is returned by the system. This should be very rare - however, it is possible. This can occur if SHMMAX is not a mulitple of page size and Oracle is trying a multi-segment model. Remember that Oracle rounds its calculation of SHMMAX to a page boundary, so it may have
rounded it up past the real SHMMAX! (Whether this is a bug is debatable).4) The shared memory segment does not exist. This would be indicated by the system error ENOENT. This would never happen on startup; it only would happen on connects. The shared memory most likely has been removed unexpectedly by someone or the instance is down.ORA-7307, ORA-7337, ORA-7320Oracle received a system error on a shmat() call. The system should bereported. There a a few possibilities:1) The attach address is bad. If this is the cause, EINVAL is returned by the system. Refer to the section on the attach address to see why the attach address might be bad. This may happen after enlarging the SGA.2) The permissions on the segment do not allow the process to attach it. The operating system error will be EACCES. Generally the cause of this is either the setuid bit is not turned on for the oracle executable, or root started the database (and happens to own the shared memory). Normally, this would be seen only on connects.3) The process cannot attach any more shared memory segments. This would be accompanieed by the system error EMFILE. SHMSEG is too small. Note that as long as SHMSEG is greater than SS_SEG_MAX, you should never see this happen.ORA-7329, ORA-7334Oracle has determined the SGA needs too many shared memory segments. Since youcant change the limit on the number of segments, you should instead increaseSHMMAX so that fewer segments are required.ORA-7339Oracle has determined it needs too many semaphore sets. Since youcant change the limit on the number of semaphore sets, you shouldincrease SEMMSL so fewer sets are required.ORA-7250, ORA-7279, ORA-7252, ORA-27146Oracle received a system error on a semget() call. The system error should bereported. There should be only one system error ever returned withthis, ENOSPC. This can mean one of two things. Either the systemlimit on sempahore sets has been reached or the system limit on thetotal number of semaphores has been reached. Raise SEMMNI or SEMMNS,as is appropriate, or perhaps there are some semaphore sets which canbe released. In the case of ORA-7250, ORANSEMS may be set too high(>SEMMSL). If it is, raise SEMMSL or decrease ORANSEMS.ORA-7251Oracle failed to allocate even a semaphore set of only one semaphore. It islikely that semaphores are not configured in the kernel.ORA-7318Oracle could not open the sgadef file. The system error number will bereturned. There are a few possible causes:1) The file doesnt exist. In this case, the system error ENOENT is returned. Maybe ORACLE_SID or ORACLE_HOME is set wrong so that Oracle
is looking in the wrong place. Possibly the file does not exist (in this case, a restart is necessary to allow connections again). 2) The file cant be accessed for reading. The operating system error returned with this is EACCES. The permissions on the file (or maybe directories) dont allow an open for reading of the sgadef file. It might not be owned by the oracle owner. The setuid bit might not be turned on for the oracle executable. ORA-7319 Oracle did not find all the data it expected when reading the sgadef<SID>.dbf file. Most likely the file has been truncated. The only recovery is to restart the instance. ORA-7430 Oracle expected a key to be used for the segment which does not match the key stored in the shared memory and semaphore data structure. This probably indicates a corruption of the sgadef file (in version 6) or the data in the first segment of the SGA (in version 7). A restart of the instance is probably necessary to recover in that case. It may also be a key collision problem and Oracle is attached to the wrong instance. ORA-7321 Oracle was able to attach the segment, but not at the address it requested. In most cases, this would be caused by corrupted data in the sgadef file (in version 6) or the first segment of the SGA (in version 7). A restart of the database may be necessary to recover. ORA-7324, ORA-7325 Oracle was unable to allocate memory. Most likely, the heap (data segment) has grown into the bottom of the SGA. Relocating the SGA to a higher attach address may help, but there may be other causes. Memory leaks can cause this error. The init.ora parameter sort_area_size may be too large, decreasing it may resolve the error. The init.ora parameter context_incr may also be too large, decreasing it may resolve this ORA-7264, ORA-7265 Oracle was unable to decrement/increment a semaphore. This generally is accompanied by the system error EINVAL and a number which is the identifier of the semaphore set. This is almost always because the semaphore set was removed, but the shadow process was not aware of it (generally due to a shutdown abort or instance crash). This error is usually ignorable.System Parameters=================SHMMAX - kernel parameter controlling maximum size of one shared memory segmentSHMMHI - kernel parameter controlling maximum number of shared memory segments in the systemSHMSEG - kernel parameter controlling maximum number of shared memory segments a process can attachSEMMNS - kernel parameter controlling maximum number of semphores in the systemSEMMNI - kernel parameter controlling maximum number of semaphore sets. Semphores in Unix are allocated in sets of 1 to SEMMSL.
SEMMSL - kernel parameter controlling maximum number of semaphores in a semphore set.SHMLBA - kernel parameter controlling alignment of shared memory segments; all segments must be attached at multiples of this value. Typically, non-tunable.System errors=============ENOENT - No such file or directory, system error 2ENOMEM - Not enough core, system error 12EACCES - Permission denied, system error number 13EINVAL - Invalid argument, system error number 22EMFILE - Too many open files, system error number 24ENOSPC - No space left on device, system error number 28Oracle parameters=================SS_SEG_MAX - Oracle parameter specified at compile time (therefore, unmodifiable without an Oracle patch) which defines maximum number of segements the SGA can reside in. Normally set to 20.SS_SEM_MAX - Oracle parameter specified at compile time (therefore, unmodifiable without an Oracle patch) which defined maximum number of semaphore sets oracle will allocate. Normally set to 10..Calculating Oracles SEMAPHORE Requirements:============================================Semaphores should be allocated for a system as follows: 1. For each database instance you wish to run list out the processes parameter from the "init<SID>.ora" file. 2. For MIPS based machines only: Add 1 to each of these figures. Keep this list of figures for use as the ORAPROC parameter in step 4. 3. Sum these figures. The figure you have is the number of semaphores required by Oracle to start ALL databases. Add to this any other system requirements and ensure SEMMNS is AT LEAST this value. Ie: SEMMNS >= SUM of processes for all Databases + 1 per database (MIPS only) + other system requirements. 4. Semaphores are allocated by Unix in sets of up to SEMMSL semaphores per set. You can have a MAXIMUM of SEMMNI sets on the system at any one time. SEMMSL is an arbitrary figure which is best set to a round figure no smaller that the smallest processes figure for any database on the system. This is not a requirement
though. Note that SEMMSL is not used on all unix platforms. Eg: HPUX does not have a SEMMSL limit on the number of semaphores in any one set. To determine Oracle requirements for SEMMNI: Take each figure from step 2 & substitute it for ORAPROC below: Sets required for Instance = (ORAPROC / SEMMSL) rounded UP. Sum these figures for all instances. This gives you Oracles SEMMNI requirement. Add to this any other system requirements. System requirements are generally 10% above what Oracle requires, however you need to take into account any other programs that require semaphores. 5. On MIPS systems SEMMNU should be set at least equal to SEMMNS. 6. Oracle 8.0.x and 8.1.x try to allocate twice as many semaphores as are in the "init<SID>.ora" file on startup. For example, if processes = 200, Oracle will need 400 to startup the SGA. This needs to be part of your calculations. Example: If you have 3 databases and the "init.ora" files have 100 150 and 200 processes allocated for each database then you would add up the three numbers 100 +150+200 =450 and an extra 10 processes per database 450 +30 = 480. You would need to set SEMMNS to at least twice this number (480 *2 = 960 semmns =960).Recap:~~~~~~ SEMMNS total semaphores available on the system as a whole SEMMNI maximum number of SETs of semaphores (number of identifiers) SEMMSL Some platforms only. Limits the maximum number of semaphores available in any one set. SEMMNU Number of Undo structures..TECH: Unix Virtual Memory, Paging & Swapping explainedType: BULLETINStatus: PUBLISHED Content Type: TEXT/PLAINCreation Date: 23-DEC-1994Last Revision Date: 25-OCT-2000====================================================================Understanding and measuring memory usage on UNIX operating systems.====================================================================When planning an Oracle installation, it is often necessary to plan formemory requirements. To do this, it is necessary to understand how the
UNIX operating system allocates and manages physical and virtual memoryamong the processes on the system.------------------------------I. Virtual memory and paging------------------------------Modern UNIX operating systems all support virtual memory. Virtualmemory is a technique developed around 1961 which allows the size of aprocess to exceed the amount of physical memory available for it. (Aprocess is an instance of a running program.) Virtual memory alsoallows the sum of the sizes of all processes on the system to exceedthe amount of physical memory available on the machine. (Contrast thiswith a system running MS-DOS or Apple MacIntosh, in which the amount ofphysical memory limits both the size of a single process and the totalnumber of simultaneous processes.)A full discussion of virtual memory is beyond the scope of thisarticle. The basic idea behind virtual memory is that only part of aparticular process is in main memory (RAM), and the rest of the processis stored on disk. In a virtual memory system, the memory addressesused by programs do not refer directly to physical memory. Instead,programs use virtual addresses, which are translated by the operatingsystem and the memory management unit (MMU) into the physical memory(RAM) addresses. This scheme works because most programs only use aportion of their address space at any one time.Modern UNIX systems use a paging-based virtual memory system. In apaging-based system, the virtual address space is divided up intoequal-sized chunks called pages. The actual size of a single page isdependent on the particular hardware platform and operating systembeing used: page sizes of 4k and 8k are common. The translation ofvirtual addresses to physical addresses is done by mapping virtualpages to physical pages. When a process references a virtual address,the MMU figures out which virtual page contains that address, and thenlooks up the physical page which corresponds to that virtual page.One of two things is possible at this point: either the physical pageis loaded into RAM, or it is on disk. If the physical page is in RAM,the process uses it. If the physical page is on disk, the MMUgenerates a page fault. At this point the operating system locates thepage on disk, finds a free physical page in RAM, copies the page fromdisk into RAM, tells the MMU about the new mapping, and restarts theinstruction that generated the page fault.Note that the virtual-to-physical page translation is invisible to theprocess. The process "sees" the entire virtual address space as itsown: whenever it refers to an address, it finds memory at thataddress. All translation of virtual to physical addresses and allhandling of page faults is performed on behalf of the process by theMMU and the operating system. This does not mean that taking a pagefault has no effect. Since handling a page fault requires reading thepage in from disk, a process that takes a lot of page faults will runmuch slower than one that does not.In a virtual memory system, only a portion of a processs virtualaddress space is mapped into RAM at any particular time. In apaging-based system, this notion is formalized as the working set of a
process. The working set of a process is simply the set of pages thatthe process is using at a particular point in time. The working set ofa process will change over time. This means that some page faultingwill occur, and is normal. Also, since the working set changes overtime, the size of the working set changes over time as well. Theoperating systems paging subsystem tries to keep all the pages in theprocesss working set in RAM, thus minimizing the number of page faultsand keeping performance high. By the same token, the operating systemtries to keep the pages not in the working set on disk, so as to leavethe maximum amount of RAM available for other processes.Recall from above that when a process generates a page fault, theoperating system must read the absent page into RAM from disk. Thismeans that the operating system must choose which page of RAM touse for this purpose. In the general case, there may not be a freepage of physical RAM, and the operating system will have to read thedata for the new page into a physical page that is already in use. Thechoice of which in-use page to replace with the new data is called thepage replacement policy.Entire books have been written on various page replacement policies andalgorithms, so a full discussion of them is beyond the scope of thisarticle. It is important to note, however, that there are two generalclasses of page replacement policy: local and global. In a local pagereplacement policy, a process is assigned a certain number of physicalpages, and when a page fault occurs the operating system finds a freepage within the set of pages assigned to that process. In a globalpage replacement policy, when a page fault occurs the operating systemlooks at all processes in the system to find a free page for theprocess.There are a number of key points to understand about paging.(1) Typically, only a relatively small number of pages (typically 10% -50%) of a single process are in its working set (and therefore inphysical memory) at any one time.(2) The location of physical pages in RAM bears no relation whatever tothe location of pages in any processs virtual address space.(3) Most implementations of paging allow for a single physical page tobe shared among multiple processes. In other words, if the operatingsystem can determine that the contents of two (or more) virtual pagesare identical, only a single physical page of RAM is needed for thosevirtual pages.(4) Since working set sizes change over time, the amount of physicalmemory that a process needs changes over time as well. An idle processrequires no RAM; if the same process starts manipulating a large datastructure (possibly in response to some user input) its RAM requirementwill soar.(5) There exists a formal proof that it is impossible to determineworking set sizes from a static analysis of a program. You must run aprogram to determine its working set. If the working set of theprogram varies according to its input (which is almost always the case)the working sets of two processes will be different if the processeshave different inputs.
---------------------------II. Virtual memory on Unix---------------------------The discussion above of virtual memory and paging is a very generalone, and all of the statements in it apply to any system thatimplements virtual memory and paging. A full discussion of paging andvirtual memory implementation on UNIX is beyond the scope of thisarticle. In addition, different UNIX vendors have implementeddifferent paging subsystems, so you need to contact your UNIX vendorfor precise information about the paging algorithms on your UNIXmachine. However, there are certain key features of the UNIX pagingsystem which are consistent among UNIX ports.Processes run in a virtual address space, and the UNIX kerneltransparently manages the paging of physical memory for all processeson the system. Because UNIX uses virtual memory and paging, typicallyonly a portion of the process is in RAM, while the remainder of theprocess is on disk.1) The System Memory MapThe physical memory on a UNIX system is divided among three uses. Someportion of the memory is dedicated for use by the operating systemkernel. Of the remaining memory, some is dedicated for use by the I/Osubsystem (this is called the buffer cache) and the remainder goes intothe page pool.Some versions of UNIX statically assign the sizes of system memory, thebuffer cache, and the page pool, at system boot time; while otherversions will dynamically move RAM between these three at run time,depending on system load. (Consult your UNIX system vendor for detailson your particular version of UNIX.)The physical memory used by processes comes out of the page pool. Inaddition, the UNIX kernel allocates a certain amount of system memoryfor each process for data structures that allow it to keep track ofthat process. This memory is typically not more than a few pages. Ifyour system memory size is fixed at boot time you can completely ignorethis usage, as it does not come out of the page pool. If your systemmemory size is adjusted dynamically at run-time, you can also typicallyignore this usage, as it is dwarfed by the page pool requirements ofOracle software.2) Global Paging StrategyUNIX systems implement a global paging strategy. This means that theoperating system will look at all processes on the system when issearching for a page of physical memory on behalf of a process. Thisstrategy has a number of advantages, and one key disadvantage.The advantages of a global paging strategy are: (1) An idle processcan be completely paged out so it does not hold memory pages that canbe better used by another process. (2) A global strategy allows for abetter utilization of system memory; each processs page allocationswill be closer to their actual working set size. (3) The administrativeoverhead of managing process or user page quotas is completely
absent. (4) The implementation is smaller and faster.The disadvantage of a global strategy is that is is possible for asingle ill-behaved process to affect the performance of all processeson the system, simply by allocating and using a large number of pages.3) Text and Data PagesA UNIX process can be conceptually divided into two portions; text anddata. The text portion contains the machine instructions that theprocess executes; the data portion contains everything else. These twoportions occupy different areas of the processs virtual addressspace. Both text and data pages are managed by the paging subsystem.This means that at any point in time, only some of the text pages andonly some of the data pages of any given process are in RAM.UNIX treats text pages and data pages differently. Since text pagesare typically not modified by a process while it executes, text pagesare marked read-only. This means that the operating system willgenerate an error if a process attempts to write to a text page. (SomeUNIX systems provide the ability to compile a program which does nothave read-only text: consult the man pages on ld and a.out fordetails.)The fact that text pages are read-only allows the UNIX kernel toperform two important optimizations: text pages are shared between allprocesses running the same program, and text pages are paged from thefilesystem instead of from the paging area. Sharing text pages betweenprocesses reduces the amount of RAM required to run multiple instancesof the same program. For example, if five processes are running OracleForms, only one set of text pages is required for all five processes.The same is true if there are fifty or five hundred processes runningOracle Forms. Paging from the filesystem means that no paging spaceneeds to be allocated for any text pages. When a text page is pagedout it is simply over-written in RAM; if it is paged in at a latertime the original text page is available in the program image in thefile system.On the other hand, data pages must be read/write, and therefore cannot(in general) be shared between processes. This means that each processmust have its own copy of every data page. Also, since a process canmodify its data pages, when a data page is paged out it must be writtento disk before it is over-written in RAM. Data pages are written tospecially reserved sections of the disk. For historical reasons, thispaging space is called "swap space" on UNIX. Dont let this nameconfuse you: the swap space is used for paging.4) Swap Space UsageThe UNIX kernel is in charge of managing which data pages are in RAMand which are in the swap space. The swap space is divided into swappages, which are the same size as the RAM pages. For example, if aparticular system has a page size of 4K, and 40M devoted to swap space,this swap space will be divided up into 10240 swap pages.A page of swap can be in one of three states: it can be free, allocated,or used. A "free" page of swap is available to be allocated as a diskpage. An "allocated" page of swap has been allocated to be the disk
page for a particular virtual page in a particular process, but no datahas been written to the disk page yet -- that is, the correspondingmemory page has not yet been paged out. A "used" page of swap is onewhere the swap page contains the data which has been paged out from RAM.A swap page is not freed until the process which "owns" it frees thecorresponding virtual page.On most UNIX systems, swap pages are allocated when virtual memory isallocated. If a process requests an additional 1M of (virtual) memory,the UNIX kernel finds 1M of pages in the swap space, and marks thosepages as allocated to a particular process. If at some future time aparticular page of RAM must be paged out, swap space is alreadyallocated for it. In other words, every virtual data page is "backedwith" a page of swap space.An important consequence of this strategy is if all the swap space isallocated, no more virtual memory can be allocated. In other words,the amount of swap space on a system limits the maximum amount ofvirtual memory on the system. If there is no swap space available, anda process makes a request for more virtual memory, then the requestwill fail. The request will also fail if there is some swap spaceavailable, but the amount available is less than the amount requested.There are four system calls which allocate virtual memory: these arefork(), exec(), sbrk(), and shmget(). When one of these system callsfails, the system error code is set to EAGAIN. The text messageassociated with EAGAIN is often "No more processes". (This is becauseEAGAIN is also used to indicate that the per-user or system-wideprocess limit has been reached.) If you ever run into a situationwhere processes are failing because of EAGAIN errors, be sure to checkthe amount of available swap as well as the number of processes.If a system has run out of swap space, there are only two ways to fixthe problem: you can either terminate some processes (preferably onesthat are using a lot of virtual memory) or you can add swap space toyour system. The method for adding swap space to a system variesbetween UNIX variants: consult your operating system documentation orvendor for details.5) Shared MemoryUNIX systems implement, and the Oracle server uses, shared memory. Inthe UNIX shared memory implementation, processes can create and attachshared memory segments. Shared memory segments are attached to aprocess at a particular virtual address. Once a shared memory segmentis attached to a processes, memory at that address can be read from andwritten to, just like any other memory in the processes address space.Unlike "normal" virtual memory, changes written to an address in theshared memory segment are visible to every process that has attached tothat segment.Shared memory is made up of data pages, just like "conventional"memory. Other that the fact that multiple processes are using the samedata pages, the paging subsystem does not treat shared memory pages anydifferently than conventional memory. Swap space is reserved fora shared memory segment at the time it is allocated, and the pages ofmemory in RAM are subject to being paged out if they are not in use,just like regular data pages. The only difference between the
treatment of regular data pages and shared data pages is that sharedpages are allocated only once, no matter how many processes are usingthe shared memory segment.6) Memory Usage of a ProcessWhen discussing the memory usage of a process, there are really twotypes of memory usage to consider: the virtual memory usage and thephysical memory usage.The virtual memory usage of a process is the sum of the virtual textpages allocated to the process, plus the sum of the virtual data pagesallocated to the process. Each non-shared virtual data page has acorresponding page allocated for it in the swap space. There is nosystem-wide limit on the number of virtual text pages, and the numberof virtual data pages on the system is limited by the size of the swapspace. Shared memory segments are allocated on a system-wide basisrather than on a per-process basis, but are allocated swap pages andare paged from the swap device in exactly the same way as non-shareddata.The physical memory usage of a process is the sum of the physical textpages of that process, plus the sum of the physical data pages of thatprocess. Physical text pages are shared among all processes runningthe same executable image, and physical data pages used for sharedmemory are shared among among all processes attached to the same sharedmemory segment. Because UNIX implements virtual memory, the physicalmemory usage of a process will be lower than the virtual memory usage.The actual amount of physical memory used by a process depends on thebehavior of the operating system paging subsystem. Unlike the virtualmemory usage of a process, which will be the same every time aparticular program runs with a particular input, the physical memoryusage of a process depends on a number of other factors.First: since the working set of a process changes over time, the amountof physical memory needed by the process will change over time.Second: if the process is waiting for user input, the amount ofphysical memory it needs will drop dramatically. (This is a specialcase of the working set size changing.) Third: the amount of physicalmemory actually allocated to a process depends on the overall systemload. If a process is being run on a heavily loaded system, then theglobal page allocation policy will tend to make the number of physicalmemory pages allocated to that process to be very close to the size ofthe working set. If the same program is run with the same input on alightly loaded system, the number of physical memory pages allocated tothat process will tend to be much larger than the size of the workingset: the operating system has no need to reclaim physical pages fromthat process, and will not do so.The net effect of this is that any measure of physical memory usagewill be inaccurate unless you are simulating both the input and thesystem load of the final system you will be testing. For example, thephysical memory usage of a Oracle Forms process will be very differentif a user is rapidly moving between 3 large windows, infrequentlymoving between the same three windows, rapidly typing into a singlewindow, slowly typing into the same window, or if they are reading dataoff of the screen and the process is sitting idle -- even though the
virtual memory usage of the process will remain the same. By the sametoken, the physical memory usage of an Oracle Forms process will bedifferent if it is the only active process on a system, or if it is oneof fifty active Oracle Forms processes on the same system.7) Key PointsThere are a number of key points to understand about the UNIX virtualmemory implementation.(1) Every data page in every process is "backed" by a page in the swapspace. This size of the swap space limits the amount of virtual dataspace on the system; processes are not able to allocate memory ifthere is not enough swap space available to back it up, regardless ofhow much physical memory is available on the system.(2) UNIX implements a global paging strategy. This means that theamount of physical memory allocated to a process varies greatly overtime, depending on the size of the processs working set and theoverall system load. Idle processes may be paged out completely on abusy system. On a lightly loaded system processes may be allocatedmuch more physical memory than they require for their working sets.(3) The amount of virtual memory available on a system is determinedby the amount of swap spaces configured for that system. The amount ofswap space needed is equal to the sum of the virtual data allocated byall processes on the system at the time of maximum load.(4) Physical memory is allocated for processes out of the page pool,which is the memory not allocated to the operating system kernel andthe buffer cache. The amount of physical memory needed for the pagepool is equal to the sum of the physical pages in the working sets ofall processes on the system at the time of maximum load.----------------------------------III. Process Memory Layout on UNIX----------------------------------1) The Segments of a ProcessThe discussion above speaks of a UNIX process as being divided up intotwo regions: text and data. This division is accurate for discussionsof the paging subsystem, since the paging subsystem treats everynon-text page as a data page. In fact, a UNIX process is divided intosix segments: text, stack, heap, BSS, initialized data, and sharedmemory. Each of these segments contains a different type of informationand is used for a different purpose.The text segment is used to store the machine instructions that theprocess executes. The pages that make up the text segment are markedread-only and are shared between processes that are running the sameexecutable image. Pages from the text segment are paged from theexecutable image in the filesystem. The size of the text segment isfixed at the time that the program is invoked: it does not grow orshrink during program execution.The stack segment is used to store the run-time execution stack. Therun-time program stack contains function and procedure activation
records, function and procedure parameters, and the data for localvariables. The pages that make up the stack segment are markedread/write and are private to the process. Pages from the stacksegment are paged into the swap device. The initial size of the stacksegment is typically one page; if the process references an addressbeyond the end of the stack the operating system will transparentlyallocate another page to the stack segment.The BSS segment is used to store statically allocated uninitializeddata. The pages that make up the BSS segment are marked read/write,are private to the process, and are initialized to all-bits-zero atthe time the program is invoked. Pages from the BSS segment are pagedinto the swap device. The size of the BSS segment is fixed at thetime the program is invoked: it does not grow or shrink during programexecution.The initialized data segment is used to store statically allocatedinitialized data. The pages that make up the initialized data segmentare marked read/write, and are private to the process. Pages from theinitialized data segment are initially read in from the initializeddata in the filesystem; if they have been modified they are paged intothe swap device from then on. The size of the initialized datasegment is fixed at the time the program is invoked: it does not growor shrink during program execution.The dynamically allocated data segment (or "heap") contains data pageswhich have been allocated by the process as it runs, using the brk() orsbrk() system call. The pages that make up the heap are markedread/write, are private to the process, and are initialized toall-bits-zero at the time the page is allocated to the process. Pagesfrom the heap are paged into the swap device. At program startup theheap has zero size: it can grow arbitrarily large during programexecution.Most processes do not have a shared data segment. In those that do,the shared data segment contains data pages which have been attached tothis process using the shmat() system call. Shared memory segments arecreated using the shmget() system call. The pages that make up theshared data segment are marked read/write, are shared between allprocesses attached to the shared memory segment, and are initialized toall-bits-zero at the time the segment is allocated using shmget().Pages from the shared data segment are paged into the swap device.Shared memory segments are dynamically allocated by processes on thesystem: the size of a shared memory segment is fixed at the time it isallocated, but processes can allocate arbitrarily large shared memorysegments.2) Per-Process Memory MapThe six segments that comprise a process can be laid out in memory inany arbitrary way. The exact details of the memory layout depend onthe architecture of the CPU and the design of the particular UNIXimplementation. Typically, a UNIX process uses the entire virtualaddress space of the processor. Within this address space, certainaddresses are legal, and are used for particular segments. Addressesoutside of any segment are illegal, and any attempt to read or write tothem will generate a Segmentation Violation signal.
The diagram below shows a typical UNIX per-process virtual memory mapfor a 32-bit processor. Note that this memory map covers the entirevirtual address space of the machine. In this diagram, regions markedwith a t are the text segment, s indicates the stack segment, Sthe shared memory segment, h the heap, d the initialized data, andb the BSS. Blank spaces indicate illegal addresses.+--------+-----+--------+----+---------------------+-------+----+----+|tttttttt|sssss| |SSSS| |hhhhhhh|dddd|bbbb||tttttttt|sssss| ->> |SSSS| <<- |hhhhhhh|dddd|bbbb||tttttttt|sssss| |SSSS| |hhhhhhh|dddd|bbbb|+--------+-----+--------+----+---------------------+-------+----+----+0 2GIn this particular implementation, the text segment occupies the lowestvirtual addresses, and the BSS occupies the highest. Note that memoryis layed out in such a way as to allow the stack segment and the heapto grow. The stack grows "up", toward higher virtual addresses, whilethe heap grows "down", toward lower virtual addresses. Also note thatthe placement of the shared memory segment is critical: if it isattached at too low of an address it will prevent the stack fromgrowing, and if it is attached at too high of an address it willprevent the heap from growing.3) Process size limitsAll UNIX systems provide some method for limiting the virtual size of aprocess. Note that these limits are only on virtual memory usage:there is no way to limit the amount of physical memory used by aprocess or group of processes.On systems that are based on SVR3, there is a system-wide limit on thevirtual size of the data segment. Changing this limit typicallyrequires you to change a UNIX kernel configuration parameter and relinkthe kernel: check your operating system documentation for details.On systems that are based on BSD or SVR4, there is a default limit onthe size of the stack segment and the data segment. It is possible tochange these limits on a per-process basis; consult the man pages ongetrlimit() and setrlimit() for details. If you are using the C-shellas your login shell the limit command provides a command-lineinterface to these system calls. Changing the system-wide defaulttypically requires that you change a UNIX kernel configurationparameter and relink the kernel: check your operating systemdocumentation for details.Most systems also provide a way to control the maximum size and numberof shared memory segments: this typically involves changing the UNIXkernel parameters SHMMAX, SHMSEG and SHMMNI. Again, consult youroperating system documentation for details.4) The High-Water-Mark EffectRecall from above that the size of the data segment can only be changedby using the brk() and sbrk() system calls. These system calls allowyou to either increase or decrease the size of the data segment.However, most programs, including Oracle programs, do not use brk() orsbrk() directly. Instead, they use a pair of library functions
provided by the operating system vendor, called malloc() and free().These two functions are used together to manage dynamic memoryallocation. The two functions maintain a pool of free memory (calledthe arena) for use by the process. They do this by maintaining a datastructure that describe which portions of the heap are in use and whichare available. When the process calls malloc(), a chunk of memory ofthe requested size is obtained from the arena and returned to thecalling function. When the process calls free(), thepreviously-allocated chunk is returned to the arena making it availablefor use by a later call to malloc().If a process calls malloc() with a request that is larger than thelargest free chunk currently in the arena, malloc() will call sbrk() toenlarge the size of the arena by enlarging the heap. However, mostvendors implementations of free() will not shrink the size of the arenaby returning memory to the operating system via sbrk(). Instead, theysimply place the free()d memory in the arena for later use.The result of this implementation is that processes which use themalloc() library exhibit a high-water-mark effect: the virtual sizesof the processes grow, but do not shrink. Once a process has allocatedvirtual memory from the operating system using malloc(), that memorywill remain part of the process until it terminates. Fortunately, thiseffect only applies to virtual memory; memory returned to the arena isquickly paged out and is not paged in until it is re-allocated viamalloc().-------------------------IV. Monitoring Memory Use-------------------------In the final analysis, there are only two things to be concerned withwhen sizing memory for a UNIX system: do you have enough RAM, and doyou have enough swap space? In order to answer these questions, it isnecessary to know how much virtual memory and how much physical memoryeach process on the system is using. Unfortunately, the standard UNIXprocess monitoring tools do not provide a way to reliably determinethese figures. The standard tools for examining memory usage on a UNIXsystem are size, ipcs, ps, vmstat and pstat. MostSYSV-derived systems will also have the crash utility: mostBSD-derived systems will allow you to run dbx against the UNIXkernel.The size utility works by performing a static analysis of the programimage. It prints out the virtual memory size of the text, BSS andinitialized data segments. It does not attempt to determine the sizeof the stack and the heap, since both of these sizes can vary greatlydepending on the input to the program. Since the combined size of thestack and the heap is typically several hundred times larger than thanthe combined size of the BSS and the initialized data, this method isthe single most unreliable method of determining the runtime virtualmemory requirement of a program. It is also the method used in the ICGto determine memory requirements for Oracle programs. The one usefulpiece of information you can obtain from size is the virtual size ofthe text segment. Since the text segment is paged from the filesystem,knowing the virtual size of the text segment will not help you sizeeither swap space or RAM.
The ipcs utility will print out the virtual memory size of all theshared memory segments on the system. Use the -mb flags to have itprint the size of the segments under the SEGSZ column.The ps utility will print out information about any process currentlyactive on the system. On SYSV-based systems, using ps with the -lwill cause ps to print out the SZ field, which contains the virtualsize of the processs non-text segments, measured in pages. OnBSD-based systems, using ps with the -u flag will also cause the SZfield to be printed. While this figure is an accurate measure of thevirtual memory being used by this process, it is not accurate if theprocess has attached a shared memory segment. This means that whensizing memory, you must subtract the size of the SGA (obtained viaipcs, above) from the virtual memory used by all of the Oraclebackground and shadow processes.On SVR4-based and BSD-based systems, using the BSD-style ps commandwith the -u flag will also cause the RSS field to be printed. Thisfield contains the physical memory usage for the process.Unfortunately, this value is the combined physical memory usage for allthe segments of the process, and does not distinguish between pagesprivate to the process and pages shared between processes. Since textand shared data pages are shared between processes, this means thatadding up the RSS sizes of all processes on the system willover-estimate the amount of physical memory being used by the system.This also means that if you add up the RSS fields for all the processeson the system you may very well come up with a number larger than theamount of RAM on your system! While the RSS field is a good indicatorof how much RAM is required when there is only one process running aprogram image, it does not tell you how much additional RAM is requiredwhen a second process runs that same image.The pstat utility is also used to print per-process information. Ifit has a SZ or RSS field, the same limitations that apply to psoutput also apply to pstat output. On some versions of UNIX, pstatinvoked with a flag (typically -s or -T) will give you informationabout swap space usage. Be careful! Some UNIX versions will onlyprint out information about how much swap space that is used, and notabout how much has been allocated. On those machines you can run outof swap, and pstat will still tell you that you have plenty of swapavailable.The vmstat utility is used to print out system-wide information onthe performance of the paging subsystem. Its major limitation is thatit does not print out per-process information. The format of vmstatoutput varies between UNIX ports: the key fields to look at are theones that measure the number of page-in and page-out events persecond. Remember that some paging activity is normal, so you will haveto decide for yourself what number of pages-in or pages-out per secondmeans that your page pool is too small.On SYSV-based systems, the sar utility is used to print outsystem-wide information on the performance of a wide variety of kernelsubsystems. Like vmstat, its major limitation is that it does notprint out per-process information. The -r, -g, and -p optionsare the most useful for examining the behavior of the paging subsystem.
On SYSV-based systems, the crash utility lets you directly examinethe contents of the operating system kernel data structures. OnBSD-based systems, it is usually possible to use a kernel debugger toexamine these same data structures. These data structures are alwayshardware- and operating system-specific, so you will not only need ageneral knowledge of UNIX internals, but you will also need knowledge ofthe internals of that particular system. However, if you have thisinformation (and a lot of patience) it is possible to get crash togive you precise information about virtual and physical memory usage ona per-process basis.Finally, there are a variety of public domain and vendor-specific toolsfor monitoring memory usage. Remember: you are looking for a utilitythat lets you measure the physical memory usage of a process, and whichgives you separate values for the number of pages used by the textsegment, the shared memory segment, and the remainder of the process.Consult your operating system vendor for details.----------------------------V. Sizing Swap Space and RAM----------------------------The bottom line is, that while it is possible to estimate virtual andphysical memory usage on a UNIX machine, doing so is more of an artthan a science.First: you must measure your actual application. An Oracle Formsapplication running in bitmapped mode, using 256 colors, 16 full-screenwindows, and retrieving thousands of records with a single query maywell use two orders of magnitude more stack and heap than an OracleForms application running in character mode, using one window and onlyretrieving a few dozen rows in any single query. Similarly, aserver-only system with five hundred users logged into the database butonly fifty of them performing queries at any one time will have a farlower RAM requirement than a server-only system which has only twohundred users logged into the database all of which are continuallyperforming queries and updates.Second: when measuring physical memory usage, make sure that yoursystem is as heavily loaded as it will be in a production situation.It does no good to measure physical memory usage with 255 processesrunning Oracle Forms if all 255 processes are sitting idle waiting forinput -- all of the processes are paged out waiting for input.Sizing swap space is relatively easy. Recall that every page ofvirtual data must be backed with a page of swap. This means that ifyou can estimate the maximum virtual memory usage on your machine, youhave determined how much swap space you need. Use the SZ column fromthe ps command to determine the virtual memory usage for theprocesses running on the system. The high-water mark can be your allyin this measurement: take one process, run it as hard as you can, andsee how high you can drive the value of the SZ column.Add together the virtual memory used by the system processes to forma baseline, then calculate the maximum amount of virtual memory usedby each incremental process (dont forget to count all processes thatget created when a user logs on, such as the shell and any dedicatedshadow processes). The swap space requirement is simply the sum of theSZ columns of all processes at the time of maximum load. The careful
system administrator will add 10% to the swap space size for overheadand emergencies.Sizing RAM is somewhat more difficult. First, start by determining theamount of RAM dedicated for system space (this is usually printed in amessage during startup). Note that tuning the operating system kernelmay increase the amount of RAM needed for system space.Next, determine the amount of RAM needed for the buffer cache.Finally, determine the amount of RAM needed for the page pool. Youwill want to have enough RAM on the system so that the working set ofevery active process can remain paged in at all times.--------------VI. References--------------`Operating Systems Design and Implementation Andrew S. Tannenbaum, Prentice-Hall, ISBN 0-13-637406-9`The Design and Implementation of the 4.3BSD Unix Operating System, Samuel Leffler, Kirk McKusick, Michael Karels, John Quarterman, 1989, Addison-Wesley, ISBN 0-201-06196-1`The Design of the Unix Operating System, Maurice Bach, 1986, Prentice Hall, ISBN 0-13-201757-1`The Magic Garden Explained: The Internals of Unix System V Release 4, Berny Goodheart, James Cox, 1994, Prentice Hall, ISBN 0-13-098138-9..DETERMINING WHICH INSTANCE OWNS WHICH SHARED MEMORY & SEMAPHORE SEGMENTSType: BULLETINStatus: PUBLISHED Content Type: TEXT/PLAINCreation Date: 03-FEB-1999Last Revision Date: 10-MAY-2001Purpose=======This article describes how to identify which shared memory and semaphoresegments are owned by a particular instance, in Oracle v7.x, v8.0 and v8.1.Scope & Application===================This is helpful when in recovery situations where the instance may not havereleased the shared memory or semaphores on database shutdown.How To Determine Which Instance Owns Which Shared memory and Semaphore Segments=============================================================================== For 7.0.X - 8.0.X ===================
You have several instances running and one instance crashes and leaves"sgadef<sid>.dbf" file, shared memory and semaphore segments running. As thereare many instances running, you are unsure which segments to kill and when todo an ipcs. You may see several shared memory and semaphore segments.This is an example of what you may see:% ipcs -b (this command will return something similar to the following output)IPC status from /dev/kmem as of Wed Apr 8 16:12:18 1998T ID KEY MODE OWNER GROUP QBYTESMessage Queues:m 2 0x4e0c0002 --rw-rw-rw- root root 31008m 3 0x41200207 --rw-rw-rw- root root 8192m 45060 0x5fa4f34e --rw-r----- osupport dba 4526080m 8709 0x5fa5b36c --rw-r----- osupport dba 4640768m 12806 0x00000000 D-rw-r----- osupport dba 4640768m 4615 0x6aac51e2 --rw-r----- osupport dba 5140480m 6664 0x5aac503f --rw-r----- osupport dba 4392968m 6665 0x5fa37342 --rw-r----- osupport dba 6422528m 17418 0x5fa2b2b1 --rw-r----- osupport dba 4640768m 523 0x5fa23296 --rw-r----- osupport dba 4591616m 1036 0x52aea224 --rw-r----- usupport dba 4521984Semaphores:s 0 0x2f180002 --ra-ra-ra- root sys 6s 1 0x411c02f9 --ra-ra-ra- root root 1s 2 0x4e0c0002 --ra-ra-ra- root root 2s 3 0x41200207 --ra-ra-ra- root root 2s 4 0x00446f6e --ra-r--r-- root root 1s 5 0x00446f6d --ra-r--r-- root root 1s 6 0x01090522 --ra-r--r-- root root 1s 11271 0x00000000 --ra-r----- osupport dba 50s 4360 0x00000000 --ra-r----- osupport dba 50s 2828 0x00000000 --ra-r----- osupport dba 50You can determine which shared memory and semaphore segments NOT to kill.*NOTE: It is very hard to guess, and very dangerous to those instances still running.First, set your "ORACLE_SID" and "ORACLE_HOME", then log into each individualinstance you have up and running.The following is an example of how to proceed:SVRMGR> connect internalConnected.SVRMGR> oradebug ipc-------------- Shared memory --------------Seg Id Address Size6665 c4c94000 6422528Total: # of segments = 1, size = 6422528-------------- Semaphores ----------------
Total number of semaphores = 50Number of semaphores per set = 50Number of semaphore sets = 1Semaphore identifiers: 2828The following output shows the shared memory segment and semaphore segment:Seg Id Address Size6665 c4c94000 6422528Semaphore identifiers: 2828Then look to verify this is running with the following command% ipcs -bm 6665 0x5fa37342 --rw-r----- osupport dba 6422528s 2828 0x00000000 --ra-r----- osupport dba 50You now know these are valid segments on a running database. Using thisprocess of elimination you can identify the idle segments from a crashedinstance. You can then kill them using "ipcrm -m" and "ipcrm -s" respectfully.The command syntax to remove the shared memory segments or semaphores is asfollows:% ipcrm -m <shared memory id>% ipcrm -s <semaphore id> For 8.1.X: ==========To obtain the shared memory id and semaphore id for 8.1.X you can doeither of the following: $ORACLE_HOME/bin/sysresv IPC Resources for ORACLE_SID "V817" : Shared Memory: ID KEY 14851 0x8a85a74c Semaphores: ID KEY 11206656 0x4bd4814c Oracle Instance alive for sid "V817" OR%sqlplus internalSQL> oradebug ipcInformation written to trace file.
Trace file is written to USER_DUMP_DEST.The shared memory segment id can be found by looking in the trace file forShmid:The shared memory segment id in the following is 2007. Area Subarea Shmid Stable Addr Actual Addr 0 0 2007 0000000080000000 0000000080000000To find the semaphore id look for Semaphore List=In the following example the semaphore id is 1245189.Semaphore List=1245189Example of trace file:/u02/app/oracle/product/8.1.6/admin/R816/udump/r816_ora_975.trcOracle8i Enterprise Edition Release 184.108.40.206.0 - ProductionWith the Partitioning optionJServer Release 220.127.116.11.0 - ProductionORACLE_HOME = /u02/app/oracle/product/8.1.6System name: SunOSNode name: sandbox1Release: 5.6Version: Generic_105181-16Machine: sun4uInstance name: R816Redo thread mounted by this instance: 1Oracle process number: 12Unix process pid: 975, image: oracle@sandbox1 (TNS V1-V3)*** SESSION ID:(14.4287) 2000-08-31 10:47:44.542Dump of unix-generic skgm contextareaflags 00000037realmflags 0000000fmapsize 00002000protectsize 00002000lcmsize 00002000seglen 00002000largestsize 00000000f8000000smallestsize 0000000000400000stacklimit ef87eebfstackdir -1mode 640magic acc01adeHandle: 177b8c8 `/u02/app/oracle/product/8.1.6R816Dump of unix-generic realm handle `/u02/app/oracle/product/8.1.6R816, flags = 00000000 Area #0 `Fixed Size containing Subareas 0-0 Total size 0000000000010ff0 Minimum Subarea size 00000000 Area Subarea Shmid Stable Addr Actual Addr 0 0 2007 0000000080000000 0000000080000000 Subarea size Segment size 0000000000012000 00000000039d4000 Area #1 `Variable Size containing Subareas 1-1 Total size 00000000025a2000 Minimum Subarea size 00100000