DEV Community: Vahid Yousefzadeh

Installing Oracle AI Database 26ai on Oracle Linux 10

Vahid Yousefzadeh — Sun, 23 Aug 2026 17:37:49 +0000

Starting with Oracle AI Database 26ai Release Update 23.26.2, the Linux x86–64 operating system is supported with the following minimum supported versions:

Oracle Linux 10 with the Unbreakable Enterprise Kernel 8: 6.12.0–104.43.4.2.el10uek.x86_64 or later
Oracle Linux 10 with the Red Hat Compatible Kernel: 6.12.0–55.40.1.0.1.el10_0.x86_64 or later

In this article, we will walk through the installation of Oracle AI Database 26ai on Oracle Linux 10.2.

The installation process can be divided into two main parts. First, we prepare the operating system for Oracle Database by configuring the hostname, local package repository, required packages, Oracle user and groups, kernel parameters, resource limits, directories, and environment variables.

In the second part, we install the Oracle Database software, apply the required Release Update (RU), execute the required root scripts, and finally create a database using Database Configuration Assistant (DBCA).

1. Preparing Oracle Linux 10 for Oracle Database Installation

Before installing Oracle AI Database 26ai, we need to prepare the operating system.

The following sections describe the main preparation steps.

Step 1: Configure the Hostname

The first step is to configure the hostname of the Oracle Linux server.

the hostname is set to OL10.

First, edit /etc/hostname:

[root@localhost ~]# vi /etc/hostname
OL10

We also configure /etc/hosts:

[root@localhost ~]# vi /etc/hosts
# Loopback entries; do not change.
# For historical reasons, localhost precedes localhost.localdomain:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
# See hosts(5) for proper format and other examples:
# 192.168.1.10 foo.example.org foo
# 192.168.1.13 bar.example.org bar

192.168.1.40 OL10

The hostname can be changed immediately without rebooting:

[root@localhost ~]# hostname OL10
[root@localhost ~]# su -
Last login: Sat Aug 22 15:36:26 EDT 2026 from 192.168.1.35 on pts/1
[root@OL10 ~]#

Step 2: Configure a Local Oracle Linux 10 Repository

The next step is to make the Oracle Linux installation media available as a local package repository.

This is particularly useful in environments where the server does not have direct Internet access.

First, create a mount point:

[root@OL10 ~]# mkdir /dvd

Then mount the Oracle Linux installation media:

[root@OL10 ~]# mount /dev/sr0 /dvd
mount: /dvd: WARNING: source write-protected, mounted read-only.

Now, we can configure YUM/DNF to use it.

First, remove the existing repository definitions:

[root@OL10 ~]# rm -rf /etc/yum.repos.d/*

Create a new repository file:

[root@OL10 ~]# vi /etc/yum.repos.d/OEL10.repo
[InstallMedia-BaseOS]
name=OEL10 - BaseOS
metadata_expire=-1
gpgcheck=0
enabled=1
baseurl=file:///dvd/BaseOS/

[InstallMedia-AppStream]
name=OEL10 - AppStream
metadata_expire=-1
gpgcheck=0
enabled=1
baseurl=file:///dvd/AppStream/

Step 3: Install the Oracle AI Database Preinstallation Package

Oracle provides a preinstallation RPM for Oracle AI Database 26ai. This package performs the OS-level preparation required by Oracle, including:

Installing the required RPM dependencies.
Configuring the required kernel parameters.
Configuring the required user limits.
Creating and configuring the required Oracle groups and users.
Applying other OS settings required for Oracle AI Database 26ai.

In this lab, the following package is used:

oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm

We install it using:

[root@OL10 source]# yum -y localinstall oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm

The package automatically identifies and installs many of the packages required by Oracle Database 26ai.

For example, the installation pulls packages such as:

bc
binutils
elfutils-libelf
fontconfig
glibc
glibc-devel
glibc-headers
ksh
libaio
libgcc
libibverbs
libstdc++
libvirt-libs
libxcb
libX11
libXau
libXi
libXrender
libXtst
libxcrypt-compat
make
policycoreutils
policycoreutils-python-utils
smartmontools
sysstat

and their required dependencies.

The preinstallation package also performs important Oracle operating-system preparation tasks.

For example, after installing it, the following files are available:

[root@OL10 ~]# ls -l /etc/security/limits.d
total 4
-rw-r--r--. 1 root root 1245 Aug 22 15:48 oracle-ai-database-preinstall-26ai.conf

The corresponding sysctl configuration file is also created:

[root@OL10 ~]# ls -lh /etc/sysctl.d/99-oracle-ai-database-preinstall-26ai-sysctl.conf
-rw-r--r--. 1 root root 2.4K Aug 22 15:48 /etc/sysctl.d/99-oracle-ai-database-preinstall-26ai-sysctl.conf

Step 4: Configure Firewall and SELinux

The next step concerns the operating-system security services.

Whether these services should be disabled depends on the environment and security requirements.

Firewall

In a test or lab environment, the firewall can be stopped and disabled:

[root@OL10 ~]# systemctl stop firewalld
 [root@OL10 ~]# systemctl disable firewalld
Removed '/etc/systemd/system/multi-user.target.wants/firewalld.service'.
Removed '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'.

The Oracle Database software does not inherently require the firewall to be disabled.

In a production environment, it is generally preferable to keep the firewall enabled and allow only the required Oracle Database and listener ports.

SELinux

The lab configuration also sets SELinux to disabled:

[root@OL10 ~]# vi /etc/sysconfig/selinux
SELINUX=disabled

Again, disabling SELinux is not inherently required simply to install Oracle Database 26ai. The appropriate configuration depends on the organization’s security policies and the Oracle software components being deployed.

Step 5: Create the Oracle Directories

Next, we create the directories that will be used for the Oracle software and Oracle base.

[root@OL10 ~]# mkdir /oracle/26.2 /oracle/base /oraInventory -p

Then change their ownership:

[root@OL10 ~]# chown -R oracle:oinstall /oracle /oraInventory

The /oraInventory directory stores information about installed Oracle products and their configuration.

Step 6: Configure Oracle Environment Variables

The Oracle environment variables are configured in the Oracle user’s login profile.

[oracle@OL10 ~]$ vi .bash_profile
export ORACLE_SID=db26ai
export ORACLE_BASE=/oracle/base
export ORACLE_HOME=/oracle/26.2
export PATH=${PATH}:$HOME/bin:$ORACLE_HOME/bin:/oracle/26.2/bin/
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib
export TMP=/tmp
export TMPDIR=$TMP

2. Installing Oracle AI Database 26ai

After completing the operating-system preparation, we can start installing the Oracle Database software.

Extract the Oracle Database Software and Patches

First, extract the Oracle AI Database 26ai software into the Oracle Home directory:

 [oracle@OL10 ~]$ unzip /source/LINUX.X64_2326100_db_home.zip -d /oracle/26.2/

The Oracle Home is now ready for the installation.

Next, extract the required OPatch utility for 23.26.2:

[oracle@OL10 ~]$ unzip /source/p6880880_236R2_Linux-x86-64.zip -d /oracle/26.2/

Then, extract the 23.26.2 Release Update patch into a separate directory:

[oracle@OL10 ~]$ unzip /source/p39088031_230000_26R2_Linux-x86-64.zip -d /patch26.2/

Applying the Release Update and Launching the Installer

Before starting the Oracle Database installation, apply the 23.26.2 Release Update (RU) to the Oracle Home.

[oracle@OL10 ~]$ cd /oracle/26.2/
[oracle@OL10 26.2]$ ./runInstaller -applyRU /patch26.2/39088031/39093711/

Two operations will be performed: first the home will be patched, and then the installer will be launched.

Operation 1:

Preparing the home to patch...
Applying the patch /patch26.2/39088031/39093711/...
Successfully applied the patch.
The log can be found at: /tmp/InstallActions2026-08-22_04-02-40PM/installerPatchActions_2026-08-22_04-02-40PM.log

Operation 2:

Launching Oracle AI Database Setup Wizard...

The installer first patches the Oracle Home and, after successfully applying the RU, automatically launches the Oracle AI Database Setup Wizard to continue the installation.

Step 1: Choose the Installation Option

The first step determines whether the Oracle software should be installed only or whether a database should also be created as part of the installation.

For a software-only installation, select the option that installs the database software without creating a database.

In this lab, the Oracle software is installed first and the database is created afterward using DBCA.

Step 2: Select Single Instance Database Installation

“Single instance database installation” is appropriate when Oracle Database is being installed on a standalone server rather than an Oracle RAC environment.

Oracle RAC requires additional Grid Infrastructure and cluster configuration, while a single-instance installation does not.

Step 3: Specify Oracle Base

The Oracle Home is already determined by the location from which the installer is launched.

The Oracle Base can be reviewed or changed during installation.

Step 4: Specify the Oracle Inventory

The installer asks for the location of the Oracle Inventory. The Oracle Inventory contains information about Oracle products installed on the server.

Step 5: Operating System Groups

The installer automatically identifies the operating-system groups created for Oracle. These groups provide different levels of administrative privileges for Oracle software and database administration.

The preinstallation package prepares the required operating-system configuration automatically.

Step 6: Root Script Configuration

At the end of the installation, Oracle requires root-level scripts to be executed.

The installer can either request the root password and execute the scripts automatically or allow the DBA to execute them manually.

