19c Release Update (RU) Application Checklist for EBS DBAs

If you support Oracle E-Business Suite on Database 19c, Release Updates aren't optional — they're a recurring fact of life. Every quarter (or close to it), a new RU lands, and every time, the same question comes up: what do I actually need to check before, during, and after applying it?

This post lays out a practical checklist you can reuse every cycle, built around the mistakes that most commonly turn a routine RU into a weekend-long incident.

1. Why RUs Matter for EBS Specifically

Unlike a generic database, EBS layers a large amount of custom PL/SQL, interMedia/Text indexes, and AD/FND schema objects on top of the core database. An RU that applies cleanly on a vanilla database can still break EBS-specific objects if datapatch doesn't run cleanly, or if EBS-specific interoperability patches haven't been applied for that RU level.

Important

Always check My Oracle Support for the EBS interoperability note that corresponds to your specific RU before applying it. Applying an RU without checking EBS certification/interop patches is one of the most common causes of post-patch breakage.

2. Pre-Application Checklist

• Confirm the target RU is certified for your EBS release and Database edition (check My Oracle Support certification pages, not just the RU release notes)

• Identify and download the EBS-specific interoperability patch for that RU, if one exists — these are often released a few weeks after the base RU

• Review the RU's known issues and bug fixes list for anything relevant to EBS (AD/TXK, Fusion Middleware, or interMedia-related fixes are the ones to watch)

• Take a full RMAN backup (or validated snapshot) immediately before applying — don't rely on a backup from days earlier

• Confirm sufficient space in the Oracle Home, $ORACLE_BASE, and the OPatch inventory location — RU staging can consume significant space

• Run OPatch conflict checks (opatch prereq CheckConflictAgainstOHWithDetail) against the current Oracle Home before applying

• Verify you're on a supported OPatch version — RUs frequently require a minimum OPatch version, and applying with an outdated OPatch is a common failure point

• Schedule a maintenance window that accounts for datapatch runtime, not just the OPatch apply itself — datapatch on an EBS-sized schema can take considerably longer than on a vanilla database

Tip

Run the pre-checks in a non-production clone first, even if it's just a quick sanity check. An RU that applies cleanly on a smaller or differently-configured non-prod instance can still surface unexpected conflicts on production due to one-off patches already in place.

3. Applying the RU — Step by Step

Step 1: Stop all instances tied to the Oracle Home

Shut down the database and any listener processes cleanly before touching the Oracle Home.

Step 2: Apply the RU with OPatch

$ export ORACLE_HOME=<db_oracle_home>
$ cd <RU_patch_directory>
$ $ORACLE_HOME/OPatch/opatch apply

Step 3: Start the database in upgrade mode and run datapatch

$ sqlplus / as sysdba
SQL> startup
$ cd $ORACLE_HOME/OPatch
$ ./datapatch -verbose

Step 4: Review the datapatch log carefully

Don't just check the exit code — open the log and confirm every SQL patch shows a successful status. Partial datapatch failures don't always stop the process outright.

Note

If datapatch reports failed or errored patches, do not proceed to the EBS-specific steps until the underlying SQL error is understood. Re-running datapatch blindly can mask the real issue.

4. EBS-Specific Post-Steps

• Apply the EBS interoperability patch for the RU, if applicable, using adop in the normal patching cycle
• Run AutoConfig on both the run and patch file systems to pick up any configuration changes
• Re-run EDBPC (the EBS Database Parameter Checker) to confirm no recommended parameters were reset or need adjustment after the RU — RUs occasionally touch parameter defaults
• Validate invalid objects in the database and recompile as needed:

$ sqlplus apps/apps_password
SQL> @$AD_TOP/sql/adzdshow.sql

• Check the FND and AD schema for any objects left invalid after the patch, and utlrp.sql if needed
• Confirm concurrent managers start cleanly and process a test request
• Spot-check a few core responsibilities (login, forms, OA Framework pages) before declaring the window closed

5. Common Failure Points to Watch For

6. Build a Reusable Runbook

Since RUs come every quarter, don't start from scratch each time. Keep a running document (or better, a checklist template) that captures:

• The certification note number for your current EBS/DB combination
• Space and OPatch version requirements confirmed for the last few RUs
• Any environment-specific one-off patches you always need to re-verify for conflicts
• Your actual maintenance window timing from the last few cycles, so estimates stay realistic

