# Installation Guide for Linux This file contains the text from each Installation Guide for Linux article landing page, release 19c. # Changes in this Release for Oracle Database ## New Features Oracle Database 19c introduces Oracle Memory Speed support for persistent memory devices through an XFS-based, DAX-enabled file system; installer options to automate required root configuration scripts while retaining manual execution; and simplified image-based Oracle Database client installation, where extracted client images are installed using the runInstaller script. Read More: [New Features](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/changes-in-this-release-for-oracle-database/new-features.html) ## Deprecated Features Oracle Database 19c deprecates ASM Filter Driver on Linux and Oracle Solaris, with ASMFD filtering unsupported on Linux kernel 5.14 and later and ASMlib v3 recommended as an alternative; the clone.pl script, which is replaced by installer-based gold image deployment; the SERVICE\_NAMES parameter for all high-availability operations; and Oracle ACFS on IBM AIX, for which GPFS may be used for eligible files. ASMFD remains supported on Oracle Solaris until formal desupport. Read More: [Deprecated Features](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/changes-in-this-release-for-oracle-database/deprecated-features.html) ## Other Changes In Oracle Database 19c and Oracle Grid Infrastructure 19c, Rapid Home Provisioning is renamed Fleet Patching and Provisioning. Linux installation documentation now lists required operating system package names without exact versions; users should install the latest packages available from the minimum supported distribution, using only packages officially released by Oracle or the operating-system vendor. Read More: [Other Changes](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/changes-in-this-release-for-oracle-database/other-changes.html) # Oracle Database Installation Checklist Use checklists to review system requirements, and to plan and carry out Oracle Database installation. Oracle recommends that you use checklists as part of your installation planning process. Using checklists can help you to confirm that your server hardware and configuration meet minimum requirements for this release, and can help you to ensure you carry out a successful installation. ## Server Hardware Checklist for Oracle Database Installation Verify runlevel 3 or 5, a display resolution of at least 1024 × 768, network connectivity, and minimum memory of 1 GB for Oracle Database installations, with 2 GB recommended, or 8 GB for Oracle Grid Infrastructure. On Linux for Arm, use a Neoverse N1-capable processor, preferably an Ampere Altra or Altra Max. Read More: [Server Hardware Checklist for Oracle Database Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-installation-checklist/server-hardware-checklist-for-oracle-database-installation.html) ## Operating System Checklist for Oracle Database Installation on Linux Ensure OpenSSH and a supported Linux kernel are installed, using the version requirements for Linux x86-64, IBM Linux on System z, or Linux for Arm as applicable. Oracle recommends the Oracle Database Preinstallation RPM on Oracle Linux, the RPM Checker utility on IBM Linux on System z, upgrading older Oracle Linux and Red Hat releases where possible, and disabling Transparent HugePages in favor of standard HugePages. Read More: [Operating System Checklist for Oracle Database Installation on Linux](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-installation-checklist/operating-system-checklist-for-oracle-database-installation-on-linux.html) ## Server Configuration Checklist for Oracle Database Installation Prepare at least 1 GB in /tmp, configure swap according to available RAM and HugePages usage, and establish proper Oracle Inventory, OINSTALL groups, users, mount points, and ASCII-only Oracle home paths. Unset conflicting Oracle environment variables, configure locale as needed, verify that /dev/shm is a suitable executable tmpfs mount, follow Optimal Flexible Architecture practices, and ensure Oracle home, Oracle base, and their parent directories are not symbolic links. Read More: [Server Configuration Checklist for Oracle Database Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-installation-checklist/server-configuration-checklist-for-oracle-database-installation.html) ## Oracle User Environment Configuration Checklist for Oracle Database Installation Plan the Oracle Inventory and OINSTALL group as the central inventory and primary group for all Oracle software owners, create required users and groups with ASCII-only names, and apply suitable resource limits. Remove obsolete Oracle environment variables from reused accounts, and configure the oracle or grid user environment with a umask of 022 and an appropriate DISPLAY setting. Read More: [Oracle User Environment Configuration Checklist for Oracle Database Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-installation-checklist/oracle-user-environment-configuration-checklist-for-oracle-database-installation.html) ## Storage Checklist for Oracle Database Installation Provide minimum local storage of 6.5 GB for Grid Infrastructure and 7.2 GB for Oracle Database on Linux x86-64 or Arm, or 5.5 GB and 5.9 GB respectively on IBM Linux on System z; approximately 100 GB is recommended for future patches. Select a separate file system, LVM or RAID volume, NFS/NAS storage, or Oracle ASM for database files, installing Grid Infrastructure first when using ASM, and define a file-system or ASM fast recovery area if recovery is required. Read More: [Storage Checklist for Oracle Database Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-installation-checklist/storage-checklist-for-oracle-database-installation.html) ## Installer Planning Checklist for Oracle Database Before installation, review platform release notes, certification and licensing information, validate prerequisites with OUI, CVU, and the latest ORAchk, and install Grid Infrastructure first when using ASM, Oracle Restart, or RAC. Plan process shutdowns and cron-job handling, obtain My Oracle Support credentials if needed, choose a database management tool, select appropriate memory management, determine root or sudo script execution, and verify client interoperability requirements. Read More: [Installer Planning Checklist for Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-installation-checklist/installer-planning-checklist-for-oracle-database.html) # Checking and Configuring the Server for Oracle Database Verify that servers where you install Oracle Database meet the minimum requirements for installation. This section provides minimum server requirements to complete installation of Oracle Database. It does not provide system resource guidelines, or other tuning guidelines for particular workloads. ## Logging In to a Remote System Using X Window System This procedure enables Oracle Universal Installer (OUI) to run on a remote server while displaying its graphical interface on a local X Window System client. Start an X session, permit the remote host with `xhost + RemoteHost`, connect to the installation server using `ssh -Y`, and switch to `root` when required; repeat the process for each installation owner account, such as `oracle` or `grid`, and consult the X server documentation if command order or security settings differ. Read More: [Logging In to a Remote System Using X Window System](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/checking-and-configuring-the-server-for-oracle-database/logging-in-to-a-remote-system-using-x-window-system.html) ## Setting Remote Display and X11 Forwarding Configuration Configure the remote display by setting `DISPLAY` to the local host and display number, using `export DISPLAY=hostname:0` for Bourne, Korn, or Bash shells or `setenv DISPLAY hostname:0` for C shell. To prevent installation failures caused by X11 forwarding, create or edit each Oracle installation owner’s `~/.ssh/config`, set `ForwardX11 no` for all hosts, and secure the `.ssh` directory and its contents so they are accessible only to the installation owner. Read More: [Setting Remote Display and X11 Forwarding Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/checking-and-configuring-the-server-for-oracle-database/setting-remote-display-and-x11-forwarding-configuration.html) ## Checking Server Hardware and Memory Configuration Verify that the server meets installation requirements by checking physical memory with `/proc/meminfo`, configured swap, available `/tmp` space, free memory and swap with `free`, processor architecture with `uname -m`, and shared memory sizing and mounting with `df -h /dev/shm`. Add memory or swap, clean `/tmp` without removing Oracle temporary directories, or configure `TMP` and `TMPDIR` when necessary, and confirm that the architecture matches the Oracle software release. Read More: [Checking Server Hardware and Memory Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/checking-and-configuring-the-server-for-oracle-database/checking-server-hardware-and-memory-configuration.html) ## Preventing Installation Errors Caused by Terminal Output Commands Because OUI uses SSH to execute commands and transfer files across Grid Infrastructure nodes, remove or conditionally suppress terminal-output commands in hidden shell startup files such as `.bashrc` and `.cshrc` for every Oracle installation owner. Commands such as `stty` must run only in interactive terminals, using appropriate Bourne-style or C-shell conditionals, because output from remotely loaded startup files can cause OUI to report errors and stop the installation. Read More: [Preventing Installation Errors Caused by Terminal Output Commands](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/checking-and-configuring-the-server-for-oracle-database/preventing-installation-errors-caused-by-terminal-output-commands.html) # Automatically Configuring Oracle Linux with Oracle Database Preinstallation RPM ## About the Oracle Database Preinstallation RPM The Oracle Database Preinstallation RPM simplifies Oracle Database and Grid Infrastructure preparation on Oracle Linux or supported Red Hat Enterprise Linux systems by installing required packages, resolving dependencies, creating the standard oracle user and groups, configuring kernel, driver, startup, NUMA, and resource-limit settings, and installing X11 client libraries. Install it only once during the initial Oracle software installation, do not use it on Oracle Engineered Systems, and manually configure settings for any additional software owners because its limits and kernel parameters apply only to oracle. Read More: [About the Oracle Database Preinstallation RPM](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/automatically-configuring-oracle-linux-with-oracle-database-preinstallation-rpm/about-the-oracle-database-preinstallation-rpm.html) ## Overview of Oracle Linux Configuration with Oracle Database Preinstallation RPM The Oracle Database Preinstallation RPM automates required package and operating-system configuration for Oracle installations. The recommended process is to install Oracle Linux, register it with ULN or configure the appropriate yum repository, install the release-specific preinstallation RPM and update the system, create role-separated users and groups with consistent IDs, configure cluster networking, and prepare shared storage; after these steps, the environment is ready for Grid Infrastructure and Database installation. The RPM should be installed only for the first installation on a system and not on Oracle Engineered Systems. Read More: [Overview of Oracle Linux Configuration with Oracle Database Preinstallation RPM](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/automatically-configuring-oracle-linux-with-oracle-database-preinstallation-rpm/overview-of-oracle-linux-configuration-with-oracle-database-preinstallation-rpm.html) ## Installing the Oracle Database Preinstallation RPM Using ULN To install the preinstallation RPM through ULN, obtain the latest Oracle Linux update media, register each server with ULN, sign in to ULN, and install the release-specific package as root using yum on Oracle Linux 7 or dnf on Oracle Linux 8 and later. The RPM creates the standard Oracle installation owner and groups and applies required kernel settings; review changes in the generated orakernel.log file and repeat the procedure on every cluster server. Eligible support customers may also enable Ksplice for zero-downtime patching. Read More: [Installing the Oracle Database Preinstallation RPM Using ULN](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/automatically-configuring-oracle-linux-with-oracle-database-preinstallation-rpm/installing-the-oracle-database-preinstallation-rpm-using-uln.html) ## Installing Oracle Database Preinstallation RPM During an Oracle Linux Installation During a new Oracle Linux installation, select customized software packages, navigate to the server system administration tools, and choose the Oracle Database Preinstallation RPM matching the operating system release and architecture. Complete the installation to allow Oracle Linux to create the standard Oracle owner and groups and configure required kernel settings; if a suitable package is unavailable on the installation media, install the correct release-specific RPM afterward. Repeat the process for all cluster nodes. Read More: [Installing Oracle Database Preinstallation RPM During an Oracle Linux Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/automatically-configuring-oracle-linux-with-oracle-database-preinstallation-rpm/installing-oracle-database-preinstallation-rpm-during-an-oracle-linux-installation.html) ## Installing Oracle Oracle Database Preinstallation RPM Using the Oracle Linux yum Server After installing Oracle Linux according to its official documentation, apply current security and bug-fix updates with yum update and reboot the system. As root, install oracle-database-preinstall-19c with yum on Oracle Linux 7 or dnf on Oracle Linux 8 and later, optionally using the confirmation bypass option. The RPM creates the standard Oracle owner and groups and configures required kernel settings; additional users and groups must be created manually when job-role separation is required. Read More: [Installing Oracle Oracle Database Preinstallation RPM Using the Oracle Linux yum Server](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/automatically-configuring-oracle-linux-with-oracle-database-preinstallation-rpm/installing-oracle-oracle-database-preinstallation-rpm-using-the-oracle-linux-yum-server.html) ## Configure Additional Operating System Features Before beginning installation, configure any supplementary operating-system features required by the deployment, such as IPMI support or additional programming environments. Review the relevant preinstallation guidance to verify that all feature-specific configuration tasks are complete. Read More: [Configure Additional Operating System Features](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/automatically-configuring-oracle-linux-with-oracle-database-preinstallation-rpm/configure-additional-operating-system-features.html) # Configuring Operating Systems for Oracle Database on Linux ## Guidelines for Linux Operating System Installation Before installing Oracle software on Linux, complete the required operating system configuration, hardware checks, and supported-distribution requirements. Deploy the operating system according to your vendor’s security guidance and apply common security practices to establish a secure foundation. Read More: [Guidelines for Linux Operating System Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/guidelines-for-linux-operating-system-installation.html) ## Completing a Minimal or Default Linux Installation Perform either a minimal or default Linux installation. Minimal installations require the Oracle Database Preinstallation RPM or manual installation of all required packages, while default installations include most dependencies and reduce manual verification; Oracle recommends retaining the default package selection rather than customizing RPMs. Read More: [Completing a Minimal or Default Linux Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/completing-a-minimal-or-default-linux-installation.html) ## About Oracle Linux with the Unbreakable Enterprise Kernel Oracle Linux includes the Unbreakable Enterprise Kernel (UEK), which is optimized and tested for Oracle Database, middleware, hardware, and enterprise workloads, and Oracle strongly recommends using it. UEK is optional when strict RHEL kernel compatibility is required because Oracle Linux also provides a RHEL-compatible kernel; Ksplice can update the running kernel without rebooting. Read More: [About Oracle Linux with the Unbreakable Enterprise Kernel](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/about-oracle-linux-with-the-unbreakable-enterprise-kernel.html) ## Reviewing Operating System and Software Upgrade Best Practices Before upgrading, document existing versions, patches, and configurations, review the applicable upgrade procedures and documentation, and back up all databases. Operating system upgrades can use manual file migration with control-file recreation and command-line database upgrades, or Export/Import with Data Pump, which is recommended for performance and new data type support; verify platform, kernel, and package compatibility, and observe Oracle ASM rolling-upgrade restrictions for clustered environments. Read More: [Reviewing Operating System and Software Upgrade Best Practices](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/reviewing-operating-system-and-software-upgrade-best-practices.html) ## Restrictions for HugePages and Transparent HugePages Configurations Oracle recommends disabling Transparent HugePages because dynamic memory allocation can cause access delays, performance problems, or RAC node restarts, while standard HugePages provide more predictable performance. If HugePages are enabled, reserve sufficient memory for all database SGAs and the Grid Infrastructure Management Repository, account for that memory when sizing swap, and ensure the allocation is large enough to prevent fallback to regular pages. Read More: [Restrictions for HugePages and Transparent HugePages Configurations](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/restrictions-for-hugepages-and-transparent-hugepages-configurations.html) ## Setting and Disabling Transparent HugePages on UEK Kernels Configure Transparent HugePages according to the UEK version: set it to `madvise` on UEK7 and later, and disable it on earlier UEK releases unless the system has subsequently been upgraded to UEK7 or later. Update the GRUB kernel parameters, regenerate the boot configuration, restart the system, and verify the active setting through the appropriate kernel interface; the preinstallation RPM performs the recommended configuration automatically. Read More: [Setting and Disabling Transparent HugePages on UEK Kernels](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/setting-and-disabling-transparent-hugepages-on-uek-kernels.html) ## Configuring HugePages on Linux Enable standard HugePages by confirming kernel support, setting an appropriate `memlock` limit for the Oracle user, verifying the HugePage size and Oracle group ID, and configuring `vm.hugetlb_shm_group` persistently. After database creation, calculate the required page count from active shared-memory segments, set and persist `vm.nr_hugepages`, verify availability, and restart instances; reserve no more than 70 percent of RAM for HugePages and retain at least 30 percent for standard pages. Read More: [Configuring HugePages on Linux](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/configuring-hugepages-on-linux.html) ## About Installation Fixup Scripts Oracle Universal Installer can generate `runfixup.sh` scripts to correct incomplete prerequisite configuration, including kernel and shared-memory parameters, network limits, inventory permissions, group memberships, and shell limits, with changes applied both persistently and immediately. Fixup scripts do not replace full prerequisite verification; for Grid Infrastructure and RAC installations, CVU and the `cluvfy` utility provide additional automated or manual checks. Read More: [About Installation Fixup Scripts](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/about-installation-fixup-scripts.html) ## Additional Drivers and Software Packages for Linux Optional Linux components include current PAM libraries for external scheduler authentication, OCFS2 for supported Oracle Linux cluster filesystems, required Messaging Gateway fixes, unixODBC 2.3.4 or later for Oracle ODBC drivers, LDAP packages for directory-dependent scripts, and platform-specific Java, compiler, COBOL, Python, and XDK environments. Web browsers are needed only for Enterprise Manager interfaces and must support JavaScript and the specified HTML and CSS standards; OCFS2, Messaging Gateway, and some development components have platform-specific support limitations. Read More: [Additional Drivers and Software Packages for Linux](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/additional-drivers-and-software-packages-for-linux.html) ## Checking Kernel and Package Requirements for Linux Identify the installed Linux distribution with release-information commands, verify the running kernel and required errata with `uname -r`, and compare the results with the Oracle Database support requirements. Query required RPMs with `rpm -q` or architecture-aware RPM queries, and install missing or outdated packages from the distribution media or vendor repositories. Read More: [Checking Kernel and Package Requirements for Linux](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/checking-kernel-and-package-requirements-for-linux.html) ## Setting Clock Source for VMs on Linux x86-64 For Linux x86-64 virtual machines, Oracle recommends using the `tsc` clock source when available. Check available sources, set and verify `tsc`, add `clocksource=tsc` to the GRUB kernel command line, and regenerate the GRUB configuration so the setting persists after reboot. Read More: [Setting Clock Source for VMs on Linux x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/setting-clock-source-for-vms-on-linux-x86-64.html) ## Confirming Host Name Resolution Ensure the database server hostname resolves through DNS, NIS, or a centrally maintained `/etc/hosts` file. Use `ping` with the short and fully qualified hostname as appropriate to verify successful name resolution before installation. Read More: [Confirming Host Name Resolution](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/confirming-host-name-resolution.html) ## Using Automatic SSH Configuration During Installation Configure passwordless SSH and SFTP between all cluster nodes because Oracle Universal Installer, configuration assistants, and Enterprise Manager use these services for remote commands and file transfers. OUI can configure SSH automatically for the installation account, but login profiles must not emit messages or run disruptive commands such as `stty`; if remote connections close during Clusterware installation, set `LoginGraceTime 0` in the SSH daemon configuration on every node. Read More: [Using Automatic SSH Configuration During Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/using-automatic-ssh-configuration-during-installation.html) ## Verifying the Disk Input Output Scheduler on Linux 8 and Later Systems Review the disk I/O scheduler used by ASM devices on Linux 8 and later, RHEL 8 and later, and SLES 15 and later, consulting the storage vendor for the optimal configuration. Oracle generally recommends `mq-deadline` for rotational disks and `none` for SSDs and NVMe devices; verify the active scheduler on every cluster node through the device queue interface. Read More: [Verifying the Disk Input Output Scheduler on Linux 8 and Later Systems](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/verifying-the-disk-input-output-scheduler-on-linux-8-and-later-systems.html) ## Verifying the Disk Input Output Scheduler on Linux 7 Systems Review the disk I/O scheduler for ASM devices on Linux 7, RHEL 7, and SLES 12, with storage-vendor guidance taking precedence. Oracle generally recommends `deadline` for rotational disks and `none` for SSDs and NVMe devices; verify the configured scheduler on each cluster node through the device queue interface. Read More: [Verifying the Disk Input Output Scheduler on Linux 7 Systems](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-operating-systems-for-oracle-database-on-linux/verifying-the-disk-input-output-scheduler-on-linux-7-systems.html) # Operating System Requirements for x86-64 Linux Platforms ## About Operating System Requirements for x86-64 Linux Platforms Before installing Oracle Database or Oracle Grid Infrastructure on x86-64 Linux, verify the supported distribution, kernel, packages, and software requirements for the intended products. Oracle Universal Installer checks required packages, but prerequisites should be validated beforehand using current certification information. All cluster members must run the same operating system version unless undergoing an upgrade. Read More: [About Operating System Requirements for x86-64 Linux Platforms](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/about-operating-system-requirements-for-x86-64-linux-platforms.html) ## General Guidelines for Operating System Packages Oracle recommends Oracle Linux with the Oracle Database Preinstallation RPM, which configures the system and installs required dependencies. Reduced installations must include X Window System packages such as libX, while 32-bit packages are needed only for 32-bit client applications accessing 64-bit servers. Oracle Database 12c Release 2 and later do not require gcc or gcc-c++, and these requirements do not apply to Oracle Engineered Systems, which provide their own integrated software environment. Read More: [General Guidelines for Operating System Packages](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/general-guidelines-for-operating-system-packages.html) ## Supported Oracle Linux 10 Distributions for x86-64 Oracle Linux 10 requires OpenSSH and is supported with UEK 8 kernel 6.12.0-104.43.4.2.el10uek or later, or the Red Hat Compatible Kernel 6.12.0-55.40.1.0.1.el10\_0 or later, beginning with the specified Oracle Database 19c releases. Install the latest required packages, preferably through the oracle-database-preinstall-19c RPM, with optional packages available for IPMI, RAC, Clusterware, ACFS, and Database Client use. Oracle Database Client is supported on Oracle Linux 10, while Instant Client support begins with Oracle Database 19c 19.33. Read More: [Supported Oracle Linux 10 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-oracle-linux-10-distributions-for-x86-64.html) ## Supported Oracle Linux 9 Distributions for x86-64 Oracle Linux 9 requires OpenSSH and is supported with UEK 7 kernel 5.15.0-1.43.4.2.el9uek or later, the Red Hat Compatible Kernel 5.14.0-70.22.1.0.2.el9\_0 or later, and Oracle Linux 9.6 with UEK 8 kernel 6.12.0-1.23.3.2.el9uek or later for the applicable releases. Install the latest required packages, preferably using oracle-database-preinstall-19c; optional packages support development, IPMI, Database Client, RAC, Clusterware, and ACFS. Install corresponding 32-bit packages when required by 32-bit clients and review current release updates and known issues. Read More: [Supported Oracle Linux 9 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-oracle-linux-9-distributions-for-x86-64.html) ## Supported Oracle Linux 8 Distributions for x86-64 Oracle Linux 8 requires OpenSSH and supports UEK 6, the Red Hat Compatible Kernel, and specified UEK 7 kernel levels beginning with the applicable Database and Grid Infrastructure releases. Required packages should be installed at their latest versions, preferably through oracle-database-preinstall-19c, with optional packages for IPMI, Database Client, KVM, RAC, Clusterware, and ACFS. Install 32-bit equivalents when needed for 32-bit clients, review current patches and known issues, and note that KVM is certified for supported Oracle Linux 8 distributions. Read More: [Supported Oracle Linux 8 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-oracle-linux-8-distributions-for-x86-64.html) ## Supported Oracle Linux 7 Distributions for x86-64 Oracle Linux 7 requires OpenSSH and supports specified minimum UEK 4, UEK 5, UEK 6, and Red Hat Compatible Kernel versions. Oracle recommends upgrading to Oracle Linux 8 or later despite continued Oracle Database 19c support. Install the required packages, preferably with oracle-database-preinstall-19c, adding 32-bit versions for 32-bit clients and optional packages for IPMI, RAC, Clusterware, KVM, ACFS, and ACFS Remote. KVM is certified for supported Oracle Linux 7 distributions. Read More: [Supported Oracle Linux 7 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-oracle-linux-7-distributions-for-x86-64.html) ## Supported Red Hat Enterprise Linux 10 Distributions for x86-64 Red Hat Enterprise Linux 10 requires OpenSSH and is supported beginning with Oracle Database 19c 19.32 using kernel 6.12.0-55.40.1.0.1.el10\_0 or later. Install the latest versions of the specified system, X Window, runtime, security, storage, and monitoring packages, with optional packages for IPMI, RAC, Clusterware, and ACFS. Review the applicable installation guidance, known issues, and open bugs before deployment. Read More: [Supported Red Hat Enterprise Linux 10 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-red-hat-enterprise-linux-10-distributions-for-x86-64.html) ## Supported Red Hat Enterprise Linux 9 Distributions for x86-64 Red Hat Enterprise Linux 9 requires OpenSSH and is supported beginning with Oracle Database 19c 19.19 using kernel 5.14.0-70.22.1.el9\_0 or later. Install the latest required packages, including compatibility, runtime, RDMA, X Window, security, and monitoring components; install 32-bit versions where required for 32-bit clients. Optional packages support database and RAC operations, development, IPMI, Database Client, Clusterware, and ACFS, and current patches and known issues should be reviewed. Read More: [Supported Red Hat Enterprise Linux 9 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-red-hat-enterprise-linux-9-distributions-for-x86-64.html) ## Supported Red Hat Enterprise Linux 8 Distributions for x86-64 Red Hat Enterprise Linux 8 requires OpenSSH and kernel 4.18.0-80.el8.x86\_64 or later. Install the latest listed runtime, development, X Window, RDMA, security, storage, and monitoring packages, including 32-bit equivalents when required by client applications. Optional packages support IPMI, Database Client, RAC, Clusterware, and ACFS, while patch levels, known issues, and open bugs should be checked before installation. Read More: [Supported Red Hat Enterprise Linux 8 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-red-hat-enterprise-linux-8-distributions-for-x86-64.html) ## Supported Red Hat Enterprise Linux 7 Distributions for x86-64 Red Hat Enterprise Linux 7 requires OpenSSH and version 7.5 with kernel 3.10.0-862.11.6.el7.x86\_64 or later. Although Oracle Database 19c remains supported, upgrading to version 8 or later is strongly recommended. Install the required compatibility, runtime, development, X Window, and monitoring packages, including 32-bit versions for 32-bit clients, and add optional packages for IPMI, RAC, Clusterware, ACFS, and ACFS Remote. Read More: [Supported Red Hat Enterprise Linux 7 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-red-hat-enterprise-linux-7-distributions-for-x86-64.html) ## Supported SUSE Linux Enterprise Server 12 Distributions for x86-64 SUSE Linux Enterprise Server 12 requires OpenSSH and SP3 with kernel 4.4.162-94.72-default or later. Install the latest required development, runtime, X Window, capability, networking, RDMA, storage, compression, and monitoring packages, including 32-bit versions when needed for 32-bit clients. Optional net-tools supports RAC and Clusterware, while nfs-kernel-server supports ACFS. Read More: [Supported SUSE Linux Enterprise Server 12 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-suse-linux-enterprise-server-12-distributions-for-x86-64.html) ## Supported SUSE Linux Enterprise Server 15 Distributions for x86-64 SUSE Linux Enterprise Server 15 requires OpenSSH and kernel 4.12.14-23-default or later. Install the latest listed runtime, development, X Window, capability, networking, RDMA, system, compression, storage, and monitoring packages, adding 32-bit versions when required for 32-bit clients. Optional net-tools supports RAC and Clusterware, nfs-kernel-server supports ACFS, and current patches and known issues should be reviewed. Read More: [Supported SUSE Linux Enterprise Server 15 Distributions for x86-64](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/supported-suse-linux-enterprise-server-15-distributions-for-x86-64.html) ## Installing Operating System Packages Install the latest operating system packages from the vendor’s enabled repository using the platform’s package manager: YUM on Oracle Linux or Red Hat Enterprise Linux, and YaST on SUSE Linux Enterprise Server. Ensure the appropriate software channel or repository is enabled, then install each required package with the corresponding package-manager command, such as installing bc through YUM or YaST. Read More: [Installing Operating System Packages](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-x86-64-linux-platforms/installing-operating-system-packages.html) # Operating System Requirements for Linux for Arm (aarch64) ## About Operating System Requirements for Linux for Arm (aarch64) This section identifies the supported Linux distributions, kernels, and required packages for Linux for Arm (aarch64). Before installation, verify that the system meets the applicable requirements and consult Oracle’s certification matrix for the latest supported hardware and operating system versions, as certifications may change after publication. Read More: [About Operating System Requirements for Linux for Arm (aarch64)](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-linux-for-arm-aarch64/about-operating-system-requirements-for-linux-for-arm-aarch64.html) ## Supported Oracle Linux 8 Distributions on Linux for Arm (aarch64) For Oracle Database 19c Release 19.19 and later, Oracle Linux 8.6 or later is supported on Linux for Arm (aarch64) with Unbreakable Enterprise Kernel 7 version 5.15.0-6.80.3.1.el8uek.aarch64 or later; Oracle recommends using the latest available Oracle Linux 8 release. Install the oracle-database-preinstall-19c RPM from the Unbreakable Linux Network or Oracle Linux yum server to automatically install the required database and Grid Infrastructure packages, dependencies, and system configuration. Read More: [Supported Oracle Linux 8 Distributions on Linux for Arm (aarch64)](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-linux-for-arm-aarch64/supported-oracle-linux-8-distributions-on-linux-for-arm-aarch64.html) # Operating System Requirements for IBM: Linux on System z ## About Operating System Requirements for IBM: Linux on System z Before installing Oracle Database or Grid Infrastructure on IBM Linux on System z, verify that the distribution, kernel, packages, and other software meet the release requirements. Consult the current certification matrix because supported platforms may change, and use Oracle Universal Installer checks to confirm package compliance. Thirty-two-bit packages are required only for 32-bit client applications accessing 64-bit servers, and all cluster members must use the same operating system version unless performing an upgrade. Read More: [About Operating System Requirements for IBM: Linux on System z](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-ibm-linux-on-system-z/about-operating-system-requirements-for-ibm-linux-on-system-z.html) ## Using Oracle RPM Checker on IBM: Linux on System z Use the Oracle RPM Checker utility to validate required Red Hat Enterprise Linux or SUSE packages before installation. Download the distribution-specific utility from My Oracle Support, install and run it as root, and use the applicable RPM or yum command for RHEL 7, 8, or 9 and SLES 12 or 15; on RHEL, yum can also install the required RPMs. The utility can be removed with the corresponding rpm -e command. Read More: [Using Oracle RPM Checker on IBM: Linux on System z](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-ibm-linux-on-system-z/using-oracle-rpm-checker-on-ibm-linux-on-system-z.html) ## Supported Red Hat Enterprise Linux 9 Distributions for IBM: Linux on System z Red Hat Enterprise Linux 9 requires OpenSSH and, beginning with Oracle Database 19c Release 19.23, RHEL 9.2 with kernel 5.14.0-284.30.1.el9\_2.s390x or later. Install current versions of the required development, compiler, runtime, X11, networking, RDMA, security, monitoring, and system-management packages, including glibc-devel, ksh, libaio, libgcc, libstdc++, make, policycoreutils, smartmontools, and sysstat. Optional packages support RAC and Clusterware, application development, IPMI, and Database Client installations. Read More: [Supported Red Hat Enterprise Linux 9 Distributions for IBM: Linux on System z](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-ibm-linux-on-system-z/supported-red-hat-enterprise-linux-9-distributions-for-ibm-linux-on-system-z.html) ## Supported Red Hat Enterprise Linux 8 Distributions for IBM: Linux on System z Red Hat Enterprise Linux 8 requires OpenSSH, RHEL 8.3 with kernel 4.18.0-240.el8.s390x or later, and the specified or newer s390x packages. Required components include compilers, glibc and development libraries, KornShell, asynchronous I/O, X11 libraries, RDMA libraries, C++ runtimes, PAM, make, networking tools, policy utilities, smartmontools, and sysstat. Read More: [Supported Red Hat Enterprise Linux 8 Distributions for IBM: Linux on System z](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-ibm-linux-on-system-z/supported-red-hat-enterprise-linux-8-distributions-for-ibm-linux-on-system-z.html) ## Supported Red Hat Enterprise Linux 7 Distributions for IBM: Linux on System z Red Hat Enterprise Linux 7 requires OpenSSH, RHEL 7.4 with kernel 3.10.0-693.el7.s390x or later, and the listed or newer s390 and s390x packages. The package set covers binutils, compatibility capabilities, GCC and C++ development tools, glibc, KornShell, X11 libraries, asynchronous I/O, attribute and compiler libraries, PAM, make, and sysstat. Read More: [Supported Red Hat Enterprise Linux 7 Distributions for IBM: Linux on System z](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-ibm-linux-on-system-z/supported-red-hat-enterprise-linux-7-distributions-for-ibm-linux-on-system-z.html) ## Supported SUSE Linux Enterprise Server 12 Distributions for IBM: Linux on System z SUSE Linux Enterprise Server 12 requires OpenSSH and kernel 4.4.73-5-default for s390x or later. Install the specified or newer compiler, glibc, asynchronous I/O, X11, capability, C and C++ runtime, XCB, KornShell, and make packages, including both required architecture variants where listed. Read More: [Supported SUSE Linux Enterprise Server 12 Distributions for IBM: Linux on System z](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-ibm-linux-on-system-z/supported-suse-linux-enterprise-server-12-distributions-for-ibm-linux-on-system-z.html) ## Supported SUSE Linux Enterprise Server 15 Distributions for IBM: Linux on System z SUSE Linux Enterprise Server 15 requires OpenSSH and kernel 5.3.18-57-default for s390x or later, together with the specified or newer development, compiler, runtime, X11, capability, networking, RDMA, compression, storage, monitoring, and system utilities. Required packages include GCC, glibc, libaio, C and C++ runtimes, X libraries, libcap, libgcc, libgfortran, libpcap, libpcre, libtiff, make, smartmontools, sysstat, and related dependencies; install the latest available 32-bit versions as well when 32-bit clients will access 64-bit servers. Read More: [Supported SUSE Linux Enterprise Server 15 Distributions for IBM: Linux on System z](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/operating-system-requirements-for-ibm-linux-on-system-z/supported-suse-linux-enterprise-server-15-distributions-for-ibm-linux-on-system-z.html) # Configuring Users, Groups and Environments for Oracle Grid Infrastructure and Oracle Database Before installation, create operating system groups and users, and configure user environments. ## Required Operating System Groups and Users Oracle installations require an installation owner, a shared Oracle Inventory group as the primary group for installation owners, and at least one system-privileges group. Administrators should verify whether an existing central inventory and `oraInst.loc` file are present, reuse the same inventory for all installations, and ensure installation owners can write to it. Create the inventory group if necessary, typically `oinstall`, and configure `grid` for Grid Infrastructure or `oracle` for Database installations, ensuring the appropriate primary and secondary group memberships. The `oraInventory` directory should not be placed under the Oracle base directory. Read More: [Required Operating System Groups and Users](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database/required-operating-system-groups-and-users.html) ## Oracle Installations with Standard and Job Role Separation Groups and Users Oracle supports standard configurations that share administrative users and groups, as well as job role separation configurations that assign distinct users and operating system groups to Grid Infrastructure, ASM, and individual databases. The required OSDBA group, typically `dba`, grants SYSDBA privileges, while optional or extended groups such as `oper`, `backupdba`, `dgdba`, `kmdba`, and `racdba` provide specialized privileges. ASM commonly uses separate `asmadmin`, `asmoper`, and `asmdba` groups, and the `ASMSNMP` user can provide limited monitoring access. Role separation improves security but does not prevent software owners from starting or stopping shared Clusterware resources. Read More: [Oracle Installations with Standard and Job Role Separation Groups and Users](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database/oracle-installations-with-standard-and-job-role-separation-groups-and-users.html) ## Creating Operating System Privileges Groups This page defines the operating system groups required or commonly used for Oracle administration and provides representative `groupadd` commands. ASM installations may require `asmadmin` for SYSASM, `asmdba` for ASM disk-device access, and optionally `asmoper` for ASM startup and shutdown. Database installations require `dba` for SYSDBA and may use `oper` for SYSOPER, while `backupdba`, `dgdba`, `kmdba`, and `racdba` provide SYSBACKUP, SYSDG, SYSKM, and SYSRAC privileges respectively. Administrators should reuse existing groups where appropriate or create distinct groups for separated administrative roles. Read More: [Creating Operating System Privileges Groups](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database/creating-operating-system-privileges-groups.html) ## Creating Operating System Oracle Installation User Accounts Before installation, create and configure Oracle software owner accounts such as `oracle` and `grid`, assigning the Oracle Inventory group `oinstall` as the primary group and the required database or ASM privilege groups as secondary groups. Example commands demonstrate memberships for database and Grid Infrastructure owners. Existing accounts can be updated with `usermod`, but their primary inventory group must not be changed and all Oracle software owners must share the same central inventory group to avoid inventory corruption. Record each installation user’s UID for preinstallation tasks. Read More: [Creating Operating System Oracle Installation User Accounts](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database/creating-operating-system-oracle-installation-user-accounts.html) ## Configuring Software Owner User Environments Oracle installation owners must have correctly configured shell environments before running the installer. Set `umask 022`, configure suitable file-descriptor and process limits, establish `DISPLAY` for graphical installations, and remove conflicting Oracle variables such as `ORACLE_HOME`, `ORACLE_BASE`, `ORACLE_SID`, `ORA_NLS10`, `TNS_ADMIN`, and `ORA_CRS_HOME`; also remove Oracle home paths from `PATH`. If `/tmp` lacks sufficient space, configure `TMP` and `TMPDIR` on a local filesystem with at least 1 GB available, not a shared filesystem for RAC. Reload the shell profile and verify the environment and umask values before installation. Read More: [Configuring Software Owner User Environments](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database/configuring-software-owner-user-environments.html) ## Checking Resource Limits for Oracle Software Installation Users Each Oracle installation owner must meet recommended shell resource limits: at least 1,024 soft and 65,536 hard open files, 2,047 soft and 16,384 hard processes, and a stack size of at least 10,240 KB with a maximum hard limit of 32,768 KB. Locked memory should be at least 90 percent of RAM with HugePages or at least 3 GB without HugePages, and is unlimited on Exadata. Check limits using `ulimit`, adjust distribution-specific security configuration such as `/etc/security/limits.conf` when necessary, and have affected users log out and back in for changes to take effect. Read More: [Checking Resource Limits for Oracle Software Installation Users](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database/checking-resource-limits-for-oracle-software-installation-users.html) ## Creating Oracle Database Vault User Accounts Deployments that enable Oracle Database Vault by default must create and configure a Database Vault Owner account before using the feature, with an optional separate Account Manager administrative account. Database Vault establishes baseline auditing for security configuration, Oracle Catalog information, system privilege use, and Oracle Label Security settings, while initializing security-related database parameters with default values. Read More: [Creating Oracle Database Vault User Accounts](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database/creating-oracle-database-vault-user-accounts.html) # Configuring Networks for Oracle Database ## About Oracle Database Network Configuration Options Oracle Database generally requires no special network configuration on a server with a static, resolvable host name, IP address, and network interface. Additional planning is required for multihomed, multialias, or initially non-networked systems, including ensuring firewall ports are open, supporting clients that connect through multiple IP addresses, and configuring services after installation when necessary. Read More: [About Oracle Database Network Configuration Options](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-networks-for-oracle-database/about-oracle-database-network-configuration-options.html) ## About Assigning Global Database Names During Installation During installation, the database name establishes the DB\_NAME, DB\_UNIQUE\_NAME, and DB\_DOMAIN values used to form the unique global database name. The global name combines the database name and domain, while the SID uniquely identifies the database instance on its host; each instance must have a distinct SID and database name. Database and domain names must comply with Oracle’s length and character restrictions, and DB\_NAME does not have to be the first eight characters of DB\_UNIQUE\_NAME. Read More: [About Assigning Global Database Names During Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-networks-for-oracle-database/about-assigning-global-database-names-during-installation.html) ## Network Configuration for Computers Completed After Installation Oracle Database can be installed on computers without fixed network addresses, including DHCP-based systems, provided the computer can resolve and contact itself. Before installation, test connectivity with ping using both the short host name and fully qualified host name, confirming that the expected local IP address is returned. After the computer connects to a network, the database can operate with either static or DHCP addressing. Read More: [Network Configuration for Computers Completed After Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-networks-for-oracle-database/network-configuration-for-computers-completed-after-installation.html) ## Network Configuration for Multihome Computers Installing Oracle Database on a multihomed computer requires setting ORACLE\_HOSTNAME to identify the intended host name or interface. Oracle Universal Installer uses this value when available, or otherwise derives host information from /etc/hosts and installation responses. Clients must resolve and reach the database through both the selected host name or alias and its fully qualified domain name, which should be verified with ping. Read More: [Network Configuration for Multihome Computers](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-networks-for-oracle-database/network-configuration-for-multihome-computers.html) ## Setting the ORACLE\_HOSTNAME Environment Variable Set ORACLE\_HOSTNAME in the Oracle installation owner’s environment to the fully qualified host name required for the installation. Bourne, Bash, and Korn shells use export, while C Shell uses setenv; the example value is somehost.example.com. Read More: [Setting the ORACLE\_HOSTNAME Environment Variable](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-networks-for-oracle-database/setting-the-oracle_hostname-environment-variable.html) ## Network Configuration for Computers with Multiple Aliases Installing Oracle Database on a computer with multiple host-name aliases requires setting ORACLE\_HOSTNAME to the preferred host name. Such systems use one IP address with multiple names resolved by the naming service, so the environment variable determines which computer name Oracle uses during installation. Read More: [Network Configuration for Computers with Multiple Aliases](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-networks-for-oracle-database/network-configuration-for-computers-with-multiple-aliases.html) # Supported Storage Options for Oracle Database and Oracle Grid Infrastructure Review supported storage options as part of your installation planning process. ## Supported Storage Options for Oracle Database Oracle Database supports Oracle ASM, Oracle ACFS, local file systems, NVMe over Fabrics, NFS on NAS, and Oracle Memory Speed with varying support for binaries, data files, and recovery files. Oracle ASM is recommended on dedicated disks and can store database and recovery files plus Clusterware files, while raw or block devices cannot be used directly. ACFS on IBM AIX is deprecated in Oracle Database 19c, and local file systems are supported for data and recovery files but not recommended. Read More: [Supported Storage Options for Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/supported-storage-options-for-oracle-database-and-oracle-grid-infrastructure/supported-storage-options-for-oracle-database.html) ## About Oracle Grid Infrastructure for a Standalone Server Oracle Grid Infrastructure for a standalone server combines Oracle Restart and Oracle ASM for single-instance databases, providing volume management, file-system services, monitoring, and automatic restart. Oracle Restart manages database instances, listeners, services, and ASM, restarting failed components in the correct order and monitoring their health. It must be installed before using ASM unless the database is later registered manually, is limited to nonclustered environments, and cannot be installed on or added to an Oracle Grid Infrastructure cluster node. Read More: [About Oracle Grid Infrastructure for a Standalone Server](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/supported-storage-options-for-oracle-database-and-oracle-grid-infrastructure/about-oracle-grid-infrastructure-for-a-standalone-server.html) ## Oracle ACFS and Oracle ADVM Oracle ACFS extends ASM to provide a general-purpose file system for application and database files in single-instance and clustered environments, while Oracle ADVM supplies volume management and the device-driver interface through which ACFS accesses ASM. ACFS and ADVM are supported on specified Oracle Linux, Red Hat Enterprise Linux, and SUSE Linux Enterprise Server kernels, but not Linux Containers; ACFS on IBM AIX is deprecated in Oracle Database 19c and unsupported on AIX WPARs. ACFS requires ASM, supports database homes and files subject to configuration restrictions, does not support encryption or replication for several database file types, and has limitations in Oracle Restart and Clusterware configurations. Read More: [Oracle ACFS and Oracle ADVM](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/supported-storage-options-for-oracle-database-and-oracle-grid-infrastructure/oracle-acfs-and-oracle-advm.html) ## File System Options for Oracle Database Oracle Database files can be stored on file systems located on physically attached disks, LVM or RAID volumes, or NFS-mounted NAS devices, with Direct NFS Client available to simplify administration and improve performance. Oracle recommends separating database file systems from operating system and Oracle software file systems, distributing storage according to OFA or SAME practices, and using Oracle Managed Files when automatic file naming and management are desired. These options support both standard installations and advanced configurations using one or multiple file systems. Read More: [File System Options for Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/supported-storage-options-for-oracle-database-and-oracle-grid-infrastructure/file-system-options-for-oracle-database.html) ## Guidelines for Placing Oracle Database Files On a File System or Logical Volume Database file systems should use storage dedicated to the database, preferably RAID or logical volumes spanning multiple physical devices with a stripe-and-mirror-everything policy. A single file system simplifies deployment, while multiple file systems can distribute I/O, separate control files, improve reliability, and support OFA practices. Installation-created databases require at least 2 GB of free space, production capacity must be estimated from expected usage, and the Oracle installation user must have write access to the selected paths. Read More: [Guidelines for Placing Oracle Database Files On a File System or Logical Volume](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/supported-storage-options-for-oracle-database-and-oracle-grid-infrastructure/guidelines-for-placing-oracle-database-files-on-a-file-system-or-logical-volume.html) ## About NFS Storage for Data Files NFS enables database files to reside on shared NAS storage and supports both single-instance and Oracle RAC databases. Performance depends heavily on the network connection, so dedicated private connections using Gigabit Ethernet or faster are recommended. Before installation, all required NFS file systems must be mounted and available on the database servers, with configuration completed according to the storage vendor’s guidance. Read More: [About NFS Storage for Data Files](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/supported-storage-options-for-oracle-database-and-oracle-grid-infrastructure/about-nfs-storage-for-data-files.html) ## About Direct NFS Client Mounts to NFS Storage Devices Direct NFS Client integrates NFS access into Oracle software to optimize database I/O, supports NFSv3, NFSv4, NFSv4.1, and pNFS, and can use a dispatcher to reduce TCP connections and improve scalability. NFS servers require a write size of at least 32768, and mount points must be available to both the operating-system NFS client and dNFS for fallback capability. dNFS searches for configuration in the Oracle home, system oranfstab, and mtab locations, permits only one active NFS client implementation per instance, and selects protocol versions according to configuration, using NFSv4.1 when NFSv4.2 is specified. Read More: [About Direct NFS Client Mounts to NFS Storage Devices](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/supported-storage-options-for-oracle-database-and-oracle-grid-infrastructure/about-direct-nfs-client-mounts-to-nfs-storage-devices.html) # Configuring File System Storage for Oracle Database Complete these procedures to use file system storage for Oracle Database. For optimal database organization and performance, Oracle recommends that you install data files and the Oracle Database software in different disks. ## Deploying Oracle Direct NFS for Oracle Database Oracle recommends Oracle Direct NFS (dNFS) for database file systems hosted on NFS storage because it provides performance optimizations; database software and data files should preferably reside on separate disks. Configure NFS mounts with rsize and wsize values of at least 32768, and ensure TCP receive and transmit buffers are sized appropriately for the network, with changes applied through sysctl and a network restart. Create an oranfstab file defining each NFS server, local and server network paths, exports, mount points, optional mount timeouts, NFS versions, security modes, routing behavior, management interfaces, and SNMP community strings. Supported security modes include sys, krb5, krb5i, and krb5p; NFSv3 is the default, while NFSv4.x and pNFS require explicit configuration, and pNFS supports only sys authentication. Read More: [Deploying Oracle Direct NFS for Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-file-system-storage-for-oracle-database/deploying-oracle-direct-nfs-for-oracle-database.html) ## Enabling and Disabling Direct NFS Client Control of NFS Single-instance Oracle Database installations normally install Direct NFS Client disabled. After configuring oranfstab, enable dNFS from $ORACLE\_HOME/rdbms/lib with make -f ins\_rdbms.mk dnfs\_on; disable it with the corresponding dnfs\_off command and remove oranfstab. Restart the database after removing an NFS path currently in use. To enable Hybrid Columnar Compression through dNFS, verify that SNMP is enabled on the ZFS storage server, configure the oranfstab management and community parameters when required, and ensure the libnetsnmp.so library and snmpget utility are installed. Read More: [Enabling and Disabling Direct NFS Client Control of NFS](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-file-system-storage-for-oracle-database/enabling-and-disabling-direct-nfs-client-control-of-nfs.html) # Deploying the Oracle Memory Speed File System ## About Oracle Memory Speed Oracle Memory Speed (OMS) is a user-space file system recommended for safely using persistent memory (PMEM) with single-instance Oracle Database. It uses memory-mapped files on XFS DAX-enabled storage to provide near-hardware I/O performance while preventing corruption risks associated with direct DAX file access. OMS supports database control, redo, data, and temporary files; reduces context switches, copies, TLB misses, and cache overhead; leverages HugePages and non-temporal stores; permits file inspection while the database is stopped; and provides diagnostic capabilities. Read More: [About Oracle Memory Speed](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/deploying-the-oracle-memory-speed-file-system/about-oracle-memory-speed.html) ## Requirements and Guidelines for Oracle Memory Speed OMS requires an Intel Cascade Lake, Ice Lake, or later server, PMEM devices with socket-level memory interleaving, Oracle Linux with HugePages support beginning with UEK5, and a DAX-capable file system such as XFS. Oracle supports OMS only for single-instance databases and recommends Oracle Data Guard to protect against primary-instance failures through standby failover. Read More: [Requirements and Guidelines for Oracle Memory Speed](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/deploying-the-oracle-memory-speed-file-system/requirements-and-guidelines-for-oracle-memory-speed.html) ## Setting-Up Hardware and Operating System Components for OMS Preparing OMS involves verifying HugePages support, configuring PMEM in BIOS App Direct mode, managing regions and namespaces with `ipmctl` and `ndctl`, confirming 2 MiB alignment, and partitioning each device into metadata and data areas. Create XFS with 2 MiB real-time extents, mount it with DAX, verify the mount, and create appropriately sized, 2 MiB-aligned OMS uber files owned by the Oracle software user. Each uber file represents an OMS storage volume and must be associated with an Oracle instance through its SID. Read More: [Setting-Up Hardware and Operating System Components for OMS](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/deploying-the-oracle-memory-speed-file-system/setting-up-hardware-and-operating-system-components-for-oms.html) ## Setting-Up the Oracle Memory Speed File System Start one OMS daemon per database instance with the appropriate `ORACLE_SID`; it creates the shared memory segment, configuration file, and diagnostic traces required by OMS and should not be manually removed or edited. Use `omsfscmds` to format uber files with the supported 4 KB block size and mount them on protected directories. OMS supports up to two simultaneous file systems, typically corresponding to PMEM devices on two sockets, and automatically remounts them after daemon restart and node reboot. Read More: [Setting-Up the Oracle Memory Speed File System](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/deploying-the-oracle-memory-speed-file-system/setting-up-the-oracle-memory-speed-file-system.html) ## Deploying Oracle Database with Oracle Memory Speed Enable OMS by building the Oracle Disk Manager library with `oms_on`, then confirm operation through the alert log message identifying OMS as the ODM implementation; disable it with `oms_off` when required. For performance validation, trace DAX faults and confirm 2 MiB HugePages mappings that bypass the page cache; a `FALLBACK` trace indicates unsuitable 4 KB handling and the system must not run OMS workloads. Disable tracing before production use because it significantly affects performance. Read More: [Deploying Oracle Database with Oracle Memory Speed](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/deploying-the-oracle-memory-speed-file-system/deploying-oracle-database-with-oracle-memory-speed.html) ## Migrating Oracle Database to Oracle Memory Speed Database migration to OMS, supported from Oracle Database 19c Release Update 19.12, requires creating and mounting OMS storage, starting its daemon, enabling the OMS ODM library, and configuring Oracle Managed Files and redo destinations as needed. Individual data files can be moved with SQL, redo members can be replaced after adding OMS-based members and ensuring old logs are inactive, and entire databases can be migrated with RMAN backup-as-copy, SPFILE and control-file relocation, database switching, recovery, and optional restoration of Flashback or change tracking. Temporary files require separate drop-and-recreate operations, while standby recovery must be managed appropriately during migration. Read More: [Migrating Oracle Database to Oracle Memory Speed](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/deploying-the-oracle-memory-speed-file-system/migrating-oracle-database-to-oracle-memory-speed.html) ## omsfscmds Command Reference `omsfscmds` is the OMS command-line utility and requires a running OMS daemon with a matching database SID. It provides commands to format or force-format devices, mount and unmount file systems, list mounts, inspect space and files, copy or remove files, navigate directories, generate diagnostic dumps, enable tracing, control daemon trace levels, and exit the utility. The primary syntax uses PMEM uber files as devices and OMS mount paths as destinations. Read More: [omsfscmds Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/deploying-the-oracle-memory-speed-file-system/omsfscmds-command-reference.html) # Configuring Storage for Oracle Grid Infrastructure for a Standalone Server ## About Configuring Storage for Oracle Grid Infrastructure for a Standalone Server Page Oracle Grid Infrastructure for a standalone server, also known as Oracle Restart, provides high availability support for single-instance databases and includes Oracle ASM for volume management and file storage. Oracle recommends installing Grid Infrastructure before creating databases when using Oracle ASM or Oracle Restart; Oracle Restart cannot be installed on, or added to, a cluster member node managed by Grid Infrastructure for a Cluster. Read More: [About Configuring Storage for Oracle Grid Infrastructure for a Standalone Server Page](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server/about-configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server-page.html) ## Configuring Storage for Oracle Automatic Storage Management Plan Oracle ASM storage by selecting whether database files, recovery files, or both will use ASM; choosing disk-group redundancy; calculating capacity; and defining failure groups where needed. External redundancy relies on storage-level protection, normal redundancy generally provides two-way mirroring, high redundancy provides three-way mirroring, and flex or extended redundancy support more flexible or site-aware protection. Use similarly sized and performing devices owned by the grid installation user, avoid multiple partitions from one physical disk, and prefer direct LUNs over complex logical volumes. ASMFD is deprecated on Linux and Solaris, and ASMlib v3 is recommended for supported Linux kernels. Existing ASM disk groups can be inspected with ASMCMD, while NAS files, DAS, and SAN partitions may also provide ASM devices when configured correctly. Read More: [Configuring Storage for Oracle Automatic Storage Management](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server/configuring-storage-for-oracle-automatic-storage-management.html) ## Configuring Storage Device Path Persistence Using Oracle ASMLIB Oracle ASMLIB provides persistent ASM disk labels, permissions, and device discovery across system restarts and operating-system upgrades. Configure the disk discovery string as `ORCL:*`, and use an interactive ASMCA installation method when creating a database with the ASM library driver. Install ASMLIB v3 on Oracle Linux 8 and later kernels and ASMLIB v2 on Oracle Linux 7 and earlier, verifying the system kernel and architecture first; ASMLIB is not supported on IBM Linux on System z or Linux for Arm. Read More: [Configuring Storage Device Path Persistence Using Oracle ASMLIB](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server/configuring-storage-device-path-persistence-using-oracle-asmlib.html) ## Deinstalling Oracle ASMLIB On Oracle Database To remove unused Oracle ASMLIB, log in as root, stop the database, ASM, and Oracle Restart stack, unload and disable ASMLIB, remove the `oracleasm-support` and `oracleasmlib` packages, and delete any remaining Oracle ASM RPMs or configuration files. After cleanup, restart the Oracle Restart stack. Read More: [Deinstalling Oracle ASMLIB On Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server/deinstalling-oracle-asmlib-on-oracle-database.html) ## Creating Directories for Oracle Database Files To place database and recovery files on separate file systems, check available capacity with `df -h`, select mount points meeting the database and recovery space requirements, and create directories manually when the installer lacks permission. Assign the Oracle software owner and inventory group, apply suitable permissions, and preferably place the fast recovery area on a separate physical disk from the database files so it remains available for recovery if the database storage fails. Read More: [Creating Directories for Oracle Database Files](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server/creating-directories-for-oracle-database-files.html) ## Migrating from Oracle ASM Filter Driver to Oracle ASMLib for Oracle Restart On Linux kernels 5.14 and later, migrate Oracle ASMFD to ASMLIB 3.1 in rolling mode because ASMFD filtering is disabled. Confirm ASMFD disks, apply required patches and compatibility changes, stop Oracle Restart and ACFS, deconfigure ASMFD, install and configure ASMLIB, initialize and enable its service, scan and verify that the disk list matches the original configuration, restart ACFS and Oracle Restart, and confirm that ASM disks are exposed with the `ORCL:` prefix and owned by the `asmdba` group. Read More: [Migrating from Oracle ASM Filter Driver to Oracle ASMLib for Oracle Restart](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server/migrating-from-oracle-asm-filter-driver-to-oracle-asmlib-for-oracle-restart.html) ## Deconfiguring Oracle ASM Filter Driver To deconfigure unused ASMFD, set a temporary `ORACLE_BASE`, stop Oracle Restart and ACFS, run `asmcmd afd_deconfigure`, restart ACFS even when it is not otherwise used, and then start Oracle Restart. For future upgrades where ASMFD is desupported, ensure ASM devices have the required `asmdba` ownership and group configuration. Read More: [Deconfiguring Oracle ASM Filter Driver](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-storage-for-oracle-grid-infrastructure-for-a-standalone-server/deconfiguring-oracle-asm-filter-driver.html) # Installing and Configuring Oracle Grid Infrastructure for a Standalone Server ## About Installing and Configuring Oracle Grid Infrastructure for a Standalone Server Page Oracle Grid Infrastructure for a standalone server includes Oracle Restart and Oracle ASM. Databases created after installation are automatically registered with Oracle Restart, while preexisting databases, listeners, ASM instances, and other resources must be registered manually. A single host can support multiple single-instance databases managed by Oracle Restart. Read More: [About Installing and Configuring Oracle Grid Infrastructure for a Standalone Server Page](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/about-installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server-page.html) ## About Image-Based Oracle Grid Infrastructure Installation Image-based installation simplifies Oracle Grid Infrastructure deployment by requiring administrators to create the Grid home, extract the installation image, and run gridSetup.sh. It supports new clusters, standalone servers with Oracle Restart, upgrades, software-only installations, and node changes, while also enabling automated deployments using customized images patched with RUs or RURs. The image must be extracted directly into an appropriately configured Grid home. Read More: [About Image-Based Oracle Grid Infrastructure Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/about-image-based-oracle-grid-infrastructure-installation.html) ## Setup Wizard Installation Options for Creating Images The runInstaller and gridSetup.sh setup wizards support gold-image creation through the -createGoldImage option, with parameters for the destination directory, excluded files, and help output. These options allow administrators to package Oracle Database or Grid homes into reusable image archives while selectively excluding files such as release notes. Read More: [Setup Wizard Installation Options for Creating Images](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/setup-wizard-installation-options-for-creating-images.html) ## Installing Oracle Grid Infrastructure for a Standalone Server with a New Database Installation Install Oracle Restart and Oracle ASM by preparing the Oracle base, inventory, users, groups, storage, and network, extracting the Grid image into an appropriately owned Grid home, and running gridSetup.sh. Select the standalone-server configuration, create or extend ASM disk groups, complete the configuration prompts, and run or automate the required root scripts. Then install the database and select ASM disk groups for database storage; ASM Filter Driver is deprecated on Linux and Oracle Solaris in 19c. Read More: [Installing Oracle Grid Infrastructure for a Standalone Server with a New Database Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/installing-oracle-grid-infrastructure-for-a-standalone-server-with-a-new-database-installation.html) ## Installing Oracle Grid Infrastructure for a Standalone Server for an Existing Database For an existing database, set ORACLE\_HOME and ORACLE\_SID, stop its listeners, install Grid Infrastructure in a separate Grid home, and select the Oracle Restart standalone-server configuration. After installation, register the database with Oracle Restart using srvctl. Oracle Restart can manage databases from its own release and up to one release earlier, while older releases may remain installed but unmanaged. Read More: [Installing Oracle Grid Infrastructure for a Standalone Server for an Existing Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/installing-oracle-grid-infrastructure-for-a-standalone-server-for-an-existing-database.html) ## Installing Oracle Grid Infrastructure for a Standalone Server Using a Software-Only Installation A software-only installation places Grid Infrastructure binaries without configuring Oracle Restart and is intended for advanced users because it lacks installation validation and requires manual postinstallation work. Administrators extract the image, verify prerequisites with runcluvfy.sh, run gridSetup.sh with Set Up Software Only, and execute the requested root scripts. Configuration with ASM proceeds through the setup wizard; without ASM, administrators run roothas.sh, update the node list, and configure the listener with SRVCTL and Oracle Net Configuration Assistant. Read More: [Installing Oracle Grid Infrastructure for a Standalone Server Using a Software-Only Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/installing-oracle-grid-infrastructure-for-a-standalone-server-using-a-software-only-installation.html) ## Testing the Oracle Automatic Storage Management Installation Test ASM by setting ORACLE\_SID to the ASM instance and ORACLE\_HOME to the Grid home, then running asmcmd lsdg to list disk groups. If the ASM instance is not running, start it with srvctl start asm before repeating the verification. Read More: [Testing the Oracle Automatic Storage Management Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/testing-the-oracle-automatic-storage-management-installation.html) ## Relinking Oracle Restart and Oracle ASM Binaries After operating-system patching or upgrades, shut down all executables and applications using the Grid home or its shared libraries, unlock the Grid home with roothas.sh -unlock, relink the binaries as the grid user, run rootadd\_rdbms.sh as root, and relock the home with roothas.sh -lock. Read More: [Relinking Oracle Restart and Oracle ASM Binaries](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/relinking-oracle-restart-and-oracle-asm-binaries.html) ## Configuring Oracle ASM Disk Groups Manually using Oracle ASMCA After installing Grid Infrastructure, use Oracle ASMCA to create additional ASM disk groups and configure Oracle ADVM and Oracle ACFS. ASMCA creates an ASM instance during installation when none exists; it can be launched from the Grid home’s bin directory with the asmca command. Read More: [Configuring Oracle ASM Disk Groups Manually using Oracle ASMCA](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/configuring-oracle-asm-disk-groups-manually-using-oracle-asmca.html) ## Enabling Oracle ACFS on Oracle Restart Configurations Enable root access for Oracle ACFS by running roothas.sh -lockacfs as root from the Grid home’s crs/install directory. On IBM AIX, the ACFS storage option is deprecated in Oracle Database 19c, and roothas.sh replaces the older roothas.pl script beginning with release 12.1.0.2. Read More: [Enabling Oracle ACFS on Oracle Restart Configurations](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/enabling-oracle-acfs-on-oracle-restart-configurations.html) ## Applying Patches During an Oracle Grid Infrastructure Installation or Upgrade Starting with Oracle Grid Infrastructure 18c, administrators can apply Release Updates and one-off patches during installation or upgrade. Download the patches, place them in accessible directories, run gridSetup.sh with -applyRU and, when needed, -applyOneOffs, and complete the configuration wizard. Both patch types may be applied separately or in the same command. Read More: [Applying Patches During an Oracle Grid Infrastructure Installation or Upgrade](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/applying-patches-during-an-oracle-grid-infrastructure-installation-or-upgrade.html) ## Patching and Switching Oracle Grid Infrastructure Homes Perform out-of-place Oracle Restart patching by extracting the base image into a new Grid home, updating OPatch, applying the desired RU or one-off patches through gridSetup.sh, and completing a software-only installation. As root, relink and prepare the new home with the prepatch script, switch services with the postpatch script, and update the central inventory to designate the new home as active. The same prepatch, postpatch, and inventory procedures can switch services back to the former Grid home. Read More: [Patching and Switching Oracle Grid Infrastructure Homes](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/patching-and-switching-oracle-grid-infrastructure-homes.html) ## Changing the Oracle Grid Infrastructure Base Path To change the Grid base directory in release 19.21 or later, stop Oracle Restart, TFA, and dependent executables, create and populate the new base, and preserve the old location as a backup. Update the ORACLE\_BASE values in Grid configuration files, inventory and network files, revise /etc/oracle/olr.loc, restore permissions with roothas.sh -init, move AHF data with ahfctl, and restart the Oracle Restart stack. Read More: [Changing the Oracle Grid Infrastructure Base Path](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-and-configuring-oracle-grid-infrastructure-for-a-standalone-server/changing-the-oracle-grid-infrastructure-base-path.html) # Installing Oracle Database ## About Installing Oracle Database Oracle Database and Oracle Grid Infrastructure are distributed as image-based zip files and can be installed through Oracle Universal Installer, silent or response-file methods, or Oracle Fleet Patching and Provisioning. Software is obtained from Oracle download services or installation media. Oracle ASM storage requires Oracle Grid Infrastructure for a standalone server, and components from this release cannot be installed with an earlier Oracle Universal Installer. Read More: [About Installing Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/about-installing-oracle-database.html) ## About Image-Based Oracle Database Installation Image-based installation creates an Oracle home, extracts the database image into it, and runs the setup wizard to register and configure the product. It supports single-instance and clustered deployments, enables database options by default, and facilitates automation, cloning, and deployment of patched custom images. The image must be extracted directly into an OFA-compliant Oracle home before running the setup wizard. Read More: [About Image-Based Oracle Database Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/about-image-based-oracle-database-installation.html) ## About Deploying Oracle Database Using Oracle Fleet Patching and Provisioning Oracle Fleet Patching and Provisioning provisions, patches, and upgrades Oracle Database software through managed gold images of Oracle homes. Working copies of these images can be deployed across data-center or cloud nodes for single-instance databases on Oracle Restart, clusters, or standalone systems, regardless of whether Grid Infrastructure is installed. The technology, formerly called Rapid Home Provisioning, is not supported on Microsoft Windows or HP-UX Itanium. Read More: [About Deploying Oracle Database Using Oracle Fleet Patching and Provisioning](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/about-deploying-oracle-database-using-oracle-fleet-patching-and-provisioning.html) ## Downloading Oracle Software Oracle Database software can be downloaded from the Oracle website or Oracle Software Delivery Cloud, subject to the applicable license terms. Downloads should be stored in suitable product directories with sufficient space for extraction, verified against published file sizes and checksums, and then extracted. Software Delivery Cloud requires signing in, selecting the product and platform, accepting the license agreement, downloading the files, and validating their digest. Read More: [Downloading Oracle Software](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/downloading-oracle-software.html) ## About Character Set Selection During Installation The database character set should be selected carefully before creation because changing it later can require extensive data conversion. It defines the encoding for character data, identifiers, and stored SQL or PL/SQL; Oracle Database 12.2 and later generally use Unicode AL32UTF8 by default. Although Unicode may require more storage and processing for some workloads, it supports broad language and technology compatibility. Legacy character sets should be chosen only for compelling compatibility, storage, or performance needs, and a multitenant container database should use a character set compatible with intended pluggable databases. Read More: [About Character Set Selection During Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/about-character-set-selection-during-installation.html) ## About Automatic Memory Management Installation Options Typical installations generally enable Automatic Memory Management through DBCA, while Advanced installations allow manual allocation or automatic management. Automatic Memory Management dynamically distributes a configured memory target between the SGA and instance PGA, but it cannot be selected during installation when total physical memory exceeds 4 GB; automatic shared memory management should be used instead. Automatic memory management can also be enabled after installation, requiring a database restart, and is disabled by default for typical installations on systems with more than 4 GB of RAM. Read More: [About Automatic Memory Management Installation Options](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/about-automatic-memory-management-installation-options.html) ## Running the Installer in a Different Language The database installer uses the operating system session locale to determine its language. Supported languages include Brazilian Portuguese, French, German, Italian, Japanese, Korean, Simplified Chinese, Spanish, and Traditional Chinese. The locale must be changed before starting the installer, and unsupported locales cause the installer to run in English. Read More: [Running the Installer in a Different Language](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/running-the-installer-in-a-different-language.html) ## Installing the Oracle Database Software Oracle Database is normally installed by extracting the database image into an OFA-compliant Oracle home and running runInstaller from that directory, with GUI, silent, response-file, and optional Release Update application supported. The process requires appropriate Oracle base and inventory directories, ownership, permissions, configuration choices, and root-script execution or automation. Gold images can be created with setup-wizard options, and Oracle Restart or ASM deployments require Grid Infrastructure for a standalone server beforehand. Read More: [Installing the Oracle Database Software](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/installing-the-oracle-database-software.html) ## Installing Oracle Database Using RPM Packages RPM installation supports single-instance Oracle Database and Instant Client deployments by performing prerequisite checks, extracting software, configuring ownership and inventory, and creating an Oracle home; DBCA can then create a database. Packages may be installed through yum or manually after installing the preinstallation RPM, and the supplied service script can create a default ORCLCDB container with ORCLPDB1 and a listener on port 1521. RPM patching and upgrades are unsupported, Standard Edition 2 is unavailable through this method, and multiple versions may be installed in separate homes. Read More: [Installing Oracle Database Using RPM Packages](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/installing-oracle-database-using-rpm-packages.html) ## Installing Standard Edition High Availability Standard Edition High Availability provides cluster-based failover for single-instance Oracle Database Standard Edition 2 using Oracle Clusterware, ASM, and ACFS. It requires at least two nodes, compatible Grid Infrastructure and database releases, consistent operating-system configuration, supported local or ACFS software storage, ASM or ACFS data storage, shared SPFILE and password files, and appropriate listener registration. Installation involves deploying patched database software on local storage or ACFS, extending the Oracle home to other nodes, running required root scripts, and using DBCA to create the database. Read More: [Installing Standard Edition High Availability](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/installing-oracle-database/installing-standard-edition-high-availability.html) # Oracle Database Postinstallation Tasks Complete configuration tasks after you install Oracle Database. You are required to complete some configuration tasks after Oracle Database is installed. In addition, Oracle recommends that you complete additional tasks immediately after installation. You must also complete product-specific configuration tasks before you use those products. > **Note:** > > This chapter describes basic configuration only. Refer to product-specific administration and tuning guides for more detailed configuration and tuning information. ## Downloading Release Update Patches After installation, download and install the required Oracle Release Updates or Monthly Recommended Patches through My Oracle Support by searching by patch number, bug number, or product criteria, reviewing the patch details and README, downloading, and uncompressing the files. Oracle recommends out-of-place patching with Gold Images for quarterly updates in Oracle AI Database 26ai; OPatch and OPatchAuto remain available for in-place patching, while the Free release does not support release-update patching. Read More: [Downloading Release Update Patches](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/downloading-release-update-patches.html) ## Unlocking and Resetting Oracle Database User Passwords Most Oracle administrative and predefined accounts are locked or have revoked passwords after installation, so accounts must be selectively unlocked and assigned secure passwords before use. Account status and Oracle-maintained users can be checked through data dictionary views, and accounts can be managed with EM Express or SQL\*Plus using ALTER USER commands to lock, unlock, or reset passwords. Internal Oracle-maintained accounts should not be modified except through their associated installation or maintenance scripts. Read More: [Unlocking and Resetting Oracle Database User Passwords](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/unlocking-and-resetting-oracle-database-user-passwords.html) ## Creating a Backup of the root.sh Script Back up the root.sh script after installation because installing additional products into the same Oracle home can overwrite its contents. The backup preserves the original installation information if it is needed later. Read More: [Creating a Backup of the root.sh Script](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/creating-a-backup-of-the-root.sh-script.html) ## Setting Language and Locale Preferences for Client Connections Configure client locale and character-set settings according to the application, operating system, and connection API. OCI applications use NLS\_LANG and related NLS settings, with environment variables taking precedence over Windows Registry values; an incorrect client character set can cause data loss. JDBC applications instead use the Java virtual machine’s default locale and Unicode character handling, while application servers may define their own locale settings. Read More: [Setting Language and Locale Preferences for Client Connections](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/setting-language-and-locale-preferences-for-client-connections.html) ## Recompile Invalid Objects in the Database After installation, patching, or upgrading, recompile invalid objects across the CDB and PDBs using Oracle’s recompilation scripts and catcon.pl. AutoUpgrade normally performs this task, while utlrp.sql and utlprp.sql can recompile all invalid objects and utlprpom.sql can prioritize Oracle-maintained objects. Parallelism and the number of PDBs processed concurrently can be configured, with execution time depending on the number of containers and invalid objects. Read More: [Recompile Invalid Objects in the Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/recompile-invalid-objects-in-the-database.html) ## About Installing Oracle Autonomous Health Framework Oracle Autonomous Health Framework provides proactive health checks and diagnostic collection across Oracle Database, Grid Infrastructure, RAC, MAA, upgrade readiness, and GoldenGate environments by incorporating ORAchk, EXAchk, and TFA capabilities. Although it is preinstalled with Oracle Database, Oracle recommends downloading and installing the latest version from My Oracle Support. Read More: [About Installing Oracle Autonomous Health Framework](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/about-installing-oracle-autonomous-health-framework.html) ## About Changes in Default SGA Permissions for Oracle Database From Oracle Database 12c Release 2, only the Oracle software owner can read and write the SGA by default, improving security but potentially restricting DBAs who rely on OSDBA group access. The ALLOW\_GROUP\_ACCESS\_TO\_SGA initialization parameter can be set to TRUE to permit OSDBA members to access the SGA, although Oracle strongly recommends retaining the default FALSE setting. Read More: [About Changes in Default SGA Permissions for Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/about-changes-in-default-sga-permissions-for-oracle-database.html) ## Checking Installed Oracle Database Contents and Directory Location Use Oracle Universal Installer from the $ORACLE\_HOME/oui/bin directory to inspect installed products and their locations. Launch runInstaller, open Installed Products, select the Oracle Database product, choose Details for additional information, and then close and exit the installer without making changes. Read More: [Checking Installed Oracle Database Contents and Directory Location](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/checking-installed-oracle-database-contents-and-directory-location.html) ## Enabling and Disabling Oracle Database Options After Installation The chopt utility in the Oracle home’s bin directory enables or disables supported database options, including OLAP, Partitioning, and Real Application Testing, after installation. The database must be shut down before running chopt and restarted afterward; OLAP changes also require validation procedures to update the database registry. Oracle Advanced Analytics is enabled by default and cannot be disabled with chopt. Read More: [Enabling and Disabling Oracle Database Options After Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/enabling-and-disabling-oracle-database-options-after-installation.html) ## Starting Oracle Enterprise Manager Database Express Start EM Express by using the URL supplied by Oracle Database Configuration Assistant during database creation. If DBCA did not provide the URL or the HTTPS port must be changed, consult the EM Express configuration procedures in the Oracle Database 2 Day DBA documentation. Read More: [Starting Oracle Enterprise Manager Database Express](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/starting-oracle-enterprise-manager-database-express.html) ## Creating a Fast Recovery Area Create a fast recovery area to centralize RMAN backups, archived logs, control-file autobackups, and database copies, allowing Oracle to manage obsolete recovery files automatically. Configure it with DB\_RECOVERY\_FILE\_DEST and DB\_RECOVERY\_FILE\_DEST\_SIZE, preferably on a separate ASM disk group sized to retain several days of recovery data or meet the database retention policy. ASMCA can create the disk group with the required name, redundancy, and member disks, and multiple databases may share the area with individually sized quotas. Read More: [Creating a Fast Recovery Area](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-postinstallation-tasks/creating-a-fast-recovery-area.html) # Cloning Oracle Database ## Cloning an Oracle Home Cloning an Oracle home creates a configured copy for a new environment. It can accelerate multiple Oracle Database installations by reusing an existing installation, including any patches already applied to the source home. Read More: [Cloning an Oracle Home](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/cloning-oracle-database/cloning-an-oracle-home.html) ## Cloning an Oracle Database Home To clone an Oracle Database home with `clone.pl`, verify the source installation and patches, stop its processes, archive and transfer only the Oracle home, extract it on the target, correct ownership, remove source-specific configuration and database files, and run the cloning script with the target paths and operating-system groups. Review the cloning log, then use Net Configuration Assistant to configure connectivity and Database Configuration Assistant to create a database. Root privileges may be required, and although `clone.pl` is supported in this procedure, it is deprecated in Oracle Database 19c in favor of the software-only installation option. Read More: [Cloning an Oracle Database Home](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/cloning-oracle-database/cloning-an-oracle-database-home.html) # Removing Oracle Database Software ## About Oracle Deinstallation Options The `deinstall` command removes Oracle Database, Grid Infrastructure, Oracle RAC, and Client software from an Oracle home, along with associated configuration. It must be run from the same release as the software being removed, and failed or inactive installations require complete configuration details interactively or through a response file. Before removing Grid Infrastructure, dismount ACFS, disable ADVM, and address any GNS DNS entries. If no other Oracle homes are registered, the command may delete Oracle base directories and can also remove database configuration, user data, and recovery files located outside the Oracle base. Read More: [About Oracle Deinstallation Options](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/removing-oracle-database-software/about-oracle-deinstallation-options.html) ## Oracle Deinstallation (Deinstall) The `deinstall` command stops and removes Oracle software and configuration for a specific Oracle home. It supports interactive, silent, validation-only, response-file, parameter override, output, temporary-file, and log-directory options. In clustered environments, `-local` limits software removal to the current node while deconfiguring remote nodes, and Grid Infrastructure options can preserve local or remote homes during deconfiguration. Use `-help` for additional command information. Read More: [Oracle Deinstallation (Deinstall)](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/removing-oracle-database-software/oracle-deinstallation-deinstall.html) ## Deinstallation Examples for Oracle Database Run `deinstall` from the Oracle home’s `deinstall` directory to remove Oracle Database or Grid Infrastructure software. The command can run interactively or use a response file specified with `-paramfile`; response files can be generated with `-checkonly` or based on the provided template. For Grid Infrastructure, execute the command from the Grid home’s `deinstall` directory and supply the appropriate response file when required. Read More: [Deinstallation Examples for Oracle Database](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/removing-oracle-database-software/deinstallation-examples-for-oracle-database.html) ## Downgrading Oracle Restart To downgrade or troubleshoot Oracle Restart, back up the database SPFILE, record database and Oracle Restart component configurations, and downgrade the database and its Restart resources when necessary. Stop all databases and listeners, deconfigure the current Oracle Restart installation with `roothas.sh -deconfig -force`, update the central inventory, unlock and reconfigure the previous-release Grid home, and restore databases, listeners, and services using their recorded attributes. Read More: [Downgrading Oracle Restart](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/removing-oracle-database-software/downgrading-oracle-restart.html) ## Removing an RPM-based Oracle Database Installation Remove an RPM-based Oracle Database installation as `root` with `yum -y remove oracle-database-ee-19c`. The command automatically handles the default database and listener, but stops if additional databases or listeners are configured. Remove those components manually with DBCA and NETCA as the Oracle software owner, then rerun the `yum` removal command as `root`. Read More: [Removing an RPM-based Oracle Database Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/removing-oracle-database-software/removing-an-rpm-based-oracle-database-installation.html) ## Deinstalling Previous Release Grid Home To remove a previous-release Grid home after an upgrade, log in as `root`, correct the home and parent-directory permissions and ownership, then switch to the Grid Infrastructure software owner and run the `deinstall` command. The procedure uses the previous Grid home, installation owner, and inventory group values appropriate to the environment. Read More: [Deinstalling Previous Release Grid Home](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/removing-oracle-database-software/deinstalling-previous-release-grid-home.html) # Completing Preinstallation Tasks Manually You can complete the preinstallation configuration tasks manually. Oracle recommends that you use Oracle Universal Installer and Configuration Verification Utility (CVU) fixup scripts to complete minimal configuration settings. If you cannot use fixup scripts, then complete minimum system settings manually. ## Configuring Kernel Parameters for Linux Manually configure Linux kernel parameters when fixup scripts or the Oracle Database Preinstallation RPM are unavailable, using the documented minimum values for semaphore limits, shared memory, file handles, asynchronous I/O, network ports, and socket buffers while retaining any higher existing settings. Inspect values with sysctl, persist required changes in `/etc/sysctl.d/97-oracle-database-sysctl.conf`, apply them with `sysctl --system`, and verify the results; increase `fs.file-max` and `fs.aio-max-nr` for demanding RAC workloads. SUSE Linux Enterprise Server additionally requires enabling `boot.sysctl` and setting `vm.hugetlb_shm_group` to the oinstall GID. Configure ephemeral UDP/TCP ports with an even/odd-compatible range beginning at 9000 or higher, sized for workload requirements, and make the setting persistent. Read More: [Configuring Kernel Parameters for Linux](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/completing-preinstallation-tasks-manually/configuring-kernel-parameters-for-linux.html) ## Configuring Default Thread Limits Value for SUSE Linux On SUSE Linux Enterprise Server 12 SP2 or later and version 15 or later, increase systemd’s `DefaultTasksMax` from its typical value of 512 to 65535 to prevent service failures caused by thread limits. Check the current value with `systemctl show --property DefaultTasksMax` or by reviewing `/etc/systemd/system.conf`, uncomment and set the parameter to `65535` if necessary, then reboot or run `systemctl daemon-reload` to activate the change. Read More: [Configuring Default Thread Limits Value for SUSE Linux](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/completing-preinstallation-tasks-manually/configuring-default-thread-limits-value-for-suse-linux.html) ## Configuring Storage Device Path Persistence Manually To preserve Oracle ASM device names, ownership, and permissions across reboots, identify each disk’s stable SCSI identifier with `scsi_id`, enable trusted-device scanning through `/etc/scsi_id.config`, and create a UDEV rules file under `/etc/udev/rules.d/` that assigns the appropriate installation owner, ASM OSDBA group, and mode 0660. Ensure OWNER, GROUP, and MODE precede other rule attributes, copy the rules to every cluster node, run `partprobe`, test the rules with `udevtest`, and reload or restart UDEV using the distribution-specific command. Verify that all ASM devices have the intended persistent paths, ownership, and permissions. Read More: [Configuring Storage Device Path Persistence Manually](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/completing-preinstallation-tasks-manually/configuring-storage-device-path-persistence-manually.html) # Response Files ## Reasons for Using Silent Mode or Response File Mode Response files automate Oracle software installation and configuration by supplying answers to installer prompts, supporting repeatable deployments across multiple systems. Silent mode uses a fully configured response file and the `-silent` option to run unattended without installer screens, while response file mode supplies some or all answers but continues displaying required screens. Silent mode is suitable for scheduled, repeated, or non-GUI installations; response file mode is useful for standardized installations that still require user input. Read More: [Reasons for Using Silent Mode or Response File Mode](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/response-files/reasons-for-using-silent-mode-or-response-file-mode.html) ## Using Response Files Response files support Oracle product installation and configuration in silent or response file mode. Complete all required preinstallation tasks, prepare the response file, run the installer, execute root scripts when prompted, and, for software-only installations, run Net Configuration Assistant and Oracle DBCA in the appropriate automated mode to create the listener and database. Read More: [Using Response Files](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/response-files/using-response-files.html) ## Preparing Response Files Oracle supplies product- and tool-specific response file templates in the relevant Oracle home directories, including files for database installation, DBCA, NETCA, Grid Infrastructure, and Database Client installation. Copy and edit a template according to its instructions, retain the `.rsp` suffix, validate all required values, and secure files with ownership restricted to the installation owner and permissions set to 600 because passwords may be stored in plain text. Alternatively, record a response file during an interactive OUI installation from the Summary page; recorded files exclude passwords and should be reviewed and adjusted before reuse on another system. Read More: [Preparing Response Files](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/response-files/preparing-response-files.html) ## Running Oracle Universal Installer Using a Response File Run `runInstaller` or `gridSetup.sh` as the Oracle software owner with a fully qualified response file path, using `-silent` for noninteractive execution or omitting it for response file mode. Complete normal preinstallation tasks, set `DISPLAY` only for response file mode, and consult the installer’s `-help` option for available parameters. If this is the first Oracle installation, run `orainstRoot.sh` as root, then run the product’s `root.sh` after installation; relative response file paths are not supported. Read More: [Running Oracle Universal Installer Using a Response File](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/response-files/running-oracle-universal-installer-using-a-response-file.html) ## Postinstallation Configuration Using Response File Created During Installation The response file generated during installation can also drive postinstallation configuration through the `-executeConfigTools` option for Oracle Grid Infrastructure or Oracle AI Database. Before execution, add the required configuration passwords, protect the file with 600 permissions, and assign it to the installation owner and inventory group. Run the appropriate `gridSetup.sh` or `runInstaller` command from the Oracle home, optionally adding `-silent`; without that option, configuration progress is displayed through the graphical interface. Read More: [Postinstallation Configuration Using Response File Created During Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/response-files/postinstallation-configuration-using-response-file-created-during-installation.html) ## Postinstallation Configuration Using the ConfigToolAllCommands Script The deprecated `configToolAllCommands` utility performs postinstallation configuration using a separate password response file with `component|variable=value` entries, such as credentials for Grid Infrastructure or database configuration assistants. Create a `.properties` file, populate only the required passwords, secure it with 600 permissions and appropriate ownership, and run the script from `$ORACLE_HOME/cfgtoollogs` using `RESPONSE_FILE=/path/name.properties`. The file should be securely retained only when needed because it contains sensitive credentials. Read More: [Postinstallation Configuration Using the ConfigToolAllCommands Script](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/response-files/postinstallation-configuration-using-the-configtoolallcommands-script.html) ## Running Configuration Assistants Using Response Files Oracle DBCA and NETCA can automate postinstallation database and network configuration using copied and edited response file templates. DBCA uses `dbca.rsp` with `-responseFile` and supports silent execution through `-silent`; response file operation requires a graphical display and `DISPLAY`, while DBCA may also accept equivalent command-line options. NETCA uses `netca.rsp` with `-silent -responsefile` to configure listeners, naming methods, and service names. In both cases, run as the Oracle software owner, set `ORACLE_HOME`, use an absolute response file path, and ensure the template is correctly configured. Read More: [Running Configuration Assistants Using Response Files](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/response-files/running-configuration-assistants-using-response-files.html) # Optimal Flexible Architecture ## About the Optimal Flexible Architecture Standard Oracle Optimal Flexible Architecture (OFA) provides directory, ownership, and configuration guidelines for organizing Oracle installations. It supports coexistence of multiple databases and software versions, simplifies administration and expansion, and promotes consistent support practices. Oracle Universal Installer uses OFA-compliant defaults, which Oracle recommends accepting, particularly for large or multi-database environments. OFA also helps associate an ORACLE\_BASE with Automatic Diagnostic Repository data for incident collection. Read More: [About the Optimal Flexible Architecture Standard](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/optimal-flexible-architecture/about-the-optimal-flexible-architecture-standard.html) ## About Multiple Oracle Homes Support Oracle Database supports installing multiple releases in separate Oracle homes on the same server, but different releases cannot share one home. OFA-compliant directory structures allow databases of different versions and ownership to coexist, simplify administration, protect user home directories, and support repeated installations. Each installation requires extracting the software image into its own home and running the installer there; newer releases can access older databases only for upgrade operations. Read More: [About Multiple Oracle Homes Support](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/optimal-flexible-architecture/about-multiple-oracle-homes-support.html) ## About the Oracle Inventory Directory and Installation The Oracle Inventory directory, or oraInventory, records all Oracle software installations and is writable by installation owners through the OINSTALL group. Existing installations reuse the inventory identified in `/etc/oraInst.loc`; first-time installations determine its location from ORACLE\_BASE, an available OFA path, or the installer user’s home directory. Oracle Database homes are normally placed beneath the Oracle base, while Grid Infrastructure homes use separate locations and may become root-owned after installation. Without ORACLE\_BASE or an OFA path, inventory and software are created under the installer’s home directory. Read More: [About the Oracle Inventory Directory and Installation](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/optimal-flexible-architecture/about-the-oracle-inventory-directory-and-installation.html) ## Oracle Base Directory Naming Convention Oracle base directories use the OFA pattern `_/pm/h/u_`, combining a mount point, standard directory, and installation owner name. The same base may serve multiple installations for one owner, but separate operating system owners require separate bases and should generally have unique accounts for clearer log separation. Oracle recommends a common mount-point and standard-directory path across owners, and neither Oracle bases nor their parent directories may be symbolic links. Read More: [Oracle Base Directory Naming Convention](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/optimal-flexible-architecture/oracle-base-directory-naming-convention.html) ## Oracle Home Directory Naming Convention Oracle home directories follow the OFA pattern `/pm/s/u/product/v/type_n`, where the components identify the mount point, standard directory, owner, software version, installation type, and optional instance counter. This convention supports multiple homes for databases, clients, or Grid Infrastructure within an organized hierarchy; a typical path is `/u01/app/oracle/product/19.0.0/dbhome_1`. Oracle homes, their bases, and all parent directories up to root must not be symbolic links. Read More: [Oracle Home Directory Naming Convention](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/optimal-flexible-architecture/oracle-home-directory-naming-convention.html) ## Optimal Flexible Architecture File Path Examples OFA-compliant installations organize inventory, Oracle bases, administration files, recovery areas, data files, products, and software homes across structured mount points such as `/u01` through `/u04`. The examples distinguish database and Grid Infrastructure layouts for standalone and clustered deployments, including ownership changes for clustered Grid homes, and illustrate multiple database, client, and Oracle home directories. Oracle ASM is recommended for redundancy and throughput, and private or application files should not be stored within OFA directories. Read More: [Optimal Flexible Architecture File Path Examples](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/optimal-flexible-architecture/optimal-flexible-architecture-file-path-examples.html) # Configuring Read-Only Oracle Homes ## About Read-Only Oracle Homes Starting with Oracle Database 18c, an Oracle home can be configured in read-only mode while its underlying file system remains read/write. This configuration separates software installation from operational configuration by relocating user-specific files, logs, and configuration data outside ORACLE\_HOME into ORACLE\_BASE\_HOME and ORACLE\_BASE\_CONFIG. Read-only mode should be enabled before creating the database or listener and does not change database monitoring, diagnosis, or performance-tuning procedures. Read More: [About Read-Only Oracle Homes](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/about-read-only-oracle-homes.html) ## About Oracle Base Homes ORACLE\_BASE\_HOME stores user-specific, instance-specific, and log files for both read-only and read/write Oracle homes. In a read/write installation it is the same directory as ORACLE\_HOME, while in a read-only installation it is located at ORACLE\_BASE/homes/HOME\_NAME; for example, networking administration, trace, and log directories reside there. The orabasehome command, run from ORACLE\_HOME/bin, displays the active ORACLE\_BASE\_HOME path. Read More: [About Oracle Base Homes](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/about-oracle-base-homes.html) ## About Oracle Base Config ORACLE\_BASE\_CONFIG contains Oracle home configuration files. In a read/write installation it is the same as ORACLE\_HOME, whereas in a read-only installation it equals ORACLE\_BASE. Its dbs subdirectory stores configuration files identified by ORACLE\_SID, allowing the directory to support multiple instances. The orabaseconfig command from ORACLE\_HOME/bin displays the configured ORACLE\_BASE\_CONFIG path. Read More: [About Oracle Base Config](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/about-oracle-base-config.html) ## About orabasetab The orabasetab file, located at ORACLE\_HOME/install/orabasetab, defines ORACLE\_BASE, HOME\_NAME, and the relationships among Oracle home directories. Its final colon-delimited entry identifies the Oracle home, base directory, internal home name, and mode indicator, with N denoting read/write and Y denoting read-only. In read-only mode, ORACLE\_BASE\_HOME is ORACLE\_BASE/homes/HOME\_NAME and ORACLE\_BASE\_CONFIG is ORACLE\_BASE; in read/write mode, all three logical locations coincide with ORACLE\_HOME. The file can be inspected by the Oracle software owner. Read More: [About orabasetab](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/about-orabasetab.html) ## Enabling a Read-Only Oracle Home Enable a read-only Oracle home after completing a software-only Oracle Database installation by running roohctl -enable, then create the database with DBCA. The installation requires creating and extracting the database home, running the installer with Set Up Software Only selected, and executing roohctl from the home’s bin directory. For Oracle RAC, run the command on every node or specify a node list. The read-only configuration must be enabled before creating the database or listener. Read More: [Enabling a Read-Only Oracle Home](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/enabling-a-read-only-oracle-home.html) ## Copying demo Directories to Oracle Base Home Because demonstration directories may be modified during use, their required copies must be moved from ORACLE\_HOME to ORACLE\_BASE\_HOME for read-only installations. The affected directories include jdbc, odbc, ord/http, precomp, rdbms, sqlj, sqlplus, and xdk demo paths; symbolic links are required for the odbc, precomp, rdbms, and xdk locations so applications resolve the relocated content. The init.ora file must also be copied to ORACLE\_BASE\_HOME or synchronized there, while plsql/demo/ncmpdemo.sql is not usable in read-only mode. Read More: [Copying demo Directories to Oracle Base Home](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/copying-demo-directories-to-oracle-base-home.html) ## Determining if an Oracle Home is Read-Only Use the orabasehome command from ORACLE\_HOME/bin to determine the Oracle home mode. If it returns the same path as ORACLE\_HOME, the installation is read/write; if it returns ORACLE\_BASE/homes/HOME\_NAME, the installation is read-only. ORACLE\_HOME must be set in the shell environment before running the command. Read More: [Determining if an Oracle Home is Read-Only](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/determining-if-an-oracle-home-is-read-only.html) ## File Path and Directory Changes in Read-Only Oracle Homes Read-only Oracle homes retain the same ORACLE\_HOME and ORACLE\_BASE locations but relocate operational directories. ORACLE\_BASE\_HOME moves from ORACLE\_HOME to ORACLE\_BASE/homes/HOME\_NAME, and ORACLE\_BASE\_CONFIG moves from ORACLE\_HOME to ORACLE\_BASE. Consequently, networking files are stored under ORACLE\_BASE\_HOME/network, while database configuration files are stored under ORACLE\_BASE/dbs instead of ORACLE\_HOME/dbs; read/write installations keep these paths within ORACLE\_HOME. Read More: [File Path and Directory Changes in Read-Only Oracle Homes](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-read-only-oracle-homes/file-path-and-directory-changes-in-read-only-oracle-homes.html) # Oracle Memory Speed CLI Commands ## About Oracle Memory Speed CLI Commands The `omsfscmds` utility administers Oracle Memory Speed (OMS) and requires the OMS daemon to be running. Set `ORACLE_SID` to the daemon’s SID before launching the utility from `$ORACLE_HOME/bin`; the `OMS>` prompt indicates successful startup. Read More: [About Oracle Memory Speed CLI Commands](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/about-oracle-memory-speed-cli-commands.html) ## mkfs and forcemkfs Command Reference Use `mkfs` or `forcemkfs` to format an OMS uber file on a PMEM DAX mount point, optionally specifying a block size; only 4 KB is currently supported. The uber file size must be an exact multiple of 2 MB and cannot be mounted during formatting. `mkfs` rejects an existing OMS file system, whereas `forcemkfs` overwrites it without checking, permanently destroying its data. Read More: [mkfs and forcemkfs Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/mkfs-and-forcemkfs-command-reference.html) ## mount, unmount and lsmount Command Reference Use `mount` to attach an OMS uber file to an existing POSIX directory, `umount` to detach a mounted OMS file system, and `lsmount` to list mount points. A previously mounted uber file cannot be mounted again, OMS supports up to two mount points, and mount directories must exist and should not be writable. Read More: [mount, unmount and lsmount Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/mount-unmount-and-lsmount-command-reference.html) ## df Command Reference The `df` command reports the total, used, and free space in a mounted OMS file system. Its output is expressed in kilobytes and provides the capacity and current utilization for the specified mount path. Read More: [df Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/df-command-reference.html) ## cp Command Reference The `cp` command copies files between POSIX and OMS mount points, within one OMS mount point, or between OMS mount points associated with the same SID. Files in OMS require absolute paths, and `cp` is available only while the Oracle instance is down; Oracle recommends using SQL commands for file transfers while the instance is running. Read More: [cp Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/cp-command-reference.html) ## ls and lls Command Reference Use `ls` to list files in an OMS mount point and `lls` to display detailed file metadata, including blob number, size, block size, database ID, and directory ID. `lls` provides accurate allocated-byte totals, while `ls` may not accurately account for allocated space. Read More: [ls and lls Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/ls-and-lls-command-reference.html) ## rm Command Reference The `rm` command deletes a file from an OMS mount point using its absolute path. It is available only when the Oracle instance is down, deleted files cannot be restored, and removing critical files can prevent the instance from starting. Read More: [rm Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/rm-command-reference.html) ## cd and pwd Command Reference Use `cd` to set the current OMS working directory and `pwd` to display it. After changing the working directory, commands such as `ls` can operate without an explicit mount path. Read More: [cd and pwd Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/cd-and-pwd-command-reference.html) ## lsom and lsof Command Reference The `lsom` diagnostic operation lists Oracle process identifiers and the OMS files they have open, while `lsof` lists process identifiers holding a specified file open. These operations require the Oracle instance to be running, write results to a specified dump file, and require the alert log to map Oracle process identifiers to operating-system process IDs. Read More: [lsom and lsof Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/lsom-and-lsof-command-reference.html) ## Daemon Control Command Reference The `daemon` command controls the OMS daemon: `daemon exit` marks the shared memory segment for deletion and requests a clean daemon shutdown, while `trace` changes daemon trace verbosity to low, medium, or high, with medium as the default. Diagnostic trace files are stored under the OMS directory within the Oracle diagnostic destination. Read More: [Daemon Control Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/daemon-control-command-reference.html) ## Diagnostics and Tracing The `dump` command provides diagnostic subcommands for printing OMS information, and the `trace` command traces internal OMS modules. Oracle technical support should be consulted before using these diagnostic and tracing options. Read More: [Diagnostics and Tracing](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-memory-speed-cli-commands/diagnostics-and-tracing.html) # Managing Oracle Database Port Numbers ## About Managing Ports Oracle Database components are assigned ports during installation from predefined ranges, beginning with the lowest available number. Administrators should review these assignments, prevent conflicts between services, and use `/bin/netstat -a` to identify ports currently in use. Oracle checks for ports occupied by other Oracle installations, active processes, or entries in `/etc/services`, advancing through the assigned range until it finds an available port. Read More: [About Managing Ports](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/managing-oracle-database-port-numbers/about-managing-ports.html) ## Oracle Database Component Port Numbers and Protocols During a single-instance installation, the Oracle Net Services Listener typically uses TCP port 1521 and can be reassigned with Net Configuration Assistant, while Oracle Connection Manager uses TCP port 1630 and is configured in `cman.ora`. Oracle XML DB HTTP and FTP ports default to 0 and must be configured manually for HTTP or FTP access. Read More: [Oracle Database Component Port Numbers and Protocols](https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/managing-oracle-database-port-numbers/oracle-database-component-port-numbers-and-protocols.html)