Sometimes it's necessary to determine certain characteristics of your server. For example, you might have the task of installing the Oracle database binaries, and before you download and install this software, you need to know the system architecture and operating system version of the target Linux box.

Use the uname (print system information) tool to display system details. This example uses the -a option to print all the information:

$ uname -a
Linux dv2.rmug.org 2.6.9-55.0.6.ELsmp #1 SMP Tue Sep 4 21:36:00 EDT 2007 i686 i686
i386 GNU/Linux

The previous output shows the kernel name (Linux), hostname (dv2.rmug.org), kernel release (2.6.9-55.0.6.ELsmp), kernel build (#1 SMP Tue Sep 4 21:36:00 EDT 2007), name of hardware (i686), processor type (i686), hardware platform (i386), and operating system (GNU/Linux).

In today's global environment, you'll often find yourself connecting remotely to database servers located in dispersed data centers. In these situations, you'll find yourself constantly using the uname command with the -a option to verify what machine you're logged on to. Use the --help parameter to display all the choices available with uname in your environment:

$ uname --help
Usage: uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.
  -a, --all                print all information, in the following order:
  -s, --kernel-name        print the kernel name
  -n, --nodename           print the network node hostname
  -r, --kernel-release     print the kernel release
  -v, --kernel-version     print the kernel version
  -m, --machine            print the machine hardware name
  -p, --processor          print the processor type
  -i, --hardware-platform  print the hardware platform
  -o, --operating-system   print the operating system
      --help     display this help and exit
      --version  output version information and exit

From the prior output, if you wanted to view only the kernel release version of your Linux server, you can use the -r option of the uname command, as shown here:

$ uname -r
2.6.9-55.0.6.ELsmp

In a Linux environment, you can also view server information by querying the virtual files in the /proc directory. For example, you can view the current version of the server by viewing the /proc/version file:

$ cat /proc/version
Linux version 2.6.9-55.0.6.ELsmp ([email protected]) (gcc
version 3.4.6 20060404 (Red Hat 3.4.6-8)) #1 SMP Tue Sep 4 21:36:00
EDT 2007

Interestingly, some utilities such as top and free extract information from the /proc virtual files and present it in a human-readable formatted fashion. Table 9-1 describes some of the virtual files in the /proc directory. Use your favorite file-viewing utility (cat, more, less, view, grep, and so on) to inspect these virtual files.

The Oracle installation documentation recommends installing the binaries on a server with powerful CPUs. You want to display the CPU characteristics on your Linux server.

You can quickly obtain in-depth information about the physical characteristics of the CPU(s) on a Linux server by viewing the virtual /proc/cpuinfo file:

$ cat /proc/cpuinfo

For multiple processor boxes, there will be a section in the output for each CPU. The first CPU on the box is identified as 0 and the next one as 1, and so on. Here's a partial listing of some typical output from /proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.66GHz
stepping        : 5
cpu MHz         : 2667.494
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1

Sometimes you need to know whether the CPUs on your box are powerful enough to handle the database software being installed. If you have multiple CPUs on your server, then you'll see a listing for each CPU. Use the information in the /proc/cpuinfo file to determine whether your server meets Oracle's prerequisites for CPU minimum megahertz speed (this is usually the cpu MHz line in the /proc/cpuinfo file).

Oracle's installation documentation recommends you have a certain minimal amount of memory installed on the Linux server. You want to verify you have enough memory on a box before you do a database installation.

With Linux, you can view the contents of the /proc/meminfo file with grep to check the total physical memory amount:

$ grep MemTotal /proc/meminfo
MemTotal:      2074904 kB

To view the total amount of swap memory, issue the following grep command:

$ grep SwapTotal /proc/meminfo
SwapTotal:     4184924 kB

When dealing with database servers, you have to be aware of two types of memory: physical RAM and virtual (swap). Depending on the software you install on a box, you are sometimes required to check to see whether there is sufficient RAM and swap memory on the target server. If you don't have enough physical or swap memory, usually the Oracle Universal Installer will alert you as to any inadequacies when attempting to perform the installation.

You can also view physical and swap memory by issuing the free command with no options. This command gives you a view of the currently free and consumed memory on the box:

$ free
             total       used       free     shared    buffers     cached
Mem:       2074904    2050512      24392          0      84704    1759792
-/+ buffers/cache:     206016    1868888
Swap:      4184924      74652    4110272

Additionally, if you want to view per-process memory consumption, use the following cat commands:

$ cat /proc/<PID>/maps
$ cat /proc/<PID>/status

# dd if=/dev/zero of=tempswap bs=1k count=1000000
# chmod 600 tempswap
# mkswap tempswap
# swapon tempswap

# swapon -s

# swapoff tempswap
# rm tempswap

You're installing database binaries on a new Linux server and need to modify some kernel parameters per the installation documentation. Before you make the change, you first want to view all kernel parameters.

Run the following grep command as root to view the current kernel settings in the /proc/sys/kernel directory:

# grep . /proc/sys/kernel/*

The previous command instructs grep to print all strings contained in files located in the /proc/sys/kernel directory. Here is a partial listing of the output:

/proc/sys/kernel/real-root-dev:0
/proc/sys/kernel/sem:250        32000   100     128
/proc/sys/kernel/shmall:2097152
/proc/sys/kernel/shmmax:536870912
/proc/sys/kernel/shmmni:4096
/proc/sys/kernel/suid_dumpable:0
/proc/sys/kernel/sysrq:0
/proc/sys/kernel/tainted:0
/proc/sys/kernel/threads-max:32750

You can also use grep to filter for a particular setting. The next example searches for the string sem in any files in the /proc/sys/kernel directory:

# grep . /proc/sys/kernel/* | grep sem
/proc/sys/kernel/sem:250        32000   100     128

If you want to save all the current kernel values in a file, then pipe the output of the grep command to a file:

# grep . /proc/sys/kernel/* >jul11_kernel_parms.txt

Another way to display all kernel parameters is via the sysctl utility. This utility allows you to view and modify the kernel files found in the /proc/sys directory. Use the -a option of sysctl to view all kernel parameters:

# sysctl -a

Here is a small snippet of the large output of the previous command:

kernel.sysrq = 0
kernel.sem = 250        32000   100     128
kernel.msgmnb = 16384
kernel.msgmni = 16
kernel.msgmax = 8192
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.acct = 4 2       30
kernel.hotplug = /sbin/hotplug

You can save the output of the sysctl -a command to a text file, as shown here:

# sysctl -a > /root/kernelsysctl.txt

Inspect the output of the sysctl -a command. Notice that the kernel values are either a single value or an array of values. When just a single value is involved, it's fairly easy to determine the setting of the parameter. For example, from the output of sysctl -a, the maximum setting for shared memory (shmmax) is 536,870,912 bytes:

kernel.shmmax = 536870912

When the kernel settings are stored as an array, it becomes a bit more difficult to determine a particular value. For example, this array of four values shows the current kernel settings for sem (semaphores):

kernel.sem = 250   32000   100     128

When working with array values, it's important to know what element of the array maps to what kernel setting. In the previous output, the values of the semaphore array 250 32000 100 128 map to the following kernel parameters, respectively, semmsl, semmns, semopm, and semmni. For example, semmsl is set to 250 and defines the maximum number of semaphores in a semaphore array. The meanings of these semaphore parameters are discussed in detail in recipe 9-6 of this chapter.

You're performing a database installation. The Oracle documentation specifies the recommending settings for several kernel parameters. You want to modify these kernel parameters.

There are several valid techniques for changing kernel parameters:

These methods are detailed in the next several sections.

# sysctl -w kernel.sem="250 32000 100 128"

error: 'kernel.sem' must be of the form name=value
error: Malformed setting '='
error: '250 32000 100 128' must be of the form name=value

# vi /etc/sysctl.conf
# Add changes and then exit...

# sysctl -p

# cp /etc/sysctl.conf  /etc/sysctl.conf.01_jan_08

# echo 250 32000 100 128 > /proc/sys/kernel/sem

kernel.sem = 250 32000 100 128

# echo "kernel.sem = 250 32000 100 128" >> /etc/sysctl.conf

kernel.sem = 500 64000 200 500
kernel.sem = 250 32000 100 128

# sysctl -p

# cat >> /etc/sysctl.conf <<EOF
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144
EOF

# sysctl -p

One advantageous feature of Linux is that you can dynamically change many of the kernel settings while the system is running. The parameters take effect as soon as you change them, and you are not required to reboot the system. This is different from many other operating systems that require a server reboot for kernel changes to become instantiated.

The /proc/sys directory contains virtual files that correspond to kernel settings. You can change the /proc/sys files to dynamically configure kernel values. Hundreds of parameters exist that you can modify. Run the following find command to give you a rough idea of how many kernel files there are with your version of Linux:

# find /proc/sys -type f | wc -l
448

Not all virtual files in the /proc/sys directory can be modified. One quick way to determine whether a /proc/sys file can be altered is to check the permissions. Any file that shows the writable permission can be changed. This example uses the ls -altr command to view the /proc/sys/kernel file permissions:

# ls -altr /proc/sys/kernel

Here is a partial listing of the output. Notice that the first two files are not modifiable, but the last three can be modified (signified by the w write permission).

-r--r--r--   1 root root 0 Sep  4 16:32 version
-r--r--r--   1 root root 0 Sep  4 16:32 tainted
-rw-r--r--   1 root root 0 Sep  4 16:32 shmmni
-rw-r--r--   1 root root 0 Sep  4 16:32 shmmax
-rw-r--r--   1 root root 0 Sep  4 16:32 shmall

The Oracle installation documentation recommends configuring the system semaphores to certain minimal values. Before you modify the settings, you want to view the semaphore parameters.

You can view semaphore information by displaying the contents of the /proc/sys/kernel/sem file. This example uses the cat command to view semaphore data (you don't have to be root to view these values):

$ cat /proc/sys/kernel/sem
250     32000   100     128

Notice that there are four values listed for semaphores in the previous output. Those numbers represent the value for the following semaphore kernel parameters: semmsl, semmns, semopm, and semmni, respectively. For example, the semmsl value is currently 250, semmns is 32000, and so forth.

Before making changes to any kernel information, it's prudent to first view the current values. Table 9-2 details the meanings of the relevant Linux semaphore variables. Notice that all semaphore variable names aptly begin with the letters sem. These semaphore names may vary slightly depending on which version of the Linux/Unix operating system you're using.

Semaphores are locking mechanisms that are used to coordinate mutually exclusive access to sharable system resources. Semaphores act as gatekeepers to ensure that particular shared system resources are not accessed by multiple processes at the same time. Databases use semaphores to manage access to operating system resources such as shared memory.

Database background processes require semaphores to manage mutually exclusive access to shared resources. If there aren't enough semaphores available for all database processes, this could cause the database to not start or cause a runtime failure. If there are any semaphore-related problems, it's critical that DBAs know how to view and configure these kernel parameters.

You're installing Oracle software on a database server and need to modify the semaphore settings.

Before beginning, first check the current values in case they need to be referenced later. To view the current semaphore settings, use the cat command:

# cat /proc/sys/kernel/sem
250     32000   32      128

As noted in Table 9-2, the values in the previous output represent the settings for the following semaphore parameters in this order: semmsl, semmns, semopm, and semmni.

This next example uses the echo command to increase the maximum number of semaphore arrays (semmni) from 128 to 256:

# echo 250 32000 100 256 > /proc/sys/kernel/sem

After you change the semaphore settings, it's a good idea to use the cat command to verify that the changes took place:

# cat /proc/sys/kernel/sem
250     32000   100     256

If you want the changes to persist across a system reboot, then ensure that you modify the /etc/sysctl.conf file appropriately. In this example, an editor (like vi) is used to add the following entry to the /etc/sysctl.conf file:

kernel.sem = 250 32000 100 256

The Oracle installation documentation indicates you need a minimal amount of memory installed on the Linux box to run the database. You want to view the database server memory settings.

All the shared memory parameters appropriately begin with the string shm. Use the ls (list) command with the −1 (that's a number one) option to display which shared memory parameters are available on your Linux system:

$ ls −1 /proc/sys/kernel/shm*

You should see output similar to this:

/proc/sys/kernel/shmall
/proc/sys/kernel/shmmax
/proc/sys/kernel/shmmni

Next use the cat command to view individual shared memory settings. This example shows how to view the maximum size (in bytes) of a shared memory segment (shmmax) that can be created:

$ cat /proc/sys/kernel/shmmax
2147483648

Table 9-3 describes the shared memory parameters. Some of these parameters may not be updatable on your particular Linux system.

If you want to view the currently allocated shared memory segments, use the -m option of the ipcs command. This next example shows the shared memory segments in use on a server running an Oracle database:

$ ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0xb3e36378 131072     oracle    640        421527552  17

Correctly sizing and configuring shared memory are important DBA tasks when building a new database server. Databases use shared memory as a holding area for data read from disk. Database processes read and modify the data held in shared memory. The shared memory area uses semaphores (described in Table 9-2) to control exclusive access to memory segments.

A database will fail to start if there is not enough shared memory available to be allocated. Therefore, it's paramount that DBAs know how to manage shared memory because it has a direct impact on database availability and performance. These tasks are described in detail in recipe 9-9.

You're installing Oracle software on a database server and need to modify the shared memory configuration.

You can use any of the techniques described in recipe 9-5 for changing the kernel parameters. This solution uses the echo command to modify the maximum shared memory segment size to approximately 500MB:

# echo 536870912 > /proc/sys/kernel/shmmax

The previous command will take effect immediately (without a system reboot). Use the cat command to verify the change:

# cat /proc/sys/kernel/shmmax
536870912

If you want the changes to persist across system reboots, then make sure you add them to the /etc/sysctl.conf file:

kernel.shmmax = 536870912

Before making on-the-fly changes to shared memory, it's a good idea to first view the overall amount of physical memory available on the box. You probably don't want to set your maximum shared memory size to a value that exceeds the total memory available on the server. Use the cat command with grep to view the contents of the virtual /proc/meminfo file, as shown here:

# cat /proc/meminfo | grep -i memtotal
MemTotal:      2057876 kB

The previous output shows that there are a total of 2GB of physical memory available on this server. If you don't filter the contents of /proc/meminfo with the grep command, then you will be presented with all the server memory information.

After you're comfortable with the overall size of physical memory on the box, you can change the shared memory settings by using either the echo command or the sysctl utility. On most Linux systems there are three memory parameters of interest: shmall, shmmax, and shmmni (see Table 9-3 for descriptions of these parameters).

Your database has experienced a hard crash. You want to see whether there are any database-related memory structures that are still physically allocated on the server.

Use the ipcs (interprocess communication status) command without any options to view the current allocated physical memory, semaphores, and message queues:

$ ipcs

Here is some typical output:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0xb3e36378 131072     oracle    640        421527552  17
------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x288e2800 1146880    oracle    640        126
0x288e2801 1179649    oracle    640        126
0x288e2802 1212418    oracle    640        126
0x288e2803 1245187    oracle    640        126
0x288e2804 1277956    oracle    640        126
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

The prior output has three sections. The oracle user has 421,527,552 bytes of shared memory allocated. There are five semaphore arrays allocated with 126 semaphores per array. There are no message queues allocated.

The "Solution" section of this recipe demonstrates how to view in-memory structures currently allocated. To view the system limits imposed on memory and semaphores, use the -lms options of the ipcs command:

$ ipcs -lms
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 2097152
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 100
semaphore max value = 32767

Compare the maximum memory values to the settings in the /proc/sys/kernel directory:

$ cat /proc/sys/kernel/shmall
2097152
$ cat /proc/sys/kernel/shmmax
2147483648
$ cat /proc/sys/kernel/shmmni
4096

Notice that the maximum total shared memory available to oracle is the product of the maximum number of segments (4,096) and the maximum size per segment (2,147,483,648).

To view all the options available with the ipcs command, use the -h (help) option:

$ ipcs -h
ipcs provides information on ipc facilities for which you have read access.
Resource Specification:
        -m : shared_mem
        -q : messages
        -s : semaphores
        -a : all (default)
Output Format:
        -t : time
        -p : pid
        -c : creator
        -l : limits
        -u : summary
-i id [-s -q -m] : details on resource identified by id
usage : ipcs -asmq -tclup
        ipcs [-s -m -q] -i id
        ipcs -h for help.

Your database unexpectedly crashed, and for some reason the semaphores and shared memory have not been released. Other databases are running on the server, so you cannot reboot the system to release the shared memory objects. You want to manually remove these orphaned memory structures.

First view the structures to be removed with the ipcs -sm command:

$ ipcs -sm

On this server there are two instances of Oracle running, each with one allocated shared memory segment and five sets of semaphore arrays:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0xb3e36378 32768      oracle    640        421527552  16
0x34525e84 65537      oracle    640        421527552  11

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x288e2800 360448     oracle    640        126
0x288e2801 393217     oracle    640        126
0x288e2802 425986     oracle    640        126
0x288e2803 458755     oracle    640        126
0x288e2804 491524     oracle    640        126
0x3239d0e4 622597     oracle    640        126
0x3239d0e5 655366     oracle    640        126
0x3239d0e6 688135     oracle    640        126
0x3239d0e7 720904     oracle    640        126
0x3239d0e8 753673     oracle    640        126

If you have multiple databases on one server, first verify which memory structures belong to the orphaned instance by running the Oracle sysresv utility (located in the ORACLE_HOME/bin directory). This command reports on memory structures that correspond to your current instance setting of ORACLE_SID. Run this command as the owner of the Oracle binaries (usually oracle):

$ sysresv

Here is the pertinent output:

IPC Resources for ORACLE_SID "RMDB2" :
Shared Memory:
ID              KEY
65537           0x34525e84
Semaphores:
ID              KEY
622597          0x3239d0e4
655366          0x3239d0e5
688135          0x3239d0e6
720904          0x3239d0e7
753673          0x3239d0e8

You can remove memory objects either by the key or by ID. This next example uses the -m option to remove a shared memory segment by its ID:

$ ipcrm -m 65537

This next example uses the -s option to remove semaphore arrays using IDs:

$ ipcrm -s 622597
$ ipcrm -s 655366
$ ipcrm -s 688135
$ ipcrm -s 720904
$ ipcrm -s 753673

You can verify that the memory structures have been removed by running sysresv again:

$ sysresv
IPC Resources for ORACLE_SID "RMDB2" :
Shared Memory
ID              KEY
No shared memory segments used
Semaphores:
ID              KEY
No semaphore resources used
Oracle Instance not alive for sid "RMDB2" 

The ipcrm command uses either the key or the ID as its input for identifying what IPC object to remove. The basic syntax for using ipcrm is as follows:

$ ipcrm [ -M key | -m id | -Q key | -q id | -S key | -s id ]

In the previous syntax description, -M is used with a shared memory key, -m is used with a shared memory ID, -S is used with a semaphore key, and -s is used with a semaphore ID.

You may run into an occasional scenario where you have a database crash and for some reason the database semaphores or shared memory structures have not been released properly by the operating system. In these rare situations (if you don't have the luxury of rebooting the server), you will have to first identify the unreleased memory object with the ipcs and sysresv commands and then remove it with the appropriate ipcrm command.

The Oracle documentation recommends setting some network parameters to minimal values. You first want to inspect the current network settings.

The virtual /proc network files are usually located either in /proc/sys/net/core or in /proc/sys/net/ipv4. By using the ls -altr command, you can see that most of the virtual network files in /proc/sys/net/core are updatable:

# ls -altr /proc/sys/net/core
total 0
-rw-r--r--  1 root root 0 Sep  4 16:54 wmem_max
-rw-r--r--  1 root root 0 Sep  4 16:54 wmem_default
-rw-r--r--  1 root root 0 Sep  4 16:54 somaxconn
-rw-r--r--  1 root root 0 Sep  4 16:54 rmem_max
-rw-r--r--  1 root root 0 Sep  4 16:54 rmem_default
-rw-r--r--  1 root root 0 Sep  4 16:54 optmem_max
-rw-r--r--  1 root root 0 Sep  4 16:54 no_cong_thresh
-rw-r--r--  1 root root 0 Sep  4 16:54 no_cong
-rw-r--r--  1 root root 0 Sep  4 16:54 netdev_max_backlog
-rw-r--r--  1 root root 0 Sep  4 16:54 mod_cong
-rw-r--r--  1 root root 0 Sep  4 16:54 message_cost
-rw-r--r--  1 root root 0 Sep  4 16:54 message_burst
-rw-r--r--  1 root root 0 Sep  4 16:54 lo_cong
-r--r--r--  1 root root 0 Sep  4 16:54 divert_version
-rw-r--r--  1 root root 0 Sep  4 16:54 dev_weight

Use the cat command to view a particular virtual network file. This example uses cat to display the current setting for the rmem_default kernel parameter:

# cat /proc/sys/net/core/rmem_default
262144

To view a complete listing of network settings, use the sysctl command and grep for the string net:

# sysctl -a | grep -i net

You'll be presented with a great deal of output. Table 9-4 lists some of the network kernel parameters that you may have to modify for database servers.

$ cat /etc/hosts

127.0.0.1               localhost.localdomain localhost
177.22.33.89            db123.cent.com   db123

You're installing database software on a Linux server, and the Oracle documentation indicates you need to configure some network parameters.

Use the echo command to update the /proc/sys/net/ipv4/ip_local_port_range file. This example uses the echo command to change the first local port allowed for TCP and UPD traffic to 1024 and the last local port to 65000:

# echo  1024 65000 > /proc/sys/net/ipv4/ip_local_port_range

You can verify the changes with the cat command:

# cat  /proc/sys/net/ipv4/ip_local_port_range
1024    65000

You need to add these entries to the /etc/sysctl.conf file to have the changes persist across system reboots. Here's a sample entry in the /etc/sysctl.conf file:

net.ipv4.ip_local_port_range=1024 65000

Before changing any network kernel parameters, make sure you first save a copy of the original values somewhere. This will allow you to change back to the old values in the event the new values cause undesirable results. In the next example, the value of the ip_local_port_range is first viewed with the cat command:

$ cat  /proc/sys/net/ipv4/ip_local_port_range
32768    61000

The Oracle installation documentation recommends setting the system-wide open file limit for the server. You want to enable this restriction.

Use the echo command or the sysctl command to dynamically modify the /proc/sys/fs/file-max value. This next example uses the echo command to change the file-max value on the fly to 65536:

# echo 65536 > /proc/sys/fs/file-max

Use the cat command to verify that the change took place:

# cat /proc/sys/fs/file-max
65536

Here's an example of using sysctl -w to modify the maximum open file limit:

# sysctl -w fs.file-max=65536

Remember to add an entry to the /etc/sysctl.conf file to make the changes persist across system reboots.

Linux imposes a limit on the overall number of files simultaneously open on the server. Servers that host database applications tend to have many simultaneously open files. If the default value for the maximum number of open files is too low, you most likely will have to increase it. You'll know that you've hit the maximum limit on the number of open files if you start seeing errors pertaining to "running out of file handles."

This maximum open file limit is governed by the Linux kernel /proc/sys/fs/file-max virtual file. You can also view the maximum number of file handles by viewing the contents of the /proc/sys/fs/file-nr virtual file:

# cat /proc/sys/fs/file-nr
885 0 65536

The previous output shows the current number of allocated file handles, the number of free file handles, and the maximum number of file handles, respectively.

You want to view system resource limits instantiated by your logon shell.

By default, the -a (all) option of the ulimit command will print the current soft limits for a process:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
pending signals                 (-i) 1024

max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 10000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 16375
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

The previous output displays the parameter, the units of measurement, the option used to manipulate the parameter, and its current setting. To view the hard limit resources, use the ulimit -aH command. If you want to view a soft or hard limit for a particular setting, specify its option. For example, to display the hard limit for the number of open files, use the -Hn option:

$ ulimit -Hn
20000

Your logon shell will impose default maximum limits on various resources that a process can use such as the number of open files, processes per user, amount of memory allocated, and so on. These shell limits are defined by the ulimit command. Each resource has a soft limit setting and a hard limit setting. The soft limit setting establishes the default resource limit when a user logs on to the system. If the user process exceeds the soft limit setting for a resource, an error will be thrown. The user can manually increase the setting of the soft limit setting for a resource up to (but not exceeding) the value defined by the hard limit.

A user can modify the hard limit down but cannot modify the hard limit up. This means if you set a hard limit to a lower value, you cannot reset it to its original value. Only the root user can modify a hard limit to a higher value.

The default values for soft and hard limits on the server are established by adding entries into the /etc/security/limits.conf file. Database processes tend to consume more resources than what the default shell limits allow. Therefore, it's important you're familiar with viewing and modifying shell resource limits.

You're performing an Oracle installation on a new server and need to modify the shell limits per the installation instructions.

To alter the default shell limits for a user, as root edit the /etc/security/limits.conf file. This example shows how to change the number of processes and number of open files defined for the oracle user:

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

In the previous output, the first line defines the soft limit for the number of processes for the oracle user to 2047, and the second line sets the hard limit for the number of processes to 16384. The third and fourth lines set the soft and hard limits for the number of open files for the oracle user, respectively. These limits will be imposed on the oracle user when logging onto the server.

The ulimit command provides a way to view and limit resources used by a shell and the resources of subprocesses started by a shell. As a non-root user, you can change your soft limits up to the value defined by the hard limit. As the root user, you can modify hard limits to higher values.

For example, to adjust the soft limit of the number of open files to 15000, issue the following:

$ ulimit -Sn 15000

To view the change, then issue the command without a value:

$ ulimit -Sn
15000

If you exceed the value defined by the hard limit, you'll receive an error such as the following:

-bash: ulimit: open files: cannot modify limit: Invalid argument

When you add entries to the /etc/security/limits.conf file, this sets the default shell limit for the user process when they log on to the system. Table 9-5 shows the meanings of values you can change in /etc/security/limits.conf file.

When working with database applications, you may not want to ever have a database process constrained by a soft limit. Rather, you want only the hard limit to govern the amount of resources a database process uses. In this case, you can set the soft limit equal to the hard limit in the database user login profile file. For example, if the oracle user on your Linux box uses the Bash shell, then you would modify the .bash_profile login file (see recipe 2-5 for further details). The following entries are added to the oracle user's .bash_profile file to establish the soft limits equal to the hard limits:

ulimit -u 16384
ulimit -n 65536

When using the ulimit command, if you don't denote an -S (soft) or -H (hard) option, then this sets both the soft and hard limits to the value specified. Whenever the oracle user logs on, the soft and hard limits for the number of processes will be 16384, and the soft and hard limits for the number of open files will be 65536.

If you write an entry into the logon file that exceeds the hard limit, the user will receive an error such as this at logon time:

-bash: ulimit: open files: cannot modify limit: Operation not permitted