header

Showing posts with label Oracle DBA. Show all posts
Showing posts with label Oracle DBA. Show all posts

How to identify who is locking the Oracle account

With AUDIT_TRAIL

The first and preferred solution is with Oracle standard auditing feature. Start by setting initialization parameter AUDIT_TRAIL to db and restart your Oracle database as it is static parameter.
Then activate network auditing with (as SYS):
SQL> AUDIT network BY ACCESS;
 
AUDIT succeeded.
With below query you get everything needed:
SELECT *
FROM dba_audit_session
ORDER BY sessionid DESC;
Returncode column contains Oracle error code and so different of 0 if logon/logoff issue. The invalid password is the error we are chasing:
[oracle@server1 ~]$ oerr ora 1017
01017, 00000, "invalid username/password; logon denied"
// *Cause:
// *Action:
So if you find 1017 values in this column then we have found what we were looking for. For example with my test case where I intentionally specify a wrong password for my account:
SQL> SELECT username,userhost,returncode
     FROM dba_audit_session
     WHERE username='YJAQUIER'
     ORDER BY sessionid DESC;
 
USERNAME                       USERHOST             RETURNCODE
------------------------------ -------------------- ----------
YJAQUIER                       server1                    1017
YJAQUIER                       GVADT30596                    0
YJAQUIER                       server1                       0
YJAQUIER                       server1                       0
.
.
.
And if you insist, as explained, you get:
SQL> SELECT username, account_status,lock_date, PROFILE FROM dba_users WHERE username='YJAQUIER';
 
USERNAME                       ACCOUNT_STATUS                   LOCK_DATE            PROFILE
------------------------------ -------------------------------- -------------------- ------------------------------
YJAQUIER                       LOCKED(TIMED)                    23-nov-2012 10:30:37 DEFAULT
If you set AUDIT_TRAIL to db behave the size of SYS.AUD$ table as a small list of audits are already implemented by default:
SQL> SET lines 200
SQL> SET pages 200
SQL> SELECT * FROM DBA_STMT_AUDIT_OPTS;
 
USER_NAME                      PROXY_NAME                     AUDIT_OPTION                             SUCCESS    FAILURE
------------------------------ ------------------------------ ---------------------------------------- ---------- ----------
                                                              ALTER SYSTEM                             BY ACCESS  BY ACCESS
                                                              SYSTEM AUDIT                             BY ACCESS  BY ACCESS
                                                              CREATE SESSION                           BY ACCESS  BY ACCESS
                                                              CREATE USER                              BY ACCESS  BY ACCESS
                                                              ALTER USER                               BY ACCESS  BY ACCESS
                                                              DROP USER                                BY ACCESS  BY ACCESS
                                                              PUBLIC SYNONYM                           BY ACCESS  BY ACCESS
                                                              DATABASE LINK                            BY ACCESS  BY ACCESS
                                                              ROLE                                     BY ACCESS  BY ACCESS
                                                              PROFILE                                  BY ACCESS  BY ACCESS
                                                              CREATE ANY TABLE                         BY ACCESS  BY ACCESS
                                                              ALTER ANY TABLE                          BY ACCESS  BY ACCESS
                                                              DROP ANY TABLE                           BY ACCESS  BY ACCESS
                                                              CREATE PUBLIC DATABASE LINK              BY ACCESS  BY ACCESS
                                                              GRANT ANY ROLE                           BY ACCESS  BY ACCESS
                                                              SYSTEM GRANT                             BY ACCESS  BY ACCESS
                                                              ALTER DATABASE                           BY ACCESS  BY ACCESS
                                                              CREATE ANY PROCEDURE                     BY ACCESS  BY ACCESS
                                                              ALTER ANY PROCEDURE                      BY ACCESS  BY ACCESS
                                                              DROP ANY PROCEDURE                       BY ACCESS  BY ACCESS
                                                              ALTER PROFILE                            BY ACCESS  BY ACCESS
                                                              DROP PROFILE                             BY ACCESS  BY ACCESS
                                                              GRANT ANY PRIVILEGE                      BY ACCESS  BY ACCESS
                                                              CREATE ANY LIBRARY                       BY ACCESS  BY ACCESS
                                                              EXEMPT ACCESS POLICY                     BY ACCESS  BY ACCESS
                                                              GRANT ANY OBJECT PRIVILEGE               BY ACCESS  BY ACCESS
                                                              CREATE ANY JOB                           BY ACCESS  BY ACCESS
                                                              CREATE EXTERNAL JOB                      BY ACCESS  BY ACCESS
