Upgrade to Oracle 23ai using Oracle Best Practices

Upgrade to Oracle 23ai using Oracle Best Practices

Have outlined detailed steps in 5 phases for upgrading Oracle Database from version 19c to 23ai. Oracle Database 23ai introduces significant changes, most notably the mandatory Multitenant architecture, which requires all databases to be either Container Databases (CDBs) or Pluggable Databases (PDBs). The AutoUpgrade utility is highly recommended for this process due to its automation capabilities and enhanced diagnosability

.

Phase1:  Key Considerations for Oracle Database 23ai

1.1 Verify Upgrade Path:

1.2: Oracle 23ai supports multi-tenant architecture only, so we need to convert non-CDB to a PDB. Single-tenant (1 PDB, no extra license) or multitenant (multiple PDBs, extra license if > 3PDBs)

1.3 Generally, no application changes are needed to use a pluggable database.

Phase2. Pre-Upgrade Steps

Thorough preparation is crucial for a successful database upgrade. These steps should be performed on your source 19c database.

2.1. Download and Install Oracle Database 23ai Software

From 23ai onwards, we can download Gold image which is updated with the latest release update. Install the Oracle Database 23ai software into a new Oracle Home. Do not install it into the existing 19c Oracle Home. 

2.2. Download the Latest AutoUpgrade Utility

Always use the latest version of AutoUpgrade, which can be downloaded from My Oracle Support (MOS) Note: 2485457.1 or directly from oracle.com

Verify AutoUpgrade version

$java -jar autoupgrade.jar –version

Auto Upgrade Execution Flow 

Plugin → Upgrade → Convert (non CDB ->PDB)

Note: NON-CDB to PDB conversion is irreversible.

2.3. Perform Pre-Upgrade Checks with AutoUpgrade

Run AutoUpgrade in analyze mode to identify potential issues and generate a pre-upgrade report. This step is critical for both Non-CDB and PDB upgrades.

#step1: ANALYSE - Check readiness (run on source)

java -jar autoupgrade.jar -config <config_file.cfg> -mode analyze

Example Configuration File (config_file.cfg) for Non-CDB to PDB Upgrade:

# oracle23ai_upgrade.cfg

global.autoupg_log_dir=/u02/AutoUpgrade

global.keystore=/u02/keystore

upg1.source_home=/u02/app/oracle/product/19.0.0.0/dbhome_1

upg1.target_home=/u02/app/oracle/product/23.0.0.0/dbhome_1

upg1.sid=NCDB191

upg1.target_cdb=DB23ai1

Review the generated pre-upgrade report (status.log in autoupg_log_dir) carefully. Address any reported issues before proceeding.

2.4. Run Pre-Upgrade Fixups

AutoUpgrade can automatically fix many pre-upgrade issues. Run it in fixups mode:

#step 2: Fixups - Apply automatic fixes

java -jar autoupgrade.jar -config oracle23ai_upgrade.cfg -mode fixups

2.5. Backup Your Database

Perform a full backup of your 19c database. This is a critical step for disaster recovery

. Oracle strongly recommends at least a level 1 backup, or a level 0 backup if time permits

.

Phase 3. Upgrade Execution

This section details the upgrade process using AutoUpgrade.

3.1. Deploy the Upgrade

Execute AutoUpgrade in deploy mode to start the upgrade process. This will handle the shutdown of the 19c database, the upgrade to 23ai, and the Non-CDB to PDB conversion if applicable.

#step3 - Deploy - Execute the full upgrade 

java -jar autoupgrade.jar -config oracle23ai_upgrade.cfg -mode deploy

Monitor the progress through the AutoUpgrade logs. AutoUpgrade provides detailed logging and the ability to resume after a failure

.

3.2. Specifics for Non-CDB to PDB Conversion

During the deploy phase, AutoUpgrade will:

1. Shutdown the 19c Non-CDB.

2. Convert the Non-CDB into a PDB.

3. Plug the newly created PDB into the specified 23ai target CDB.

4. .Open the PDB in the 23ai CDB, initiating the upgrade of the PDB's data dictionary.

3.3. Specifics for PDB Upgrade (within a CDB)

If you are upgrading a 19c PDB within a 19c CDB to a 23ai PDB within a 23ai CDB, AutoUpgrade will manage the unplugging from the source CDB and plugging into the target 23ai CDB, followed by the PDB upgrade.

