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.

OCI Basics: Building Your Cloud Network with Virtual Cloud Networks (VCNs)

You've got your cloud computers (Compute Instances) and your storage (Boot and Block Volumes) sorted out. But how do these pieces talk to each other? How do they connect to the internet or stay securely isolated? That's where networking comes in, and in Oracle Cloud Infrastructure (OCI), the foundation of your network is the Virtual Cloud Network.

Think of a VCN like your own private, customizable network that you build inside OCI. Just as your physical home or office network has routers, switches, and security rules, your VCN provides all these capabilities in a virtual environment. It's an isolated network space where all your OCI resources—like your Compute Instances and databases—can securely operate and communicate.

What is a Virtual Cloud Network (VCN)? Your Private Network in the Cloud

A VCN is essentially a software-defined network that you create in OCI. It provides a secure and isolated environment for your cloud resources. Within your VCN, you define your own IP address ranges (like 10.0.0.0/16 or 192.168.1.0/24), subnets, routing rules, and security configurations.

Imagine you're setting up a new office building. You wouldn't just plug all your computers into each other randomly; you'd design a network with different departments having their own sections, and specific rules about who can access what. A VCN is exactly that, but for your cloud "office."

In simple terms: A VCN is your custom, private network in OCI, where all your cloud resources live.

Why is a VCN Important? The Foundation of Connectivity and Security

The VCN isn't just about connecting things; it's also crucial for security and organization.

Isolation and Security: Your VCN is logically isolated from other customer VCNs in OCI. This means your network traffic and resources are private and secure. You control exactly what traffic goes in and out using security rules.

Organization: You can divide your VCN into smaller sections called subnets. This allows you to group resources based on their function (e.g. a "web server subnet" for public-facing servers, and a "database subnet" for backend databases).

Connectivity: Resources within the same VCN can communicate with each other. You can also configure your VCN to connect to the internet, to your on-premises data center, or even to other VCNs.

Flexibility: You have complete control over IP addressing, routing tables, and security lists, allowing you to design a network that perfectly fits your application's requirements.

Analogy: Think of a VCN as your own private plot of land in a massive cloud city. You get to build your roads (routing), divide your land into districts (subnets), and put up fences and security checkpoints (security lists) to control who comes and goes.

Key Fact: Every resource you deploy in OCI, whether it's a Compute Instance, a database, or a load balancer, must be placed within a VCN and a specific subnet.

In simple terms: The VCN is the secure and organized network space where all your OCI cloud components connect and operate.

Understanding VCNs is your next big step in mastering OCI. It’s the invisible backbone that ensures all your cloud components work together efficiently and securely. With a solid grasp of VCNs, you can confidently design and deploy robust applications in the cloud.

OCI Basics: Your First Guide to Cloud Servers and Storage

                         OCI Basics: Your First Guide to Cloud Servers and Storage

So, Let's start our journey with Oracle Cloud Infrastructure (OCI)? Welcome! It can seem like there are a lot of new terms to learn, but it's all quite logical once you break it down.

Today, we're going to talk about the three fundamental building blocks of any cloud setup:                             Compute Instances, Boot Volumes, and Block Volumes.

Think of it like building a new computer. You need the computer itself (the brains), a main hard drive for the operating system, and maybe an extra hard drive for your files. Let's see how this works in OCI.

What is a Compute Instance? The "Computer" in the Cloud

An OCI Compute Instance is basically your own private computer or server living in Oracle's secure data center. It's the "brains" of the operation. This is where you'll run your website, your application, or any other software. It has processing power (CPU) and memory (RAM), just like the PC or Mac you're using right now.

You can choose how powerful you want this cloud computer to be—from something small for a personal blog to a massive server for a busy e-commerce site.

In simple terms: A Compute Instance is your virtual server in the cloud.

What is a Boot Volume? The Main Hard Drive (C: Drive)

Every computer needs a main hard drive where the operating system (like Windows or Linux) is installed. In OCI, this is called a Boot Volume.

When you create a new Compute Instance, OCI automatically creates and attaches a Boot Volume to it. It's the startup disk. Without it, your cloud server wouldn't know how to turn on.

Its Job: To hold the operating system and essential system files.

Analogy: It’s the C: Drive on a Windows PC. It's essential for the computer to start and run.

Key Fact: The Boot Volume is directly tied to its Compute Instance. When the instance starts, the boot volume starts.

In simple terms: The Boot Volume is the startup disk for your cloud server.

What is a Block Volume? The Extra, Portable Hard Drive

Now, what if your main C: Drive is full, or you want to keep your personal files separate from your system files? You’d plug in an external USB hard drive, right? In OCI, that's a Block Volume.

A Block Volume is an extra storage drive that you can attach to your Compute Instance. It’s perfect for storing things like:

Website files and images

Databases

User data

Log files

The best part about Block Volumes is that they are independent. You can unplug it from one Compute Instance and attach it to a different one, and all your files will travel with it, safe and sound. If you decide you don't need your cloud server anymore, you can delete the server but keep the Block Volume with all your important data.

Its Job: To provide extra, flexible storage for your data.

Analogy: It’s like an external USB hard drive. You can attach it, detach it, and move it between computers without losing your files.