Step 7: Prerequisite Checks

The installer performs a series of prerequisite checks before starting the installation.

These checks can identify problems with:

Operating-system packages
Memory
Swap
Disk space
Kernel configuration
Resource limits
Operating-system configuration

Step 8: Installation Summary

The installer displays a summary of the selected configuration.

Review the settings carefully before starting the installation.

Step 9: Install the Oracle Software

After confirming the configuration, the installer begins copying and configuring the Oracle software.

At this point, the Oracle Home is populated and the required Oracle components are installed.

Executing the Root Scripts

Write on Medium
After the Oracle software installation finishes, two root scripts must be executed.

[root@OL10 ~]# /oraInventory/orainstRoot.sh
Changing permissions of /oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.
Changing groupname of /oraInventory to oinstall.
The execution of the script is complete.

[root@OL10 ~]# /oracle/26.2/root.sh
Performing root user operation.
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /oracle/26.2
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin …
Copying oraenv to /usr/local/bin …
Copying coraenv to /usr/local/bin …
Creating /etc/oratab file…
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.

Verifying the Oracle Software Installation

After the installation is complete, we can test SQL*Plus.

[oracle@OL10 ~]$ sqlplus "/as sysdba"
SQL*Plus: Release 23.26.2.0.0 - Production
Version 23.26.2.0.0

This confirms that the Oracle AI Database 26ai software has been installed successfully.

At this stage, however, the software installation and database creation are separate tasks. The next step is to create the database.

3. Creating the Database with DBCA

Oracle Database Configuration Assistant (DBCA) is used to create and configure the database.

[oracle@OL10 ~]$ dbca

Step 1: Create Database

DBCA can also be used to manage existing databases, but in this section our objective is to create a new database.

Step 2: Configuration Mode

DBCA provides different configuration modes.

If detailed control over the database configuration is required, select:

Advanced Configuration

For a straightforward installation, the typical configuration can be sufficient.

Advanced configuration is useful when the DBA needs to explicitly configure items such as storage, memory, database components, character set, connection mode, or other database properties.

Step 3: Database Type and Template

The next screen determines the database type and template.

For a standalone database, select:

Single Instance Database

For an Oracle RAC environment, the corresponding RAC option should be selected.

The template determines the initial database configuration.

Common templates include:

Custom Database
General Purpose or Transaction Processing
Data Warehouse A Custom Database provides the greatest control over database configuration.

For a typical OLTP environment, General Purpose or Transaction Processing is normally an appropriate starting point.

In this lab, the default template is used.

Step 4: Database Identification

The database name and SID are configured on this screen.

For example, the lab environment uses:

ORACLE_SID=db26ai

The database name identifies the database, while the SID identifies the instance.

DBCA also provides an option to specify the PDB name.

If multiple PDBs are created through the relevant DBCA option, the specified PDB name can be used as the basis for their names.

There is also an option to create an empty container database if no user PDB is required during database creation.

Step 5: Database Storage

This screen determines where the database files will be stored.

Database files include:

Data files
Control files
Online redo logs

Oracle Managed Files (OMF) can also be enabled.

The storage layout should be designed according to the workload and availability requirements of the database.

Step 6: Fast Recovery Area and ARCHIVELOG

DBCA provides the option to configure the Fast Recovery Area (FRA).

The FRA provides a managed location for files such as:

Archived redo logs
RMAN backup-related files
Flashback logs
The database can also be configured to operate in ARCHIVELOG mode.

For production databases, ARCHIVELOG mode is generally important when backup and recovery requirements include online backups, point-in-time recovery, or other recovery features.

Step 7: Listener Configuration

The listener configuration can be performed during database creation.

DBCA can create a new listener or use an existing listener.

The Oracle listener is responsible for accepting incoming client connection requests and directing them to the appropriate database service.

Step 8: Database Security

DBCA also provides options for additional database security components, such as:

Database Vault
Oracle Label Security

These features should be enabled according to the organization’s security requirements.

Step 9: Memory Configuration

DBCA provides several approaches for configuring database memory.

The main approaches are:

1. Manual Shared Memory Management

With manual shared memory management, the DBA explicitly configures the individual memory components.

2. Automatic Shared Memory Management

With Automatic Shared Memory Management, Oracle manages the sizes of individual SGA components based on the configured memory settings.

3. Automatic Memory Management

Automatic Memory Management uses MEMORY_TARGET and allows Oracle to manage the SGA and PGA within the configured memory target.

The appropriate memory-management method depends on the operating system, Oracle version, workload, and DBA requirements.

Step 10: Database Sizing

The Sizing section allows the DBA to configure parameters such as:

Database block size
PROCESSES

The block size is an important database-level decision. If a non-default block size is required, the database should be created using an appropriate custom configuration.

The PROCESSES parameter controls the maximum number of operating-system user processes that can connect to the database.

Step 11: Character Set

The character set determines how character data is stored and interpreted.

The appropriate character set should be selected based on the applications and languages that will use the database.

Step 12: Connection Mode

The connection mode determines how sessions are handled by the Oracle server.

For this installation, select:

Dedicated Server

With dedicated server architecture, each client session is associated with a dedicated server process.

Step 13: Cloud Control Registration

DBCA can also provide configuration options for registering the database with Oracle Enterprise Manager Cloud Control.

Step 14: Database Passwords

DBCA requires passwords for administrative database accounts such as:

SYS
SYSTEM
PDBADMIN

Step 15: Create the Database

After reviewing all configuration options, select:

Create Database

DBCA now begins creating the database using the configuration selected in the previous steps.

Step 16: Configuration Summary

Before or during the database creation process, DBCA provides a summary of the selected configuration.

Step 17: Database Creation in Progress

DBCA now creates the database.

During this stage, Oracle creates and configures the required database components, including the container database and the configured PDB.

The duration of this process depends on the server’s CPU, memory, and storage performance.

Step 18: Database Creation Completed

When DBCA completes successfully, the wizard displays a confirmation that the database has been created.

4. Verifying the Database

The final step is to verify the database from SQL*Plus.

[oracle@OL10 ~]$ sqlplus "/as sysdba"

SQL*Plus: Release 23.26.2.0.0 - Production

Version 23.26.2.0.0

Connected to:
Oracle AI Database 26ai Enterprise Edition Release 23.26.2.0.0 - Production
Version 23.26.2.0.0

Now check the PDBs:

SQL> show pdbs

CON_ID CON_NAME OPEN MODE RESTRICTED
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

2 PDB$SEED READ ONLY NO

3 VAHID READ WRITE NO

This confirms that:

PDB$SEED is available in READ ONLY mode.
The user PDB VAHID is open in READ WRITE mode.

Incremental Backup Using pg_basebackup in PostgreSQL 18

Vahid Yousefzadeh — Wed, 19 Aug 2026 18:02:06 +0000

In this article, I will show how to create a full backup and an incremental backup using pg_basebackup in PostgreSQL 18. I will then use pg_combinebackup to combine the backups and restore the database.

Preparing PostgreSQL

First, we need to enable the required parameters in postgresql.conf.

Add or modify the following parameters:

[postgres@OL8 ~]$ vi /var/lib/pgsql/18/data/postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'cp "%p" "/archive/%f"'
summarize_wal = on

The summarize_wal parameter enables WAL summarization, which is required for incremental backups.

After changing these parameters, restart PostgreSQL:

[postgres@OL8 ~]$ /usr/pgsql-18/bin/pg_ctl -D /var/lib/pgsql/18/data -l logfile restart
waiting for server to shut down.... done
server stopped
waiting for server to start.... done
server started

Creating Backup Directories

Next, create separate directories for the full and incremental backups:

[root@OL8 ~]# mkdir /PGbackup/Full /PGbackup/Incremental -p
[root@OL8 ~]# chown -R postgres.postgres /PGbackup

Now the environment is ready to create the full backup.

Creating the Full Backup

Run pg_basebackup as the postgres user:

[postgres@OL8 ~]$ pg_basebackup -D /PGbackup/Full/ -P
23648/23648 kB (100%), 1/1 tablespace

The backup directory contains a complete PostgreSQL data directory:

[postgres@OL8 ~]$ ls -l /PGbackup/Full/
-rw-------. 1 postgres postgres    229 Aug 17 20:55 backup_label
-rw-r-----. 1 postgres postgres    227 Aug 17 20:55 backup_label.old
-rw-------. 1 postgres postgres 138089 Aug 17 20:55 backup_manifest
drwxr-x---. 5 postgres postgres     33 Aug 17 20:55 base
-rw-------. 1 postgres postgres     30 Aug 17 20:55 current_logfiles
drwxr-x---. 2 postgres postgres   4096 Aug 17 20:55 global
drwxr-x---. 2 postgres postgres     32 Aug 17 20:55 log
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_commit_ts
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_dynshmem
-rw-r-----. 1 postgres postgres   5721 Aug 17 20:55 pg_hba.conf
-rw-r-----. 1 postgres postgres   2681 Aug 17 20:55 pg_ident.conf
drwxr-x---. 4 postgres postgres     68 Aug 17 20:55 pg_logical
drwxr-x---. 4 postgres postgres     36 Aug 17 20:55 pg_multixact
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_notify
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_replslot
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_serial
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_snapshots
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_stat
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_stat_tmp
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_subtrans
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_tblspc
drwxr-x---. 2 postgres postgres      6 Aug 17 20:55 pg_twophase
-rw-r-----. 1 postgres postgres      3 Aug 17 20:55 PG_VERSION
drwxr-x---. 4 postgres postgres     77 Aug 17 20:55 pg_wal
drwxr-x---. 2 postgres postgres     18 Aug 17 20:55 pg_xact
-rw-r-----. 1 postgres postgres     88 Aug 17 20:55 postgresql.auto.conf
-rw-r-----. 1 postgres postgres  32453 Aug 17 20:55 postgresql.conf