Alternatively, for PDBs, you can use the Replay Upgrade feature:

1.Perform pre-upgrade tasks and fixups on the 19c PDB.

2.Unplug the 19c PDB from its source CDB.

3.Plug the 19c PDB into the 23ai target CDB using create pluggable database ... nocopy;.

4.Open the PDB in the 23ai CDB: alter pluggable database <PDB_NAME> open;. The CDB will automatically upgrade the PDB's data dictionary

.

5.Note that the PDB will open in restricted mode until datapatch is run

.

Phase 4. Post-Upgrade Steps

After the upgrade completes, several post-upgrade tasks are necessary to ensure the database is fully functional and optimized.

4.1. Backup Database  (immediate post-upgrade)

Backup Database after migration (Level 0 incremental)

Check and configure standby databases

4.2. Run Datapatch

Apply any necessary patches to the upgraded database using datapatch. This is crucial for both CDBs and PDBs.

SQL

$ORACLE_HOME/OPatch/datapatch -pdbs <PDB_NAME> -- For PDBs $ORACLE_HOME/OPatch/datapatch -all -- For CDBs

4.3. Run Post-Upgrade Fixups

Execute AutoUpgrade in postfixups mode to apply any remaining post-upgrade fixes.

SQL

java -jar autoupgrade.jar -preupgrade "dir=/home/oracle/logs/orange-replay/fixups,inclusion_list=<PDB_NAME>" -mode postfixups

4.4. Review and Adjust Initialization Parameters

Review the new 23ai initialization parameters and adjust them as needed for optimal performance and compatibility. Pay close attention to parameters related to the Multitenant architecture.

ALTER SYSTEM SET “_cursor_obsolete_threshold”=1024;

ALTER SYSTEM SET “_sql_plan_directive_mgmt_control”=0;

ALTER SYSTEM SET “_column_tracking_level”=1;

4.5. Recompile Invalid Objects

Recompile any invalid database objects. This can be done using the utlrp.sql script.

SQL

@?/rdbms/admin/utlrp.sql

4.6.Performance Stability

• DO NOT gather new optimizer statistics after upgrade

• DO NOT gather system statistics (defaults are usually fine)

• Use SQL plan management (SPM) for plan standby

• Load SQL Plan baselines from SQL Tuning sets.

• Run SQL performance Analyzer (SPA) to identify regressions.

4.7. Perform Application Testing

Thoroughly test all applications connected to the upgraded database to ensure full compatibility and functionality.

Phase 5. Fallback Options

In case of an issue during or after the upgrade, having a robust fallback plan is essential. AutoUpgrade provides options for restoring a failed attempt

. Other fallback strategies include:

•Restore from RMAN Backup: Restore the database from the pre-upgrade RMAN backup.

•Data Guard with Redo Apply Disabled: If using Data Guard, disable redo apply on the standby database before the upgrade to preserve a 19c copy.

•Refreshable Clone PDBs: Utilize refreshable clone PDBs for testing and potential fallback scenarios

 

Oracle AI Vector Search: Do Enterprises Really Need a Separate Vector Database?

Over the last year, almost every AI architecture discussion I’ve participated in has eventually reached the same question:

“Which vector database should we use?”

The usual suspects quickly come up—Pinecone, Weaviate, Milvus, Qdrant, Chroma, and pgvector.

But recently, I’ve been asking a different question:

What if your vector database is already sitting inside your Oracle Database?

With the introduction of AI Vector Search in Oracle Database 23ai, Oracle has entered a space that was previously dominated by specialized vector database vendors. While many organizations are busy evaluating new platforms for Retrieval-Augmented Generation (RAG), semantic search, and AI applications, Oracle has taken a different approach: bring vector capabilities directly into the database that enterprises already trust to run their most critical workloads.

As someone who has spent years working with enterprise databases, what caught my attention wasn’t the ability to store vectors. Almost every modern database can now claim that capability.

What impressed me was Oracle’s decision to treat AI search as a database feature rather than an entirely separate platform.

The Hidden Cost of  Just Add Another Database 

When organizations begin experimenting with Generative AI, the architecture often looks something like this:

Business data lives in Oracle.

Documents are stored somewhere else.

