Showing posts with label AI. Show all posts

Thursday, September 10, 2026

Video Tutorial - How to install Oracle RAC Grid ?

Install Oracle RAC Grid

Wednesday, September 9, 2026

Video Tutorial - How to create or drop the users in Oracle Database ?

How to create user in Oracle Database ?

How to drop user in Oracle Database ?

How to set custom name on CMD prompt in Linux OS (Operating System) ?

Video Tutorial - Enterprise High-Availability Metrics and SLA Standards "Nines" Explanation

High-Availability Metrics and SLA Standards "Nines"

Video Tutorial - Oracle Database Start / Stop Administration

How to Start the Oracle Database ?

How to Stop / Shutdown the Oracle Database ?

Explain in detail how oracle database start ?

Explain in detail how oracle database stop / shutdown ?

Wednesday, August 26, 2026

what is catcon.pl (Catalog Container Script) and why very useful for Oracle Multitenant Database ?

catcon.pl (Catalog Container Script) is an Oracle utility introduced with the Multitenant Architecture (CDB/PDB) to execute SQL scripts across one or more containers (CDB root, PDBs, or all PDBs).

It is heavily used during:

Database upgrades
Patching (RU, RUR, OJVM)
Running Oracle supplied scripts
Component installation
Post-upgrade tasks
Custom DBA scripts across all PDBs

Why Oracle Created catcon.pl

Before Multitenant, if you had:

ORCL

you ran a script once:

@script.sql

With Multitenant:

CDB1

├── PDB1

├── PDB2

├── PDB3

└── PDB4

The script may need to run in:

CDB$ROOT
PDB1
PDB2
PDB3
PDB4

Instead of connecting manually to each container, Oracle uses catcon.pl to automate the execution.

Location

Usually located under:

$ORACLE_HOME/rdbms/admin

Check:

find $ORACLE_HOME -name catcon.pl

Common path:

$ORACLE_HOME/rdbms/admin/catcon.pl

Basic Syntax

perl catcon.pl [options] script.sql

Example:

$ORACLE_HOME/perl/bin/perl

$ORACLE_HOME/rdbms/admin/catcon.pl

-b test

-d /tmp

test.sql

Where:

-b = base name for logs
-d = script directory
test.sql = SQL script to execute

Execute Script on All PDBs

Example:

$ORACLE_HOME/perl/bin/perl

$ORACLE_HOME/rdbms/admin/catcon.pl

-b gather_stats

-d /tmp

gather_stats.sql

The script runs across all open containers.

Run Script Only in Specific PDB

$ORACLE_HOME/perl/bin/perl

$ORACLE_HOME/rdbms/admin/catcon.pl

-c 'PDB1'

-b test

-d /tmp

script.sql

Here:

PDB1 only

is processed.

Run in Multiple PDBs

-c 'PDB1 PDB2 PDB3'

Example:

catcon.pl -c 'PDB1 PDB2 PDB3' script.sql

Exclude Specific PDBs

-C 'PDB$SEED'

Example:

catcon.pl -C 'PDB$SEED' script.sql

Common Options

Option	Description
-b	Base log file name
-d	Script location
-c	Include containers
-C	Exclude containers
-n	Parallel execution
-l	Log directory
-u	Username
-p	Password

Parallel Execution

Suppose you have 20 PDBs.

Without parallelism:

catcon.pl script.sql

Runs one at a time.

Use:

catcon.pl -n 8 script.sql

to execute in parallel across 8 PDBs.

Example: Gather Dictionary Statistics

Oracle commonly uses:

$ORACLE_HOME/perl/bin/perl

$ORACLE_HOME/rdbms/admin/catcon.pl

-n 4

-l /tmp/logs

-b gatherstats

-d $ORACLE_HOME/rdbms/admin

gather_stats.sql

During Database Upgrade

After upgrading Oracle software, Oracle internally runs scripts such as:

catupgrd.sql

utlrp.sql

using catcon.

Example:

catctl.pl

internally calls:

catcon.pl

to process all PDBs.

Relationship:

catctl.pl

+-- catcon.pl

+-- Executes scripts in all containers

Example: Recompile Invalid Objects in All PDBs

Instead of:

ALTER SESSION SET CONTAINER=PDB1;

@utlrp.sql

ALTER SESSION SET CONTAINER=PDB2;

@utlrp.sql

Use:

$ORACLE_HOME/perl/bin/perl

$ORACLE_HOME/rdbms/admin/catcon.pl

-b utlrp

-d $ORACLE_HOME/rdbms/admin

utlrp.sql

Oracle recompiles invalid objects in all PDBs automatically.

Log Files

Suppose:

-b test

-l /tmp/logs

Oracle generates:

test0.log

test1.log

test2.log

test3.log

along with spool files for each container.

Very useful during:

Upgrades
PSU/RU patching
Component installation

How catcon Knows the Current Container

Within the SQL script, you can identify the current container:

SELECT SYS_CONTEXT('USERENV','CON_NAME')

FROM dual;

When executed through catcon, each container processes the script independently.

Typical Oracle Scripts Executed with catcon

utlrp.sql

catalog.sql

catproc.sql

utluiobj.sql

dbmsupgnv.sql

gather_stats.sql

Best Practices for DBAs

Execute on all open PDBs

catcon.pl -n 8 script.sql

Keep separate log directory

-l /u01/logs

Validate PDB status before execution

SHOW PDBS;

Review logs after completion

grep -i "ORA-" *.log

Exclude PDB$SEED unless Oracle documentation requires it

-C 'PDB$SEED'

catcon.pl vs catctl.pl

Utility	Purpose
`catcon.pl`	Execute scripts across CDB/PDBs
`catctl.pl`	Database upgrade orchestration tool
`dbupgrade`	Wrapper around `catctl.pl`
`datapatch`	Applies SQL patch changes using catcon internally

In One Line

catcon.pl is Oracle's Multitenant utility that executes SQL scripts simultaneously across one or more PDBs/CDB containers, making patching, upgrades, and administrative operations manageable in environments with many PDBs.

Saturday, August 22, 2026

10000 foot level overview - High-Level Oracle 26ai Database overview and enhancement

Oracle AI Database 26ai

AI-Native, Secure, Highly Available and Developer-Friendly Database

Executive Summary

Oracle AI Database 26ai is Oracle’s long-term support, AI-native database release. It integrates AI, application development, security, high availability, analytics, and distributed data management into a single converged platform.

Key Value Proposition

Build enterprise AI applications directly on business data
Develop modern applications using SQL, JSON, Graph, Vector and JavaScript
Protect data consistently across users, applications and AI agents
Deliver mission-critical availability and global scalability
Reduce data movement and platform complexity

1. AI and Generative AI

Major Capabilities

AI Vector Search
Performs semantic searches based on meaning rather than exact keywords.
Unified Hybrid Vector Search
Combines vector, relational, text, JSON, graph and spatial searches in a single query.
Enterprise RAG
Uses private business data to improve the accuracy and relevance of LLM-generated answers.
Select AI
Enables users to query enterprise data using natural language.
Select AI Agent
Supports governed AI agents that can retrieve information, execute database tools and perform business actions.
Model Context Protocol integration
Allows AI assistants and agent frameworks to securely discover and use database tools.
Private Agent Factory
Provides low-code and no-code capabilities for building private enterprise AI agents.
In-Database Machine Learning
Allows organizations to train and score ML models without moving sensitive data outside the database.