Key Fact: Block Volumes live on even if your Compute Instance is deleted. Your data is safe.

In simple terms: A Block Volume is an extra hard drive for your data that you can move around.

Why Does This Matter?

Understanding this separation is key to managing your cloud resources effectively.

Safety: By keeping your important data on a separate Block Volume, you can experiment with, upgrade, or even delete your Compute Instance without worrying about losing your files.

Flexibility: Need to upgrade your server to a more powerful one? Just detach your Block Volume from the old instance and reattach it to the new one. All your data is instantly available.

Cost: You can add exactly as much extra storage as you need, when you need it.

Congratulations! You now understand the core components of running a server in OCI. By thinking of Compute Instances as the computer, Boot Volumes as the main C: drive, and Block Volumes as your trusty external hard drives, you're well on your way to building amazing things in the cloud.

Guide to Managing WebLogic and APPS Passwords in Oracle EBS R12.2

 Guide to Managing WebLogic and APPS Passwords in Oracle EBS R12.2

For any Oracle Apps DBA, managing passwords is a critical and routine task. In Oracle E-Business Suite (EBS) R12.2, with the introduction of WebLogic Server, the process has more layers than in previous releases. Mismanagement of these passwords can lead to system-wide outages, so it's essential to follow the correct procedures.

This guide will walk you through the necessary steps and best practices for changing the APPS schema password and the WebLogic administrator password.

Part 1: Changing the APPS/APPLSYS Password

In EBS, the APPS and APPLSYS schemas are tightly linked, and their passwords must always be identical. 

You should use Oracle's recommended utilities, FNDCPASS or its enhanced version AFPASSWD, for this task. 

Key Utilities:

FNDCPASS: The standard utility for changing passwords for Application Object Library (AOL) users and schemas. 

AFPASSWD: An enhanced version of FNDCPASS that prompts for passwords, allowing for a better separation of duties between DBAs and application administrators. 

Step-by-Step Guide to Changing the APPS Password:

Backup Critical Tables: Before you begin, it's highly recommended to back up the FND_USER and FND_ORACLE_USERID tables. 

Shut Down Application Services: All application tier services must be shut down before changing a system schema password. 

Use the adstpall.sh script from your $INST_TOP/admin/scripts directory.

Change the Password: Use the FNDCPASS or AFPASSWD utility to change the APPLSYS password. When you change the APPLSYS password, the passwords for APPS and APPS_NE are changed simultaneously. 

bash

# Using FNDCPASS 

FNDCPASS apps/<old_apps_password> 0 Y system/<system_password> SYSTEM APPLSYS <new_apps_password> 

# Using AFPASSWD 

AFPASSWD -c apps@<TWO_TASK> -s APPLSYS 

Run AutoConfig: After changing the password, run AutoConfig to propagate the changes. 

Start Only the AdminServer: Do not start all services yet. Start only the WebLogic Admin Server. 

bash

$INST_TOP/admin/scripts/adadminsrvctl.sh start 

Update the WebLogic Data Source: This is a critical step in R12.2. You must update the data source in WebLogic with the new APPS password. You have two options:

Manual Update via Console: Log in to the WLS Administration Console, navigate to Services > Data Sources > EBSDataSource > Connection Pool, and update the password. 

Another Using the txkManageDBConnectionPool.pl Script: For more recent versions of R12.2, Oracle provides a script to automate this. 

bash

perl $FND_TOP/patch/115/bin/txkManageDBConnectionPool.pl 

When prompted, choose the updateDSPassword option.

Start All Application Services: Once the data source is updated, you can start the remaining application services. 

bash

$INST_TOP/admin/scripts/adstrtal.sh 

Verify the Changes: Log in to the WLS Administration Console and test the EBSDataSource connection to ensure it's successful. 

Part 2: Changing the WebLogic Administrator Password

The WebLogic administrator password is also a critical credential to manage. The method for changing it can vary depending on your EBS patch level. 

Step-by-Step Guide to Changing the WebLogic Password (for recent patch levels):

Shutdown Application Services: Stop all application tier services. 

Start the AdminServer: Start only the Admin Server. 

Use the txkUpdateEBSDomain.pl Script: Oracle provides a script to update the WebLogic administrator password. 

Be extremely careful, as it does not ask for password confirmation.

bash

perl $FND_TOP/patch/115/bin/txkUpdateEBSDomain.pl -action=updateAdminPassword 

Restart All Services: After the script completes successfully, restart all application tier services. 

Verify the New Password: Log in to the WebLogic Server console and the Enterprise Manager (EM) with the new password to confirm the change was successful. 

For older patch levels, the process involves more manual steps within the WebLogic console and editing boot.properties files. 

Best Practices for Password Management

Regularly Change Passwords: Adhere to your organization's security policies for password rotation. 

Use Strong Passwords: Avoid easily guessable passwords. Use a combination of uppercase letters, lowercase letters, numbers, and special characters. 

Separate Duties: Where possible, use tools like AFPASSWD to allow for a separation of administrative roles. 

Document Everything: Keep a secure record of all password changes and the procedures followed.

Backup: Always back up relevant tables and configuration files before making any changes.

By following these structured procedures and best practices, you can confidently and securely manage the critical passwords in your Oracle EBS R12.2 environment.

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