DB Creation   «Prev  Next»

Lesson 2 Preparation for this module
Objective Prepare the Environment that you need in order to create a Database

Oracle Database Environment Preparation

If you intend to work through the process of creating a database, there are a few things worth confirming before you proceed. Some of you may be taking this course without access to Oracle software at all, in which case none of the hands-on preparation below applies to you directly, but work through this lesson anyway. It contains information every DBA needs to know, whether or not you're installing anything today. Assuming you do intend to create a database, make sure of the following first:
  1. If you haven't yet installed the Oracle database software on your system, do that now.
  2. Know the passwords for the SYSTEM and SYS users.
  3. Have access to a text editor, such as vi on Linux/UNIX or a comparable editor on Windows, and know how to use it.

The easiest way to prepare for this module is to install Oracle on a machine other than a production server, taking the default options where possible. Linux is by far the most common production platform today, so the checklist below is written with a Linux install in mind. Before continuing, make sure you've completed the steps above.

Installer Planning Checklist

Work through this before you launch the installer at all:
  • Read the release notes for your platform at docs.oracle.com/en/database/database.html.
  • Check the certification matrix on My Oracle Support for your exact OS and hardware. New platforms get certified after a release ships, so this list changes over time even after installation.
  • Review the licensing information for the edition you're installing, in the Oracle AI Database Licensing Information User Manual, before enabling anything you haven't licensed.
  • Run the installer through the Summary screen without actually installing. Oracle Universal Installer runs every prerequisite check and generates fixup scripts automatically; you can stop before committing to the install itself.
  • Run Oracle ORAchk, part of the Autonomous Health Framework, for an automated pre-flight check:
    # Before a fresh install:
    ./orachk -profile preinstall
    
    # Before upgrading an existing database:
    ./orachk -pregupgrade -targetversion 23.26.0.0.0
  • Check for Oracle Grid Infrastructure if you plan to use Oracle ASM or Oracle Restart, install Grid Infrastructure for a standalone server first.
  • Check running Oracle processes. A standalone database not using ASM doesn't need to be shut down while Grid Infrastructure installs; one using ASM will have its ASM instances restarted automatically during the install.
  • Make sure cron jobs won't run mid-install. A cleanup job firing while the installer is mid-run can delete temporary files the installer still needs, causing unexplained failures.
  • Have your My Oracle Support credentials ready, you'll likely need them for updates and software downloads during installation.
  • Decide on your management tool. If you're centralizing management through Oracle Enterprise Manager Cloud Control rather than managing the database locally, have the OMS host, OMS port, EM admin username and password, and the ASMSNMP user's password ready before you start.
  • Check your memory allocation. If total physical memory exceeds 4 GB, Automatic Memory Management isn't selectable during install, use Automatic Shared Memory Management instead, which distributes available memory across SGA components automatically.
  • Decide how root-privileged scripts get run: manually, when prompted, or automatically via sudo, with a sudoers-list user's credentials supplied during install.
  • Confirm client interoperability. Oracle has discontinued developing 32-bit Oracle Database clients as of 26ai; 64-bit clients are recommended. Existing 32-bit clients can keep running under the documented Client/Server Interoperability Support Matrix (Doc ID 207303.1) and the standard release support lifecycle (MOS 742060.1), but don't plan new 32-bit deployments.