So you must put in place a purging policy for this table.

Without AUDIT_TRAIL

The only drawback of the previous solution is that you have to restart the database. And maybe two times because after problem solved you would like to deactivate auditing. This is most probably not reliable solution on a production database so I have been looking for a better solution with no database reboot.
I initially thought of the AFTER LOGON trigger but you need to be logged-in and the BEFORE LOGON does not exits. Then at same documentation place I found the AFTER SERVERERROR trigger and decided to give it a try.
First I created a dummy table to log server error (columns inherited from dba_audit_session dictionary table):
CREATE TABLE sys.logon_trigger
(
USERNAME VARCHAR2(30),
USERHOST VARCHAR2(128),
TIMESTAMP DATE
);
Second I created below trigger:
CREATE OR REPLACE TRIGGER sys.logon_trigger
AFTER SERVERERROR ON DATABASE
BEGIN
  IF (IS_SERVERERROR(1017)) THEN
    INSERT INTO logon_trigger VALUES(SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY'), SYS_CONTEXT('USERENV', 'HOST'), SYSDATE);
    COMMIT;
  END IF;
END;
/
Then third simulated a wrong password access with my account and issued:
SQL> ALTER SESSION SET nls_date_format='dd-mon-yyyy hh24:mi:ss';
 
SESSION altered.
 
SQL> SET lines 200
SQL> col USERHOST FOR a30
SQL> SELECT * FROM sys.logon_trigger ORDER BY TIMESTAMP DESC;
 
USERNAME                       USERHOST                       TIMESTAMP
------------------------------ ------------------------------ --------------------
yjaquier                       ST\GVADT30596                  23-nov-2012 11:05:56

Oracle cold backup database refresh

1.  Prepare controlfile creation script.  This can be done by
alter database backup controlfile to trace as '/export/home/oracle/ctlfile.sql';
2.  View the edit ctlfile.sql, so that it should contain the following
CREATE CONTROLFILE SET DATABASE "UATDB" RESETLOGS NOARCHIVELOG
  MAXLOGFILES 16
  MAXLOGMEMBERS 3
  MAXDATAFILES 100
  MAXINSTANCES 1
  MAXLOGHISTORY 453
LOGFILE
  GROUP 1 '/u01/oradata/UATDB/redo01.log' SIZE 200M,
  GROUP 2 '/u02/oradata/UATDB/redo02.log' SIZE 200M,
  GROUP 3 '/u03/oradata/UATDB/redo03.log' SIZE 200M
-- STANDBY LOGFILE
DATAFILE
  '/u01/oradata/UATDB/system01.dbf',
  '/u01/oradata/UATDB/undotbs01.dbf',
  '/u01/oradata/UATDB/users01.dbf',
  '/u01/oradata/UATDB/data01.dbf',
  '/u01/oradata/UATDB/tools01.dbf',
  '/u01/oradata/UATDB/perfstat01.dbf',
  '/u01/oradata/UATDB/sysaux01.dbf'
CHARACTER SET WE8ISO8859P1
;
3. Gernerate script to create TEMP tablespace
set long 2000
select DBMS_METADATA.GET_DDL('TABLESPACE','TEMP') from dual;
4. Shutdown UATDB cleanly
shutdown immediate
5. Copy the cold backup files from production to UAT box.
6. Start the database in nomount state

startup nomount
7. Run the create control file script
@/export/home/oracle/ctlfile.sql
8. Open the database with resetlogs
alter database open resetlogs;
9. Create temp tablespace from the script generated from step 3:
CREATE TEMPORARY TABLESPACE "TEMP1" TEMPFILE
'/u01/oradata/UATDB/TEMP01.dbf' SIZE 5242880000
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1048576

useful EXCEL formula to generate SQL DDL/grant scripts

TO generate update script:

---------------------------
Enter the formula as below to generate the multiple statement and drag colums to generate DDL statements
=CONCATENATE($E$3,A2,"';")
Where
$E$3 Excel cell -->update psoprdefn set operpswd = ' ' where oprid='  (or similar insert statement)
A2 Excel  cell --> list table names or user name
“’;” --> is a string


To Generate role and permision and grants
----------------------------------------------
="grant select, update, delete, insert on " & A1 & " to user_role;"
="create public synonym " & A1 & " for sysadm." & A1 & ";"


Where
& A1 & Excel column  contains the table list

Cloning PeopleSoft Database

Overview

This document describes the steps required to create a clone of the PeopleSoft production database. This is the most common task of a PeopleSoft Administrator / in any PeopleSoft upgrade project.

Here are some of the steps that need to be consider when creating a Development or Test environment from a production database on PeopleTools 8.4X.


Steps

1. Create a backup of the production database. (This is your source database)

2. Stop the Target Application Environment. (If application environment is running)



Application Servers
Process Schedulers
Web Servers

3. Overlay the target database with a recent backup of the production database.

4. Start the database

5. Set DBNAME in PSDBOWNER back to the target database name.

UPDATE PSDBOWNER SET DBOWNER = 'Database Name';


6. Set GUID to ' ' in PSOPTIONS table.

UPDATE PSOPTIONS SET GUID = ' ';

This will cause PeopleSoft to generate a new GUID so that change assistant can track it separately from the source database.

7. Delete the data from

Reporting tables
Process scheduler tables
Application messaging tables

This data isn't relevant in the target database.
Below DMS scripts are provided by PeopleSoft. Use these scripts to clean the above tables.
prcsclr.dms (Process Scheduler Tables)
rptclr.dms (Reporting Tables)
appmsgpurgeall.dms (Application Messaging Tables)

8. Reset email address to blank or predefined value.


Since you are creating a clone of the production database you will have actual email address of all the employees. Email address is a very critical data. Reset everyone's e-mail address to a pre-defined value so that workflow messages from the Test environment don't get sent to real users.

Some of the common tables of PeopleSoft ERP are as follows

PSOPRDEFN
PS_ROLEXLATOPR
PSUSEREMAIL


You need to take care of Application specific tables. You can find out these tables by using below script.


SELECT RECNAME
FROM PSRECFIELD B
WHERE EXISTS (SELECT 'X' FROM PSRECDEFN A WHERE RECTYPE = 0 AND A.RECNAME = B.RECNAME)
AND B.FIELDNAME = 'EMAILID'


8. Change application password (VP1)

Logon to PeopleSoft data mover script and execute the below scripts if you want to chage the application password.

UPDATE PSOPRDEFN SET OPERPSWD = 'PASSWORD', ENCRYPTED = 0 WHERE OPRID = VP1;
ENCRYPT_PASSWORD VP1;

Oracle Enqueues

A Latch as used in Oracle is a low-level mechanism for serializing concurrent access to memory structures such as cache buffer headers. A latch is a simple memory structure that averages 100 to 200 bytes in size (actual size is dependent upong the version of Oracle, Operating System and hardware platform). Latches are contained in a state object structure and reside in either fixed SGA (parent latches) or the shared pool. They are set via the hardware-atomic compare-and-swap (CAS) instructions – LOCK CMPXCHG for Intel. Latches can be shared and are used for some AQ operations.

Latch Contention occurs when a process attempts to get a latch but fails because another process already has control of it. If the attempt (get) was issue with in no-wait mode, then return to the calling process with a failure result. If the get was issued in a willing-to-wait mode then continue attempting to obtain the latch until x number of tries is reached.

The term to describe a get that is executed in a willing-to-wait mode that tries repeatedly without acquiring the latch is spinning – the process issues the get, if the latch is already held then the process will sleep, wake up after x amount of time expires and attempts to acquire the latch again.

The process attempting to acquire a latch may be waken by the process that releases the latch but this method isn’t used for all latches.

The following views are used to troubleshoot contention issues:

v$session_event
v$session_wait
v$latchholder
Troubleshooting latch contention consists of first identifying the session(s) that are currently experiencing problems and then identify the latch the session is waiting for and determine if the wait time is significant enough to warrant attention. Identifying the child latch that is involved will help determine if the contention is concentrated on a particular child latch or are many child latches involved.

As of Oracle 10.2 KGX Mutexes replace latches (Kernel Generic MuteX – KGX). Mutexes resemble latches (a physical allocation of memory) only they are lighter weight and consume less memory space. They can also be embedded inside other structures, they have flexible spin/yield/wait strategies defined by the client process and they do not factor into the accounting for GETS,SPINS or YIELDS, only WAITS.

Keep in mind that KGX mutexes are not OS mutexes.

In 11g+ mutexes are used instead of library cache latches. The default for pinning library cache cursors and parent examination for 10.2.0.2+ is mutexes – _kks_use_mutex_pin=true.

Some known mutex types in 11g:

Cursor Parent
Cursor Pin
Cursor Stat
Library Cache
hash table
Mutex Troubleshooting – involves querying the views: v$session_wait, v$mutex_sleep and v$mutex_sleep_history among others. The mutex sleeps are well instrumented in the wait interface and the P1, P2, P3 values contain the hash value of the library cache objects experiencing contention, the session holding the mutex, etc. The views v$event_name and v$session_wait “text” columns document the meaning of P1, P2 and P3. The v$mutex_sleep view shows the wait time and the number of sleeps for each combination of mutex type and location while the v$mutex_sleep_history view shows the last individual occurences of mutex sleeps based on a circular buffer and this view contains the highest level of detail.

Enqueues – Terminology and Views

Locks are called enqueues because the locking mechanism implements an ordered queuing structure for lock waiters. Latches and mutexes do not have sophisticated queuing mechanisms.

Enqueue Resources – v$resource(X$KSQRS)

Enqueue Locks – v$lock(X$KSQEQ)

Enqueue resource types – v$lock_type has two meanings – ID1 and ID2

Slots in a hash table identify a resource. Resources are not locks, they are placeholders that reference the object that can be locked. The unique identifier (primarykey) for a resource will consists of the following:

Resource type (TM, TX, MR, …)
Resource identifier 1 (ID1)
Resource identified 2 (ID2)
Example:
TM-XXXXXXXX-XXXXXXXX
The resource identifiers are used to break down a resource class into individual objects. An example of this would be two tables that both have a TM resource allocated to them in memory. The ID1 specifies the object_id of the table (v$lock_type which contains the meaning of ID1/2 for each resource type).

Locks – provide the link between the resource locked and the holder of that resource. If there are many lock holders on a single resource (assuming compatible mode) then it follows that there will be multiple lock structures pointing to that one resource.

What Character Set Supports Which Language

Overview
This list identifies which Oracle ISO or MSWIN character sets contains which supported language(s). All of these character sets contain the 7-bit ASCII English characters and numerals. Oracle lists both the ISO and MSWIN characteristics and their recommendation is to use the MSWIN database character sets instead of the ISO versions, even if all of your clients are not Windows based. This is simply because the MSWIN database character sets are more comprehensive and support more characters than the ISO database character sets.

There are no problems using a MSWIN database character set on a non-Windows/Unix platform.

You can determine what the current value for your database character set is by executing the following statement:

select value from NLS_DATABASE_PARAMETERS where parameter=’NLS_CHARACTERSET’;

To determine the client setting use ‘NLS_LANG’ instead of ‘NLS_CHARACTERSET’ and see note below.

Character Sets
WE8ISO8859P15 (ISO 8859-15), WE8MSWIN1252 : Albanian, Basque, Breton, Catalan, Cornish, Danish, Dutch, Finnish, French, Frisian, Galician, German, Greenlandic, Irish Gaelic, Italian, Luxembourgish, Norwegian, Portuguese, Rhaeto-Romanic, Scottish Gaelic, Spanish, Swedish and the Euro symbol

EE8ISO8859P2 (ISO 8859-2), EE8MSWIN1250 : Albanian, Croatian, Czech, German, Hungarian, Polish, Slovak, Slovenian, Sorbian

NEE8ISO8859P4 (ISO 8859-4), BLT8MSWIN1257 : Danish, Estonian, Finnish, German, Greenlandic, Latvian, Lithuanian, Norwegian, Sami, Slovenian, Swedish

CL8ISO8859P5 (ISO 8859-5), CL8MSWIN1251 : Bulgarian, Byelorussian, Slavic Macedonian, Russian, Sebian, Ukrainian

AR8ISO8859P6 (ISO 8859-6), AR8MSWIN1256 : Arabic

EL8ISO8859P7 (ISO 8859-7), EL8MSWIN1253 : Greek (monitoniko orthography)

IW8ISO8859P8 (ISO 8859-8), IW8MSWIN1255 : Hebrew

VN8MSWIN1258 : Vietnamese

TH8TISASCII : Thai

JA16SJIS : Japanese

ZHS16GBK : Simplified Chinese

KO16MSWIN949 : Korean

ZHT16HKSCS and ZHT16HKSCS31 : Traditional Chinese (Taiwan)

ZHT16HKSCS and ZHT16HKSCS31 : Traditional Chinese (Hong Kong)

WE8ISO8859P2 (ISO 8859-1) : Albanian, Basque, Breton, Catalan, Cornish, Danish, Dutch, Faroese, French, Finnish, Frisian, Galician, German, Greenlandic, Icelandic, Irish Gaelic (new orthography), Italian, Luxemburgish, Norwegian, Portugese, Rhaeto-Romanic, Scottish Gaelic, Spanish, Swedish

SE8ISO8859P3 (ISO 8859-3) : Esperanto, French, German, Italian, Maltese, Portugese, Turkish

WE8ISO8859P9 (ISO 8859-9) : Albanian, Basque, Breton, Catalan, Cornish, Danish, Dutch, Finnish, French, Galician, German, Greenlandic, Irish Gaelic (new orthography), Italian, Luxemburgish, Norwegian, Portugese, Rhaeto-Romanic, Scottish Gaelic, Spanish, Swedish, Turkish

NE8ISO8859P10 (ISO 8859-10) : Dannish, Estonian, Faroese, Finnish, German, Greenlandic, Icelandic, Irish Gaelic (new orthography), Lithuanian, Norwegian, Sami, Slovenian, Swedish

Notes:
An external resource http://www.eki.ee/letter allows you to choose a language and then it displays an overview of all the charactersets that contain all the letters.

RMAN script

Scripting Oracle RMAN Commands

Two ways to script RMAN, use a command file which is a text file residing in the file system and use a stored script which is stored in the RMAN catalog database and executed from the RMAN command prompt.

Command file to backup the USERS tablespace:

connect target /

connect catalog rman/secretpass@rmancat

run { allocate channel c1 type disk format ‘/orabak/%U’;

backup tablespace users;

}

RMAN> @backup_ts_users.rman

rman @backup_ts_users.rman

rman cmdfile=backup_ts_users.rman

rman target=/ catalog=

rman/secretpass@rmancat

Note that the CONNECT clauses are inside the backup_ts_users.rman command file, so there is no reason to provide the password in the command line – meaning you can eliminate the risk of accidental exposure of the password. Had we not included the password of the catalog user rman inside the command file, we would have had to call the Oracle RMAN executable like above.

To use a command file parameter-driven approach like the following where instead of actual values, the new command file includes the parameters (also known as placeholders or substitution variables) &1 and &2 which with a parameter-driven command file you define any number of parameters in this manner and pass the values at runtime.

connect target /

connect catalog rman/secretpass@rmancat

run { allocate channel c1 type disk format ‘&1/%U’;

backup tablespace &2;

}

A shell script, named backup_ts_generic.sh calls the backup_ts_generic.rman command file with the values /tmp as the backup location for parameter &1 and USERS as the tablespace name for parameter &2:

$ORACLE_HOME/bin/rman <
@backup_ts_generic.rman “/tmp” USERS

EOF

You can make this shell script even more generic so that the parameters are passed from the command line of the file system itself. For example, if you modify the second line in the backup_ts_generic.sh shell script to read:

@backup_ts_generic.rman “/tmp” $1

you will be able to call the backup_ts_generic.rman command file, provide /tmp as the backup location, and pass the tablespace name in the command line. For instance, if you want to backup the MYTS1 tablespace, you can issue the command:

backup_ts_generic.rman MYTS1

To log RMAN scripts via an automated mechanism such as cron in UNIX or Scheduler in Windows, you are not physically watching the command window, so how do you know the output of the Oracle RMAN commands? To capture the output, you can use the log parameter in the Oracle RMAN command line:

rman cmdfile=backup_ts_users.rman log=backup_ts_users.log

Stored Scripts – although command files work pretty well in most cases, they have one huge drawback – a command file should be available on the server where the Oracle RMAN backup is to be run. Otherwise, from within the command file, you have to connect from the Oracle RMAN client to the server by using a connect string:

connect target sys/oracle123@remotedb

There are several problems with this setup. First, the modified command file needs to store the password of SYS or some other user with SYSDBA privilege. In a security-conscious environment that may not be acceptable. Second, the Oracle RMAN client may not be compatible with the Oracle Database release. Finally, for performance reasons, you may very well want to run the Oracle RMAN client on the same server as the database itself. But what if you have databases on different servers? You will have to replicate a command file script to all servers. And when you modify the script you will have to make sure it is copied to all those servers again.

The solution use Oracle RMAN stored scripts, you can create scripts that are stored inside the Oracle RMAN catalog and not on the server itself. Because it is stored inside the Oracle RMAN catalog, you will need to connect to the catalog first, as shown below. To execute this script, al you have to do is call it with the execute command from the Oracle RMAN prompt:

RMAN> run { execute script backup_ts_users; }

Stored script for backing up USERS tablespace:

rman

RMAN> connect target /

RMAN> connect catalog rman/secretpass@rmancat

RMAN> create script backup_ts_users

command ‘Tablespace USERS Backup’

{

allocate channel c1 type disk format ‘c:\temp\%U’;

backup tablespace users;

}

The backup_ts_users stored script created above is available only to the target database to which it is currently connected. It is a local stored script, and you can’t execute a local script for one database in another. To execute a script in multiple databases, create a global stored script by using the keyword GLOBAL between CREATE and SCRIPT. For instance, to create a global script for the one above, replace:

create script backup_ts_users

with

create global script backup_ts_users

Once created, this global stored script can be executed in any database connected to this catalog. If you need to modify the script, there is no need to copy it to all servers or databases; it’s automatically available for execution to all databases connecting to the catalog.

If the global stored script already exists and you want to update it, replace CREATE with REPLACE:

replace global script backup_ts_users

- and include the updated script text.

Parameterization: This backup_ts_users stored script has a very specific purpose – backing up the USERS tablespace. What if you want to backup a different tablespace? Rather than creating multiple scripts, you can create a generic stored script to backup any tablespace.

A stored script merely asks for a value; it does not store the value you used in the script itself:

RMAN> create script backup_ts_any

comment ‘Any Tablespace Backup’

{

allocate channel c1 type disk format ‘c:\temp\%U’;

backup tablespace &1;

}

With the parameterized stored script created, pass the value of the parameter via a USING clause. For example, to backup the SYSTEM tablespace by using this backup_ts_any stored script, use the following Oracle RMAN command:

run { execute script

backup_ts_any using ‘SYSTEM’; }

To display the list of stored scripts:

RMAN> list script names;

RMAN> list global script names;

RMAN> print global script backup_ts_level1_any;

RMAN> delete global script backup_ts_level1_any;

RMAN> create script backup_ts_users

from file ‘backup_ts_users.rman’;

RMAN> print script backup_ts_users to file ‘backup_ts_users.rman’;

semaphore for Oracle Database

A semaphore can be thought of as a counter that is used to control access to a shared resource. Semaphores provide low level synchronization between processes (or threads within a process) so that only one process (or thread) has access to the shared segment, thereby ensureing the integrity of that shared resource. When an application requests semaphores, it does so using "sets".
To determine all semaphore limits, use the following: # ipcs -ls
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767You can also use the following command: # cat /proc/sys/kernel/sem
250 32000 32 128
SEMMSL
The SEMMSL kernel parameter is used to control the maximum number of semaphores per semaphore set.
Oracle recommends setting SEMMSL to the largest PROCESS instance parameter setting in the init.ora file for all databases hosted on the Linux system plus 10. Also, Oracle recommends setting the SEMMSL to a value of no less than 100.
SEMMNI
The SEMMNI kernel parameter is used to control the maximum number of semaphore sets on the entire Linux system.
Oracle recommends setting the SEMMNI to a value of no less than 100.
SEMMNS
The SEMMNS kernel parameter is used to control the maximum number of semaphores (not semaphore sets) on the entire Linux system.
Oracle recommends setting the SEMMNS to the sum of the PROCESSES instance parameter setting for each database on the system, adding the largest PROCESSES twice, and then finally adding 10 for each Oracle database on the system. To summarize: SEMMNS = sum of PROCESSES setting for each database on the system
+ ( 2 * [largest PROCESSES setting])
+ (10 * [number of databases on system]
To determine the maximum number of semaphores that can be allocated on a Linux system, use the following calculation. It will be the lesser of: SEMMNS -or- (SEMMSL * SEMMNI)
SEMOPM
The SEMOPM kernel parameter is used to control the number of semaphore operations that can be performed per semop system call.
The semop system call (function) provides the ability to do operations for multiple semaphores with one semop system call. A semaphore set can have the maximum number of SEMMSL semaphores per semaphore set and is therefore recommended to set SEMOPM equal to SEMMSL.
Oracle recommends setting the SEMOPM to a value of no less than 100.
Setting Semaphore Kernel Parameters
Finally, we see how to set all semaphore parameters using several methods. In the following, the only parameter I care about changing (raising) is SEMOPM. All other default settings should be sufficient for our example installation.
This is method I use most often. This method sets all semaphore kernel parameters on startup by inserting the following kernel parameter in the /etc/sysctl.conf startup file: # echo "kernel.sem=250 32000 100 128" >> /etc/sysctl.conf
If you wanted to dynamically alter the value of all semaphore kernel parameters without rebooting the machine, you can make this change directly to the /proc file system. This command can be made permanent by putting it into the /etc/rc.local startup file: # echo "250 32000 100 128" > /proc/sys/kernel/sem
You can also use the sysctl command to change the value of all semaphore settings: # sysctl -w kernel.sem="250 32000 100 128"

Configuring Shared Memory in Oracle

Configuring Shared Memory
The Oracle database uses shared memory in UNIX to allow processes to access common data structures and data. These data structures and data are placed in a shared memory segment to allow processes the fastest form of Interprocess Communications (IPC) available. The speed is primarily a result of processes not needing to copy data between each other to share common data and structures - relieving the kernel from having to get involved.
Oracle uses shared memory in UNIX to hold its Shared Global Area (SGA). This is an area of memory within the Oracle instance that is shared by all Oracle backup and foreground processes. It is important to size the SGA to efficiently hold the database buffer cache, shared pool, redo log buffer as well as other shared Oracle memory structures. Inadequate sizing of the SGA can have a dramatic decrease in performance of the database.
To determine all shared memory limits you can use the ipcs command. The following example shows the values of my shared memory limits on a fresh RedHat Linux install using the defaults: # ipcs -lm
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1Let's continue this section with an overview of the parameters that are responsible for configuring the shared memory settings in Linux.
SHMMAX
The SHMMAX parameter is used to define the maximum size (in bytes) for a shared memory segment and should be set large enough for the largest SGA size. If the SHMMAX is set incorrectly (too low), it is possible that the Oracle SGA (which is held in shared segments) may be limited in size. An inadequate SHMMAX setting would result in the following: ORA-27123: unable to attach to shared memory segment
You can determine the value of SHMMAX by performing the following: # cat /proc/sys/kernel/shmmax
33554432As you can see from the output above, the default value for SHMMAX is 32MB. This is often too small to configure the Oracle SGA. I generally set the SHMMAX parameter to 2GB.