Business Value

Bring AI to the data instead of moving enterprise data to separate AI platforms.

2. Modern Application Development

Major Capabilities

JSON-Relational Duality Views
Applications can access the same data as JSON documents or relational tables without creating duplicate copies.
JavaScript Stored Procedures
Developers can implement server-side application logic using JavaScript.
Operational Property Graphs
Graph analysis can be performed directly on operational relational data using SQL.
Lock-Free Reservations
Improves concurrency for highly contested data such as account balances, inventory and seat reservations.
Priority Transactions
Protects critical business transactions by automatically resolving lower-priority blocking transactions.
Data Use Case Domains
Centralizes reusable business definitions such as email, currency, URL and product identifiers.
Data Annotations
Adds business meaning to database objects, helping AI systems better understand enterprise data.
Assertions
Enforces complex business rules across multiple tables using declarative database constraints.
Enhanced SQL
Includes Boolean data types, simplified queries, direct joins for updates and deletes, and tables with up to 4,096 columns.

Business Value

Accelerates application development while reducing middleware, ORM complexity and duplicate data stores.

3. Microservices and Event-Driven Applications

Major Capabilities

Transactional Event Queues
Kafka-compatible APIs
Database-supported Saga transactions
REST and JSON APIs
MongoDB-compatible access
Redis-compatible caching
Transaction-aware messaging
Lock-free concurrency controls

Business Value

Enables reliable microservices and event-driven applications while maintaining transactional consistency.

4. High Availability and Scalability

Major Capabilities

Oracle Real Application Clusters
Provides active-active instance availability and horizontal database scaling.
Oracle Data Guard
Delivers disaster recovery and standby database protection.
Active Data Guard
Offloads read-only workloads, reporting and backups to standby databases.
Application Continuity
Replays eligible application requests following recoverable failures.
Transaction Guard
Determines the reliable outcome of transactions after interruptions.
True Cache
Provides an automatically managed, consistent in-memory cache for read-intensive applications.
Online Maintenance
Supports rolling patching, application upgrades and selected schema changes with minimal disruption.

Business Value

Maintains application availability during failures, maintenance and infrastructure changes.

5. Globally Distributed Database

Major Capabilities

Database Sharding
Distributes data across multiple databases for horizontal scalability and fault isolation.
Directory-Based Sharding
Provides flexible control over where tenant or customer data is stored.
Raft Replication
Delivers built-in consensus-based replication and rapid failover for sharded environments.
Automatic Data Movement
Automatically relocates data when a sharding key changes.
Geographic Data Distribution
Helps address data residency, latency and regional availability requirements.

Business Value

Supports globally distributed applications with scale, local performance and regional fault isolation.

6. Security and Data Protection

Major Capabilities

Deep Data Security
Enforces authorization at the row, column or cell level for users, applications and AI agents.
SQL Firewall
Detects and blocks unauthorized SQL statements and SQL injection attacks.
Schema-Level Privileges
Simplifies access management without granting broad system privileges.
Developer Role
Provides developers with a predefined least-privilege role.
Multi-Factor Authentication
TLS 1.3
OAuth 2.0
Microsoft Entra ID integration
Constrained Kerberos delegation
Read-Only Users and Sessions
Longer Password Support

Existing Enterprise Controls

Transparent Data Encryption
Database Vault
Data Redaction
Virtual Private Database
Unified Auditing
Fine-Grained Auditing
Privilege Analysis
Oracle Key Vault integration

Business Value

Protects enterprise data at its source, regardless of whether it is accessed by a user, application, analytics tool or AI agent.

7. Analytics and Lakehouse

Major Capabilities

Autonomous AI Lakehouse
Apache Iceberg support
Vector search over lakehouse data
SQL analytics
Graph analytics
Spatial analytics
JSON analytics
Text search
In-database machine learning

Business Value

Combines operational data, analytics, AI and open lakehouse data without creating multiple isolated platforms.

8. Performance and Optimization

Major Capabilities

True Cache for read scalability
Lock-Free Reservations for high-concurrency workloads
Improved Hybrid Columnar Compression
Wide tables with up to 4,096 columns
Consolidated background processes
RAC-based scale-out
Sharding-based horizontal scaling
Exadata optimization

Business Value

Improves transaction throughput, query performance, storage efficiency and application response time.

9. Manageability and DevOps

Major Capabilities

Multitenant CDB and PDB architecture
Automated provisioning and cloning
Fleet patching and standardized maintenance
Container images for development and CI/CD
Automated backup and recovery
Automatic performance diagnostics
Autonomous tuning, indexing and scaling
Simplified transition from Oracle Database 23ai
Enterprise monitoring and observability

Business Value

Reduces operational effort and enables consistent database management across on-premises, cloud and multicloud environments.

Key Features at a Glance

Category	Key Features
AI	Vector Search, Hybrid Search, RAG, Select AI, AI Agents and MCP
Applications	JSON Duality, JavaScript, Graph, Domains, Assertions and enhanced SQL
Microservices	Kafka APIs, TxEventQ, Sagas, REST, Redis and MongoDB-compatible APIs
High Availability	RAC, Data Guard, Active Data Guard, Application Continuity and True Cache
Distributed Database	Sharding, Raft Replication and geographic data distribution
Security	Deep Data Security, SQL Firewall, MFA, TLS 1.3 and Entra ID
Analytics	Autonomous AI Lakehouse, Iceberg, Graph, Spatial, JSON and ML
Performance	True Cache, HCC, lock-free transactions, RAC and Exadata
Operations	Multitenant, automation, containers, fleet management and autonomous operations

Top Features for Enterprise Adoption

Immediate Priorities

SQL Firewall and schema-level privileges
Deep Data Security for applications and AI agents
Application Continuity and Data Guard improvements
JSON-Relational Duality for modern applications
AI Vector Search for enterprise RAG

Strategic Priorities

True Cache for read-intensive workloads
Select AI and Select AI Agent
Transactional Event Queues and Kafka APIs
Autonomous AI Lakehouse and Apache Iceberg
Sharding with Raft replication

Oracle AI Database 26ai features and use

Oracle AI Database 26ai features, It focuses on application development, AI, high availability, security, distributed databases, performance, analytics, and manageability rather than listing every minor initialization parameter or API enhancement.

Release context: Oracle AI Database 26ai is the long-term support release that replaces Oracle Database 23ai. Existing 23ai environments can transition by applying the relevant Release Update, without a conventional database upgrade or application recertification. Features introduced during the 23ai innovation cycle are therefore part of the broader 26ai feature set.

1. AI and Generative AI

1.1 Oracle AI Vector Search

Native VECTOR data type for storing numerical embeddings.
Semantic similarity search based on meaning rather than exact keyword matching.
Exact and approximate nearest-neighbor vector search.
Vector indexes for scalable similarity search.
Ability to combine vector predicates with:
- Relational filters
- Full-text search
- JSON
- Spatial data
- Property graphs
Support for enterprise Retrieval-Augmented Generation, or RAG.
Database-native document loading, transformation, chunking, embedding, retrieval, and LLM integration.
Vector search over structured and unstructured information.
Support for vectors stored in Oracle tables and Apache Iceberg tables.

1.2 Unified Hybrid Vector Search

Oracle can combine different retrieval techniques in one workflow:

Semantic vector search
Keyword and Oracle Text search
Relational SQL predicates
JSON filtering
Spatial filtering
Graph relationships
Business-rule filters

This is particularly useful for enterprise RAG because exact terms such as employee IDs, product codes, locations, and policy names can be combined with semantic similarity.

1.3 Select AI

Select AI provides a natural-language interface to enterprise data:

Converts natural-language questions into SQL.
Generates natural-language explanations from query results.
Supports conversational interaction with database data.
Supports RAG over private enterprise content.
Uses database metadata and annotations to improve generated SQL.
Can integrate with supported external LLM providers.
Helps reduce the need for applications to build separate natural-language-to-SQL layers.

1.4 Select AI Agent

Create and operate AI agents close to governed enterprise data.
Agents can use database objects and procedures as tools.
Agents can invoke external tools through REST interfaces.
Agents can interact with MCP servers.
Supports multi-step agentic workflows involving retrieval, reasoning, and actions.
Database security and auditing can be applied to agent activity.

1.5 Model Context Protocol support

Oracle Database can participate in the MCP ecosystem used by AI applications and agents.
Database capabilities can be exposed as discoverable agent tools.
Managed MCP endpoints can expose Select AI Agent tools.
MCP clients can invoke governed database functions and retrieval workflows.
Integration logic can be kept closer to the data rather than creating a separate custom middleware service.

1.6 Private Agent Factory

No-code or low-code creation of private enterprise AI agents.
Deployable in a customer-controlled environment.
Designed to work against protected enterprise information.
Helps create agents without sending all business data to externally managed systems.
Complements Select AI and database-native agent capabilities.

1.7 Private AI Services Container

Supports deployment of selected AI services in customer-controlled infrastructure.
Helps organizations keep AI processing closer to sensitive database data.
Useful for regulated, disconnected, or tightly controlled environments.
Reduces dependency on sending information to a public AI endpoint.

1.8 Embedding and model interoperability

Integration with leading LLMs.
Support for ONNX embedding models.
Ability to generate embeddings through database-controlled workflows.
Support for open agentic AI frameworks.
Greater flexibility in selecting embedding and language models.

1.9 In-database machine learning

Train and score models without moving data outside the database.
Enhancements to algorithms for improved text and data classification.
Better algorithm performance and flexibility.
Integration of machine-learning output with SQL, analytics, and application workloads.
Reduces data movement and separate ML infrastructure requirements.

2. Application Development

2.1 JSON-Relational Duality Views

Present normalized relational data as application-friendly JSON documents.
Read and update the same underlying data through either SQL or JSON.
Avoid maintaining separate relational and document copies.
Reduce dependence on complex Object-Relational Mapping frameworks.
Updatable JSON documents remain transactionally consistent with relational tables.
Accessible using SQL, REST, document APIs, and MongoDB-compatible interfaces.
Supports optimistic or lock-free concurrency control.
Fine-grained rules can control whether parts of the document are insertable, updateable, or deletable.

2.2 Native JSON capabilities

Native JSON data type and optimized binary JSON storage.
SQL/JSON query and transformation functions.
JSON collection tables.
JSON search indexes.
JSON schema validation capabilities.
JSON document access through SODA and supported document APIs.
Integration of JSON with vector, spatial, graph, and relational queries.

2.3 JavaScript stored procedures

Develop database stored procedures in JavaScript.
Use JavaScript for server-side application logic.
Access database data directly from JavaScript procedures.
Allows JavaScript developers to build data-intensive logic closer to the database.
Complements existing PL/SQL, Java, SQL, and external-language support.

2.4 Operational Property Graphs and SQL/PGQ

Create property graphs over operational relational data.
Query graph relationships using the ISO/IEC SQL Property Graph Queries standard.
Run graph analysis without copying operational data to a separate graph database.
Combine graph results with relational, JSON, vector, and spatial operations.
Useful for fraud detection, dependency analysis, network analysis, recommendations, and customer relationships.

2.5 Lock-Free Reservations

Reserve portions of a numeric resource without locking the complete row.
Designed for heavily updated records such as:
- Account balances
- Inventory quantities
- Seats
- Credit limits
- Quotas
Validation is performed without conventional row-lock serialization.
Final updates are applied at commit.
Improves throughput and reduces blocking for high-concurrency OLTP applications.

2.6 Priority Transactions

Applications can assign transaction priorities.
A low-priority transaction blocking a high-priority transaction can be automatically aborted.
Helps protect business-critical operations.
Reduces the need for DBAs to identify and terminate blockers manually.
Maintains better throughput under contention.

2.7 Data Use Case Domains

Define reusable domain-level business semantics for columns.
Examples include:
- Email
- URL
- Currency
- Password
- Phone number
- Product identifier
Centralizes data validation and semantic information.
Applications and development tools can use domains for code generation and value validation.
Helps maintain consistent definitions across tables and applications.

2.8 Data annotations

Attach business descriptions and semantic context to schemas and data.
Give AI systems a clearer understanding of table and column meaning.
Improve natural-language-to-SQL accuracy.
Improve AI-generated application code.
Reduce ambiguity where technical database names differ from business terminology.

2.9 SQL enhancements

Major developer-facing enhancements include:

Native SQL BOOLEAN data type.
SELECT statements without a FROM clause.
GROUP BY using a column alias or column position.
Direct joins in UPDATE and DELETE.
Unicode 15.0 support.
Improved SQL syntax compatibility for developers migrating from other platforms.
Wide tables supporting as many as 4,096 columns.
Assertions for declarative business rules spanning one or more tables.

2.10 Assertions

Define declarative business rules across one or multiple tables.
Address cases that are difficult to implement with normal check constraints.
Reduce dependency on complex custom triggers.
Enforce rules consistently regardless of which application modifies the data.
Handle concurrency and serialization concerns within the database.
Allow a single central rule to replace duplicate validation logic in multiple applications.

2.11 Transactional Event Queues and Kafka APIs

Kafka-compatible APIs for Oracle Transactional Event Queues, or TxEventQ.
Existing Kafka applications can connect with fewer code changes.
Messaging can participate in Oracle transactions.
Supports event-driven application and microservices architectures.
Reduces the need to operate a separate event platform for certain database-centric workloads.

2.12 Sagas for microservices

Database-supported saga patterns for long-running distributed transactions.
Helps coordinate transactions across multiple services.
Supports compensation when one stage of a business transaction fails.
Avoids holding traditional distributed locks across services.
Appropriate for order, payment, inventory, and shipment workflows.

2.13 Redis-compatible access

Oracle AI Database and True Cache can provide Redis-compatible server functionality.
Redis objects can be backed by Oracle database objects.
Cached data can be synchronized automatically when underlying data changes.
Offers a database-managed alternative for selected Redis-style caching patterns.
Can be used with Oracle Database, Active Data Guard, and True Cache configurations.

2.14 Developer connectivity and APIs

The 26ai development ecosystem includes:

JDBC and Universal Connection Pool
Python python-oracledb
Node.js node-oracledb
Oracle Call Interface
ODBC
.NET providers
Oracle REST Data Services
SODA and document APIs
MongoDB-compatible API
JavaScript, PL/SQL, Java, C, C++, Python, and other supported programming interfaces

3. High Availability and Scalability

3.1 Oracle True Cache