Summary

Applying a 19c RU to an EBS environment is more than an OPatch command — it's a sequence of certification checks, datapatch validation, and EBS-specific post-steps (interoperability patch, AutoConfig, invalid object checks). Most RU incidents trace back to skipping the EBS interoperability patch, an outdated OPatch version, or not reviewing the datapatch log closely enough. Build a runbook once, and every quarterly cycle gets faster and safer. Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Reference: Check My Oracle Support for the RU-specific EBS interoperability note and the current EDBPC patch number (MOS KA1180) before every cycle.

Hybrid Read-Only Mode in Oracle Database 26ai

Oracle continues to evolve its multitenant architecture with features that improve flexibility, availability, and control. One of the most impactful enhancements in Oracle Database 26ai is Hybrid Read-Only Mode—a smart balance between operational continuity and administrative control.

What is Hybrid Read-Only Mode?

Hybrid Read-Only Mode allows a Pluggable Database (PDB) to operate in a unique state where:

• Local users are restricted to read-only access
• Common users (like SYS, SYSTEM, or other CDB-level users) still have read-write privileges

This means that while application users can continue querying data, administrative users can still perform critical changes in the background.

How It Works

In a traditional setup:

• A READ ONLY PDB blocks all write operations (including admin tasks)
• A READ WRITE PDB allows full access to everyone

With Hybrid Read-Only Mode:

• Oracle introduces a middle ground
• Local users - No data modifications allowed
• Common users - Full administrative control remains intact

This separation ensures better governance and operational safety.

Comparison of Modes

Let's get our hands dirty and see how this feature works in a practical lab scenario. We'll use a PDB named ORCLPDB for this demonstration.

First, connect as a privileged user to the root container. You'll need to close the PDB before you can reopen it in the new hybrid state.

Close the PDB:- 

Open the PDB in the new hybrid mode

Verify the State

Test the Access Levels

As a Local User

Hybrid Read-Only Mode in Oracle 26ai is a strategic enhancement that empowers administrators to maintain and patch databases with minimal disruption. It strikes a balance between operational safety and flexibility, making it a valuable tool in modern database management.

Oracle Document :- https://blogs.oracle.com/ace/how-to-use-the-new-hybrid-readonly-mode-for-pluggable-databases-in-oracle-database-23c-free-developer-release

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Creating a New Pluggable Database Using PDB$SEED

Oracle's Multitenant architecture allows a Container Database (CDB) to host multiple Pluggable Databases (PDBs), each acting as a fully independent Oracle database. One of the most common DBA tasks is provisioning a new PDB — and the fastest, cleanest way to do it is by cloning from PDB$SEED, the read-only template PDB that ships with every CDB.

In this guide, we walk through the entire process — from verifying prerequisites to opening and saving the PDB's state across restarts.

What is PDB$SEED?

PDB$SEED is a special, read-only template PDB that Oracle ships with every Container Database. It contains the minimal set of data files and dictionary objects required to seed a new Pluggable Database. When you create a PDB using the default method, Oracle copies PDB$SEED's data files to a new location and bootstraps a fresh PDB from them.

Key characteristics of PDB$SEED:

•        Always in READ ONLY mode — it can never be opened for writes

•        CON_ID = 2 in every CDB (CDB$ROOT = 1, user PDBs start from 3)

•        Patched automatically when you run datapatch on the CDB

•        Serves as the template for CREATE PLUGGABLE DATABASE ... FROM PDB$SEED (the default)

Note: Never attempt to open PDB$SEED in READ WRITE mode. Oracle will reject it, and attempting workarounds can corrupt your CDB.

Step 1 -Verify Prerequisites

Before issuing the CREATE command, confirm your session is connected to CDB$ROOT and that PDB$SEED is healthy.

1. Confirm you are in CDB$ROOT

    Show CON_NAME

2. Confirm this is a CDB

     SELECT NAME, CDB, CON_ID FROM V$DATABASE;

3. List all existing PDBs
        SELECT CON_ID, NAME, OPEN_MODE, RESTRICTED FROM V$PDBS ORDER  BY CON_ID;

4. Verify PDB$SEED is READ ONLY

    SELECT CON_ID, NAME, OPEN_MODE FROM   V$PDBS WHERE  NAME = 'PDB$SEED';

