As part of normal operations, Oracle database processes constantly coordinate and communicate with system server processes. In Linux, this type of process-to-process coordination is referred to as interprocess communication (IPC). Linux supports three types of interprocess communication mechanisms: semaphores, shared memory, and message queues. Oracle database applications typically require significant amounts of semaphore and shared memory resources to function properly. This chapter focuses on how to view and manage these critical system resources.
A semaphore is a construct used by the operating system to control what processes can have access to other server resources such as shared memory. The amount of operating system resources that a database application can consume is governed by several kernel parameters. Maintaining these values is described in detail in this chapter.
The kernel is the core program of the operating system that manages access to operating system resources required by other processes on the system. The kernel is typically responsible for process, CPU, memory, and disk management activities.
Nowadays, just about any medium to large database can quickly exceed the default kernel settings for system resource limits. Therefore, most database vendors (Oracle, MySQL, DB2, PostgreSQL, and so on) have their own set of recommended values for the kernel parameters that govern the various required operating system resources.
Before you can install a database on a Linux server, it's prudent to first ensure that the kernel parameters are configured correctly. An incorrectly configured kernel usually results in either a nonoperative or poorly performing database. For example, when starting Oracle, if enough shared memory can't be allocated, then an error message like this will be thrown:
ORA-27123: unable to attach to shared memory segment
That's not good. Your boss will not be impressed. To avoid problems like this, a knowledgeable DBA must know how to view and set kernel parameters that impact database availability and performance. This chapter begins with a high-level overview of how to examine and modify kernel parameters and then dives into specific details for settings most critical for database applications.
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.
Table 9.1. Descriptions of Virtual Files in the /proc
Directory
File Name | Contains Information Regarding |
---|---|
| CPU and system architecture. |
| Free and used memory for both physical RAM and swap. |
| Directory containing network information. |
| All mounted filesystems. |
| Disk I/O statistics for each disk. |
| PCI devices. |
| Filesystems compiled into the kernel. |
| Contains subdirectories and files pertaining to kernel variables. Some variables can be configured with the |
| Parameters passed to the kernel at boot time. |
| Version of the operating system. |
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
See Oracle's MetaLink Note 233753.1 for a detailed discussion of /proc/meminfo
.
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
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 view many files in the /proc
virtual filesystem as a non-root
account. However, you will need root
access to view all virtual files.
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:
Running sysctl
Editing sysctl.conf
Adding entries with echo
Adding entries with cat
These methods are detailed in the next several sections.
Use the sysctl
command with the -w
option to dynamically modify kernel parameters. The following command changes the kernel semaphore settings in the /proc/sys/kernel/sem
virtual file:
# sysctl -w kernel.sem="250 32000 100 128"
Notice there are no spaces around the =
sign. If you attempt to run the sysctl
command with spaces around the =
sign, you will receive an error like the following:
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
To make changes persist across system reboots, use your favorite editor (like vi
) to add the parameters to the /etc/sysctl.conf
file.
Use the man sysctl
or sysctl --help
command for all options available in your environment.
You can also directly modify the /etc/sysctl.conf
file and then use the sysctl -p
command to make desired kernel parameter changes. This example uses vi to first edit the /etc/sysctl.conf
file:
# vi /etc/sysctl.conf # Add changes and then exit...
After you modify the /etc/sysctl.conf
file, you can use the sysctl -p
command to make the entries in the /etc/sysctl.conf
file instantiated as the current values used by the Linux kernel:
# sysctl -p
The previous command loads into memory the values found in the /etc/sysctl.conf
file. You can verify that the values were changed by using cat
to view the corresponding virtual file.
When editing the sysctl.conf
file, we recommend you first make a copy of the file with the date embedded into the file name. For example, before making any changes, create a copy of the file, as shown here:
# cp /etc/sysctl.conf /etc/sysctl.conf.01_jan_08
Making a copy serves two purposes. First, it provides you with a copy of the parameters as they were before the change. This comes in handy if for any reason you want to revert to the previous settings. Second, this also gives you an audit trail of all kernel changes made via this file. You can then use commands like diff
to display differences in file versions (see recipe 5-14 for details).
You can use the echo
command to write the desired output to the specified virtual file. This example writes the values 250 32000 100 128
to the virtual /proc/sys/kernel/sem
file using the echo
command:
# echo 250 32000 100 128 > /proc/sys/kernel/sem
The previous command immediately changes the kernel settings for the sem
(semaphores) parameter. If you want the change to persist across system reboots, then you also need to add an entry to the /etc/sysctl.conf
file. This file is read when the system boots to determine the settings for kernel parameters. You can edit the /etc/sysctl.conf
file directly (with an editor such as vi
) and add the following line:
kernel.sem = 250 32000 100 128
Alternatively, you can use the echo
command to add the desired parameters to the end of the /etc/sysctl.conf
file, as shown here:
# echo "kernel.sem = 250 32000 100 128" >> /etc/sysctl.conf
Notice that the previous command uses >>
to concatenate the desired entry to the bottom of the /etc/sysctl.conf
file. You would not want to use just a single right arrow >
, because that would overwrite the contents of /etc/sysctl.conf
.
When you use echo
and >>
to write to the contents of the /etc/sysctl.conf
file, no checks are performed to determine whether the kernel parameters you are writing to the file already exist. The echo
and >>
technique simply adds the values to the bottom of the file.
If there happen to be two entries in the /etc/sysctl.conf
file that configure the same kernel parameter, the value that appears nearest to the bottom of the file will be the one that gets set. This is because the parameters are processed from top to bottom. For example, say you have the following two lines in the /etc/sysctl.conf
file:
kernel.sem = 500 64000 200 500 kernel.sem = 250 32000 100 128
The bottom line in the previous listing will be set last and therefore will dictate the kernel setting for the kernel.sem
value.
After you use echo
to write to the /etc/sysctl.conf
file, you can use the sysctl -p
command to make the entries in the /etc/sysctl.conf
file instantiated as the current values used by the Linux kernel:
# sysctl -p
The technique shown here is handy for adding several entries to the /etc/sysctl.conf
file at the same time. First use the cat
command to add entries to the /etc/sysctl.conf
file. This example shows how to use cat
to write typical kernel parameter settings for an Oracle database:
# 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
The previous command uses cat
to write to the /etc/sysctl.conf
file all the values encapsulated between the two EOF markers. This allows you to add several parameters simultaneously to the /etc/sysctl.conf
file. When using cat
and >>
to write parameters to the /etc/sysctl.conf
file, there is no automatic checking to determine whether the parameters already exist in the file. Using cat
and >>
will simply write to the bottom of the file.
After the desired changes are made, use the sysctl -p
command to make the entries in the /etc/sysctl.conf
file the current values used by the Linux kernel, as shown here:
# 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
Be careful when modifying kernel values. Modifying a kernel parameter to an unusable value can cause the system to become unstable and require a restart with the boot disk.
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.
Table 9.2. Semaphore Kernel Parameters and Descriptions
IPC Semaphore Parameter | Description |
---|---|
| Maximum number of semaphores per set (array) |
| Maximum number of semaphores on entire system |
| Maximum operations for |
| Maximum number of semaphore arrays on entire system |
| Maximum value of a semaphore |
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.
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
See recipe 9-5 for alternate ways of changing kernel parameters.
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
Refer to Oracle's installation documentation for recommended settings of semaphores for your version of Oracle and Linux.
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.
Table 9.3. Shared Memory Kernel Parameter Descriptions
IPC Shared Memory Parameter | Description |
---|---|
| Maximum size (in bytes) for shared memory segment |
| Minimum size (in bytes) of shared memory segment |
| Total amount of shared memory (in bytes or pages) that can be used at any time |
| Maximum number of shared memory segments per process |
| Maximum number of shared memory segments for the entire 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
Refer to Oracle's installation documentation for recommended settings for shared memory parameters for your version of Oracle and Linux.
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).
The shmmax
parameter can have a significant impact on database performance. With Oracle databases, this parameter should be set to a value higher than the SGA size. If the shmmax
value is too small, then you may not be able to start your Oracle instance.
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're working on a server that has multiple Oracle instances running, ensure that you remove the correct memory structure. If you remove the wrong structure, you will inadvertently crash another database.
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.
Table 9.4. Network Kernel Parameter Descriptions
Network Kernel Parameter | Location | Description |
---|---|---|
|
| Default socket receive buffer size (in bytes) |
|
| Default socket send buffer size (in bytes) |
|
| Maximum socket receive buffer size (in bytes) |
|
| Maximum socket send buffer size (in bytes) |
|
| Number of seconds a connection is idle before TCP starts sending keep-alive probes |
|
| Interval (in seconds) between keep-alive probes |
|
| Number of unacknowledged probes sent before connection is terminated |
|
| Number of times TCP will attempt to transmit packet normally |
|
| Maximum number of times a TCP will attempt to transmit a packet |
|
| Maximum number of SYNs attempts to transmit |
|
| Ports allowed for TCP and UDP traffic |
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
Refer to the Oracle installation documentation for recommended settings for network kernel parameters for your version of Oracle and Linux.
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.
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.
The Bash, Bourne, and Korn shells use the ulimit
command to view and modify shell resource limits. If you are using the C shell, then use the limit
command.
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.
Do not set the hard limit for a user resource to be higher than the system-wide limit. In particular, don't set the hard limit for the number of open files to be higher than the value defined in the /proc/sys/fs/file-max
virtual file. If a process is able to open the maximum number of files that reaches the system-wide setting, this causes the system to run out of open files and could cause the system to become unstable. Not good.
The ulim
it 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.
Table 9.5. Description of Limits Set via /etc/security/limits.conf
Virtual File
Parameter | Limits |
---|---|
| Core file size (in KB) |
| Maximum data size (in KB) |
| Maximum filesize (in KB) |
| Maximum locked in memory address space (in KB) |
| Maximum number of open files |
| Maximum resident set size (in KB) |
| Maximum stack size (in KB) |
| Maximum CPU time (in minutes) |
| Maximum number of processes |
| Address space limit |
| Maximum number of logins for user |
| Priority at which to run user process |
| Maximum number of locks for user |
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
The Bourne and Korn shells use the .profile
initialization file for setting parameters on logon. The C shell uses the .login
or .cshrc
file.