Primarily in-memory, automatically managed cache for Oracle Database data.
Transactionally consistent with the primary database.
Offloads read-intensive workloads.
Applications can connect directly for read-only operations.
JDBC applications can route read-only sections to configured True Cache instances.
Provides fresher and more consistently managed data than many manually maintained application caches.
Designed mainly for read scalability and performance, not as a disaster-recovery replacement for Data Guard.

3.2 Oracle RAC

Oracle Real Application Clusters remains the foundation for:

Active-active database instance availability.
Scale-out of database processing.
Instance failover.
Service-based workload management.
Online maintenance with reduced application disruption.
Fast Application Notification and connection-pool integration.

The 26ai high-availability documentation continues to group RAC enhancements alongside general and Data Guard improvements.

3.3 Oracle Data Guard

Major 26ai Data Guard areas include:

Physical standby protection and disaster recovery.
Data Guard Broker automation.
Fast-Start Failover.
Active Data Guard read offload.
Multitenant and per-PDB protection enhancements.
Improved hybrid cloud support.
Better automation-oriented output and management.
Greater control over role-transition targets.
Application Continuity and rolling-maintenance improvements.

Oracle’s 26ai new-features guide specifically organizes Data Guard, RAC, and general improvements under High Availability.

3.4 Globally Distributed Database with Raft replication

Built-in replication for sharded databases.
Consensus-based commit using the Raft protocol.
Does not require configuring Data Guard or GoldenGate for this replication model.
Declarative replication configuration.
Subsecond failover capabilities.
Improves fault isolation and availability for globally distributed applications.
Helps optimize hardware utilization in sharded environments.

3.5 Directory-based sharding

Dynamically determines the location of records by sharding key.
Maintains key-to-shard mapping in a directory.
Supports large numbers of key mappings.
Allows individual or bulk movement of keys between shards.
Useful for data residency, tenant placement, load balancing, and geographic distribution.
Delivers horizontal scalability with shard-level fault isolation.

3.6 Automatic data movement after sharding-key updates

Automatically moves a row when its updated sharding key maps to another partition or shard.
Reduces application-side data-movement logic.
Supports business changes such as customer relocation, organizational reassignment, or jurisdiction changes.

3.7 Application Continuity and Transaction Guard

Helps applications survive planned and unplanned outages.
Replays eligible database work safely after recoverable failures.
Transaction Guard provides a reliable transaction outcome.
Reduces duplicate transaction risk.
Integrates with RAC, Data Guard, database services, JDBC/UCP, and connection pools.

These capabilities remain central to Oracle’s high-availability stack, with 26ai expanding high-availability and failover integration.

3.8 Online operations

Oracle 26ai continues Oracle’s broader support for online:

Patching and rolling maintenance
Schema changes
Table and index maintenance
Data movement
Reorganization
Application upgrades using Edition-Based Redefinition

Availability depends on deployment type, licensing, and the specific operation.

4. Security

4.1 Oracle Deep Data Security

Database-enforced authorization for users, applications, analytics, and AI agents.
Propagates the original user or agent identity and execution context to the database.
Declarative SQL policies enforce access at:
- Row level
- Column level
- Individual-cell level
Applies authorization regardless of whether data is reached through an application, SQL tool, analytics platform, or AI agent.
Helps mitigate excessive AI-agent privilege and prompt-injection consequences.
Centralizes authorization instead of duplicating it in every application.
Provides an additional defense if application-level authorization is bypassed or incorrectly implemented.

4.2 Oracle SQL Firewall

Built into Oracle AI Database.
Inspects incoming SQL statements.
Learns or defines approved SQL behavior.
Detects, logs, alerts on, or blocks unauthorized SQL.
Helps defend against SQL injection and compromised application credentials.
Enforcement occurs inside the database, regardless of the SQL execution path.

4.3 Schema-level privileges

Grant privileges across objects in a schema without using broad system privileges.
Simplifies privilege administration.
Reduces large sets of individual object grants.
Supports least-privilege access more effectively.
Makes access easier to manage as new objects are introduced into an application schema.

4.4 `DB_DEVELOPER_ROLE`

Predefined role for application developers.
Provides a curated set of privileges required to design, build, and deploy database applications.
Reduces the practice of assigning broad DBA-like privileges to developers.
Supports least-privilege development environments.

4.5 Multi-factor authentication

MFA can be enabled for native Oracle Database users.
Strengthens authentication beyond a password-only model.
Helps protect privileged and sensitive database accounts.

4.6 TLS 1.3 and simplified TLS

Support for TLS 1.3.
Newer cipher suites provide stronger protection for data in transit.
Simplified client/server TLS configuration.
Helps reduce configuration errors while improving transport security.

4.7 FIPS 140-3 preparation

Oracle AI Database 26ai supports preparation for FIPS 140-3 compliance.
Organizations may need to review and replace older encryption algorithms.
Relevant for regulated and government environments.

4.8 Constrained Kerberos delegation

Introduces control over unconstrained versus constrained Kerberos ticket delegation.
Reduces exposure associated with forwarding broad ticket-granting credentials.
Useful for enterprise single sign-on environments.

4.9 OAuth 2.0 and Microsoft Entra ID integration

OAuth 2.0 authentication support through supported database clients.
Integration with OCI IAM and Microsoft Entra ID, formerly Azure AD.
Enables cloud-based single sign-on to Oracle Database services and supported on-premises databases.
Helps application teams avoid embedding permanent database passwords.

4.10 Long passwords

Native database passwords can be up to 1,024 bytes.
Supports stronger password and passphrase policies.
Better accommodates externally generated credentials.

4.11 Read-only users and sessions

A user or session can be restricted to read-only operations irrespective of other granted privileges.
Useful for reporting, troubleshooting, audit access, and production support.
Reduces the possibility of accidental data modification.

4.12 Existing enterprise security capabilities

Oracle 26ai also retains Oracle’s established security stack:

Transparent Data Encryption
Data Redaction
Virtual Private Database
Real Application Security
Label Security
Database Vault
Unified Auditing
Fine-Grained Auditing
Privilege Analysis
Key Vault integration
Native network encryption
Backup encryption
Data Safe integration

Licensing requirements vary by edition, option, cloud service, and deployment platform.

5. Analytics and AI Lakehouse

5.1 Autonomous AI Lakehouse

Combines Oracle AI Database analytics with Apache Iceberg data lakes.
Executes Oracle SQL and AI workloads over Iceberg data.
Supports relational, JSON, graph, spatial, and vector analytics.
Uses Exadata-powered processing.
Offers serverless, pay-per-use scaling.
Available across OCI, AWS, Google Cloud, and Microsoft Azure.
Designed to interoperate with Iceberg ecosystems, including data managed through platforms such as Databricks and Snowflake.

5.2 Apache Iceberg support

Query open-format data-lake tables.
Combine lakehouse data with operational database data.
Store vectors in Iceberg tables.
Create vector indexes over supported Iceberg vector data.
Apply vector similarity and structured business predicates in one workflow.
Reduce forced movement of lakehouse data into proprietary formats.

5.3 Converged analytics

SQL analytics over relational data.
JSON analytics.
Graph analytics.
Spatial analytics.
Text search.
Vector similarity search.
In-database machine learning.
Lakehouse analytics.

The advantage is that these workloads can be combined in a single database platform rather than requiring a separate specialized database for each data model.

6. Performance and Scalability