Note: If SHOW CON_NAME returns a PDB name rather than CDB$ROOT, switch back: ALTER SESSION SET CONTAINER = CDB$ROOT;

Step 2 - Create the Pluggable Database

CREATE PLUGGABLE DATABASE TESTPDB1 ADMIN USER TESTPDB1 IDENTIFIED BY "StrongPassword#1"  ROLES = (DBA)  DEFAULT TABLESPACE users DATAFILE '/u01/app/oracle/oradata/TEST/TESTPDB1/users01.dbf' SIZE 250M AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED  FILE_NAME_CONVERT = ( '/u01/app/oracle/oradata/TEST/pdbseed/',    '/u01/app/oracle/oradata/TEST/TESTPDB1/');

Step 3 - Open the PDB

Newly created PDB is in MOUNTED state. You must open it explicitly before any connections can be made.

Open the PDB in READ WRITE mode

    ALTER PLUGGABLE DATABASE TESTPDB1 OPEN;

Verify the open mode

    SELECT CON_ID, NAME, OPEN_MODE, RESTRICTED FROM   V$PDBS WHERE  NAME = 'PDB_NAME';

Step 4 - Save the Open State

By default, PDBs return to MOUNTED state when the CDB is restarted. Use SAVE STATE to instruct Oracle to automatically re-open the PDB to its saved mode after every CDB startup.

Persist the open state across CDB restarts
 ALTER PLUGGABLE DATABASE TESTPDB1 SAVE STATE;

Confirm the saved state
    SELECT CON_NAME, STATE FROM   DBA_PDB_SAVED_STATES;

Note: SAVE STATE is the equivalent of adding the PDB to a startup trigger. Always run it after opening a new PDB in production.

Step 5 - Post-Creation Tasks

With the PDB open, switch into it and perform the initial housekeeping tasks before handing it off to the application team.

-- Switch into the new PDB

ALTER SESSION SET CONTAINER = TESTPDB1;

-- Confirm context

SHOW CON_NAME;

-- Review tablespaces

SELECT TABLESPACE_NAME, STATUS, CONTENTS FROM   DBA_TABLESPACES; 

-- Create the application user

CREATE USER app_user IDENTIFIED BY "AppPassword#1"

  DEFAULT TABLESPACE users

  TEMPORARY TABLESPACE temp

  QUOTA UNLIMITED ON users;

 GRANT CONNECT, RESOURCE TO app_user;

 -- Return to CDB root

ALTER SESSION SET CONTAINER = CDB$ROOT;

The table below covers the most frequent errors encountered during PDB creation and their resolutions.

Error Code	Cause	Fix
ORA-65012	PDB name already exists	Choose a different name or drop the existing PDB
ORA-17537	Wrong file path	Verify FILE_NAME_CONVERT paths exist on the OS
ORA-65016	FILE_NAME_CONVERT required	Set DB_CREATE_FILE_DEST or specify FILE_NAME_CONVERT
ORA-01109	PDB not open	Run ALTER PLUGGABLE DATABASE pdb_name OPEN
ORA-65040	Not in CDB root	Run ALTER SESSION SET CONTAINER = CDB$ROOT first

Key Takeaways

• PDB$SEED is the read-only seed template — never open it in READ WRITE mode
• Always run from CDB$ROOT with SYSDBA privileges when creating PDBs
• FILE_NAME_CONVERT is mandatory unless OMF (DB_CREATE_FILE_DEST) is configured
• Newly created PDBs are in MOUNTED state — open them explicitly with ALTER PLUGGABLE DATABASE ... OPEN
• Always run SAVE STATE in production so PDBs survive CDB restarts automatically
• Each PDB shares the CDB's redo, undo, and TEMP — but owns its own data files.

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

How to Enable Archive Log Mode and Change Archive Log Destination in Oracle 19c

Introduction

Archive logging is a critical feature in Oracle databases that enables database recovery and online backups. When the database runs in ARCHIVELOG mode, Oracle archives redo log files before they are overwritten. These archived logs can later be used for point-in-time recovery and disaster recovery.

In this article, we will walk through:

• Checking the current archive log status

• Enabling ARCHIVELOG mode

• Configuring the Fast Recovery Area (FRA)

• Changing the archive log destination

• Verifying archive log generation

This guide applies to Oracle 19c running on Linux.

Step 1: Check the Current Archive Log Location and Archive Log Status

First, connect to the database and verify the current archive log destination.