Embeddings are generated using an AI model.

Those embeddings are loaded into a vector database.

Applications query both systems and combine the results.

On paper, it sounds straightforward.

In reality, every additional platform introduces complexity:

• Another system to patch and monitor
• Another backup strategy
• Another security model
• Another set of APIs
• Another place where data can become out of sync

I’ve seen teams spend months building synchronization pipelines between operational databases and AI platforms before they even start delivering business value.

This is where Oracle’s approach becomes interesting.

Instead of moving data to a dedicated vector store, Oracle allows vectors to live alongside the business data they represent.

Customer records, support tickets, documents, product catalogs, and vector embeddings can all reside in the same database.

For many enterprises, that’s a much bigger advantage than raw vector search speed.

What Oracle Actually Added

The headlines often focus on “AI Vector Search,” but several underlying features make this capability practical for enterprise deployments.

Oracle introduced a native VECTOR data type that allows embeddings to be stored directly in database tables.

This means a support ticket can contain both traditional relational data and its AI embedding without requiring external storage.

Developers can then perform similarity searches using SQL, something Oracle professionals already understand.

For database teams, this feels much less like learning a new technology stack and more like extending an existing one.

Oracle also supports modern vector indexing techniques such as HNSW and IVF, enabling efficient approximate nearest-neighbor searches on large datasets.

While these terms may sound academic, they are the same indexing approaches used by many specialized vector database platforms.

In other words, Oracle isn’t offering a simplified version of vector search. It’s implementing the same foundational techniques directly inside the database.

Where Oracle Has an Enterprise Advantage

After evaluating several vector database platforms, I’ve come to an interesting conclusion:

The real competition isn’t about vector search.

It’s about data gravity.

Enterprise data already lives in Oracle databases.

Customer information, financial transactions, supply chain data, support systems, HR systems, and operational workloads have often been running there for decades.

The challenge isn’t finding a place to store vectors.

The challenge is avoiding unnecessary movement of data.

Consider a simple AI use case.

A support engineer asks: “Show me incidents similar to this production outage from customers with active premium support contracts.”

A dedicated vector database can easily find semantically similar incidents.

But the moment you need to combine semantic similarity with customer entitlements, contract status, support history, and relational business logic, things become more complicated.

Oracle can perform both operations within a single platform.

That’s a powerful advantage that often gets overlooked.

How Does Oracle Compare to Dedicated Vector Databases?

Dedicated vector databases such as Pinecone, Weaviate, Milvus, and Qdrant were built specifically for AI workloads.

They are excellent products and continue to innovate rapidly.

If you’re building an AI-native startup with no existing database investment, one of these platforms may be the most practical choice.

However, enterprise organizations have different priorities.

They’re concerned about:

• Security
• Governance
• Compliance
• Disaster recovery
• High availability
• Operational support

This is where Oracle’s decades of database maturity become valuable.

Features such as Real Application Clusters (RAC), Data Guard, Transparent Data Encryption, Database Vault, auditing, and enterprise-grade backup strategies already exist.

Vector search automatically benefits from that ecosystem.

A startup may prioritize flexibility.

A global bank may prioritize governance.

The right answer depends on the problem you’re solving.

Feature Comparision Table 

Feature	Oracle AI Vector Search	Pinecone	Weaviate	Milvus	pgvector
Vector Storage	Yes	Yes	Yes	Yes	Yes
SQL Support	Yes	No	Limited	Limited	Yes
Relational Data Support	Excellent	No	Limited	No	Good
Enterprise Security	Excellent	Good	Good	Good	Good
High Availability	Built-in	Managed Service	Available	Available	PostgreSQL HA
Operational Complexity	Low (for Oracle customers)	Low	Medium	Medium	Low
Best Fit	Enterprise Applications	AI-First Apps	AI Platforms	Large AI Deployments	PostgreSQL Environments

 

Does This Mean Dedicated Vector Databases Are Going Away?

Not at all, I don't think that's right comparision.

Specialized vector databases still have advantages in certain scenarios.

Organizations managing massive AI-only datasets containing billions of embeddings may benefit from infrastructure designed specifically for vector workloads.

Similarly, teams that are heavily invested in open-source ecosystems may find platforms like Milvus, Weaviate, or Qdrant more aligned with their technology strategy.