6.1 Wide tables

Maximum table or view width increased to 4,096 columns.
Useful for:
- Machine-learning feature stores
- IoT data
- De-normalized analytical models
- Large packaged applications
Can simplify designs that previously had to split attributes across multiple tables.

6.2 Hybrid Columnar Compression improvements

Faster compression and decompression.
Improved compression ratios for newly created or rebuilt HCC tables.
Potentially reduced storage and I/O requirements.
Exact benefit depends on the data and compression level.

6.3 Consolidated background services

Consolidates database maintenance and service actions into a more flexible group of background processes.
Reduces dependence on many dedicated background processes.
Improves process and resource management.
Particularly relevant for consolidated environments with many PDBs.

6.4 Concurrency improvements

Lock-Free Reservations reduce row-level contention.
Priority Transactions protect important transactions.
JSON-Relational Duality supports optimistic concurrency.
True Cache offloads read workloads.
RAC and sharding provide scale-out options.
Improved HCC reduces analytical storage and I/O overhead.

7. Database Architecture and Data Management

7.1 Multitenant architecture

Oracle 26ai continues the CDB/PDB architecture for:

Database consolidation
Tenant isolation
Rapid provisioning and cloning
PDB relocation
Centralized patching and administration
Resource governance
Fleet-standardized operations
PDB-level availability and disaster-recovery patterns

7.2 Converged data model

A single Oracle Database can manage:

Relational data
JSON documents
Vectors
Property graphs
Spatial data
XML
Text
Time-series-style data
Blockchain and immutable tables
Large objects and multimedia content

Oracle positions this converged model as a way to eliminate separate data stores and synchronization pipelines for each data type.

7.3 Immutable and blockchain-style data protection

Append-only and tamper-resistant data-management patterns.
Useful for audit trails, financial records, compliance records, and chain-of-custody requirements.
Complements auditing and enterprise security controls.

7.4 Automatic storage and lifecycle functions

Partitioning
Compression
Heat Map
Automatic Data Optimization
Online table and index operations
SecureFiles
Recovery Manager
Flashback technologies

These are established capabilities carried into 26ai rather than completely new 26ai inventions.

8. Manageability, DevOps, and Operations

8.1 Simplified transition from 23ai

Oracle 26ai replaces the 23ai product identity.
Existing 23ai installations transition by applying the October 2025 Release Update or a later relevant RU.
No traditional database upgrade is required for the 23ai-to-26ai transition.
No application recertification is required solely because of the product-name transition. 8.2 Container support and Free edition

Oracle AI Database 26ai Free is available as a container image.
Full and Lite image variants are available.
Lite images reduce image size and improve pull time for simpler development and CI/CD scenarios.
Container settings can enable Archive Log mode and Force Logging.
Useful for local development, testing, training, and automated pipelines.

8.3 Observability and automation

Improved machine-readable administration output.
Integration with Oracle Enterprise Manager and cloud management services.
Data Guard Broker automation.
Fleet Patching and Provisioning.
Automatic performance diagnostics.
Automatic Workload Repository.
SQL Monitor and SQL tuning facilities.
Data Safe integration for security assessment and monitoring.

8.4 Autonomous operations

Depending on the chosen Autonomous Database service:

Automated configuration
Automated backup
Automated patching
Elastic scaling
Automatic tuning
Automatic indexing
Built-in availability management
Serverless consumption models
Autonomous AI Lakehouse capabilities

9. Quick Category Summary

Category	Most important Oracle 26ai capabilities
AI	AI Vector Search, Unified Hybrid Vector Search, Select AI, Select AI Agent, MCP, Private Agent Factory, RAG, ONNX embeddings
Application development	JSON-Relational Duality, JavaScript procedures, SQL/PGQ graphs, annotations, domains, assertions, SQL enhancements
Microservices	Sagas, TxEventQ Kafka APIs, lock-free reservations, REST/JSON APIs, priority transactions
High availability	RAC, Data Guard, Active Data Guard, Application Continuity, Transaction Guard, True Cache
Distributed database	Sharding, directory-based sharding, Raft replication, automatic data movement
Security	Deep Data Security, SQL Firewall, schema privileges, developer role, MFA, TLS 1.3, OAuth2, Entra ID
Analytics	Autonomous AI Lakehouse, Apache Iceberg, graph, spatial, JSON, vector and SQL analytics
Performance	True Cache, HCC enhancements, wide tables, lock-free concurrency, RAC and sharding
Manageability	Multitenant, autonomous operations, containers, fleet tooling, 23ai-to-26ai RU transition

Highest-Priority Features

For architecture evaluation or an Oracle 19c-to-26ai roadmap:

AI Vector Search and enterprise RAG
JSON-Relational Duality Views
Oracle Deep Data Security
Oracle SQL Firewall
True Cache
Data Guard and Application Continuity enhancements
Lock-Free Reservations and Priority Transactions
Schema-level privileges and DB_DEVELOPER_ROLE
TxEventQ Kafka APIs and microservice Sagas
Autonomous AI Lakehouse and Apache Iceberg
Operational Property Graphs with SQL/PGQ
Globally Distributed Database with Raft replication

Important licensing note

Feature availability is not identical across Free, Standard Edition 2, Enterprise Edition, Exadata, Autonomous Database, and cloud database services. Some capabilities are included in the base database, while RAC, Active Data Guard, Partitioning, Advanced Security, Database Vault, and other functions may require a specific edition, option, engineered system, or cloud service entitlement. Always validate the exact deployment against the current Oracle Licensing Information User Manual and your Oracle ordering documents.

Friday, August 21, 2026

Oracle Database Patches and Enterprise Patching Policy

Below is a practical review of Oracle Database patch types, followed by a step-by-step patching policy suitable for an enterprise database estate. The approach emphasizes security, availability, rollback capability, audit evidence, RAC/Data Guard coordination, and repeatable automation.

Important: Patch instructions differ by Oracle release, operating system, architecture, and deployment model. The patch README and applicable My Oracle Support, or MOS, notes must remain the final authority for every implementation.

1. Oracle patching concepts

Oracle patch maintenance falls into two broad categories:

Proactive maintenance

Proactive patching applies Oracle-recommended cumulative updates before a known problem affects the environment. For Oracle Database 19c and later, the principal proactive mechanisms are quarterly Release Updates and, where supported, Monthly Recommended Patches.

Reactive maintenance

Reactive patching addresses a particular defect or urgent problem, usually through an interim or one-off patch. These patches are produced for a specific bug, database version, platform, and configuration, and may later be included in an RU.

Recommended policy: Use RUs and supported MRPs as the standard maintenance path. Use one-off patches only when required by Oracle Support, a documented critical defect, or an approved security exception.

2. Oracle Database patch types

2.1 Release Update, or RU

An RU is Oracle’s primary cumulative quarterly database patch bundle for currently supported database releases.

It generally includes:

Security fixes
Optimizer and database engine fixes
Reliability and availability fixes
Data Guard, RAC, ASM, RMAN, and other component fixes
Fixes from previous RUs
SQL changes that may require datapatch

Oracle no longer delivers traditional patch sets for current releases. Quarterly RUs are the normal proactive maintenance mechanism.

Recommended usage

Make the RU the baseline patch for all production databases.
Do not remain indefinitely on the base release, such as 19.3.
Prefer a recent and internally certified RU.
Avoid allowing different databases in the same service stack to drift across many RU levels.
Patch Grid Infrastructure and database homes according to the combination and sequence prescribed in the patch README.

