Real-World Oracle OCI PDB Refresh: Solving Clone Performance Bottlenecks Across Peered VCNs

 

Introduction

Recently, I had a task to refresh our UAT environment using a PDB from the production database hosted in Oracle Cloud Infrastructure (OCI).

At first, the activity looked straightforward. The plan was to perform a remote PDB clone from Production to UAT. However, there was one challenge from the beginning: the source and target databases were located in different OCI VCNs.

After establishing connectivity between the environments, I started the cloning process. The clone started successfully, but after approximately one hour, it appeared to stall, and no significant progress was observed.

After some investigation and testing, I identified two important factors that affected the cloning process:

• The target DBCS was running with only 1 OCPU.
• The production database had an hourly archive log backup and a delete job running through Commvault.

In this article, I will share the architecture, troubleshooting process, and lessons learned from this refresh activity.

Cross-Version Oracle Database Automation on Oracle Linux (7, 8, 9) with systemd, dbstart/dbshut, and Email Alerts on Failure

 

Introduction

In Oracle environments that do not use Oracle ASM, databases are not configured to start automatically after a server reboot. To automate database startup and shutdown, administrators commonly use Oracle's standard dbstart and dbshut utilities.

Although these tools provide basic automation, they do not always verify that the database has successfully reached the OPEN state, and they do not provide built-in notification when startup failures occur.

This article demonstrates how to combine dbstart/dbshut, systemd, startup validation checks, and automated email alerts to create a reliable Oracle database auto-start framework. The approach is compatible with Oracle Linux 7, 8, and 9 and can be used with Oracle database versions that support the standard dbstart/dbshut utilities. It also includes a safe testing method for validating the email alert system without affecting a production database.

In this blog post, I design:

• An Oracle auto-start service using systemd
• Proper shutdown control
• An email alert system for service failures
• A safe test service to validate the alerting mechanism without production risk

This design is simple, stable, and suitable for Oracle Linux production environments.

Part 3: Lessons Learned – Upgrading a Solaris Non-Global Zone Using the Wrong Zone Image

 

Introduction

In Part 2 of this series, I described how I upgraded several Solaris Non-Global Zones using an out-of-place upgrade method. Because the zones did not have enough temporary working space for a direct IPS upgrade, I copied the zone filesystems to a larger storage area, performed the package update there, and then synchronized the updated files back to the original zones.

The approach worked, but it also introduced additional manual steps compared to a standard upgrade. As with many administrative tasks, the technical procedure itself was not the biggest challenge. The real challenge was making sure each step was performed against the correct zone and the correct filesystem.

During the upgrade process, I made two mistakes that led to some unexpected troubleshooting. First, I accidentally synchronized files from the wrong upgraded zone image, causing one Non-Global Zone to boot with another zone's hostname, IP address, and listener configuration. Later, while correcting the network settings, I mistakenly executed an IP configuration command in the Global Zone instead of the target Non-Global Zone, which immediately disconnected my SSH session and required recovery through the server's ILOM console.

Fortunately, neither issue resulted in data loss, and both were recoverable. This article documents what happened, how the problems were identified, the recovery steps I followed, and the lessons I took away from the experience.

Part 2: Upgrading Solaris Non-Global Zones

 

Introduction

In Part 1 of this series, I covered the process of upgrading the Global Zone from Solaris 11.4 SRU22 to SRU89. Once the Global Zone upgrade was completed successfully, the next task was upgrading the Non-Global Zones running on the same server.

According to Oracle's recommended approach, upgrading Non-Global Zones is usually a straightforward process. If the zone has sufficient free space available, the update can normally be completed by mounting the zone, updating the packages, and then booting the zone.

In many environments, this method works without any issues. However, during this project I encountered an unexpected problem. Even though several Non-Global Zones had more than 12 GB of free space available, the standard upgrade procedure repeatedly failed. This article documents the issue I encountered, the troubleshooting process, and the workaround that ultimately allowed the upgrades to complete successfully.

Part 1: Pre-Upgrade Steps and Upgrading the Solaris Global Zone

 

Introduction:

Upgrading Solaris is never very simple work. It is not like just running one command and everything finishes. Especially when you are going from Solaris 11.4.22 to 11.4.89, it becomes more complicated and needs more careful thinking. In this situation, it is not only about updating packages but also about understanding how Global Zone (GZ) and Non-Global Zones (NGZs) are working together and how this relation will change.

One of the main problems in this upgrade is something called a "Sync-Linked" exception. This happens when dependencies between packages are very tight, and the system does not allow upgrading all zones together in one step. Because of this, we cannot follow the normal upgrade path. We need to separate the process and let Global Zone go first, independent of others.

In this blog series, I will go through the complete upgrade process from Solaris 11.4.22 to 11.4.89 and share the steps I followed in my environment. I will explain how to upgrade the Global Zone and Non-Global Zones, what issues I faced during the process, and how I solved them. I will also cover some mistakes that can happen during the upgrade and the recovery steps that helped me bring the system back when things did not go as expected. My hope is that this real-world experience can help others who are planning a similar Solaris upgrade.

Oracle 26ai: Integrating Google Gemini via PL/SQL and UTL_HTTP

 

Introduction

Talking to your data is no longer a future idea. With Oracle AI Database 26ai, Oracle has made it possible to use natural language instead of writing long SQL queries. You can ask questions in simple English and get answers directly from the database.

However, there is a problem.

In the Oracle 26ai Free VirtualBox Appliance, Select AI does not work as expected. Some required AI packages are missing, and even after creating and compiling them manually, DBMS_CLOUD_AI.CREATE_PROFILE still does not work.

The reason is simple: the Free VirtualBox Appliance does not currently support Google Gemini or OpenAI through native Select AI. The feature is present, but external AI providers are not yet enabled in this environment.

This is not a setup mistake. It is a limitation of the current Free release.

In this blog, I will show how to solve this by building our own AI connection using PL/SQL and UTL_HTTP. This method gives full control, works without Select AI, and allows us to use Google Gemini directly from Oracle 26ai.

Oracle GoldenGate From On-Premises to OCI DBCS – Part 4: Connecting On-Premises GoldenGate to OCI using NGINX and Creating Extract & Replicat

Introduction

This is Part 4 of a four-part blog series on replicating data from an on-premises Oracle Database to Oracle Cloud Infrastructure (OCI) using Oracle GoldenGate.

In this final blog, we focus on establishing secure connectivity between the on-premises and OCI GoldenGate environments using NGINX. Once connectivity is in place, we create and configure the Extract and Replicat processes to enable real-time data replication from the on-premises source to the OCI target database.

Related blogs in this series:

• Part 1: Configuring the Source Environment
• Part 2: Configuring the Target Environment on OCI
• Part 3: Connecting On-Premises GoldenGate to Source and OCI GoldenGate to Target Database