But I do think we’re witnessing a broader trend.

The industry is moving toward convergence.

Relational databases are becoming AI databases.

AI databases are adding transactional capabilities.

The lines between the two categories are beginning to blur.

For years, every new technology trend seemed to require adding another specialized platform.

Data warehouses.

NoSQL databases.

Graph databases.

Vector databases.

Oracle’s AI Vector Search challenges that pattern.

Instead of asking organizations to move their data to AI, Oracle is bringing AI directly to the data.

Will it replace every dedicated vector database? Probably not.

Will it eliminate the need for many enterprises to deploy a separate vector platform? I believe the answer is increasingly yes.

And for organizations already running Oracle at scale, that may be one of the most important AI developments of the past few years.

Oracle 23C New Features and Release Dates

Oracle Database 23c introduces several new features and enhancements across various areas. Here are some of the key new features in Oracle Database 23c:

Oracle Database 23C Release Dates:

Oracle typically releases new versions of its database software in a staggered manner, with the cloud (Oracle Cloud Infrastructure) releases preceding the on-premises releases. Here are the expected release dates for Oracle Database 23c:

Cloud Release:

Oracle Autonomous Database 23c: This version was released and made generally available on the Oracle Cloud Infrastructure (OCI) on May 16, 2023.

On-Premises Release:

Oracle Database 23c: The on-premises version of Oracle Database 23c is expected to be released in H1-2024. However, Oracle has not yet announced the specific release date.

Initially available on OCI Base Database Service. Will become available on other platforms (cloud and on-premises) starting 1H CY2024. 

It's important to note that these dates are subject to change, and Oracle may adjust the release timelines based on various factors, such as development progress, testing, and customer feedback.

Once the on-premises version of Oracle Database 23c is released, customers with active support subscriptions will be able to download and install it on their on-premises infrastructure or private clouds. Oracle typically provides support for new database releases for several years, including critical patch updates, security fixes, and performance enhancements.

It is advised to consult Oracle's official documentation, release notes, and support channels for the most up-to-date information on the Oracle Database 23c release dates, system requirements, and any specific considerations for their environments.

Oracle 23C New Features:

Autonomous JSON:

Native storage and processing of JSON data within the database.

Faster ingestion, querying, and analysis of semi-structured data.

Support for JSON data types, functions, and SQL/JSON path expressions.

Blockchain Tables:

Tamper-resistant and immutable storage of data using blockchain technology.

Ensures data integrity, transparency, and non-repudiation.

Suitable for applications requiring auditing, regulatory compliance, or secure transaction records.

Autoindex:

Automatic creation and management of indexes based on workload patterns and queries.

Leverages machine learning algorithms to identify optimal indexes.

Improves query performance without manual index management.

Converged Database:

Combines the capabilities of Autonomous Data Warehouse (ADW) and Autonomous Transaction Processing (ATP).

Allows running mixed workloads (analytical and transactional) within a single database instance.

Simplifies data management and reduces operational overhead.

Enhanced Machine Learning:

Improved machine learning capabilities with support for more algorithms.

Better model explanations and integration with Oracle Analytics Cloud.

Enables advanced data analysis and predictive modeling within the database.

Query Performance Optimizations:

Enhanced parallelism and in-memory processing.

Optimizations for specific workloads like Star Queries and Hash Joins.

Improved query execution times for analytical and reporting workloads.

Increased Storage Capacity:

Support for larger database instances to handle growing data volumes.

Ability to provision more storage capacity as needed.

Security and Compliance Enhancements:

Support for Oracle Database Vault for improved data security and access control.

Enhanced auditing capabilities and data masking options.

Compliance with industry standards and regulations.

Database Memory Management Improvements:

Automatic Memory Management enhancements for better memory utilization.

Improved performance for memory-intensive workloads.

SQL Enhancements:

New SQL functions and syntax improvements.

Support for additional data types and improved compatibility with other database systems.

These new features in Oracle Database 23c aim to enhance performance, security, data processing capabilities, and workload consolidation. Additionally, Oracle continues to optimize the database for cloud deployments, with a focus on automation, scalability, and self-management capabilities. 

MySQL Router with NDB Cluster

MySQL Router with NDB Cluster

There is a general question on  can we use MySQL router for NDB Cluster?