Example version interpretation

For a database showing a version such as:

19.28.0.0.0

19 represents the major release family and 28 identifies the RU level.

2.2 Monthly Recommended Patch, or MRP

An MRP provides Oracle-recommended fixes on top of the current RU. Oracle introduced MRPs as a more frequent proactive maintenance option, initially for Oracle Database 19c on Linux x86-64. Availability must therefore be verified for the exact database release and operating-system platform.

Recommended usage

Use MRPs when:

The platform and release support them.
The organization can test monthly maintenance.
A recommended fix is needed before the next quarterly RU.
Security or operational risk justifies a monthly cadence.

Suggested policy

Critical internet-facing or high-risk systems: Evaluate each applicable MRP.
Standard production systems: Quarterly RU as the minimum; use an MRP where risk analysis identifies a need.
Low-criticality systems: Keep aligned with the approved RU baseline.

MRPs should not be treated as a substitute for moving to the next quarterly RU.

2.3 Critical Patch Update, or CPU

A CPU is Oracle’s security advisory and security-fix delivery program across Oracle products. CPUs normally occur on the third Tuesday of January, April, July, and October. The advisory identifies affected products, vulnerabilities, severity, affected versions, and links to patch availability documentation.

For Oracle Database, the security fixes announced in a CPU are normally delivered through the applicable database patch bundle, commonly the RU, rather than as a completely separate database maintenance strategy.

Policy implication

When a CPU is released:

Security must review the advisory.
The DBA team must identify affected versions and components.
The team must download the relevant Patch Availability Document from MOS.
Risk must be assessed using:
- CVSS score
- Remote exploitability
- Authentication requirement
- Exposure of the listener or database service
- Usage of affected components
- Availability of mitigation
Applicable patches must enter expedited testing.

Oracle advises customers to use actively supported releases and apply security patches without delay.

2.4 Security Patch Update, or SPU

SPU is historically associated with the security-only database patch stream and may still appear in MOS references, older releases, and patch-selection documentation. It contains a narrower set of fixes than a full proactive bundle.

Recommended usage

For modern supported databases, an RU should generally be preferred because it provides cumulative security and reliability fixes. Select an SPU only when:

It is the applicable Oracle-supported delivery method for that release or platform.
Oracle Support directs the organization to use it.
An approved exception prevents adoption of the RU.

Do not mix RU, PSU, BP, or SPU streams without checking the README and MOS conflict guidance.

2.5 Patch Set Update, or PSU

PSUs are cumulative patch bundles used primarily with older Oracle release families. They include security fixes and selected high-impact fixes.

For 12.2 and later release families, Oracle moved to the RU model. Older databases may still have PSU or Bundle Patch terminology.

Policy implication

A database that depends on PSUs should be classified as a legacy platform and placed on an upgrade or retirement roadmap.

2.6 Bundle Patch, or BP

A Bundle Patch groups fixes for a specific platform or product configuration. The term is commonly encountered with:

Older Windows database releases
Engineered systems
Grid Infrastructure
Specific components or products

Bundle Patches are normally cumulative within their patch stream.

Policy implication

Never assume that a BP, PSU, SPU, and RU are interchangeable. The DBA must confirm the correct patch stream for the product, release, and platform in MOS.

2.7 Interim or one-off patch

A one-off patch fixes a particular Oracle bug. It is usually associated with:

An Oracle Service Request
A specific bug number
A particular RU level
A particular operating-system platform

One-off patches are reactive and may conflict with an RU, MRP, OJVM patch, or another one-off patch. Oracle therefore requires interim patch conflict analysis before maintenance.

Recommended control

Every one-off patch should have:

Oracle SR number
Bug number
Business justification
Patch ID
Applicable RU
Platform
Conflict-check result
Expiry or removal plan
Confirmation whether the fix is included in a later RU

One-offs should not become permanent undocumented dependencies.

2.8 Oracle JavaVM, or OJVM patch

An OJVM patch addresses vulnerabilities and defects in the Java Virtual Machine component installed inside Oracle Database.

Important considerations

Determine whether OJVM is installed and used.
Review whether the patch supports rolling or requires non-rolling maintenance.
Check for Java-dependent applications and invalid objects.
Run all required SQL patching steps.
Validate JAVAVM and related components after patching.

Do not assume a database RU automatically resolves every separately delivered OJVM requirement. Always inspect the RU and OJVM README.

2.9 Grid Infrastructure Release Update

A Grid Infrastructure RU patches components such as:

Clusterware
Oracle Restart
ASM
ACFS
Cluster communication components
GI-managed listeners and resources

For RAC environments, OPatchAuto can orchestrate prerequisite checks, stopping and starting services, patch application, post-checks, and rollback. Oracle recommends Fleet Patching and Provisioning for larger RAC, Exadata, and Data Guard estates.

Key rule

The Grid home and database homes are separate software inventories. Both need to be assessed and patched where applicable.

3. Recommended enterprise patching policy

3.1 Patch cadence

Environment	Target cadence	Suggested completion target
Sandbox / laboratory	As soon as patch is available	3 to 5 business days
Development	Every quarterly RU	Within 7 to 10 days
Test / SIT	Every quarterly RU	Within 14 days
UAT / pre-production	Every quarterly RU	Within 21 days
Critical production	Every quarterly RU	Within 30 days
Standard production	Every quarterly RU	Within 30 to 45 days
Security emergency	Out-of-band	Based on risk, normally 24 hours to 7 days
Supported MRP candidates	Monthly assessment	Risk-based

Oracle’s CPU calendar is quarterly, but Security Alerts can be published outside the normal schedule for particularly critical vulnerabilities or active exploitation.

3.2 Patch currency standard

Use an organizational standard such as:

Production databases must be on the approved current RU or, temporarily, no more than one RU behind. Any database more than one RU behind requires a documented security exception, compensating controls, business-owner approval, and a remediation date.

For highly exposed systems, the organization may adopt a stricter standard:

Internet-facing, regulated, or Tier-0 databases must be moved to the approved current RU within 30 days, or faster when the CPU risk assessment requires it.

3.3 Preferred deployment model

Oracle recommends using a new Oracle home and performing out-of-place patching because this simplifies maintenance and reduces the risk associated with modifying the active home.

Out-of-place patching

Install or clone a new Oracle home.
Apply the approved RU and required one-offs.
Validate the new home.
Switch the database to the new home.
Execute datapatch.
Retain the previous home for an approved fallback period.

Why it is better

Cleaner rollback
Reduced risk of corrupting the active home
Repeatable gold-image deployment
Easier standardization
Shorter database outage
Better separation between preparation and cutover

For a large RAC, Exadata, or Data Guard estate, Oracle recommends Fleet Patching and Provisioning.

4. Step-by-step Oracle Database patching procedure

Phase 1: Discovery and scope definition

Step 1: Build the database inventory

Collect:

Hostname and operating system
Database name and DB unique name
Database release and RU
Oracle home
Grid home
RAC or single instance
CDB and PDB architecture
Data Guard configuration
GoldenGate usage
ASM and ACFS usage
OJVM installation status
One-off patches
Business owner
Criticality and RTO/RPO
Maintenance window

Useful discovery commands:

$ORACLE_HOME/OPatch/opatch version

