Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

Oracle UNIX Administration RAM Memory Segments

Oracle UNIX/Linux Tips by Burleson Consulting

Viewing allocated RAM memory segments IN UNIX

To see all allocated memory segments you your server, enter the inter-process control system, or ipcs command. The ipcs command shows all held memory segments on the server, and those owned by the Oracle user represent the allocated memory for the Oracle System Global Area, or SGA.

root> ipcs -pmb

IPC status from <running system> as of Mon Sep 10 13:56:17 EDT 2001

T         ID      KEY        MODE       OWNER    GROUP  SEGSZ  CPID 

Shared Memory:

m       2400   0xeb595560 --rw-r-----   oracle   dba  281051136 15130
m        601   0x65421b9c --rw-r-----   oracle   dba  142311424 15161
m        702   0xe2fb1874 --rw-r-----   oracle   dba  460357632 15185
m        703   0x77601328 --rw-r-----   oracle   dba  255885312 15231

Here we see all of the UNIX RAM memory segments that are associated with each Oracle SGA on the Oracle server.  We also see the size of each memory segment and this can give us a clue about which segment is associated with each SGA.

To see the specific memory segments, you can enter SQL*Plus as SYSDBA and issue the oradebug ipc command. 

root> sqlplus /nologin

SQL*Plus: Release 8.1.7.0.0 - Production on Mon Sep 10 14:00:02 2001

(c) Copyright 2000 Oracle Corporation.  All rights reserved.

SQL> connect system/manager as sysdba;

Connected.

SQL> oradebug ipc

Information written to trace file.

Next, we go to the udump directory where we cat the trace file to see the details about the RAM memory segment for this database. In the listing we see the shared memory ID (Shmid) number 703, indicating that 703 is the RAM region associated with this database instance.

cheops*testsid-/u01/app/oracle/admin/testsid/bdump

>udump

cheops*testsid-/u01/app/oracle/admin/testsid/udump

>ls -alt|head

total 3212

drwxr-xr-x   2 oracle   dba      4096 Sep 10 14:01 .
-rw-r-----   1 oracle   dba     17721 Sep 10 14:01 testsid_ora_17727.trc
-rw-r-----   1 oracle   dba     17820 Sep 10 14:00 testsid_ora_17690.trc
-rw-r-----   1 oracle   dba       919 Sep  9 01:03 testsid_ora_15231.trc

cheops*testsid-/u01/app/oracle/admin/testsid/udump
>cat testsid_ora_17727.trc

Dump file /u01/app/oracle/admin/testsid/udump/testsid_ora_17727.trc
Oracle8i Enterprise Edition Release 8.1.7.0.0 - 64bit Production
With the Partitioning option
JServer Release 8.1.7.0.0 - 64bit Production
ORACLE_HOME = /u01/app/oracle/product/8.1.7_64
System name:    SunOS
Node name:      cheops
Release:        5.8
Version:        Generic_108528-03
Machine:        sun4u
Instance name: testsid
Redo thread mounted by this instance: 1
Oracle process number: 0
17727
Dump of unix-generic skgm context
areaflags            00000037
realmflags           0000000f
mapsize              00002000
protectsize          00002000
lcmsize              00002000
seglen               00002000
largestsize  0000040000000000
smallestsize 0000000000400000
stacklimit   ffffffff7f87e2ef
stackdir                   -1
mode                      640
magic                acc01ade
Handle:             101e319c0 `/u01/app/oracle/product/8.1.7_64testsid'
Dump of unix-generic realm handle
/u01/app/oracle/product/8.1.7_64testsid', flags = 00000000
 Area #0 `Fixed Size' containing Subareas 0-0
  Total size 0000000000018ebc Minimum Subarea size 00000000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      0        0      703 0000000380000000 0000000380000000
                              Subarea size     Segment size
                          000000000001a000 000000000f408000
 Area #1 `Variable Size' containing Subareas 1-1
  Total size 000000000d774000 Minimum Subarea size 00100000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      1        1      703 000000038001a000 000000038001a000
                              Subarea size     Segment size
                          000000000d800000 000000000f408000
 Area #2 `Database Buffers' containing Subareas 3-3
  Total size 00000000007d0000 Minimum Subarea size 00004000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      2        3      703 000000038eb2e000 000000038eb2e000
                              Subarea size     Segment size
                          00000000007d0000 000000000f408000
 Area #3 `Redo Buffers' containing Subareas 4-4
  Total size 0000000000104000 Minimum Subarea size 00000000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      3        4      703 000000038f2fe000 000000038f2fe000
                              Subarea size     Segment size
                          0000000000104000 000000000f408000
 Area #4 `Lock Manager' containing Subareas 5-5
  Total size 0000000000004000 Minimum Subarea size 00000000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      4        5      703 000000038f402000 000000038f402000
                              Subarea size     Segment size
                          0000000000004000 000000000f408000
 Area #5 `Java' containing Subareas 2-2
  Total size 0000000001313000 Minimum Subarea size 00000000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      5        2      703 000000038d81a000 000000038d81a000
                              Subarea size     Segment size
                          0000000001314000 000000000f408000
 Area #6 `skgm overhead' containing Subareas 6-6
  Total size 0000000000002000 Minimum Subarea size 00000000
   Area  Subarea    Shmid      Stable Addr      Actual Addr
      6        6      703 000000038f406000 000000038f406000
                              Subarea size     Segment size
                          0000000000002000 000000000f408000