The backup_manifest file is particularly important because it is used to identify the contents of the backup when creating an incremental backup.

Making Changes to the Database

Now, let’s make some changes to the database after the full backup has been created.

First, create a new database:

postgres=# create database vahid;
CREATE DATABASE

postgres=# \c vahid
You are now connected to database "vahid" as user "postgres".

vahid=# create table tb(id int,name varchar(100));
CREATE TABLE

vahid=# insert into tb values(1,'Vahid Yousefzadeh');
INSERT 0 1

At this point, the full backup does not contain these changes because they were made after the full backup was created.

Creating the Incremental Backup

Now we can create an incremental backup based on the full backup.

Use the backup_manifest from the full backup as the reference:

[postgres@OL8 ~]$ pg_basebackup -D /PGbackup/Incremental/ --incremental /PGbackup/Full/backup_manifest -P
11477/31360 kB (36%), 1/1 tablespace

The incremental backup is much smaller than the full backup because it contains only the data required to update the referenced backup.

The resulting directory contains another backup manifest and the required PostgreSQL files:

[postgres@OL8 ~]$ ls -lh /PGbackup/Incremental/
total 252K
-rw-------. 1 postgres postgres  286 Aug 17 20:59 backup_label
-rw-r-----. 1 postgres postgres  227 Aug 17 20:59 backup_label.old
-rw-------. 1 postgres postgres 184K Aug 17 20:59 backup_manifest
drwxr-x---. 6 postgres postgres   46 Aug 17 20:59 base
-rw-------. 1 postgres postgres   30 Aug 17 20:59 current_logfiles
drwxr-x---. 2 postgres postgres 4.0K Aug 17 20:59 global
drwxr-x---. 2 postgres postgres   32 Aug 17 20:59 log
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_commit_ts
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_dynshmem
-rw-r-----. 1 postgres postgres 5.6K Aug 17 20:59 pg_hba.conf
-rw-r-----. 1 postgres postgres 2.7K Aug 17 20:59 pg_ident.conf
drwxr-x---. 4 postgres postgres   68 Aug 17 20:59 pg_logical
drwxr-x---. 4 postgres postgres   36 Aug 17 20:59 pg_multixact
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_notify
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_replslot
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_serial
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_snapshots
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_stat
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_stat_tmp
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_subtrans
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_tblspc
drwxr-x---. 2 postgres postgres    6 Aug 17 20:59 pg_twophase
-rw-r-----. 1 postgres postgres    3 Aug 17 20:59 PG_VERSION
drwxr-x---. 4 postgres postgres   77 Aug 17 20:59 pg_wal
drwxr-x---. 2 postgres postgres   18 Aug 17 20:59 pg_xact
-rw-r-----. 1 postgres postgres   88 Aug 17 20:59 postgresql.auto.conf
-rw-r-----. 1 postgres postgres  32K Aug 17 20:59 postgresql.conf

Restoring the Full and Incremental Backups

Now let’s test the backup by completely removing the existing PostgreSQL data directory and rebuilding it from the full and incremental backups.

First, stop PostgreSQL:

[postgres@OL8 ~]$ /usr/pgsql-18/bin/pg_ctl -D /var/lib/pgsql/18/data -l logfile stop
waiting for server to shut down.... done
server stopped

Remove the contents of the existing data directory:

[postgres@OL8 ~]$ rm -rf  /var/lib/pgsql/18/data/*

At this point, the original data directory is empty.

Combining the Backups with pg_combinebackup

PostgreSQL provides the pg_combinebackup utility, which can combine a base backup and one or more incremental backups into a new PostgreSQL data directory.

[postgres@OL8 ~]$ pg_combinebackup -o /var/lib/pgsql/18/data/ /PGbackup/Full/ /PGbackup/Incremental/

The command creates the restored data directory:

[postgres@OL8 data]$ ll
total 248
-rw-r-----. 1 postgres postgres    229 Aug 17 21:03 backup_label
-rw-r-----. 1 postgres postgres    227 Aug 17 21:03 backup_label.old
-rw-r-----. 1 postgres postgres 182110 Aug 17 21:03 backup_manifest
drwxr-x---. 6 postgres postgres     46 Aug 17 21:03 base
-rw-r-----. 1 postgres postgres     30 Aug 17 21:03 current_logfiles
drwxr-x---. 2 postgres postgres   4096 Aug 17 21:03 global
drwxr-x---. 2 postgres postgres     32 Aug 17 21:03 log
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_commit_ts
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_dynshmem
-rw-r-----. 1 postgres postgres   5721 Aug 17 21:03 pg_hba.conf
-rw-r-----. 1 postgres postgres   2681 Aug 17 21:03 pg_ident.conf
drwxr-x---. 4 postgres postgres     68 Aug 17 21:03 pg_logical
drwxr-x---. 4 postgres postgres     36 Aug 17 21:03 pg_multixact
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_notify
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_replslot
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_serial
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_snapshots
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_stat
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_stat_tmp
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_subtrans
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_tblspc
drwxr-x---. 2 postgres postgres      6 Aug 17 21:03 pg_twophase
-rw-r-----. 1 postgres postgres      3 Aug 17 21:03 PG_VERSION
drwxr-x---. 4 postgres postgres     77 Aug 17 21:03 pg_wal
drwxr-x---. 2 postgres postgres     18 Aug 17 21:03 pg_xact
-rw-r-----. 1 postgres postgres     88 Aug 17 21:03 postgresql.auto.conf
-rw-r-----. 1 postgres postgres  32453 Aug 17 21:03 postgresql.conf

The output directory now contains the combined contents of the full and incremental backups.

Starting PostgreSQL

The data directory has been restored, so we can start PostgreSQL:

[postgres@OL8 ~]$ /usr/pgsql-18/bin/pg_ctl -D /var/lib/pgsql/18/data -l logfile start
waiting for server to start.... done
server started

Verifying the Restore

Finally, let’s verify that the database and table created after the full backup are available.

Connect to PostgreSQL:

[postgres@OL8 ~]$ psql
psql (18.0)
Type "help" for help.

postgres=# \l
                                                     List of databases
   Name    |  Owner   | Encoding | Locale Provider |   Collate   |    Ctype    | Locale | ICU Rules |   Access privileges
-----------+----------+----------+-----------------+-------------+-------------+--------+-----------+-----------------------
 postgres  | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |        |           |
 template0 | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |        |           | =c/postgres          +
           |          |          |                 |             |             |        |           | postgres=CTc/postgres
 template1 | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |        |           | =c/postgres          +
           |          |          |                 |             |             |        |           | postgres=CTc/postgres
 vahid     | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |        |           |
(4 rows)

postgres=# \c vahid
You are now connected to database "vahid" as user "postgres".

vahid=# \d
        List of relations
 Schema | Name | Type  |  Owner
--------+------+-------+----------
 public | tb   | table | postgres
(1 row)

vahid=# select * from tb;
 id |       name
----+-------------------
  1 | Vahid Yousefzadeh
(1 row)

The table and its data are available after restoring the full backup together with the incremental backup.

Point-in-Time Recovery (PITR) with pg_basebackup in PostgreSQL 18

Vahid Yousefzadeh — Mon, 17 Aug 2026 17:51:59 +0000

pg_basebackup is a useful tool for creating a base backup of a PostgreSQL cluster. When combined with continuous WAL archiving, it can be used to perform Point-in-Time Recovery (PITR).

In this article, I will demonstrate how to create a base backup using pg_basebackup and then perform PITR to a specific point in time.

1. Check the Current PostgreSQL Cluster

First, let’s check the current state of the PostgreSQL cluster.

psql (18.0)
WARNING: Console code page (720) differs from Windows code page (1256)
         8-bit characters might not work correctly. See psql reference
         page "Notes for Windows users" for details.
Type "help" for help.

postgres=# \l
                                                                    List of databases
   Name    |  Owner   | Encoding | Locale Provider |          Collate           |           Ctype            | Locale | ICU Rules |   Access privileges
-----------+----------+----------+-----------------+----------------------------+----------------------------+--------+-----------+-----------------------
 postgres  | postgres | UTF8     | libc            | English_United States.1256 | English_United States.1256 |        |           | =Tc/postgres         +
           |          |          |                 |                            |                            |        |           | postgres=CTc/postgres
 template0 | postgres | UTF8     | libc            | English_United States.1256 | English_United States.1256 |        |           | =c/postgres          +
           |          |          |                 |                            |                            |        |           | postgres=CTc/postgres
 template1 | postgres | UTF8     | libc            | English_United States.1256 | English_United States.1256 |        |           | =c/postgres          +
           |          |          |                 |                            |                            |        |           | postgres=CTc/postgres
 usefdb    | postgres | UTF8     | libc            | English_United States.1256 | English_United States.1256 |        |           |

2. Configure WAL Archiving

Before creating the base backup, we need to configure PostgreSQL for WAL archiving.

The following parameters are configured in:

D:\postgres18_windows_installed\data\postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'copy "%p" "E:\\Archive\\%f"'

for Linux:

[postgres@OL8 ~]$ vi /var/lib/pgsql/18/data/postgresql.conf

wal_level = replica
archive_mode = on
archive_command = 'cp "%p" "/archive/%f"'

The wal_level setting determines how much information is written to the WAL. The replica level is sufficient for WAL archiving and physical replication.

archive_mode = on enables WAL archiving, while archive_command specifies how completed WAL segments are copied to the archive location.

In this example, the WAL archive directory is:

E:\Archive

Because archive_mode cannot be changed without restarting the server, we restart PostgreSQL:

C:\Users\Win10-991005> pg_ctl restart
waiting for server to shut down....   
 done
server stopped
waiting for server to start....2026-08-12 22:32:04 +0330 LOG:  redirecting log output to logging collector process
2026-08-12 22:32:04 +0330 HINT:  Future log output will appear in directory "log".
 done
server started

3. Generate a WAL Segment

We can force PostgreSQL to switch to a new WAL segment by using

pg_switch_wal():

postgres=# select pg_switch_wal();
 pg_switch_wal
---------------
 0/1D0020C0
(1 row)

We can then verify that the WAL segment has been archived:

C:\Users\Win10-991005>dir e:\Archive\*
08/12/2026  10:32 PM    <DIR>          .
08/12/2026  10:32 PM    <DIR>          ..
08/12/2026  10:32 PM        16,777,216 00000005000000000000001D
               1 File(s)     16,777,216 bytes
               2 Dir(s)   7,594,000,384 bytes free

At this point, WAL archiving is working and we can create the base backup.

4. Create a Base Backup with pg_basebackup

The base backup can be created with the following command:

C:\Users\Win10-991005> pg_basebackup -D "E:\backup" -Ft -P -U postgres
Password:

32844/32844 kB (100%), 1/1 tablespace

In this example:

-D “E:\backup” specifies the destination directory.
-Ft tells pg_basebackup to use tar format.
-P displays progress information.
-U postgres specifies the PostgreSQL user used to connect to the server.
The backup directory contains the following files:

C:\Users\Win10-991005> dir E:\backup\*
08/12/2026  10:34 PM           184,439 backup_manifest
08/12/2026  10:34 PM        33,632,768 base.tar
08/12/2026  10:34 PM        33,558,528 pg_wal.tar
               3 File(s)     67,375,735 bytes
               2 Dir(s)   7,476,281,344 bytes free

5. Generate Some Test Data

Now we will create a table and insert some test data.

postgres=# create table tb_2026_08_12(id serial primary key,name varchar(50));

CREATE TABLE

postgres=# insert into tb_2026_08_12 values(1,’Vahid Yousefzadeh’);

INSERT 0 1

6. Determine the PITR Target Time

Now I want to restore the database to a point after the first row was inserted but before the second row was inserted.

First, I switch WAL and record the current time:

postgres=# select pg_switch_wal();
 pg_switch_wal
---------------
 0/214ADFF0
(1 row)
postgres=# select now();
               now
----------------------------------
 2026-08-12 22:36:26.779349+03:30
(1 row)

Next, I insert another row:

postgres=# insert into tb_2026_08_12 values(2,'Payan Rafat');
INSERT 0 1

Then I switch WAL again:

postgres=# select pg_switch_wal();
 pg_switch_wal
---------------
0/22000160
(1 row)

At this point, the WAL archive contains the WAL required to replay the changes between the base backup and our target time.

7. Prepare the Environment for Recovery

Now we stop PostgreSQL:

C:\Users\Win10-991005>pg_ctl  stop
waiting for server to shut down....        1 file(s) copied.
.. done
server stopped

For this demonstration, I remove the existing data directory:

C:\Users\Win10-991005>rmdir /s /q "D:\postgres18_windows_installed\data"
Then I create an empty data directory again:

C:\Users\Win10-991005>mkdir "D:\postgres18_windows_installed\data"

8. Restore the Base Backup

Because the base backup was created in tar format, we can extract into the base.tar PostgreSQL data directory:

C:\Users\Win10-991005>tar -xvf "E:\backup\base.tar" -C "D:\postgres18_windows_installed\data"

9. Create recovery.signal

To tell PostgreSQL to enter archive recovery, we create an empty file named recovery.signal in the data directory:

C:\Users\Win10-991005> type nul > "D:\postgres18_windows_installed\data\recovery.signal"

When PostgreSQL starts with recovery.signal present, it enters recovery mode and uses the recovery configuration parameters to determine how recovery should proceed.

10. Configure PITR

The following parameters are added to postgresql.conf:

restore_command = 'copy "E:\\Archive\\%f" "%p"'

recovery_target_time = '2026-08-12 22:36:26'

recovery_target_action = 'promote'

The restore_command tells PostgreSQL how to retrieve archived WAL files. %f is replaced with the requested WAL file name, while %p is replaced with the path where PostgreSQL expects the file to be restored.

The recovery_target_time specifies the point in time at which recovery should stop.

Finally, recovery_target_action = ‘promote’ tells PostgreSQL to end recovery and promote the server to a normal read-write state once the recovery target has been reached.

11. Start PostgreSQL and Perform PITR

Now we can start PostgreSQL:

C:\Users\Win10-991005> pg_ctl start
waiting for server to start....2026-08-12 22:47:03 +0330 LOG:  redirecting log output to logging collector process
2026-08-12 22:47:03 +0330 HINT:  Future log output will appear in directory "log".
done
server started

The PostgreSQL log shows that archive recovery has started:

2026-08-12 22:47:03 +0330 LOG:  starting PostgreSQL 18.0 on x86_64-windows, compiled by msvc-19.44.35217, 64-bit
2026-08-12 22:47:03 +0330 LOG:  listening on IPv6 address "::", port 5432
2026-08-12 22:47:03 +0330 LOG:  listening on IPv4 address "0.0.0.0", port 5432
2026-08-12 22:47:03 +0330 LOG:  database system was interrupted; last known up at 2026-08-12 22:34:34 +0330
2026-08-12 22:47:06 +0330 LOG:  starting backup recovery with redo LSN 0/20000028, checkpoint LSN 0/20000080, on timeline ID 5
2026-08-12 22:47:06 +0330 LOG:  restored log file "000000050000000000000020" from archive
2026-08-12 22:47:06 +0330 LOG:  starting point-in-time recovery to 2026-08-12 22:36:26+03:30
2026-08-12 22:47:06 +0330 LOG:  redo starts at 0/20000028
2026-08-12 22:47:06 +0330 LOG:  completed backup recovery with redo LSN 0/20000028 and end LSN 0/20000120
2026-08-12 22:47:06 +0330 LOG:  consistent recovery state reached at 0/20000120
2026-08-12 22:47:06 +0330 LOG:  database system is ready to accept read-only connections
2026-08-12 22:47:06 +0330 LOG:  restored log file "000000050000000000000021" from archive
2026-08-12 22:47:06 +0330 LOG:  restored log file "000000050000000000000022" from archive
2026-08-12 22:47:06 +0330 LOG:  recovery stopping before commit of transaction 850, time 2026-08-12 22:36:53.547442+03:30
2026-08-12 22:47:06 +0330 LOG:  redo done at 0/220000E8 system usage: CPU: user: 0.01 s, system: 0.07 s, elapsed: 0.36 s
2026-08-12 22:47:06 +0330 LOG:  last completed transaction was at log time 2026-08-12 22:36:02.679092+03:30
2026-08-12 22:47:06 +0330 LOG:  selected new timeline ID: 6
2026-08-12 22:47:06 +0330 LOG:  archive recovery complete
2026-08-12 22:47:06 +0330 LOG:  checkpoint starting: end-of-recovery immediate wait
2026-08-12 22:47:08 +0330 LOG:  checkpoint complete: wrote 1024 buffers (5.6%), wrote 3 SLRU buffers; 0 WAL file(s) added, 0 removed, 2 recycled; write=0.486 s, sync=0.968 s, total=1.499 s; sync files=335, longest=0.009 s, average=0.003 s; distance=32768 kB, estimate=32768 kB; lsn=0/220000E8, redo lsn=0/220000E8
2026-08-12 22:47:08 +0330 LOG:  database system is ready to accept connections
The new timeline ID is important. After PITR completes and PostgreSQL is promoted, it creates a new timeline so that the recovered database can continue generating WAL independently from the original timeline.

Finally, PostgreSQL becomes available for normal connections:

LOG: database system is ready to accept connections

12. Verify the Recovery

Now we can connect to the database and check the table:

postgres=#  select * from tb_2026_08_12;
 id |       name
----+-------------------
  1 | Vahid Yousefzadeh
(1 row)

Only the first row exists.

The second row:

2 | Payan Rafat

is not present because it was inserted after the selected PITR target.

Therefore, the recovery successfully restored the PostgreSQL cluster to the requested point in time.

Oracle 26ai- Installing Oracle Grid Infrastructure for a Standalone Server Using the Command-Line Interface

Vahid Yousefzadeh — Mon, 17 Aug 2026 07:20:42 +0000

Before Oracle AI Database 26ai, Oracle Grid Infrastructure could be installed using a response file.

For example(using a response file):

./gridSetup.sh -silent \
INVENTORY_LOCATION=/oraInventory \
SELECTED_LANGUAGES=en \
ORACLE_BASE=/grid/base \
oracle.install.option=HA_CONFIG \
oracle.install.asm.OSDBA=asmdba \
oracle.install.asm.OSOPER=asmoper \
oracle.install.asm.OSASM=asmadmin \
oracle.install.crs.config.autoConfigureClusterNodeVIP=false \
oracle.install.asm.diskGroup.name=ASM \
oracle.install.asm.diskGroup.redundancy=EXTERNAL \
oracle.install.asm.diskGroup.diskDiscoveryString='ORCL:*' \
oracle.install.asm.diskGroup.disks=ORCL\:ASM01 \
oracle.install.asm.SYSASMPassword=Your_Password \
oracle.install.asm.monitorPassword=Your_Password \
-ignorePrereqFailure

At the end of the installation, the installer displays a message similar to the following:

As install user, execute the following command to complete the configuration.
        /grid/19.25/gridSetup.sh -executeConfigTools -responseFile /grid/19.25/install/response/grid_2025-03-28_08-34-17AM.rsp [-silent]

Therefore, we should use a response file such as the following:

[grid@OL95 ~]$ cat /grid/19.25/install/response/gridsetup.rsp
oracle.install.responseFileVersion=/oracle/install/rspfmt_crsinstall_response_schema_v19.0.0
INVENTORY_LOCATION=/oraInventory
oracle.install.option=HA_CONFIG
ORACLE_BASE=/grid/base
oracle.install.asm.OSOPER=asmoper
oracle.install.asm.OSASM=asmadmin
oracle.install.asm.OSDBA=asmdba
oracle.install.asm.SYSASMPassword=Deraz_Kolah_122_Kebria
oracle.install.asm.diskGroup.name=ASM
oracle.install.asm.diskGroup.redundancy=EXTERNAL
oracle.install.asm.diskGroup.disks=ORCL:ASM01
oracle.install.asm.diskGroup.diskDiscoveryString=ORCL:*
oracle.install.asm.monitorPassword=Deraz_Kolah_122_Kebria

Starting with Oracle AI Database 26ai, Oracle Grid Infrastructure can be installed and configured using the command-line interface. Oracle provides the -configureCluster and -configureStandaloneServer options for the gridSetup.sh command. The -configureCluster option is used to configure Oracle Grid Infrastructure for a cluster, while the -configureStandaloneServer option is used to configure Oracle Grid Infrastructure for a standalone server.
In this article, I will show how to install and configure Oracle Grid Infrastructure on a standalone server using the -configureStandaloneServer option.
As the grid user, run the following command:

[grid@OL95 26ai]$ ./gridSetup.sh  -silent -configureStandaloneServer \
  -OSDBA asmdba \
  -OSASM asmadmin \
  -OSOPER asmoper \
  -ORACLE_BASE /grid/base \
  -dbDiskGroupName ASM \
  -diskList 'ORCL:ASM' \
  -redundancy EXTERNAL \
  -diskString 'ORCL:*'  \
  -executeRootScript \
  -configMethod root \
  -auSize 64 \
  -INVENTORY_LOCATION /oraInventory

Launching Oracle Grid Infrastructure Setup Wizard...

Enter password for SYS user:

Confirm password:

Enter password for ASMSNMP user:

Confirm password:


 Enter password for 'root' user:

 The response file for this session can be found at:
 /grid/26ai/install/response/grid_2026-08-16_08-52-51PM.rsp

You can find the log of this install session at:
 /tmp/GridSetupActions2026-08-16_08-52-51PM/gridSetupActions2026-08-16_08-52-51PM.log
[ Start ] NETCA - 2026-08-16 20:57:42.784
Command: /bin/sh -c /grid/26ai/bin/netca /orahome /grid/26ai /instype typical /inscomp client,oraclenet,javavm,server,ano /insprtcl tcp /cfg local /authadp NO_VALUE /responseFile /grid/26ai/network/install/netca_typ.rsp /silent  /orahnam OraGI23Home1  /ouiinternal

Parsing command line arguments:
    Parameter "orahome" = /grid/26ai
    Parameter "instype" = typical
    Parameter "inscomp" = client,oraclenet,javavm,server,ano
    Parameter "insprtcl" = tcp
    Parameter "cfg" = local
    Parameter "authadp" = NO_VALUE
    Parameter "responsefile" = /grid/26ai/network/install/netca_typ.rsp
    Parameter "silent" = true
    Parameter "orahnam" = OraGI23Home1
    Parameter "ouiinternal" = true
Done parsing command line arguments.
Oracle Net Services Configuration:
Profile configuration complete.
Oracle Net Listener Startup:
    Listener started successfully.
Listener configuration complete.
Oracle Net Services configuration successful. The exit code is 0
[ Exit Code ] 0
[ End ] NETCA - 2026-08-16 20:57:51.741

[ Start ] ASMCA - 2026-08-16 20:57:51.883
Command: /bin/sh -c /grid/26ai/bin/asmca -silent -oui_internal -configureASM -diskString 'ORCL:*' -diskGroupName ASM -diskList 'ORCL:ASM' -redundancy EXTERNAL -au_size 64
SYS_PASSWORD_PROMPT
ASMSNMP_PASSWORD_PROMPT

ASM has been created and started successfully.

[DBT-30001] Disk groups created successfully. Check /grid/base/cfgtoollogs/asmca/asmca-260816PM085752.log for details.

[ Exit Code ] 0
[ End ] ASMCA - 2026-08-16 20:59:03.73

[ Start ] CVU - 2026-08-16 20:59:03.83
Command: /bin/sh -c /grid/26ai/bin/cluvfy  stage -post hacfg

Performing following verification checks ...

  Oracle Restart Integrity ...PASSED
  OLR Integrity ...PASSED

Post-check for Oracle Restart configuration was successful.

CVU operation performed:      stage -post hacfg
Date:                         Aug 16, 2026, 8:59:04 PM
CVU version:                  23.26.2.0.0 (032926x8664)
CVU home:                     /grid/26ai
Grid home:                    /grid/26ai
User:                         grid
Operating system:             Linux5.15.0-302.167.6.el9uek.x86_64
Successfully Setup Software with warning(s).
[ Exit Code ] 0
[ End ] CVU - 2026-08-16 20:59:13.758

Moved the install session logs to:
 /oraInventory/logs/GridSetupActions2026-08-16_08-52-51PM

The command completes the Oracle Grid Infrastructure configuration and creates and starts the ASM instance. After the configuration completes successfully, we can verify the ASM instance by connecting to it using SQL*Plus as SYSASM:

[grid@OL95 ~]$ sqlplus "/as sysasm"
SQL*Plus: Release 23.26.2.0.0 - Production on Sun Aug 16 21:46:33 2026
Version 23.26.2.0.0
Copyright (c) 1982, 2026, Oracle.  All rights reserved.
Connected to:
Oracle AI Database 26ai Enterprise Edition Release 23.26.2.0.0 - Production
Version 23.26.2.0.0
SQL>

We can also use ASMCMD to verify that the ASM disk group was created and mounted successfully:

[grid@OL95 ~]$ asmcmd -p
ASMCMD [+] > lsdg
State    Type    Rebal  Sector  Logical_Sector  Block        AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  EXTERN  N         512             512   4096  67108864     13248    12352                0           12352              0             N  ASM/

Oracle AI Database 26ai(23.26.2)— DML Redirection for Data Guard per Pluggable Database

Vahid Yousefzadeh — Sat, 25 Jul 2026 05:57:07 +0000

**Oracle AI Database 26ai **introduces DML Redirection for Data Guard per Pluggable Database, allowing write operations to be transparently redirected from a standby PDB to its corresponding primary PDB.

With this enhancement, a standby PDB is no longer limited to serving read-only workloads. Applications can perform both read and write operations while connected to the standby PDB, with write requests automatically executed on the primary PDB. This makes the standby environment a more valuable resource by offloading additional application activity and increasing the flexibility of disaster recovery environments.

Let’s verify this feature with a simple test.

Step 1 — Verify the Standby PDB

Connect to the standby database (CDB2) and verify that the target PDB (AMOL) is opened in READ ONLY mode.

[oracle@OEL9-DB2 ~]$ sqlplus /@cdb2 as sysdba

SQL*Plus: Release 23.26.2.0.0 - Production on Tue Jul 14 13:29:04 2026
Version 23.26.2.0.0

Copyright (c) 1982, 2026, Oracle.  All rights reserved.

Connected to:
Oracle AI Database 26ai Enterprise Edition Release 23.26.2.0.0 - Production
Version 23.26.2.0.0

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 BABOL                          READ WRITE NO
         4 AMOL                           READ ONLY  NO

Also verify that the database is operating as a Physical Standby.

SQL> select database_role,open_mode from v$database;

DATABASE_ROLE    OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY WITH APPLY

At this point, the standby database is open for read access while redo apply remains active.

Step 2 — Enable DML Redirection

Enable DML redirection on the standby database.

SQL> alter system set adg_redirect_dml=true;

System altered.

This parameter enables Oracle to transparently redirect write operations issued against the standby PDB to its corresponding primary PDB.

Step 3 — Execute a DML Statement on the Standby

Insert a row while connected to the standby PDB.

SQL> alter session set container=AMOL;
Session altered.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         4 AMOL                           READ ONLY  NO
SQL> insert into tbl values(1,'Vahid Yousefzadeh');

1 row created.

SQL> commit;

Commit complete.

Notice that the INSERT and COMMIT complete successfully despite the standby PDB being opened in READ ONLY mode. The write operation is transparently redirected to the primary PDB.

Step 4 — Verify the Result on the Primary

Connect to the primary database (CDB1) and switch to the AMOL PDB.

--primary(source) CDB1

SQL> alter session set container=amol;

Session altered.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         3 AMOL                           READ WRITE NO

        ID FULLNAME
---------- --------------------
         1 Vahid Yousefzadeh

The inserted row is present in the primary PDB, confirming that the DML statement executed from the standby PDB was successfully redirected.

Automatic Standby PDB Instantiation and Standby Redo Log Creation in Oracle AI Database 26ai(23.26.2)

Vahid Yousefzadeh — Wed, 15 Jul 2026 06:12:38 +0000

Oracle AI Database Release Update 23.26.2 introduces an important enhancement for Data Guard per Pluggable Database (PDB) environments. When a protected PDB is added through Data Guard Broker, Oracle automatically performs several tasks that previously required manual intervention.

Prior to Release Update 23.26.2, creating a standby PDB typically involved multiple manual steps, such as:

Copying datafiles to the standby CDB
Creating Standby Redo Logs (SRLs)
Verifying the standby configuration

Starting with 23.26.2, Data Guard Broker automates these operations, simplifying the deployment process and reducing the risk of configuration errors.

To demonstrate this enhancement, I created a standby PDB named AMOL on the standby database CDB2 using the following Broker command:

DGMGRL>  ADD PLUGGABLE DATABASE 'amol' AT cdb2 SOURCE is 'amol' AT cdb1 PDBFileNameConvert is "'/CDB1/','/CDB2/'";
Pluggable Database "AMOL" added

Notice that no RMAN restore, manual file copy, or standby redo log creation commands are required.

The new PDB initially appears in the MOUNTED state.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 BABOL                          READ WRITE NO
         4 AMOL                           MOUNTED

After opening the PDB,

SQL> alter pluggable database AMOL open;
Pluggable database altered.

it becomes available in READ ONLY mode, which is the expected state for a physical standby PDB.

SQL>  show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 BABOL                          READ WRITE NO
         4 AMOL                           READ ONLY  NO

Next, I switched to the AMOL container and verified that the datafiles had already been created.

SQL> alter session set container=amol;
Session altered.
SQL> select name from v$datafile;
NAME
-------------------------------------------------
/oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_system_o5cv72qp_.dbf
/oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_sysaux_o5cv71nb_.dbf
/oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_undotbs1_o5cv716w_.dbf
/oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_users_o5cv710h_.dbf

This confirms that Oracle automatically copied the datafiles from the primary database during standby PDB instantiation.

Another enhancement introduced in Release Update 23.26.2 is the automatic creation of Standby Redo Logs.

SQL> select group# from v$standby_log;

    GROUP#
----------
         4
         5
         6

No manual ALTER DATABASE ADD STANDBY LOGFILE commands were necessary.

Finally, I validated the standby PDB configuration.

DGMGRL>  VALIDATE PLUGGABLE DATABASE amol AT cdb2;

  Ready for Switchover:    YES

  Data Guard Role:         Physical Standby
  Apply State:             Running
  Standby Redo Log Files:  3
  Source:                  AMOL (con_id 3) at cdb1

The validation confirms that redo apply is running successfully, the standby redo logs are configured correctly, and the standby PDB is ready for switchover.

The following alert log excerpt shows the internal operations performed automatically during standby PDB instantiation.

create pluggable database AMOL as standby from AMOL at cdb1 file_name_convert=('/CDB1/','/CDB2/')
2026-07-14T11:31:34.047911+03:30
AMOL(4):ALTER SYSTEM SET _dgpdb_file_name_convert='/CDB1/','/CDB2/' SCOPE=SPFILE PDB='AMOL';
2026-07-14T11:31:34.116071+03:30
****************************************************************
Pluggable Database AMOL with pdb id - 4 is created as UNUSABLE.
If any errors are encountered before the pdb is marked as NEW,
then the pdb must be dropped
local undo-1, localundoscn-0x0000000000000132
****************************************************************
Completed: create pluggable database AMOL as standby from AMOL at cdb1 file_name_convert=('/CDB1/','/CDB2/')
2026-07-14T11:31:34.533442+03:30
 rfs (PID:809423): krsr_rfs_atc: DBROLE:PRIMARY Client is ASYNC DB: (PID:240147) [krsr.c:6137]
 rfs (PID:809423): Foreign redo connection for cdb1(DBID:1212295561), Client is ASYNC (PID:240147) [krsr.c:6918]
 rfs (PID:809423): Disable RFS client RFS LogMiner Client [krsr.c:7033]
 rfs (PID:809423): No SRLs created [krsk.c:5084]
2026-07-14T11:31:34.562849+03:30
 rfs (PID:809423): Opened log for DBID:1212295561 B-1238578121.T-1.S-2.C-0 [krsr.c:19571]
2026-07-14T11:31:35.430667+03:30
 rfs (PID:809423): Archived Log entry 1 added for B-1238578121.T-1.S-2 LOS:0x0000000000200744 NXS:0x0000000000203102 NAB:75800 ID 0x4842e589 LAD:1 [krsp.c:952]
2026-07-14T11:31:36.546432+03:30
 rfs (PID:809435): krsr_rfs_atc: DBROLE:PRIMARY Client is ASYNC DB: (PID:240145) [krsr.c:6137]
 rfs (PID:809435): Foreign redo connection for cdb1(DBID:1212295561), Client is ASYNC (PID:240145) [krsr.c:6918]
2026-07-14T11:31:36.564502+03:30
 rfs (PID:809435): Opened LNO:4 for DBID:1212295561 B-1238578121.T-1.S-3.C-0 [krsr.c:19561]
2026-07-14T11:31:36.954106+03:30
AMOL(4):Restore from backup piece network
AMOL(4):Full restore complete of  datafile 15 /oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_users_o5cv710h_.dbf.  Elapsed time: 0:00:00
AMOL(4):   checkpoint is SCN 2109708 time 07/14/2026 11:30:48 on PDB incarnation 0
AMOL(4):2071166
AMOL(4):Restore from backup piece network
AMOL(4):Full restore complete of  datafile 14 /oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_undotbs1_o5cv716w_.dbf.  Elapsed time: 0:00:00
AMOL(4):   checkpoint is SCN 2109713 time 07/14/2026 11:30:48 on PDB incarnation 0
AMOL(4):2108839
AMOL(4):2107197
AMOL(4):Restore from backup piece network
2026-07-14T11:31:38.597999+03:30
AMOL(4):Full restore complete of  datafile 13 /oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_sysaux_o5cv71nb_.dbf.  Elapsed time: 0:00:01
AMOL(4):   checkpoint is SCN 2109718 time 07/14/2026 11:30:49 on PDB incarnation 0
AMOL(4):2081853
AMOL(4):Restore from backup piece network
AMOL(4):Full restore complete of  datafile 12 /oracle/base/oradata/CDB2/568CEB400DB29D03E0630488200A65CB/datafile/o1_mf_system_o5cv72qp_.dbf.  Elapsed time: 0:00:01
AMOL(4):   checkpoint is SCN 2109723 time 07/14/2026 11:30:50 on PDB incarnation 0
AMOL(4):2085977
AMOL(4):2107197

Oracle 26ai(23.26.2): WAIT and NOWAIT Support for DELETE, UPDATE, INSERT, and MERGE Statements

Vahid Yousefzadeh — Wed, 15 Jul 2026 06:09:05 +0000

Rows modified by DML statements are locked and, if another session attempts to modify the same row, that session must wait until the row becomes available. In previous Oracle Database releases, the WAIT clause was supported only by the SELECT FOR UPDATE statement, enabling users to specify how long to wait for a row lock before the statement is rolled back.

For example:

Connected to Oracle Database 19c Enterprise Edition Release 19.0.0.0.0

SQL> select * from tbl for update wait 10;
ORA-30006: resource busy; acquire with WAIT timeout expired

Similarly, the NOWAIT clause can be used to instruct the database to return immediately if the requested row is locked by another transaction:

SQL> select * from tbl for update nowait;

ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

If neither WAIT nor NOWAIT is specified, Oracle retains its default behavior and waits indefinitely for the row lock to become available:

SQL> select * from tbl for update;

Executing

Starting with Oracle AI Database 23.26.2 (Oracle AI Database 26ai), support for WAIT and NOWAIT has been extended to all DML statements, including INSERT, UPDATE, DELETE, and MERGE. These clauses enable users to control how the database proceeds when a transaction attempts to lock a row that is already locked by another transaction.

Specifying NOWAIT causes the database to roll back the DML statement immediately if a conflicting lock exists, while the WAIT clause allows users to define how long the database should wait before rolling back the statement.

DELETE

Session 1 acquires a row lock:

SQL> delete tbl where id=1;

1 row deleted

Session 2 attempts to delete the same row and waits for five seconds before timing out:

SQL> delete tbl where id=1 wait 5;

ORA-00054: Failed to acquire a lock (Type: "TX", Name: "Transaction", Description: "Lock held by a transaction to allow other transactions to wait for it") because it is currently held by another session. The resource being locked can be identified by 524315 ("usn<<16 | slot") and 536 ("sequence")

ORA-40097: Failure to acquire row lock, currently held by transaction ID 8.27.536

UPDATE

Session 1 updates a row:

SQL> update tbl set name='Vahid Yousefzadeh' where id=1 nowait;

1 row updated

Session 2 attempts to update the same row using NOWAIT and immediately receives an error:

SQL> update tbl set name='Vahid Yousefzadeh' where id=1 nowait;

ORA-00054: Failed to acquire a lock (Type: "TX", Name: "Transaction", Description: "Lock held by a transaction to allow other transactions to wait for it") because it is currently held by another session. The resource being locked can be identified by 65540 ("usn<<16 | slot") and 531 ("sequence")

ORA-40097: Failure to acquire row lock, currently held by transaction ID 1.4.531

INSERT

Session 1 inserts a row:

SQL> insert into tbl values(1,'Vahid YousefZadeh') wait 2;

1 row inserted

Session 2 attempts to insert a conflicting row and waits for two seconds before the statement is rolled back:

SQL> insert into tbl values(1,'Vahid YousefZadeh') wait 2;

ORA-00054: Failed to acquire a lock (Type: "TX", Name: "Transaction", Description: "Lock held by a transaction to allow other transactions to wait for it") because it is currently held by another session. The resource being locked can be identified by 655369 ("usn<<16 | slot") and 528 ("sequence")

ORA-40097: Failure to acquire row lock, currently held by transaction ID 10.9.528

MERGE

Session 1 modifies the target row:

SQL> update tbl set name='Vahid Yousefzadeh' where id=1;

1 row updated

Session 2 executes a MERGE statement with a WAIT clause:

MERGE INTO tbl t
USING (SELECT 1 id, 'Usef' name FROM dual) s
ON (t.id = s.id)
WHEN MATCHED THEN
  UPDATE SET t.name = s.name
WHEN NOT MATCHED THEN
  INSERT (id, name) VALUES (s.id, s.name) wait 2;

ORA-00054: Failed to acquire a lock (Type: "TX", Name: "Transaction", Description: "Lock held by a transaction to allow other transactions to wait for it") because it is currently held by another session. The resource being locked can be identified by 196640 ("usn<<16 | slot") and 573 ("sequence")

ORA-40097: Failure to acquire row lock, currently held by transaction ID 3.32.573

Oracle 26ai — Enhancements to Data Dictionary Views for Partitioning

Vahid Yousefzadeh — Sat, 11 Jul 2026 09:13:07 +0000

In data dictionary views related to partitioning, the HIGH_VALUE column is one of the most frequently used attributes. However, its datatype is LONG, which comes with several limitations and restrictions.

To address these limitations, Oracle AI Database 26ai introduces two additional columns, HIGH_VALUE_CLOB and HIGH_VALUE_JSON, allowing partition high values to be represented in more convenient formats.

The following example creates an interval-partitioned table:

SQL> create table tb(
  2    id  number,
  3    date_ date
  4  )
  5  partition by range ( date_ )
  6  interval ( numtoyminterval(1,'YEAR'))
  7  (
  8   PARTITION p2022 VALUES LESS THAN (TO_DATE('2023/01/01', 'YYYY/MM/DD')),
  9   PARTITION p2023 VALUES LESS THAN (TO_DATE('2024/01/01', 'YYYY/MM/DD')),
 10   PARTITION p2024 VALUES LESS THAN (TO_DATE('2025/01/01', 'YYYY/MM/DD'))
 11  );
Table created

To display partition boundary values in CLOB format, the HIGH_VALUE_CLOB column can be queried:

SQL> select partition_name, high_value_clob from user_tab_partitions where  table_name = 'TB' order by 1;
PARTITION_NAME       HIGH_VALUE_CLOB                                          
-------------------- -------------------------------------------------------- 
P2022                TO_DATE(' 2023-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS' 
P2023                TO_DATE(' 2024-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS' 
P2024                TO_DATE(' 2025-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS'

Oracle 26ai also introduces the HIGH_VALUE_JSON column, which exposes the same information in JSON format:

SQL> select partition_name,HIGH_VALUE_JSON  from user_tab_partitions where  table_name = 'TB' order by 1;
PARTITION_NAME       HIGH_VALUE_JSON
-------------------- ---------------------------------------------------------
P2022                {"high_value":"2023-01-01T00:00:00"}
P2023                {"high_value":"2024-01-01T00:00:00"}
P2024                {"high_value":"2025-01-01T00:00:00"}

Restoring a PDB Backup into a New CDB

Vahid Yousefzadeh — Sat, 11 Jul 2026 09:10:58 +0000

According to Oracle Backup and Recovery documentation, restoring a Pluggable Database (PDB) normally requires access to the backup of the Container Database (CDB) that originally hosted the PDB. Without the source CDB metadata, restoring a standalone PDB backup is generally not possible.

However, there is an alternative approach that can sometimes be used to recover a PDB backup and plug it into a different CDB. Although this method is not guaranteed to work in every scenario, it is a useful technique to be aware of when designing backup and recovery strategies.

In this example, we will back up a PDB named RMANPDB, transfer the backup to another server, and restore it into a completely new CDB.

Backing Up the PDB

First, verify that the PDB exists and is open:

Connected to:
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         5 PDB1                           READ WRITE NO
         4 RMANPDB                        READ WRITE NO

Create a RMAN backup of the PDB and include the current control file:

RMAN> backup pluggable database RmanPDB format '/oracle21c/bkp_pdb/%U' current controlfile  format '/oracle21c/bkp_pdb/control0000.bkp';
Starting backup at 16-OCT-21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=266 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00068 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_sysaux_jpo62lhz_.dbf
input datafile file number=00067 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_system_jpo62lhv_.dbf
input datafile file number=00069 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_undotbs1_jpo62lj1_.dbf
input datafile file number=00070 name=/oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_tbs01_jpo66vjx_.dbf
channel ORA_DISK_1: starting piece 1 at 16-OCT-21
channel ORA_DISK_1: finished piece 1 at 16-OCT-21
piece handle=/oracle21c/bkp_pdb/4p0bo4mu_153_1_1 tag=TAG20211016T052342 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 16-OCT-21
channel ORA_DISK_1: finished piece 1 at 16-OCT-21
piece handle=/oracle21c/bkp_pdb/control0000.bkp tag=TAG20211016T052342 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 16-OCT-21

Transferring the Backup

Copy the backup pieces to the target server:

[oracle@RAC2 ~]$ mkdir -p /oracle21c/bkp_pdb
[oracle@oLinux7 ~]$ scp /oracle21c/bkp_pdb/* 192.168.1.20:/oracle21c/bkp_pdb/
4p0bo4mu_153_1_1                                      100%  518MB  68.8MB/s   00:07    
control0000.bkp                                       100%   30MB  81.1MB/s   00:00

Creating a Minimal Instance

On the destination server, create a minimal initialization parameter file:

[oracle@RAC2 ~]$ vi p_1400_07_24.ora
*.db_name=db21c
*.db_create_file_dest='/oracle21c/recoverdb'
Start the instance in NOMOUNT mode:

SQL> startup nomount pfile='/home/oracle/p_1400_07_24.ora';

Restoring the Control File

Restore the control file from the backup:

RMAN> restore controlfile from '/oracle21c/bkp_pdb/control0000.bkp';
Starting restore at 16-OCT-21
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=4262 device type=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/oracle21c/recoverdb/DB21C/controlfile/o1_mf_jpo703jv_.ctl
Finished restore at 16-OCT-21
Mount the database:

RMAN> alter database mount;
released channel: ORA_DISK_1
Statement processed

At this point, the metadata required to locate the PDB backup is available.

Restoring the PDB

Restore the PDB datafiles:

RMAN> RESTORE PLUGGABLE DATABASE RMANPDB;
Starting restore at 16-OCT-21
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=571 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00067 to /oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_system_jpo62lhv_.dbf
channel ORA_DISK_1: restoring datafile 00068 to /oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_sysaux_jpo62lhz_.dbf
channel ORA_DISK_1: restoring datafile 00069 to /oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_undotbs1_jpo62lj1_.dbf
channel ORA_DISK_1: restoring datafile 00070 to /oracle21c/base/oradata/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_tbs01_jpo66vjx_.dbf
channel ORA_DISK_1: reading from backup piece /oracle21c/bkp_pdb/4p0bo4mu_153_1_1
channel ORA_DISK_1: piece handle=/oracle21c/bkp_pdb/4p0bo4mu_153_1_1 tag=TAG20211016T052342
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 16-OCT-21

RMAN restores all datafiles belonging to the PDB.

It is important to understand that only the datafiles have been restored. The PDB itself is not yet usable because it is not associated with an operational CDB.

Identifying the Restored Datafiles

Determine the location of the restored datafiles:

SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       MOUNTED
         4 RMANPDB                        MOUNTED
         5 PDB1                           MOUNTED
SQL> select name from v$datafile where con_id=4;

/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_system_jpo72qsh_.dbf
/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_sysaux_jpo72ppx_.dbf
/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_undotbs1_jpo72s8q_.dbf
/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_tbs01_jpo72ssg_.dbf

Generating the XML

To plug the restored PDB into another CDB, an XML file must be created.

Connect to an open CDB and use the DBMS_PDB.RECOVER procedure:

[oracle@RAC2 ~]$ srvctl start database -db db21c
[oracle@RAC2 ~]$ sqlplus "/as sysdba"
SQL*Plus: Release 21.0.0.0.0 - Production on Sat Oct 16 13:23:36 2021
Version 21.3.0.0.0
BEGIN
   DBMS_PDB.RECOVER (
      pdb_descr_file    =>   '/home/oracle/RMANPDB.xml',
      pdb_name          =>   'RMANPDB',
      filenames         =>   '
/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_system_jpo72qsh_.dbf,
/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_sysaux_jpo72ppx_.dbf,
/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_undotbs1_jpo72s8q_.dbf,
/oracle21c/recoverdb/DB21C/CE75C2880CCD2A3FE0530488200A29C8/datafile/o1_mf_tbs01_jpo72ssg_.dbf
'
   );
END;
/
PL/SQL procedure successfully completed.

The procedure creates an XML manifest describing the PDB.

A portion of the generated file looks like this:

[oracle@RAC2 ~]$ less /home/oracle/RMANPDB.xml
<?xml version="1.0" encoding="UTF-8"?>
<PDB>
  <xmlversion>1</xmlversion>
  <pdbname>RMANPDB</pdbname>
  <cid>4</cid>
  <byteorder>0</byteorder>
  <vsn>0</vsn>
  <vsns>
    <vsnnum>0.0.0.0.0</vsnnum>
    <cdbcompt>0.0.0.0.0</cdbcompt>
    <pdbcompt>21.0.0.0.0</pdbcompt>
    <vsnlibnum>0.0.0.0.0</vsnlibnum>
    <vsnsql>0</vsnsql>
    <vsnbsv>0.0.0.0.0</vsnbsv>
  </vsns>
  <dbid>3948388369</dbid>
  <ncdb2pdb>0</ncdb2pdb>
  <cdbid>246486353</cdbid>
  <guid>CE75C2880CCD2A3FE0530488200A29C8</guid>

Plugging the PDB into a New CDB

Create the PDB using the XML :

SQL> CREATE PLUGGABLE DATABASE RMANPDB USING '/home/oracle/RMANPDB.xml' NOCOPY;
Pluggable database created.

Verify that the PDB has been created:

SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 RMANPDB                        MOUNTED

Opening the PDB

The PDB may initially open in migration mode and generate warnings.

SQL> ALTER DATABASE UPGRADE SYNC OFF;
Database altered.
SQL>  alter pluggable database RMANPDB open ;
Warning: PDB altered with errors.
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 RMANPDB               READ WRITE YES

Validating the Recovery

Connect to the restored PDB and verify that application objects are accessible:

[oracle@RAC2 ~]$ sqlplus "usef/a@192.168.1.20:1521/RMANPDB"
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
SQL> select count(*) from usef.tbl1;
  COUNT(*)
----------
        91
SQL> create table usef.tbl2 as select * from tbl1;
Table created.

Oracle Data Guard 26ai: Restricting Switchover and Failover Targets with PrimaryDatabaseCandidates

Vahid Yousefzadeh — Tue, 09 Jun 2026 16:04:29 +0000

Oracle AI Database 26ai introduces a useful enhancement for Data Guard environments that contain multiple standby databases. The new PrimaryDatabaseCandidates Data Guard Broker property allows administrators to explicitly define which databases are eligible to assume the primary role during switchover or failover operations.

This feature is particularly valuable in environments where some standby databases are dedicated to disaster recovery while others are used for reporting, testing, cloning, or other non-production purposes.

*The PrimaryDatabaseCandidates property is available starting with Oracle Database 19.26 Release Update (RU).

Test Environment

For this test, I configured a Data Guard environment consisting of one primary database and two physical standby databases.

DGMGRL> show configuration

Configuration - DB2

  Protection Mode: MaxPerformance
  Members:
  DB2 - Primary database
    dg1 - Physical standby database
    dg2 - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 20 seconds ago)

In this configuration:

DB2 is the primary database.
dg1 is intended to be the only standby eligible to become primary.
dg2 should remain a standby database and must not participate in switchover or failover operations.

Configuring PrimaryDatabaseCandidates

To restrict role transitions, I configured the PrimaryDatabaseCandidates property as follows:

DGMGRL> edit configuration set property PrimaryDatabaseCandidates='dg1';
Warning: ORA-16588: The primary database was added to property PrimaryDatabaseCandidates
Property "primarydatabasecandidates" updated

Attempting a Switchover to a Restricted Standby

Next, I attempted to perform a switchover to dg2, which is not included in the candidate list.

DGMGRL> switchover to dg2;
2026-02-25T15:42:39.854+03:30
Performing switchover NOW, please wait...
Error: ORA-16529: Switchover and failover operations are restricted to databases specified in the PrimaryDatabaseCandidates configuration property.
Failed.
2026-02-25T15:42:39.859+03:30
Unable to switchover, primary database is still "DB2"

As expected, Data Guard Broker blocked the operation and returned:

Error: ORA-16529: Switchover and failover operations are restricted to databases specified in the PrimaryDatabaseCandidates configuration property.

The primary database remained unchanged, and the switchover was not performed.

26ai- Using Tags in Oracle Data Guard Broker

Vahid Yousefzadeh — Fri, 29 May 2026 13:43:47 +0000

Oracle AI Database 26ai adds tagging support to Oracle Data Guard Broker, allowing administrators to attach custom metadata to configuration members.
With tags, you can attach your own information to Data Guard members. Think of it as adding labels to databases so they become easier to identify later.

For example, you may want to store:

Deployment location
Environment type
Build date
Owner team
Compliance information

Before using tags, the feature must be enabled.

DGMGRL> EDIT CONFIGURATION SET PROPERTY TagMode=1;
Property "tagmode" updated

In this demo, I added two tags to the member dg1.

The first tag stores the location of the database:

DGMGRL>  EDIT MEMBER dg1 SET TAG location='BABOL';
Tag "location" updated in "dg1".

The second tag stores a configuration date:

DGMGRL>  EDIT MEMBER dg1 SET TAG configuation_date='2026-02-25';
Tag "configuation_date" updated in "dg1".

Now we can query V$DG_BROKER_TAG and verify the tags:

SQL> select member,name,value from V$DG_BROKER_TAG;

MEMBER  NAME                VALUE
------- ------------------- --------------------
dg1     location            BABOL
dg1     configuation_date   2026-02-25

Automatic temp file creation on the standby - Oracle AI Database 26ai

Vahid Yousefzadeh — Thu, 26 Feb 2026 06:35:29 +0000

In Oracle Database 19c, when a tempfile is added on the primary database, it is not automatically created on the physical standby database. This is because Oracle does not generate redo for tempfile-related DDL operations (such as creating, adding, resizing, or dropping tempfiles).

Behavior in Oracle Database 19c

For example, when creating a temporary tablespace on the primary database(19c):

— Primary

SQL> create temporary tablespace TEMP1404;
Tablespace created.

SQL> select ts# from v$tablespace where NAME='TEMP1404';
       TS#
----------
        15

SQL> select name from v$tempfile where ts#=15;
NAME
--------------------------------------------------------------------------------
+DATA/HUME/B3AE49A3735D8867E053088A210A341D/TEMPFILE/temp1404.807.1225812657

On the standby database, although the tablespace metadata exists, the tempfile itself is not created:

— Data Guard

SQL> select ts# from v$tablespace where NAME='TEMP1404';
       TS#
----------
        15

SQL> select name from v$tempfile where ts#=15;
no rows selected

If we add another tempfile on the primary:

— Primary

SQL> alter tablespace TEMP1404 add tempfile size 100m;
Tablespace altered.

SQL> select name from v$tempfile where ts#=15;
NAME
--------------------------------------------------------------------------------
+DATA/HUME/B3AE49A3735D8867E053088A210A341D/TEMPFILE/temp1404.807.1225812657
+DATA/HUME/B3AE49A3735D8867E053088A210A341D/TEMPFILE/temp1404.808.1225812823

Again, on the standby database:

— Data Guard

SQL> select name from v$tempfile where ts#=15;
no rows selected

Automatic Tempfile Creation in Oracle AI Database 26ai

Starting with Oracle AI Database 26ai, tempfile creation is automatically handled on the standby database.

To enable this feature, the following parameters must be configured on the standby:

standby_file_management = AUTO
db_create_file_dest must be defined

— Data Guard

SQL> alter system set standby_file_management=AUTO;
System altered.

SQL> alter system set db_create_file_dest='/oracle/base/oradata';
System altered.

Now, when creating a temporary tablespace on the primary:

— Primary

SQL> create temporary tablespace TEMP1404;
Tablespace created.

SQL> select ts# from v$tablespace where NAME='TEMP1404';
       TS#
----------
         5

SQL> select name from v$tempfile where ts#=5;
NAME
--------------------------------------------------------------------------------
/oracle/base/oradata/DB2/4A3B7527123A1205E0630288200AA7B8/datafile/o1_mf_temp1404_nsx3wdt7_.tmp

The tempfile is automatically created on the standby database:

— Data Guard

SQL> select name from v$tempfile where ts#=5;
NAME
--------------------------------------------------------------------------------
/oracle/base/oradata/DG1/4A3B7527123A1205E0630288200AA7B8/datafile/o1_mf_temp1404_nsx3wbyx_.dbf

This enhancement eliminates the need for manual synchronization of tempfile configurations between primary and standby databases, simplifying Data Guard administration.