$ORACLE_HOME/OPatch/opatch lsinventory -detail

$ORACLE_HOME/OPatch/opatch lspatches

Database checks:

SELECT banner_full

FROM v$version;

SELECT name, open_mode, database_role

FROM v$database;

SELECT con_id, name, open_mode

FROM v$pdbs

ORDER BY con_id;

SELECT comp_id, comp_name, version_full, status

FROM dba_registry

ORDER BY comp_id;

SELECT patch_id,

patch_type,

action,

status,

action_time,

description

FROM dba_registry_sqlpatch

ORDER BY action_time DESC;

DBA_REGISTRY_SQLPATCH records SQL patch apply and rollback attempts, status, patch type, time, and log location, and is maintained by datapatch.

Phase 2: Patch selection

Step 2: Select the target RU

Use MOS as the patch source of truth. Search by:

Product
Release
Platform
Patch type
Language, if applicable

Download:

Database RU
Grid Infrastructure RU
OJVM patch, if required
Latest supported OPatch version
Required one-off or merge patches
Patch README
Known-issues notes

Oracle recommends obtaining patches through MOS and reviewing the exact README for downloading, prerequisites, application, and post-patch instructions.

Step 3: Review known issues

Check:

RU known issues
Platform-specific defects
Data Guard and RAC restrictions
OJVM restrictions
Optimizer changes
RMAN issues
Data Pump issues
GoldenGate compatibility
Application certification
Required post-install fixes
Superseded one-offs

If a new RU has a serious known issue for your configuration, choose the preceding approved RU plus the required correction, but document the decision.

Phase 3: Conflict and readiness analysis

Step 4: Verify OPatch

$ORACLE_HOME/OPatch/opatch version

$ORACLE_HOME/OPatch/opatch lsinventory

Use the OPatch version specified in the patch README. Oracle recommends using the latest applicable OPatch release.

Step 5: Run conflict analysis

For a database home:

$ORACLE_HOME/OPatch/opatch prereq

CheckConflictAgainstOHWithDetail

-phBaseDir /stage/patch_directory

For a system patch or GI/RAC patch:

$GRID_HOME/OPatch/opatchauto apply

/stage/patch_directory

-analyze

Resolve conflicts by:

Removing an obsolete one-off
Obtaining a replacement one-off for the target RU
Requesting a merge patch
Raising an Oracle SR
Moving to a later RU that already includes the fix

Do not proceed with an unresolved conflict.

Step 6: Verify disk space

Check:

Oracle home
Grid home
Central inventory
Patch stage
/tmp
Database filesystem
Archive log destination
FRA
ASM disk groups

Oracle’s maintenance guidance explicitly requires system dependency and free-space checks before patch application.

Phase 4: Backup and recovery preparation

Step 7: Prepare rollback capability

At minimum:

Current RMAN backup
Validated restore capability
Control-file and SPFILE backup
Oracle home backup or retained old home
Grid home backup, where applicable
Central inventory backup
Listener and network configuration backup
Password file backup
Wallet and TDE keystore backup
OCR and voting-disk health check for RAC
Data Guard synchronization check
Recovery runbook

Oracle strongly recommends backing up Oracle home binaries, Grid home binaries, and the central Oracle inventory before applying an RU or interim patch.

Example RMAN preparation:

BACKUP DATABASE PLUS ARCHIVELOG;

BACKUP CURRENT CONTROLFILE;

BACKUP SPFILE;

RESTORE DATABASE VALIDATE;

A backup is not sufficient unless its restore path has been tested.

Phase 5: Rehearsal and approval

Step 8: Patch non-production first

Follow the promotion sequence:

Sandbox -> Development -> SIT -> UAT -> Pre-production -> Production

Test:

Database startup and shutdown
Application connectivity
Critical SQL
Batch processes
RMAN backup and restore
Data Guard transport and apply
RAC service relocation
Listener registration
OEM monitoring
GoldenGate replication
Data Pump
Scheduler jobs
OJVM applications
Performance baselines

Step 9: Conduct change review

The change record should contain:

Patch IDs
Source and target RU
Affected systems
README
Conflict report
Test evidence
Backup evidence
Implementation plan
Outage estimate
Rollback criteria
Rollback steps
Business validation plan
DBA, application, infrastructure, security, and service-owner contacts

Phase 6: Production implementation

Step 10: Complete pre-patch health checks

Check for:

Invalid database components
Invalid objects
Failed scheduler jobs
Tablespace issues
FRA pressure
Archive destinations
Data Guard lag
RAC resource state
Blocking transactions
Backup failures
Existing alert-log errors

Example queries:

SELECT comp_id, comp_name, version_full, status

FROM dba_registry

WHERE status <> 'VALID';

SELECT owner, object_type, COUNT(*)

FROM dba_objects

WHERE status = 'INVALID'

GROUP BY owner, object_type

ORDER BY owner, object_type;

SELECT dest_id, status, error

FROM v$archive_dest_status

WHERE status <> 'INACTIVE';

SELECT job_name, status, actual_start_date, run_duration

FROM dba_scheduler_job_run_details

WHERE actual_start_date > SYSDATE - 1

ORDER BY actual_start_date DESC;

Record existing faults so they are not incorrectly attributed to the patch.

Step 11: Stop or relocate services

Coordinate:

Application connections
Connection pools
Database services
GoldenGate
Monitoring
Backup jobs
Batch jobs
Data Guard Broker
RAC services

When GoldenGate is used, Oracle’s patch-maintenance guidance says its processes must be shut down before patching the database.

Step 12: Apply the binary patch

The exact command must come from the patch README.

Typical single-instance in-place pattern:

cd $ORACLE_HOME/OPatch

./opatch apply

Typical GI/RAC pattern:

$GRID_HOME/OPatch/opatchauto apply /stage/patch_directory

OPatch applies and rolls back patches in an Oracle home. OPatchAuto can perform prechecks, stop and start resources, apply patches, conduct post-checks, and perform rollback orchestration.

Step 13: Run `datapatch`

After the database and required PDBs are open in the mode prescribed by the README:

$ORACLE_HOME/OPatch/datapatch -verbose

When OPatch is used for database maintenance, datapatch must be run to load applicable SQL changes into the database.

For multitenant environments:

Confirm all required PDBs are open.
Confirm each PDB receives the SQL patch.
Check for PDBs that were closed or unavailable during datapatch.
Rerun datapatch if directed after opening missed PDBs.

Phase 7: Validation

Step 14: Validate binary inventory

$ORACLE_HOME/OPatch/opatch lsinventory

$ORACLE_HOME/OPatch/opatch lspatches

In RAC, validate every node and every relevant home.

Step 15: Validate SQL patch registry

SELECT patch_id,

patch_type,

action,

status,

action_time,

description

FROM dba_registry_sqlpatch

ORDER BY action_time DESC;

The expected result is normally:

ACTION = APPLY

STATUS = SUCCESS

Any WITH ERRORS status requires log review and remediation.

Step 16: Validate database health

SELECT comp_id, comp_name, version_full, status

FROM dba_registry

ORDER BY comp_id;

SELECT owner, object_type, COUNT(*)

FROM dba_objects

WHERE status = 'INVALID'

GROUP BY owner, object_type;

SELECT instance_name, status, database_status

FROM gv$instance;

SELECT name, open_mode

FROM v$pdbs