Server Hardware, OS, and Configuration Checklist

  • Run level: 3 or 5.
  • Display: 1024x768 minimum for the graphical installer; not needed for silent or VNC-based installs.
  • Network: the server needs to be connected before you start.
  • RAM: at least 1 GB for the database itself, 2 GB recommended in practice; at least 8 GB if Grid Infrastructure is involved.
  • Supported Linux versions are specific down to the kernel build, not just the distribution name. As of this release, minimums include Oracle Linux 8.6 with UEK7 (5.15.0-202.135.2.el8uek.x86_64 or later, and Oracle explicitly recommends this as your floor rather than anything older), Oracle Linux 9.2/9.6, Oracle Linux 10, RHEL 8.6/9.2/10, and SUSE Linux Enterprise Server 15 SP5. Arm (aarch64) is also now supported, starting with Oracle Linux 8.6 UEK7 (added in Release Update 23.7) and extended to Oracle Linux 9.4 UEK7 (Release Update 23.26.2). Check the current release notes for the exact minimum kernel build for your specific OS version, these get revised as UEK and RHEL kernels are updated.
  • Transparent HugePages: set it to madvise, not disabled. This is a real reversal from older guidance worth knowing if you learned Oracle administration on an earlier release: "disable Transparent HugePages" used to be standard advice, and is now actively wrong. The current recommendation is madvise on all UEK7-and-later kernels. The Preinstallation RPM sets this for you automatically if you use it.
  • /tmp: at least 1 GB free.
  • Swap space: for the database itself, 1-2 GB RAM scales to 1.5x RAM, 2-16 GB RAM scales 1:1 with RAM, and anything above 16 GB RAM needs a flat 16 GB of swap. If you're also running Oracle Restart, the minimums are higher: 8-16 GB RAM needs swap equal to RAM, above 16 GB still needs 16 GB flat. Either way, if HugePages is enabled, deduct that allocation from available RAM before calculating swap.
  • oraInventory and the OINSTALL group: for upgrades, the installer detects an existing inventory from /etc/oraInst.loc and reuses it. For new installs, if you haven't configured one yet, Oracle Universal Installer sets it up for you, one directory level above your Oracle base, using your installation owner's primary group as the inventory group. Every Oracle software owner on the server must have OINSTALL as their primary group.
  • OS users and groups: create these before installing, not during. Names must be ASCII only. The Preinstallation RPM can auto-create the standard oracle user along with the oinstall (oraInventory) and dba (OSDBA) groups for you.
  • Mount points: follow Optimal Flexible Architecture, covered in the previous lesson.
  • Oracle home path: ASCII characters only, this restriction covers the installation owner's username too, since it defaults into some home paths.
  • Environment variables to unset, if reusing an existing OS user for a new install: $ORACLE_HOME, $ORA_NLS10, and $TNS_ADMIN. Separately, unset $ORA_CRS_HOME entirely if it's set, and don't use it as a user environment variable except when Oracle Support specifically directs you to.
  • Locale/NLS: set this if your environment needs a specific language or territory; it governs date formatting, number formatting, and UI language for both server and clients.
  • Shared memory: /dev/shm must be mounted as tmpfs with rw and exec permissions, without noexec or nosuid. Most distributions set this correctly by default; only worth checking manually if CVU or the installer flags a failure here.
  • Symlinks: neither Oracle home nor Oracle base, nor any directory in the path up to root, can be a symlink.

Storage Checklist

  • Disk space for the software itself: at least 4.2 GB for a standalone Grid Infrastructure install, at least 8.3 GB for Oracle AI Database Enterprise Edition, the same figures apply on both x86-64 and Arm. Oracle recommends allocating roughly 100 GB overall in practice, to leave room for future patches on top of the existing Oracle home.
  • Database file storage: either a file system, ideally separate from the one your OS or Oracle software lives on, on an LVM volume, a RAID device, or NFS against certified network-attached storage, or Oracle Automatic Storage Management, which comes as part of a Grid Infrastructure install.
  • Recovery plan: if you want recovery configured during installation, decide between a fast recovery area on a plain file system or an ASM disk group configured through ASMCA.

Installing the Preinstallation RPM