Explanation

• Database log mode: No Archive Mode – The database is not archiving redo logs.

• Automatic archival: Disabled – Archive log generation is turned off.

• Archive destination: Default location where archive logs will be stored once archiving is enabled.

• Log sequence numbers: Show the redo log sequence currently in use.

Since the database is in NOARCHIVELOG mode, you cannot perform point-in-time recovery or hot backups.

Step 2: Steps to Enable ARCHIVELOG Mode

Shutdown the Database

Start Database in Mount Mode

Enable ARCHIVELOG Mode

Open the Database

Step 3: Verify Archive Log Mode

Step 4: Configure Fast Recovery Area (FRA)

The Fast Recovery Area (FRA) is a central location where Oracle stores:

• Archive logs

• Flashback logs

• Backup files

• Control file backups

Check the FRA parameters.

Set FRA Size

Step 5: Set Archive Log Destination

Step 6: Confirm Archive Destination

Step 7: Generate Archive Logs

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Oracle Database Security Assessment Tool (DBSAT) Version: 4.2.0.0.0

What is Oracle Database Security Assessment?

Oracle Database Security Assessment is the process of reviewing database configurations, user privileges, and security settings to detect vulnerabilities and ensure that security policies are properly implemented.

The goal is to identify risks such as:

Weak password policies

Excessive user privileges

Unpatched vulnerabilities

Lack of auditing and monitoring

Misconfigured database parameters

By performing regular security assessments, organizations can strengthen their database security posture and prevent unauthorized access.

Database security is a critical responsibility for every DBA. Regular security assessments help identify vulnerabilities before attackers can exploit them.

Oracle Database Security Assessment Tool (DBSAT) consists of three main components: Collector, Reporter, and Discoverer, each designed to analyze and evaluate different aspects of database security.

The Collector and Reporter work together to detect potential security risks in the Oracle Database environment and generate the Database Security Assessment Report, while the Discoverer operates independently to identify and report sensitive data through the Database Sensitive Data Assessment Report.

Collector:

The Collector gathers information from the target database by executing SQL queries and operating system commands. It mainly retrieves metadata from database dictionary views and stores the collected data in a JSON file, which is later used by the Reporter for analysis.

Reporter:

The Reporter processes and analyzes the data collected by the Collector. Based on this analysis, it generates a detailed security assessment report that highlights potential risks and configuration issues. The report can be produced in multiple formats, including HTML, Excel, JSON, and Text.

Discoverer:

The Discoverer is responsible for locating sensitive data within the database. It runs SQL queries on database dictionary views according to the rules defined in configuration files. The output identifies potentially sensitive information and provides reports in HTML, CSV, and JSON formats.

How to download DBSAT Tool?

To download you need to use below link. 

https://support.oracle.com/support/?anchorId=&kmContentId=2138254&page=sptemplate&sptemplate=km-article 

Demo: Running a Security Assessment Using DBSAT

Installing DBSAT 

Create directory to install DBSAT

mkdir dbsat4

Download or copy the dbsat.zip file to the database server

Unzip the DBSAT zip file

Collect Data

Let's  reviewing all DBSAT command-line parameters

Run DBSAT to collect data from TEST

Generate the report 

Unpack the file to view the reports

Analyze Report

Discover Sensitive Data

Unpack the file to view the reports

View Sensitive Data

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Apply Patch RU on Database 19c(19.30)

 

Environment:- 

      DB Version : Oracle 19c, File system: Normal

       Platform : Linux86_64

Download Patch from My Oracle Support:- 

https://support.oracle.com/support/anchorId=&documentId=CPU4&page=sptemplate&sptemplate=km-article

Unzip Patch:-

Unzip Bundle Patch

First, apply the Database RU patch 38632161.
Minimum required OPatch version for this patch is 12.2.0.1.48.
Let’s verify our current OPatch version before proceeding.

Current Version:-

Let’s upgrade the OPatch version by downloading Patch 6880880.
While downloading, select "OPatch for DB 19.0.0.0.0" from the Select a Release dropdown menu, as shown in the screenshot below.

Now, the OPatch version has been upgraded.

 Interim Patch Conflict Detection and Resolution

Shutdown database and as well listener

Let's Apply Database RU patch 

Applying OJVM Patch 

Current Version Apply SQL Changes(DataPatch)

Verify from dba_registry_sqlpatch

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.