ORDER BY con_id;

Also review:

Alert log
Listener log
Patch logs
CRS resources
ASM state
Data Guard transport and apply lag
Application smoke tests
Critical execution plans
Backup operation
Monitoring alerts
Performance compared with baseline

5. Data Guard patching best practices

For Data Guard:

Confirm zero or acceptable transport and apply lag.
Validate broker configuration.
Patch the standby side first where supported.
Restart and validate standby apply.
Perform switchover if the chosen strategy requires it.
Patch the former primary.
Validate both directions of the configuration.
Run datapatch in accordance with the README and the selected Data Guard procedure.
Test failover and service behavior where possible.

Oracle prefers out-of-place maintenance using a new Oracle home and recommends Fleet Patching and Provisioning for Data Guard estates. OPatchAuto remains an available alternative for relevant configurations.

Do not independently activate standby databases merely to run SQL patching unless the documented procedure specifically requires it.

6. RAC patching best practices

For RAC:

Use rolling patching only if the patch is explicitly certified as rolling.
Run conflict checks against both Grid and database homes.
Check opatch lsinventory on every node.
Confirm CRS resources before and after each node.
Drain or relocate services before stopping an instance.
Validate SCAN listeners and local listeners.
Review service failover and connection-pool behavior.
Verify the patch inventory is consistent across all nodes.
Run SQL patching once according to the README, not separately and blindly from every node.

Oracle recommends FPP to simplify RAC maintenance, while OPatchAuto remains an orchestration option. Out-of-place patching with a new home is the preferred maintenance model.

7. Rollback policy

Rollback must be defined before entering the maintenance window.

Typical rollback triggers

Database cannot start
RAC resource remains unstable
Data Guard transport or apply cannot be restored
datapatch fails and cannot be corrected
Critical application smoke test fails
Severe performance regression
Data corruption symptoms
Maintenance window is exceeded
Oracle Support recommends rollback

Preferred rollback sequence for out-of-place patching

Stop application access.
Return the database configuration to the previous Oracle home.
Restart the database from the old home.
Roll back SQL changes if they were applied and the README requires it.
Validate services and application operation.
Record all commands and errors.
Raise or update the Oracle SR.

Typical in-place binary rollback may use:

$ORACLE_HOME/OPatch/opatch rollback -id PATCH_ID

System patch rollback may use:

$GRID_HOME/OPatch/opatchauto rollback /stage/patch_directory

Exact rollback commands and SQL sequencing must come from the applicable README.

8. Governance, evidence, and KPIs

Required patch evidence

Retain:

Before-and-after opatch lsinventory
Before-and-after opatch lspatches
datapatch logs
DBA_REGISTRY_SQLPATCH results
Database component status
Invalid-object comparison
Backup record
Conflict-check output
Change approval
Test results
Application-owner validation
Alert-log review
Data Guard or RAC validation
Rollback decision record
Updated CMDB

Recommended KPIs

Percentage of databases on approved RU
Percentage more than one RU behind
Median days from RU release to production
Critical-patch SLA compliance
Patch success rate
Rollback rate
datapatch failure rate
Inventory mismatch count
Number of undocumented one-offs
Number of unsupported database releases
Number of outstanding security exceptions
Percentage of restore tests completed

9. Recommended policy statement

A concise organization-level policy could be:

Oracle Database environments shall be maintained on an actively supported Oracle release and an approved recent Release Update. Quarterly RUs shall be assessed immediately after release, tested through the defined environment sequence, and deployed to critical production systems within 30 days and standard production systems within 45 days. Critical security vulnerabilities, Security Alerts, and actively exploited issues shall follow the emergency patching process. Out-of-place patching shall be the preferred deployment method. Every patch implementation shall include conflict analysis, current recovery capability, non-production testing, documented rollback criteria, binary and SQL patch validation, application-owner sign-off, and retention of audit evidence.

10. Practical recommendation for your database estate

As a Database Architect, I recommend structuring the program around five controls:

One approved RU baseline per database release and platform
Out-of-place gold-image patching as the default
Quarterly release train with monthly security review
Central register for one-offs, conflicts, and exceptions
Automated evidence collection for SOX and operational audits

The most important architectural improvement is to move away from individually patching every Oracle home manually. Maintain certified gold images containing:

Required RU
Approved OJVM patch
Required one-offs
Correct OPatch release
Standard configuration
Antivirus exclusions, if applicable
Verification manifest and checksum
Test and approval reference

This reduces configuration drift, patch conflicts, execution errors, and outage duration while producing stronger audit evidence. Oracle’s current maintenance guidance similarly favors out-of-place patching and recommends FPP for large RAC, Exadata, and Data Guard deployments.

Review summary

This framework separates proactive, reactive, security, and component-specific patches, then ties each category to a controlled lifecycle. The most important best-practice improvements are adopting quarterly RUs as the standard, preferring out-of-place patching, validating both binary and SQL registries, and treating backup verification and rollback as mandatory entry criteria rather than optional DBA activities.

Thursday, September 10, 2026

Install Oracle RAC Grid

Wednesday, September 9, 2026

How to create user in Oracle Database ?

How to drop user in Oracle Database ?

How to set custom name on CMD prompt in Linux OS (Operating System) ?

High-Availability Metrics and SLA Standards "Nines"

How to Start the Oracle Database ?

How to Stop / Shutdown the Oracle Database ?

Explain in detail how oracle database start ?

Explain in detail how oracle database stop / shutdown ?

Wednesday, August 26, 2026

Why Oracle Created catcon.pl

Location

Basic Syntax

Execute Script on All PDBs

Run Script Only in Specific PDB

Run in Multiple PDBs

Exclude Specific PDBs

Common Options

Parallel Execution

Example: Gather Dictionary Statistics

During Database Upgrade

Example: Recompile Invalid Objects in All PDBs

Log Files

How catcon Knows the Current Container

Typical Oracle Scripts Executed with catcon

Best Practices for DBAs

Execute on all open PDBs

Keep separate log directory

Validate PDB status before execution

Review logs after completion

Exclude PDB$SEED unless Oracle documentation requires it

catcon.pl vs catctl.pl

In One Line

Saturday, August 22, 2026

Oracle AI Database 26ai

AI-Native, Secure, Highly Available and Developer-Friendly Database

Executive Summary

Key Value Proposition

1. AI and Generative AI

Major Capabilities

Business Value

2. Modern Application Development

Major Capabilities

Business Value

3. Microservices and Event-Driven Applications

Major Capabilities

Business Value

4. High Availability and Scalability

Major Capabilities

Business Value

5. Globally Distributed Database

Major Capabilities

Business Value

6. Security and Data Protection

Major Capabilities

Existing Enterprise Controls

Business Value

7. Analytics and Lakehouse

Major Capabilities

Business Value

8. Performance and Optimization

Major Capabilities

Business Value

9. Manageability and DevOps

Major Capabilities

Business Value

Key Features at a Glance

Top Features for Enterprise Adoption

Immediate Priorities

Strategic Priorities

Recommended Closing Slide

Why Oracle AI Database 26ai?

One Database for Modern Enterprise Workloads

Oracle AI Database 26ai features and use

1. AI and Generative AI

1.1 Oracle AI Vector Search

1.2 Unified Hybrid Vector Search

1.3 Select AI

4.4 `DB_DEVELOPER_ROLE`