Stay organized with collections Save and categorize content based on your preferences.

Best practices for Oracle on Bare Metal Solution

When implementing Oracle databases on Bare Metal Solution, we know that your goal is to bring up your environment easily and with as few issues as possible. To help you succeed in this goal, we've gathered feedback from customers, our Solution Architects, and support staff who have implemented Oracle databases on Bare Metal Solution. The following information provides you with recommendations learned from these experts to help you be as successful as possible when bringing up your own Oracle database environment on Bare Metal Solution.

Software Deployment

For the most successful Oracle software deployment, we recommend that you use the Bare Metal Solution Toolkit. The toolkit provides several Ansible and JSON scripts to help you perform the Oracle software installation on Bare Metal Solution. For more information about the Bare Metal Solution Toolkit and how to install Oracle databases in a Bare Metal Solution environment, see the toolkit user guide.

Operating System

When setting up your operating system on a Bare Metal Solution server, we recommend you perform the following actions.

Validate your NTP servers

All Bare Metal Solution servers should be synchronized with a time source. Select an NTP server option, either physical or virtual, that best meets your needs.

When your servers use NTP for time synchronization, use the timedatectl or ntpstat command to see if the server is synchronized with a time source. The following examples show the output from these commands for a server that synchronizes successfully:

timedatectl show -p NTPSynchronized
NTPSynchronized=yes
synchronised to NTP server (216.239.35.8) at stratum 3
   time correct to within 49 ms
   polling server every 1024 s

Check your /etc/fstab settings for the correct mount options

To prevent the boot process from hanging, always configure the non-root mount points you create (such as /u01 and /u02) with the nofail mount option in place of the default settings. In rare cases, the underlying storage devices might not be available when a host restarts. Setting the nofail mount option allows the boot process to continue when the server cannot view the storage devices.

The following example shows the recommended settings for the /u01 and /u02 mount points in the /etc/fstab file:

/dev/mapper/3600a098038314352513f4f765339624c1 /u01 xfs nofail 0 0
/dev/mapper/3600a374927591837194d4j371563816c1 /u02 xfs nofail 0 0

You can modify the mount option from defaults to nofail without any impact to an operational system. However, to apply the new settings, you need to reboot your server.

Confirm your shell limit settings

The Bare Metal Solution toolkit configures shell limits needed to configure Oracle RAC. You can skip this validation if you used the Bare Metal Solution toolkit and didn't change the shell limits. Shell limits must be set for all operating system accounts that own Oracle software, including Grid Infrastructure. Oracle recommends the following settings for Linux:

Limit Soft Value Hard Value
Open files 1024 65536
Maximum user processes 16384 16384
Stack size 10240 32768
Maximum locked memory At least 90% of memory At least 90% of memory

Use the ulimit command to verify the soft and hard shell limits. For example, enter this command to verify the soft shell limit:

ulimit -S -n -u -s -l

The following output shows the correct soft shell limit settings for a system with 384GB of memory:

open files                      (-n) 1024
max user processes              (-u) 16384
stack size              (kbytes, -s) 10240
max locked memory       (kbytes, -l) 355263678

To verify the hard shell limits, use the following command:

ulimit -H -n -u -s -l

The following output shows the correct hard shell limits for a system with 384GB of memory:

open files                      (-n) 65536
max user processes              (-u) 16384
stack size              (kbytes, -s) 32768
max locked memory       (kbytes, -l) 355263678

If any of the shell limits are not set correctly, modify the entries in the /etc/security/limits.conf file, as shown in the following example:

oracle  soft  nofile  1024
oracle  hard  nofile  65536
oracle  soft  nproc   2047
oracle  hard  nproc   16384
oracle  soft  stack   10240
oracle  hard  stack   32768
oracle  soft  memlock 355263678
oracle  hard  memlock 355263678

grid    soft  nofile  1024
grid    hard  nofile  65536
grid    soft  nproc   2047
grid    hard  nproc   16384
grid    soft  stack   10240
grid    hard  stack   32768
grid    soft  memlock 355263678
grid    hard  memlock 355263678
grep MemTotal /proc/meminfo
MemTotal:       16092952 kB

Avoid changing your multipath settings

If you choose to change the multipath settings, do not configure the path_grouping_policy attribute if you use multipath.conf to create aliased names for devices. Such a change overrides the default policy set in the devices definition section.

Under normal operation, the multipath -ll command should show a status similar to the following example. Each device includes two active paths that are in the ready state.

3600a0980383143524f2b50476d59554e dm-7 NETAPP  ,LUN C-Mode
size=xxxG features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 14:0:3:2 sdf                8:80   active ready running
| `- 16:0:5:2 sdv                65:80  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 14:0:2:2 sdc                8:32   active ready running
  `- 16:0:3:2 sdq                65:0   active ready running

Oracle is a registered trademark of Oracle and/or its affiliates.