MySQL Router can be used with MySQL NDB Cluster to provide intelligent routing capabilities and improve the overall availability and scalability of the cluster deployment.

In an NDB Cluster setup, MySQL Router can act as a middleware component between the application clients and the cluster data nodes. It automatically discovers the topology of the cluster and routes client requests to the appropriate data nodes based on the operation type (read or write) and the current state of the cluster.

Here are some key benefits of using MySQL Router with MySQL NDB Cluster:

1. Read/Write Splitting: MySQL Router can automatically identify read and write queries from the application clients. It routes write queries to the primary data node (or group of data nodes in a multi-primary setup), while read queries are distributed across the remaining data nodes. This read/write splitting improves overall throughput and scalability by utilizing the resources of multiple data nodes for read operations.

2. Load Balancing: MySQL Router can perform load balancing for read queries by distributing them across the available data nodes. This helps in evenly distributing the read load and preventing any single data node from becoming a bottleneck.

3. Failover and High Availability: In case of a data node failure or maintenance operation, MySQL Router can automatically detect the change in cluster topology and redirect client traffic to the remaining available data nodes. This ensures high availability and minimizes disruption to client applications.

4. Connection Pooling: MySQL Router can maintain a pool of persistent connections to the data nodes, reducing the overhead of establishing new connections for each client request. This can improve overall performance, especially in scenarios with a high number of short-lived client connections.

5. Simplified Client Configuration: By using MySQL Router, application clients no longer need to handle the complexities of connecting to multiple data nodes or managing failover scenarios. They can connect to a single entry point (MySQL Router), which transparently routes their requests to the appropriate data nodes.

To use MySQL Router with MySQL NDB Cluster, you need to configure MySQL Router with the appropriate metadata and connection details for your NDB Cluster deployment. MySQL Router can then automatically discover the cluster topology and start routing client traffic accordingly.

It's important to note that while MySQL Router can provide intelligent routing and load balancing capabilities, it does not replace the need for proper cluster configuration and management. MySQL NDB Cluster still requires careful planning and configuration to ensure data consistency, high availability, and optimal performance.

MySQL Router 8.3

 

MySQL Router 8.3 

MySQL Router 8.3 is the latest version of the middleware component that provides transparent routing capabilities between MySQL clients and MySQL servers. It is designed to simplify the deployment and management of highly available and scalable MySQL deployments, such as InnoDB Clusters and replication setups.
One of the key features of MySQL Router 8.3 is its enhanced routing capabilities for InnoDB Clusters. It can automatically detect the primary and secondary instances within a cluster and route read and write operations accordingly. Write operations are directed to the primary instance, while read operations are distributed across the secondary instances, providing improved read scalability and high availability.
MySQL Router 8.3 also offers improved support for asynchronous replication setups. It can route write operations to the replication source and read operations to the replicas, ensuring data consistency and efficient load distribution. Additionally, it supports automatic failover and switchover scenarios, seamlessly redirecting traffic to the new primary instance or replication source in case of failures or maintenance operations.
Another notable enhancement in MySQL Router 8.3 is its support for MySQL Group Replication. It can automatically detect the members of a Group Replication setup and route traffic to the appropriate nodes based on their roles (primary or secondary). This feature simplifies the deployment and management of highly available MySQL setups using Group Replication.
MySQL Router 8.3 also includes improvements in performance, security, and configuration options. It supports TLS encryption for secure communication between clients and servers, as well as improved connection pooling and caching mechanisms for better performance.
Overall, MySQL Router 8.3 aims to simplify the deployment and management of highly available and scalable MySQL deployments, providing transparent routing capabilities, automatic failover handling, and improved performance and security features.

Performance Recommendations

For best performance, MySQL Router is typically installed on the same host as the application that uses it. 

This helps to reduce the latancy and improve performence.

Read/Write Splitting

At a large scale, read operations are distributed across multiple replicas to enhance performance and availability. However, this necessitates a mechanism within the application to direct write operations to a specific location while routing read operations to other destinations. With the introduction of MySQL 8.2, MySQL Router offers a solution by automatically identifying read and write queries. For InnoDB Clusters, it routes write operations to the Primary Instances and read operations to secondary instances or replicas. In the case of asynchronous replication setups, write queries are directed to the replication source, while read queries are forwarded to the replicas or secondary instances.