Prioritized Transactions in Oracle 26ai: Comparing Traditional Locking and Priority-Based Processing

Introduction

In my previous blog post, we explored how Oracle 26ai completely eliminates lock contention for numeric attributes using Lock-Free Reservations. But what happens when you have critical business logic that must rely on standard row locks, and a background process blocks a time-sensitive VIP operation?

Traditionally, Oracle operates on a strict first-come, first-served model. If a low-priority batch script updates a row first, a high-priority executive or customer-facing transaction is forced to sit in a queue waiting on enq: TX - row lock contention.

With Priority Transactions in Oracle 26ai, you can explicitly define transaction importance and set threshold policies. If a high-priority session hits a row locked by a lower-priority transaction, Oracle will automatically abort and roll back the blocking session after a configured wait period.

In this article, I will compare traditional row-level locking with Prioritized Transactions using practical examples and show how transaction priorities can change concurrency behavior under contention.

This article is part of a small series on modern concurrency features in Oracle 26ai, including Lock-Free Reservations, Prioritized Transactions, and Value-Based Concurrency Control.

How to Resolve Oracle LogMiner SQL Reconstruction Issues in CDC During Table Structure Changes

 

Introduction 

Last week, one of my clients experienced an issue with Oracle LogMiner after a table structure change. The generated SQL appeared to be incorrectly reconstructed, raising concerns about possible corruption in the LogMiner output.

Before looking at the incident, it is useful to briefly understand what Oracle LogMiner does. LogMiner is an Oracle database utility that allows DBAs and applications to analyze redo and archived redo logs and reconstruct the database changes recorded in them. It is commonly used for troubleshooting, auditing, data recovery, and CDC (Change Data Capture) solutions.

In this case, the affected CDC environment was using LogMiner to capture changes from the database. The problem appeared after a deployment modified the following table:

USER.TRANSACTION

The table changed from 21 columns to 32 columns, with 11 new columns added.

The first important clue came from the Oracle alert log, which showed a significant increase in parsing errors around the same time:

The table's LAST_DDL_TIME was also:

These timestamps helped connect the application problem with the table structure change.

The investigation then focused on how LogMiner was obtaining its dictionary information and how it handled redo generated before and after the structural change. This ultimately led us to the root cause and the appropriate solution.

Lock-Free Reservations in Oracle 26ai: Comparing Traditional Locking and High-Concurrency Transactions

 

Introduction

Handling concurrent updates has always been a challenge in high-volume transactional systems. Consider a banking application where hundreds of transactions attempt to credit or debit the same account at the same time. With traditional row-level locking, once one session updates the account balance, other sessions must wait until the transaction commits or rolls back. As concurrency increases, this waiting can become a bottleneck, resulting in lock contention, increased response times, and events such as enq: TX - row lock contention.

One of the newer Oracle features designed to address this problem is Lock-Free Reservations. Instead of relying on immediate row locking for certain numeric updates, it allows concurrent transactions to reserve resources while preserving transactional consistency.

In this article, I will compare traditional row-level locking with Lock-Free Reservations using practical examples and see how each approach behaves under concurrent load.

This article is part of a small series on modern concurrency features in Oracle 26ai, including Lock-Free Reservations, transaction prioritization, and value-based concurrency control.

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 SRU90. 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.