Dump of Solaris-specific skgm context
sharedmmu 00000001
shareddec        0
Maximum processes:               = 2000
Number of semaphores per set:    = 62
Semaphores key overhead per set: = 4
User Semaphores per set:         = 58
Number of semaphore sets:        = 35
Semaphore identifiers:           = 35
Semaphore List=
589929

-------------- system semaphore information -------------
IPC status from <running system> as of Mon Sep 10 14:01:29 EDT 2001

T         ID      KEY        MODE     OWNER  GROUP  CREATOR   CGROUP

 Semaphores:

s    6488064   0xd75025fc --ra-r-----  oracle  dba   oracle      dba   
s    1507329   0xd75025fd --ra-r-----  oracle  dba   oracle      dba   
s    1507330   0xd75025fe --ra-r-----  oracle  dba   oracle      dba   
s    1507331   0xd75025ff --ra-r-----  oracle  dba   oracle      dba   
s    1507332   0xd7502600 --ra-r-----  oracle  dba   oracle      dba   
s    1507333   0xd7502601 --ra-r-----  oracle  dba   oracle      dba   
s    1507334   0xd7502602 --ra-r-----  oracle  dba   oracle      dba   
s    1507335   0xd7502603 --ra-r-----  oracle  dba   oracle      dba   
s    1507336   0xd7502604 --ra-r-----  oracle  dba   oracle      dba   
s    1507337   0xd7502605 --ra-r-----  oracle  dba   oracle      dba   
s    1507338   0xd7502606 --ra-r-----  oracle  dba   oracle      dba   
s    1507339   0xd7502607 --ra-r-----  oracle  dba   oracle      dba   
s    1507340   0xd7502608 --ra-r-----  oracle  dba   oracle      dba   
s    1507341   0xd7502609 --ra-r-----  oracle  dba   oracle      dba   

Tip - When Oracle crashes, sometimes there memory segments are held by the server, and must be manually de-allocated.  In the example below, we can remove the SGA memory for this instance.  Remember, we only manually remove UNIX memory when Oracle has abnormally terminated.

root> ipcrm ?m 703

Viewing RAM swap paging in UNIX

Note that in a later section we show you how to use the glance utility to display RAM swap activity.

RAM paging in AIX

The lsps -a command is used in the IBM AIX Unix dialect to display the swap usage for a server.

root> lsps ?a

Page Space  Physical Volume   Volume Group    Size   %Used  Active  Auto 

paging00    hdisk3            maxvg           40MB       0      no    no   
hd6         hdisk0            rootvg        2048MB       3     yes   yes  

Also note that the glance utility is very useful for monitoring RAM memory and swapping activity.  Please refer to the discussion of glance later in this chapter for a complete description if using glance to monitor RAM memory.

Making Oracle RAM non-swappable in HP/UX and Solaris

In several dialects of UNIX (HP/UX and Solaris) it is possible to ?pin? the SGA on the UNIX server so that it will never become eligible for a page out.  This marking on the RAM region as non-swappable tells UNIX never to page out the region and ensure that it always stays in real RAM memory, never going to the swap disk. Note that you cannot do this on IBM AIX.  The pinning is done by setting the following init.ora parameters.

lock_sga=true  --  init.ora parm for hp/ux UNIX
USE_ISM=true ?- Sun Solaris ?Intimate Shared Memory? init.ora parm

Pease note that in Oracle8i (release 8.1.5 and greater) for Solaris, the USE_ISM parameter becomes a hidden parameter and defaults to true.  This means that the SGA will always be non-swappable in Solaris.