On Oracle Linux and RHEL, Oracle publishes a Preinstallation RPM that automates most of the checklist above: it installs required OS packages, creates the oracle user and the oinstall/dba groups if they don't exist, sets Transparent HugePages to madvise, and writes the recommended kernel parameters for you.
The fastest path, a single command that pulls in both the Preinstallation RPM and the database software together:
yum -y install oracle-ai-database-ee-26ai
If you'd rather install the Preinstallation RPM on its own first:
# Oracle Linux 8 and later:
dnf -y install oracle-ai-database-preinstall-26ai
On RHEL specifically, the package isn't in the default repositories, you download it directly from Oracle's yum server first. For RHEL 8:
curl -o oracle-ai-database-preinstall-26ai-1.0-1.el8.x86_64.rpm \
  https://yum.oracle.com/repo/OracleLinux/OL8/appstream/x86_64/getPackage/oracle-ai-database-preinstall-26ai-1.0-1.el8.x86_64.rpm

yum -y localinstall oracle-ai-database-preinstall-26ai-1.0-1.el8.x86_64.rpm
rm oracle-ai-database-preinstall-26ai-1.0-1.el8.x86_64.rpm
The same pattern applies for RHEL 9 and RHEL 10, just swap OL8/el8 for OL9/el9 or OL10/el10 in both the URL and the filename.

Kernel Parameters

If you used the Preinstallation RPM, your kernel parameters already live in /etc/sysctl.d/99-oracle-ai-database-server-26ai-preinstall-sysctl.conf, written there automatically. If you skipped the RPM, or CVU reports values that don't match the minimums, set them yourself in a file you create at /etc/sysctl.d/97-oracle-database-sysctl.conf:
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 4294967295
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65535
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
Apply and confirm the change:
/sbin/sysctl --system
/sbin/sysctl -a
A couple of things worth knowing: the old /etc/sysctl.conf file is deprecated, don't use it. And if you set the same parameter in more than one file under /etc/sysctl.d/, the file with the lexically later filename wins, which is exactly why the RPM's own file is named 99-..., to take precedence over a manually created 97-... file if both happen to exist. Avoid duplicating settings across files rather than relying on that precedence rule.

26ai-Specific Changes Worth Planning For

A few things have changed in recent releases that are worth knowing about, particularly if you've installed Oracle before and are working from memory:
  • Multitenant architecture is mandatory. This isn't new to 26ai specifically, a multitenant container database has been the only supported architecture since Oracle Database 21c. If you haven't touched Oracle since an older release, this is the biggest structural change to plan around: every database you create will be a CDB with at least one PDB, there's no non-CDB option anymore.
  • TDE encryption defaults have changed. If you use Transparent Data Encryption, recent releases moved tablespace encryption from AES-CFB to AES-XTS cipher mode, moved column encryption from CBC to GCM mode, and raised the default key size to AES256 for both, up from AES192 (column) and AES128 (tablespace) previously. This isn't a move to AES for the first time, TDE has used AES for a long time, it's a move to a stronger mode and larger default key. If you're upgrading a TDE-enabled database, review the current encryption migration guidance rather than assuming your existing configuration carries forward unchanged.
  • Weak RADIUS authentication is blocked by default. If your environment relies on older RADIUS client configurations, you may need an explicit sqlnet.ora setting to permit them going forward, worth checking against your specific release's networking documentation rather than assuming your existing sqlnet.ora will keep working unmodified.

Oracle Inventory Directory

The Oracle inventory directory stores the inventory of Oracle software installed on the server. This directory is required and is shared among every installation of Oracle software on that server. When you first install Oracle, the installer checks for an existing OFA-compliant directory structure in the format /u[01-09]/app. If one exists, the installer creates an Oracle inventory directory there, such as:
/u01/app/oraInventory
If the ORACLE_BASE variable is defined for the Oracle OS user, the installer instead places Oracle inventory at:
ORACLE_BASE/../oraInventory
For example, if ORACLE_BASE is defined as /ora01/app/oracle, the installer places Oracle inventory at:
/ora01/app/oraInventory
If the installer finds neither a recognizable OFA-compliant structure nor an ORACLE_BASE variable, it creates the inventory under the OS user's HOME directory instead. If HOME is /home/oracle, for instance, Oracle inventory ends up at:
/home/oracle/oraInventory

SEMrush Software 2 SEMrush Banner 2