Let?s begin by looking at how memory is configured for a database server and explore how to manage memory on a large server.

UNIX Server Memory Settings

The first step when tuning server memory is to review the kernel settings that relate to available memory. The kernel settings for memory usage (i.e., SHMMAX, SHMMNI, db_max_pct) are critical to effective Oracle performance, and you should double-check all of your kernel parameters to ensure that the server memory is properly configured.

We also must verify the configuration of the swap disk. As you may know, the swap disk is a special system disk that is reserved to accept memory frames that are paged-out from physical RAM. Most servers recommend that the size of the swap disk be set to double the amount of physical RAM.

Very Large Memory and Oracle

It is important to note that some servers are not capable of addressing ?high memory.? The high-memory boundary is a physical constraint that is determined by the bit-size of the application, and the only way to utilize above-the-line memory is to use special OS techniques. For example, in all 32-bit versions of Oracle, all memory over 1.7 gigabytes cannot be addressed regardless of the amount of RAM on the server. This can cause a very perplexing problem, since the database server will experience page-in operations, while top and glance utilities report that there is excess memory on the server. In short, the sum of all SGA memory for all of the Oracle instances on the server cannot exceed 1.7 gigabytes. For some UNIX environments such as Solaris, there are special patches that can be applied on a 32-bit server to allow the DBA to create SGA regions in excess of 2 gigabytes.

If you cannot upgrade to 64-bit Oracle and you want to address memory above the line, operating system techniques can be used. For example, in HP/UX, special patches can be applied to allow Oracle regions to run above 1.7 gigabytes. HP calls this technique ?memory windows,? and it uses a SHARED_MAGIC executable to route application to above-the-line memory regions.

Bear in mind that all 32-bit applications are required to run in low memory. For example, Oracle applications are currently 32-bit and will not be able to address high memory, above the 1.7 gigabyte limit. Fortunately, all versions of 64-bit Oracle are capable of addressing high memory. However, you must ensure that your Oracle Database and any other applications are capable of addressing all of the available memory. For example, below we see a clear case of RAM overload, even though the CPU appears to be 99-percent idle:

TO_CHAR(START_DA RUNQUE_WAITS    PAGE_IN SYSTEM_CPU   USER_CPU   IDLE_CPU
---------------- ------------ ---------- ---------- ---------- ----------
06/02/2000 05:01            2         85          1          0         99
06/02/2000 13:47            2        193          0          0         99
06/03/2000 05:04            0        114          2          3         95
06/03/2000 22:31            1        216          0          1         99
06/04/2000 05:02            0        146          1          1         99
06/04/2000 22:34            1         71          1          8         90
06/05/2000 06:57            1        213          0          0         99
06/05/2000 07:25            1        113          0          0         99
06/05/2000 07:35            1         72          0          0         99
06/05/2000 11:06            1        238          0          1         99

Making Oracle SGA RAM Memory Non-swappable

Just like with CPU shortages, the best remedy to a RAM problem is to add additional RAM to the server. However, there are some short-term techniques that can be used to prevent the Oracle SGA memory from paging. On some operating systems, it is possible to use a memory-fencing technique to ensure that the Oracle SGA is never paged-out to the swap disk.

Memory fencing with the lock_sga Initialization Parameter

The lock_sga init.ora parameter will lock the entire SGA into physical RAM memory, making it ineligible for swapping. The lock_sga parameter does not work for Windows NT or AIX, and the setting for lock_sga will be ignored. For AIX 4.3.3 and above, you can set the  SHM_PIN parameter to keep the SGA in RAM, and you can get details about this from your AIX documentation.

Solaris Memory Fencing

In Sun Solaris, you can set the use_ism parameter to invoke intimate shared memory for the Oracle SGA. In releases of Oracle prior to Oracle8i you can set the init.ora parameter use_ism=true. The use_ism init.ora parameter was obsoleted in 8.1.3, and in Oracle8i use_ism becomes a hidden parameter that defaults to True. Memory page locking is implemented in Solaris by setting some bits in the memory page's page structure. The page-out, which runs if free memory gets low, checks the status of the page's lock fields. If the field is nonzero, the page is considered locked in memory and thus not marked as a candidate for freeing.

Caution: There is a bug associated with use_ism on some versions of Solaris. For details, see MOSC for Note:1057644.6, Note:69863.1, Note:1055268.6, Doc ID 77604.1, Note:48764.1, and Note:1054590.6.

You can access MOSC at: http://MOSC.oracle.com/home.html

Next, let?s look at semaphore management in UNIX.

 

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational