DEV Community: Abhilash Kumar | Oracle ACE ♠

OCI - Connecting to an OCI Always Free MySQL DB System: Installing MySQL Shell and Building a "Poor Man's VPN"

Abhilash Kumar | Oracle ACE ♠ — Wed, 26 Aug 2026 11:18:32 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

If you've spun up an Oracle Cloud Infrastructure (OCI) Always Free MySQL DB System, you've probably noticed something deliberate about how it's configured: it only exposes a private IP address.

For demostration purposes I have created a OCI MySQL DB System with a public subnet but it exposes only the Private Subnet and this is how it must be designed from cloud a security standpoint .

There's no public endpoint to point a client at from your laptop. That's a good security default — but it means you need a way to reach a database that, by design, nothing outside its own network can see.

This post walks through two things:

Installing MySQL Shell on an Oracle Linux compute instance sitting inside the same Virtual Cloud Network (VCN) as the DB System, so you can connect directly from there.
Building an SSH tunnel from your laptop, through that compute instance, into the private DB endpoint — a lightweight substitute for a full VPN client that gets the job done with a single command.

Part 1 — Installing MySQL Shell on Oracle Linux

MySQL Shell isn't part of Oracle Linux's default repositories, so the first step is adding MySQL's own Yum/DNF repository.

Add the MySQL repository

Oracle Linux 10 is supported directly, and MySQL 8.4 LTS is the current default release line (8.0 is now the legacy series):

sudo dnf install -y https://dev.mysql.com/get/mysql84-community-release-el10-1.noarch.rpm

Install MySQL Shell

The tools (including mysql-shell) live in a subrepository that isn't always enabled by default:

sudo dnf config-manager --enable mysql-tools-community
sudo dnf install -y mysql-shell mysql-community-client

A quick note on GPG keys

MySQL's signing key rotates periodically, and if the copy your system has cached has expired, dnf will refuse the install with a NOTTRUSTED error even after you import a fresh key — because rpm itself re-validates against whatever's already sitting in its trust database. If you hit this:

# Find the expired key package
rpm -qa gpg-pubkey*

# Remove it
sudo rpm -e gpg-pubkey-<id>-<hash>

# Retry, skipping the (now moot) signature check
sudo dnf install -y --nogpgcheck mysql-shell

Once that completes, confirm it's working:

mysqlsh --version

Part 2 — Connecting Directly from the Compute Instance

If your compute instance is in the same VCN as the DB System, you can connect right away using the private endpoint shown in the OCI console (DB System → Connections → Primary endpoint):

mysqlsh --uri admin@10.10.3.3:3306

You'll be prompted for the password interactively. A successful connection here confirms two things: your compute instance has network line-of-sight to the DB System, and the security list/NSG rules allow port 3306 between them. That matters, because it's the foundation the next step depends on.

Part 3 — The "Poor Man's VPN": SSH Tunneling from Your Laptop

Here's the core problem: MySQL Workbench (or any client) running on your laptop has no route to 10.10.3.3 — that address only means something inside the VCN. Your laptop isn't in the VCN. A full OCI VPN Connect / IPSec setup would solve this properly, but for a single developer needing occasional access, that's a lot of infrastructure for a small problem.

SSH local port forwarding solves it with one command, using a resource you already have: your compute instance, which already has a legitimate route to the database.

The idea in one sentence

Open an SSH connection to the compute instance, and tell SSH to forward a local port on your laptop through that encrypted connection to the DB System's private port on the other side.

The diagram

Your laptop never talks to 10.10.3.3 directly — it can't. It talks to 127.0.0.1:3306 on itself. SSH quietly relays that traffic, encrypted, to the compute instance, which then makes the final unencrypted hop to the database — a hop it's allowed to make because it lives inside the VCN.

On macOS/Linux — a single command

ssh -L 3306:10.10.3.3:3306 opc@<compute-instance-public-ip>

Breaking that down:

Piece	Meaning
`-L`	"local forward" — open a port on my machine
`3306`	the port on your laptop you'll connect to
`10.10.3.3:3306`	the destination, resolved from the compute instance's perspective
`opc@<public-ip>`	the SSH login to the compute instance itself

Add -N if you don't need an interactive shell alongside the tunnel, and -f to background it:

ssh -f -N -L 3306:10.10.3.3:3306 opc@<compute-instance-public-ip>

Leave that session running — the tunnel only exists while the SSH connection is alive.

On Windows — the same thing, via PuTTY

PuTTY does exactly the same job through its GUI:

Session: enter the compute instance's public IP, port 22.
Connection → SSH → Auth → Credentials: browse to your private key (convert a .pem to .ppk with PuTTYgen first if needed).
Connection → SSH → Tunnels: Source port 3306, Destination 10.10.3.3:3306, leave it on Local, click Add.
Go back to Session, save it under a name, and click Open.

The PuTTY window that opens is your tunnel — as long as it's connected, the forward is live.

Pointing your client at the tunnel

Whether you built the tunnel with ssh -L or PuTTY, MySQL Workbench's connection settings look the same:

Connection Method: Standard TCP/IP (not "over SSH" — the tunnel is already handling that separately)
Hostname: 127.0.0.1
Port: 3306
Username/Password: your DB System credentials

From Workbench's point of view, it's just talking to a MySQL server on your own machine. It has no idea the traffic is actually crossing into an OCI VCN on the other side of an SSH session.

Below is my MySQL Workbench conncting through localhost - 127.0.0.1:3306 ( mylaptop's local port 3306 )

Why "Poor Man's VPN"?

A real VPN gives you full network-layer access to everything in the remote network, routed transparently, often for many users at once. An SSH tunnel gives you exactly one thing: a single port, forwarded to a single destination, for as long as your terminal session stays open. It's narrower, but it's also zero-config on the OCI side beyond the SSH access you already have — no VPN gateway, no IPSec setup, no extra always-on infrastructure. For reaching a private database from your own laptop during development, it's usually all you need.

NOTE : OCI includes Bastion Service for this kind of requirement, but it was not allowed as free service ( atleast in my region )

Summary

MySQL Shell installs cleanly on Oracle Linux via MySQL's Yum repo, once you handle the GPG key rotation quirk.
A compute instance inside the same VCN as your Always Free DB System can connect directly using its private IP.
Your laptop can't reach that private IP on its own — but an SSH tunnel through the compute instance closes that gap in one line, giving you full MySQL Workbench access without standing up a real VPN.

But in real life tunnel forwarding database IP's will not be used and once needs to a jump box , this blog should help developers and DBA's get started on learning MySQL.

To know more about OCI Always free resources , check here.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

If you’d like Nabhaas to assist in your journey, remember — TAB is just one piece. Our Managed Delivery Service ensures your Oracle operations run smoothly between patch cycles, maintaining predictability and control across your environments.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

Series Week 29/52 — The Anatomy of a Great Oracle SR: Working With Support, Not Against It

Abhilash Kumar | Oracle ACE ♠ — Thu, 20 Aug 2026 10:38:35 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

This article focuses on working with Oracle Support — and how I help you get an SR resolved instead of just logged.

Working With Oracle Support

Every DBA who's been at this long enough has a My Oracle Support (MOS) story, and most of them aren't flattering. None of that is a secret — every IT leadership reading this has heard it from their own team.

MOS UI is continuosly changed , but that does not stop a DBA to get the best out of Oracle Support by proactively sharing information to the guy sitting on the other side of the table.

A bad SR gets raised and waited on. A good SR gets raised and worked — by both sides, at the same time.

Here's the distinction that experience actually teaches you: an SR isn't a request you hand off and wait on. It's a case you build with the engineer, and the DBAs who get resolutions fastest are the ones who act less like a customer filing a complaint and more like a second engineer already working the problem. That single mindset shift — help Oracle Support, don't just wait for it — is the entire difference between a ticket that moves and one that doesn't.

1. Ground Zero: Where Challenges Start

Let's start with a plain canvas and understand our ground zero — almost every stalled SR traces back to something that should have been done before the ticket was even opened.

Typical Weekend Panic & corresponding solutions:

Ticket raised, then the team waits for the engineer to ask for diagnostics → Solution: Upload TFA, ExaCS diagnostic collections, and OS Watcher data proactively, at SR creation — don't wait to be asked
"The database is slow" logged with no application context → Solution: Explain what the application was doing, what business process it supports, and what "slow" actually means in numbers
An ORA-00600/ORA-00700 error logged as a mystery → Solution: Run it through the ORA-600/700 Lookup Tool first — it may already be a documented bug with a known fix
SR sits open for days with no update from your side either → Solution: Treat silence as your problem too — a stale SR from your end signals it's not urgent, even if it is
Engineer's first response asks for something you already have on hand → Solution: Attach it before they ask — a DBA who anticipates the next question is remembered and prioritized
SR written from the DBA's frustration, not the engineer's perspective → Solution: Ask yourself what you'd need to see if you were the one picking up this case cold
Team assumes "Oracle will figure it out" once diagnostics are attached → Solution: Diagnostics start the investigation — they don't replace your own analysis of what you're seeing

This is where most SRs go from "slow" to "stuck" — not because Oracle stopped working it, but because both sides stopped moving it forward together.

As you can see, a great SR is built through the same discipline you'd use troubleshooting the issue yourself — Oracle Support is a collaborator here, not a vending machine.

2. Underneath Ground Zero: Finding the Real Problem

Once you've understood your Ground Zero problems, you need to move to why so many DBAs default to raise-and-wait instead of raise-and-help.

Why "we logged an SR" doesn't mean the same thing to every DBA:

Proactive diagnostic tools are seen as something you run only when asked → Solution: Treat TFA, OS Watcher, and ExaCS diagnostics as part of opening the SR, not responding to it
Less experienced DBAs don't know the ORA-600/700 Lookup Tool exists → Solution: Build it into your team's first-response checklist for any internal error before an SR is even raised
The application team and the DBA team don't share context before the SR is written → Solution: Pull in the application owner briefly — what changed, what's the business impact — before logging
DBAs think "attaching everything" is the same as "explaining the problem" → Solution: A pile of logs isn't a diagnosis — pair every attachment with what you believe it shows
Support is viewed adversarially, as something to escalate against rather than work with → Solution: Shift the internal language from "fighting with support" to "working the case with
support"
No one on the team has been shown what a genuinely well-run SR looks like → Solution: Have your most experienced DBA mentor others through their first few high-severity SRs

This gap is why two DBAs with the same issue and the same Oracle support tier get completely different outcomes.

As you can see, the difference isn't Oracle's engineers — it's how much of the diagnostic and analytical work has already been done by the time they open the case.

3. Working Upwards: From Understanding to Solution

Here's what separates an SR that moves from one that doesn't — the things an experienced DBA does without being told to.

Do this before you even log the SR:

Run the error through the ORA-600/700 Lookup Tool (MOS Note 153788.1) before assuming it needs a fresh investigation. A meaningful share of ORA-600/ORA-700 errors are already documented, with a known bug number, workaround, or patch — an experienced DBA checks this first and often finds the SR is unnecessary, or at least dramatically shortened.
Collect TFA (Trace File Analyzer) output proactively. TFA correlates logs across all nodes and layers automatically — attach it at SR creation, don't wait for the engineer to request it.
On ExaCS, run the relevant Exadata diagnostic collection up front — cell server logs, ILOM data, and health check output. Exadata issues almost always need this, so there's no version of the SR where it isn't eventually asked for.
If OS-level performance is in question, have OS Watcher data ready — CPU, memory, I/O, and network captured around the incident window. Reconstructing this after the fact is far harder than having it captured continuously.

Do this when you write the SR:

Explain the application problem, not just the database symptom. "ORA-01555 during month-end batch" tells an engineer far less than "ORA-01555 during the finance close batch, which reads a 40M row table over 3 hours — this started after we increased batch parallelism last week."
Put yourself in the SR engineer's seat. They're picking this up cold, possibly mid-shift-change, with no memory of your environment. Write the SR so a stranger could triage it in five minutes.
State what you've already ruled out. If you've checked for blocking sessions, recent parameter changes, or a matching bug, say so — it prevents the engineer from re-walking ground you've already covered.

Do this while the SR is open:

Don't raise and wait — keep working the problem on your side in parallel. If you find something new, post it immediately, don't hold it for the next scheduled update.
Respond to every ask same-day where possible. An SR that goes quiet from your end loses momentum and priority just as easily as one that goes quiet from Oracle's.
If you're stuck, say exactly what you need — a call, a specific engineer, a decision by a specific time — not a general nudge.

The pattern holds no matter which version of MOS you're using: the SRs that move are the ones where the DBA is visibly still working the problem, not just waiting on someone else to.

Technical Issues:

ORA-600/700 errors logged without checking the Lookup Tool first

— Solution: Make the Lookup Tool check step one, before an SR is even opened

TFA, OS Watcher, and ExaCS diagnostics collected only after being requested — Solution: Build proactive diagnostic collection into your incident response runbook
Diagnostics attached without any accompanying analysis — Solution: Pair every attachment with a sentence on what you believe it shows

Non-Technical Issues:

Support treated as adversarial rather than collaborative —

Solution: Reframe internally as working the case together, not escalating against a vendor

Application context missing from SRs raised by the DBA team alone

— Solution: Involve the application owner briefly before logging, every time

Junior DBAs never shown what a well-run SR looks like — Solution: Pair them with an experienced DBA on their first few Sev 1/Sev 2 cases

A MOS great SR isn't about being demanding, and it isn't about waiting patiently either — it's about doing the engineer's first three steps for them before they've had the chance to ask.

OracleBootCamp 8-Aug-2026 : Top 10 - Oracle Linux 10 Utilities - HOL ( Hands On Labs )

Abhilash Kumar | Oracle ACE ♠ — Mon, 10 Aug 2026 14:17:39 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

Hands On Labs for OracleBootCamp Event on 8-Aug-2026

Sample Labs : https://github.com/abhilash-8/oraclebootcamp-8-Aug-2026-Chennai

1. bpftrace

[root@instance-20260614-1905 ~]# sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s opened %s\n", comm, str(args->filename)); }'

Attached 1 probe
stat opened /etc/ld.so.cache
stat opened /lib64/libselinux.so.1
stat opened /lib64/libc.so.6
stat opened /lib64/libpcre2-8.so.0
stat opened /usr/lib/locale/locale-archive
stat opened /usr/share/locale/locale.alias
stat opened /usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION
stat opened /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
stat opened /usr/lib64/gconv/gconv-modules.cache
stat opened /usr/lib/locale/en_US.UTF-8/LC_MEASUREMENT
stat opened /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
stat opened /usr/lib/locale/en_US.UTF-8/LC_TELEPHONE
stat opened /usr/lib/locale/en_US.utf8/LC_TELEPHONE
stat opened /usr/lib/locale/en_US.UTF-8/LC_ADDRESS
stat opened /usr/lib/locale/en_US.utf8/LC_ADDRESS
stat opened /usr/lib/locale/en_US.UTF-8/LC_NAME
stat opened /usr/lib/locale/en_US.utf8/LC_NAME
python3 opened /tmp/bootcamp-load/
python3 opened /tmp/bootcamp-load/
python3 opened /tmp/bootcamp-load/
curl opened /dev/null
curl opened /dev/null
curl opened /dev/null
python3 opened /tmp/bootcamp-load/
python3 opened /tmp/bootcamp-load/
bootcamp-load-g opened /tmp/bootcamp-load/churn_1.tmp
curl opened /dev/null
stat opened /usr/lib/locale/en_US.UTF-8/LC_PAPER
bootcamp-load-g opened /dev/null
stat opened /usr/lib/locale/en_US.utf8/LC_PAPER
stat opened /usr/lib/locale/en_US.UTF-8/LC_MESSAGES
cat opened /etc/ld.so.cache
cat opened /lib64/libc.so.6
stat opened /usr/lib/locale/en_US.utf8/LC_MESSAGES
cat opened 
cat opened /usr/share/locale/locale.alias
cat opened /usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION
cat opened /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
cat opened /usr/lib64/gconv/gconv-modules.cache
cat opened /usr/lib/locale/en_US.UTF-8/LC_MEASUREMENT
cat opened /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
.
.

2. sar

[root@instance-20260614-1905 ~]# sar -u 1 5
Linux 6.12.0-203.76.7.3.el10uek.x86_64 (instance-20260614-1905)         08/10/2026      _x86_64_        (2 CPU)

02:15:27 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:15:28 PM     all     35.47      0.00     12.81      0.00     51.72      0.00
02:15:29 PM     all     38.89      0.00      9.09      0.00     52.02      0.00
02:15:30 PM     all     39.60      0.00      7.43      0.00     52.97      0.00
02:15:31 PM     all     35.86      0.00     10.10      0.00     54.04      0.00
02:15:32 PM     all     40.91      0.00      4.55      0.00     54.55      0.00
Average:        all     38.14      0.00      8.81      0.00     53.05      0.00
[root@instance-20260614-1905 ~]#

3. iostat

[root@instance-20260614-1905 ~]# iostat -x 1 5
Linux 6.12.0-203.76.7.3.el10uek.x86_64 (instance-20260614-1905)         08/10/2026      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          25.65    0.03    3.10    0.04    1.46   69.71

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
dm-0             5.48    557.55     0.00   0.00    4.02   101.79    2.44  14179.58     0.00   0.00  133.05  5812.82    1.51   7994.73     0.00   0.00   61.31  5290.92    0.00    0.00    0.44  24.08
dm-1             0.10      6.14     0.00   0.00    0.64    59.07    0.00      1.36     0.00   0.00   11.00  2048.00    0.01  13821.19     0.00   0.00  275.70 1043659.00    0.00    0.00    0.00   0.08
sda              6.03    610.48     0.16   2.52    4.94   101.29   13.08  14222.39     0.42   3.11  435.49  1087.27    0.86  22780.55     0.68  43.91   63.12 26403.59    0.00    0.00    5.78  23.94


avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          82.50    0.00   11.50    0.00    6.00    0.00

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
dm-0             0.00      0.00     0.00   0.00    0.00     0.00    2.00  65546.50     0.00   0.00  543.50 32773.25    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    1.09  77.80
dm-1             0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    0.00   0.00
sda              0.00      0.00     0.00   0.00    0.00     0.00   41.00  50186.50     0.00   0.00  397.78  1224.06    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00   16.31  77.10


avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          82.09    0.00    6.47    0.00   11.44    0.00

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
dm-0             0.00      0.00     0.00   0.00    0.00     0.00    2.00  65546.50     0.00   0.00  541.50 32773.25    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    1.08  77.10
dm-1             0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    0.00   0.00
sda              0.00      0.00     0.00   0.00    0.00     0.00   40.00  49930.50     0.00   0.00  463.40  1248.26    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00   18.54  77.10


avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          85.29    0.00    9.80    0.00    4.90    0.00

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
dm-0             0.00      0.00     0.00   0.00    0.00     0.00    6.86  64501.47     0.00   0.00  155.57  9398.79    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    1.07  76.96
dm-1             0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    0.00   0.00
sda              0.00      0.00     0.00   0.00    0.00     0.00   32.35  35638.73     1.96   5.71  640.42  1101.56    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00   20.72  71.37


avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          87.00    0.00    7.50    0.00    5.50    0.00

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
dm-0             0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    0.00 100.00
dm-1             0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00    0.00   0.00
sda              0.00      0.00     0.00   0.00    0.00     0.00   51.00  64256.00     0.00   0.00  483.41  1259.92    0.00      0.00     0.00   0.00    0.00     0.00    0.00    0.00   24.65 105.20

4. perf


[root@instance-20260614-1905 ~]# sudo perf top --sort comm,dso


Samples: 48K of event 'cycles:P', 4000 Hz, Event count (approx.): 21654368464 lost: 0/0 drop: 0/0                                                                                                                                                                    
Overhead  Command          Shared Object                                                                                                                                                                                                                             
  26.87%  awk              gawk
  25.43%  bc               bc
  23.74%  python3          libc.so.6
   2.96%  bootcamp-load-g  [kernel]
   2.07%  curl             [kernel]
   1.97%  perf             [kernel]
   1.88%  perf             perf
   1.72%  ls               [kernel]
   1.41%  curl             ld-linux-x86-64.so.2
   1.14%  cat              [kernel]
   0.94%  rm               [kernel]
   0.72%  perf             libc.so.6
   0.62%  stat             [kernel]
   0.58%  systemd-userwor  [kernel]
   0.51%  sleep            [kernel]
   0.45%  dd               [kernel]
   0.39%  ls               libc.so.6
   0.35%  python3          libpython3.12.so.1.0
   0.32%  bc               libc.so.6
   0.31%  curl             libcrypto.so.3.5.1
   0.29%  curl             libc.so.6
   0.29%  python3          [kernel]
   0.27%  cat              libc.so.6
   0.25%  bootcamp-load-g  bash
   0.23%  perf             liblzma.so.5.6.2
   0.23%  stat             ld-linux-x86-64.so.2
   0.22%  rm               ld-linux-x86-64.so.2
   0.21%  cat              ld-linux-x86-64.so.2
   0.19%  systemd-userwor  libsystemd-shared-257-13.0.1.el10_1.3.so
   0.18%  rm               libc.so.6
   0.18%  ls               ld-linux-x86-64.so.2
   0.17%  bootcamp-load-g  libc.so.6
   0.17%  systemd          libsystemd-shared-257-13.0.1.el10_1.3.so
   0.17%  ls               libnss_systemd.so.2
   0.13%  sleep            libc.so.6
   0.13%  perf             libstdc++.so.6.0.33
   0.13%  systemd-userwor  libc.so.6
   0.12%  bc               [kernel]
   0.12%  systemd          [kernel]
   0.12%  ls               ls

5. ss



[root@instance-20260614-1905 ~]# ss -s
Total: 258
TCP:   1431 (estab 11, closed 1404, orphaned 0, timewait 1404)

Transport Total     IP        IPv6
RAW       1         0         1        
UDP       5         3         2        
TCP       27        23        4        
INET      33        26        7        
FRAG      0         0         0        

[root@instance-20260614-1905 ~]#

6. lsof

[root@instance-20260614-1905 ~]# lsof -i :8088
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python3   7413 root    3u  IPv4  30903      0t0  TCP *:radan-http (LISTEN)
curl    112296 root    4u  IPv4 313382      0t0  TCP localhost:60758->localhost:radan-http (SYN_SENT)
curl    112297 root    4u  IPv4 313381      0t0  TCP localhost:60752->localhost:radan-http (SYN_SENT)
curl    112298 root    4u  IPv4 313380      0t0  TCP localhost:60746->localhost:radan-http (SYN_SENT)
curl    112299 root    4u  IPv4 313383      0t0  TCP localhost:60762->localhost:radan-http (SYN_SENT)
[root@instance-20260614-1905 ~]#

7. strace



[root@instance-20260614-1905 ~]# sudo strace -c -p $(cat /tmp/bootcamp-load/target.pid 2>/dev/null || echo '<run before stop>')
strace: Process 7402 attached

^Cstrace: Process 7402 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 91.86    0.606314         488      1242       621 wait4
  5.81    0.038332          61       621           clone
  1.49    0.009845           2      4659           rt_sigprocmask
  0.60    0.003971           2      1863           rt_sigaction
  0.23    0.001544           2       621           rt_sigreturn
------ ----------- ----------- --------- --------- ----------------
100.00    0.660006          73      9006       621 total

8. ipcs



[root@instance-20260614-1905 ~]# ipcs -a

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0xe607dfb1 0          root       644        1048576    0                       
0x65c204d2 1          root       644        1048576    0                       
0x30809964 2          root       644        1048576    0                       

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0xda0f24f8 2          root       644        1         
0xaaa29326 3          root       644        1         
0x0af0d682 4          root       644        1         

[root@instance-20260614-1905 ~]#

9. numastat


[root@instance-20260614-1905 ~]# numastat -m

Per-node system memory usage (in MBs):
                          Node 0           Total
                 --------------- ---------------
MemTotal                 9480.82         9480.82
MemFree                  7993.14         7993.14
MemUsed                  1487.68         1487.68
SwapCached                  0.00            0.00
Active                    817.42          817.42
Inactive                  467.84          467.84
Active(anon)              512.65          512.65
Inactive(anon)              0.00            0.00
Active(file)              304.77          304.77
Inactive(file)            467.84          467.84
Unevictable                 9.40            9.40
Mlocked                     9.40            9.40
Dirty                       0.02            0.02
Writeback                  64.02           64.02
FilePages                 788.74          788.74
Mapped                    149.32          149.32
AnonPages                 502.34          502.34
Shmem                       8.69            8.69
KernelStack                 4.31            4.31
PageTables                  7.66            7.66
SecPageTables               0.00            0.00
NFS_Unstable                0.00            0.00
Bounce                      0.00            0.00
WritebackTmp                0.00            0.00
KReclaimable               33.27           33.27
Slab                       94.36           94.36
SReclaimable               33.27           33.27
SUnreclaim                 61.09           61.09
AnonHugePages             268.00          268.00
ShmemHugePages              0.00            0.00
ShmemPmdMapped              0.00            0.00
FileHugePages              76.00           76.00
FilePmdMapped              62.00           62.00
Unaccepted                  0.00            0.00
HugePages_Total             0.00            0.00
HugePages_Free              0.00            0.00
HugePages_Surp              0.00            0.00
[root@instance-20260614-1905 ~]#

10. watch -d -n1 'numastat -m'

Every 1.0s: numastat -m                                                                                                                                                                                              instance-20260614-1905: Mon Aug 10 14:20:31 2026


Per-node system memory usage (in MBs):
                          Node 0           Total
                 --------------- ---------------
MemTotal                 9480.82         9480.82
MemFree                  7937.53         7937.53
MemUsed                  1543.29         1543.29
SwapCached                  0.00            0.00
Active                    829.73          829.73
Inactive                  511.38          511.38
Active(anon)              524.96          524.96
Inactive(anon)              0.00            0.00
Active(file)              304.77          304.77
Inactive(file)            511.38          511.38
Unevictable                 9.40            9.40
Mlocked                     9.40            9.40
Dirty                       0.03            0.03
Writeback                  64.00           64.00
FilePages                 832.28          832.28
Mapped                    152.86          152.86
AnonPages                 515.71          515.71
Shmem                       8.69            8.69
KernelStack                 4.30            4.30
PageTables                  7.74            7.74
SecPageTables               0.00            0.00
NFS_Unstable                0.00            0.00
Bounce                      0.00            0.00
WritebackTmp                0.00            0.00
KReclaimable               33.49           33.49
Slab                       94.92           94.92
SReclaimable               33.49           33.49
SUnreclaim                 61.43           61.43
AnonHugePages             288.00          288.00
ShmemHugePages              0.00            0.00
ShmemPmdMapped              0.00            0.00
FileHugePages              76.00           76.00
FilePmdMapped              64.00           64.00
Unaccepted                  0.00            0.00
HugePages_Total             0.00            0.00
HugePages_Free              0.00            0.00
HugePages_Surp              0.00            0.00

I'm Not a Developer — So Why Did Oracle Backend with Firebase APIs Get Me Hooked on Oracle AI Database?

Abhilash Kumar | Oracle ACE ♠ — Sun, 02 Aug 2026 07:41:08 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

I spend my days on the infrastructure side of things — migrations, capacity planning, licensing conversations, moving workloads onto Oracle Autonomous AI Database and OCI.

I don't write mobile apps. I've never shipped an Android build or wrestled with an Xcode provisioning profile.

So when I first heard about Oracle Backend with Firebase APIs, my honest first reaction was: "that's a developer thing, not my thing , but I relaized a DBA needs to understand ORDS

A few days in, I've had to look into it as my Dev Team asked for some support on this Once our data is on Oracle AI Database, what else can we do with it?" Usually that means analytics, or AI workloads, or vector search for RAG. It almost never means "can our mobile app team build directly on top of this too" — because historically, the honest answer was no. Mobile and web teams reach for Firebase, Supabase, or some other backend-as-a-service, and the database team's carefully governed, audited, encrypted Oracle estate sits in a completely separate world from the app.

What the toolkit actually is, in plain terms

Oracle Backend with Firebase APIs is a free feature of Oracle REST Data Services (ORDS) that lets app developers build mobile and web apps directly against Oracle AI Database, using SDKs for iOS, Android, Flutter, and JavaScript that are deliberately shaped to feel like the Firebase SDKs they already know. Authentication, document-style data storage, file storage, declarative security rules, and AI vector search are all exposed through those SDKs — and all of it runs inside the same database instance, not a separate service bolted on the side.

That last part is the piece that clicked for me. It's not "Oracle built a Firebase clone." It's "Oracle exposed the database you already trust through an interface that app developers already like."

Where exactly the firebase app connects to the database

The app itself never opens a database connection — that's the key thing to understand. There's a hop in between:

App (phone/browser) → HTTPS request → ORDS → SQL/PL-SQL call inside the database → Oracle AI Database (ATP)

Broken down:

1. The SDK talks HTTP, not SQL.
When your app calls something like addDoc() or signInWithEmailAndPassword(), the SDK turns that into a plain HTTPS REST call to the ords_host URL from your app config — the same URL you set in initializeApp().

2. ORDS is the actual thing holding a database connection. ORDS maintains its own JDBC connection pool to the database (that's what got configured during the fusabase install step — host, port, PDB service name). The app, the phone, the browser — none of them ever see a database hostname, port, or credential. They only ever see the ORDS URL.

3. Inside the database, Fusabase ships as server-side PL/SQL packages. ORDS routes each REST call to Fusabase's own API packages running inside the database schema you enabled (the one with BAAS_ROLE). Those packages are what actually read/write the JSON collections, check security rules, and run vector similarity queries — as regular SQL/PL-SQL, on regular tables, in your schema.

4. On ATP specifically, this means the real connection point is whatever ORDS instance is fronting your Autonomous Database — either Oracle's default managed ORDS, or (per what we found last time) a Customer Managed ORDS if you need the install-level access Fusabase requires. Either way, the physical DB connection lives entirely on the ORDS side, using ORDS's own database user/wallet — the app's auth token only proves who the app user is, not a database login.

So the honest one-line answer: the app connects to ORDS over HTTPS; ORDS is what's connected to the database. The app never gets network-level access to ATP itself.

So What ORDS does - A DBA knowhow primer

What ORDS does — the core job list:

Turns database objects into REST APIs. Auto-REST enables tables/views with zero code; custom PL/SQL endpoints are hand-mapped to URLs.
Holds the actual database connection. Maintains a JDBC connection pool per configured database — clients never connect directly; ORDS hands out pooled sessions to fulfill requests.
Handles authentication and authorization at the API layer. OAuth2 (client credentials, roles like SQL Developer), API-key or Basic auth for auto-REST, independent of how the database itself authenticates ORDS's own pool user.
Enforces access control on endpoints. Privileges, roles, and rate limiting can be applied per REST module — separate from (but layered on top of) database grants and VPD.
Serializes results to standard web formats. JSON by default, plus CSV, GeoJSON, and binary media for BLOBs/files.
Provides request-shaping features. Filtering, sorting, pagination, and dynamic bind parameters on auto-REST endpoints without writing SQL for each variant.
Generates OpenAPI documentation for whatever it exposes, so consumers get a spec, not just an endpoint.
Runs application platforms on top of the database. APEX, SQL Developer Web / Database Actions, and — as of 26.1 — Oracle Backend for Firebase are all delivered through ORDS rather than as separate services.
Exposes vector search natively. The /vectorSearch endpoint runs similarity queries against VECTOR columns on auto-REST enabled tables.
Acts as a REST bridge for non-relational access patterns — the Database API for MongoDB and Fusabase both route MongoDB- or Firebase-shaped calls into ordinary SQL/PLSQL underneath.
Serves AI-facing tooling. MCP Tools for letting AI systems discover database connections, pull schema metadata, and execute SQL/PLSQL.
Runs as a separate mid-tier process with its own lifecycle — install, patch, scale, and version independently of the database (standalone Jetty, or deployable to Tomcat/WebLogic); on Autonomous Database, Oracle runs and manages a default instance of it for you, with limited configurability unless you go Customer Managed.

Why that matters from where I sit

A few things stood out to me as someone who thinks about this from the operations and governance side, not the app-building side:

One database set of controls. Because the toolkit runs on ORDS on top of Oracle AI Database, everything the DBA team already relies on — auditing, transparent data encryption, partitioning, Data Guard, row-level security — still applies underneath whatever the app developers build. The app team gets a familiar developer experience; the platform team doesn't lose the guardrails they spent years putting in place.
Vector search without a second system to babysit. App-driven AI features — semantic search, recommendations, retrieval-augmented generation — can query vectors stored right alongside the relational data, in the same query, under the same rules. For anyone who has had to stand up and secure a standalone vector database just to support one feature, that's a meaningfully smaller footprint to operate and explain to an audit team.
It runs wherever ORDS already runs. OCI, AWS, Azure, Google Cloud, on-premises, Cloud@Customer — this isn't a new managed service you have to onboard. If ORDS is already part of your environment, this is a feature you turn on, not a platform you migrate to.
App Trust closes a gap I hadn't thought about. Client configuration for these toolkits is public by design — anyone who inspects a deployed app can see it. App Trust adds an attestation layer so the backend can tell a real instance of your app from a script or a copycat using the same config. That's a nice bit of reassurance for anyone worried about what "expose your database to a mobile SDK" might mean for abuse or scraping.

The bigger shift

What I find genuinely interesting isn't the SDK syntax — I'll leave that to the developers. It's what this represents: Oracle AI Database showing up natively in front-end and mobile development conversations, not just backend and analytics ones. For consulting work centered on getting customers onto Oracle AI Database and OCI, that's a new thread worth pulling. A customer's mobile team building a new app is now a legitimate reason to talk about the same database platform their data team already runs on — instead of two separate conversations that never meet.

I still won't be writing the Swift or Flutter code myself. But I'll be paying attention to who is, and I'd encourage anyone in a similar seat — infrastructure, migrations, database platform work — to take a look, even if "developer toolkit" doesn't sound like it's aimed at you. It wasn't aimed at me either, and it still got me interested.

Where to go next

If this piqued your curiosity too:

Oracle Documentation for Firebase: oracle.com/database/technologies/appdev/oracle-backend-for-firebase
Announcement post: Introducing Oracle Backend for Firebase
Developer docs: docs.oracle.com — Oracle Backend for Firebase
Free LiveLabs workshops:

Oracle Backend with Firebase APIs is generally available today as part of ORDS 26.1.1, and it's free.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

Series Week 28/52 — Audit , Tracing & Logging - They all mean different things

Abhilash Kumar | Oracle ACE ♠ — Sat, 01 Aug 2026 06:07:44 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

This article focuses on audit trails, tracing, and logging — and how I help you tell them apart before an auditor and your on-call engineer end up arguing about words that don't mean what either of them thinks they mean.

Audit Trail, Tracing & Logging

Last week's post was about who can reach the database. This week's question is the natural next one: once they're in, what can you actually prove they did?

"We have logs" is the most dangerous sentence in an audit response — because everyone in the room means something different by it.

I've sat in enough audit calls to know the exact moment it goes sideways: the auditor asks for "the audit trail," the DBA pulls up the alert log, the app support engineer points at a trace file, and the compliance officer wanted DBA_AUDIT_TRAIL the whole time. Nobody's wrong. They're just speaking three different languages about three different things — and that gap is exactly where audit findings live.

1. Ground Zero: Where Challenges Start

Let's start with a plain canvas and understand our ground zero — most of this confusion isn't technical incompetence, it's vocabulary that was never standardized across teams.

Weekend-audit-panic causes & corresponding solutions:

"We have logs, so we have an audit trail" → Solution: Logs tell you what the system did; an audit trail tells you what a user did — they overlap, they aren't the same
Trace files handed to an auditor as "proof of activity" → Solution: Trace files are diagnostic, session-level, and rotate out — they were never designed as evidence
Alert log treated as a record of data changes → Solution: The alert log records instance-level events, not row-level transactions
"Turn on auditing" said without specifying which auditing → Solution: Name the mechanism — traditional auditing, FGA, or Unified Auditing — they behave differently
Assumption that the database keeps every historical transaction forever → Solution: Retention is finite everywhere — audit trail, redo, and flashback all expire on a policy
Auditors asking for "who changed this business value" and DBAs pointing at DB logs only → Solution: Business-transaction audit is usually an application responsibility, not a DB-only one
No one agreeing on what "audit trail" even refers to in a meeting → Solution: Build one shared glossary before the next audit cycle, not during it

This is where most audit conversations break down — not from missing evidence, but from mismatched vocabulary.

As you can see, before any tool gets configured, there's a language problem to solve first.

Auditors and technical support engineers are often talking about completely different layers of the same word — "audit" — and until that's made consistent, no amount of logging fixes the conversation.

2. Underneath Ground Zero: Finding the Real Problem

Once you've understood your Ground Zero problems, you need to move to why this vocabulary gap exists in the first place — it's baked into how Oracle itself separates these layers.

Why "we have logs" doesn't survive a real audit question:

OS-level and DB-level visibility are treated as one bucket → Solution: Separate what lives in the Oracle Home from what lives inside the database itself
Traditional auditing (SYS.AUD$) still assumed to be "the" audit trail → Solution: Recognize it as the legacy mechanism — Unified Auditing has superseded it since 12c
DBA_AUDIT_TRAIL and UNIFIED_AUDIT_TRAIL used interchangeably → Solution: Know which view you're actually querying — they pull from different underlying stores
No audit policy defined, so default auditing catches too little or too much → Solution: Design audit policies around what the business actually needs to prove
Flashback treated as an infinite undo button → Solution: Flashback retention is a tuned window, not a permanent transaction backup
Application-level business logic changes assumed to be visible in DB audit → Solution: If the app doesn't log "why" a value changed, the database never will either
Compliance teams write "maintain an audit trail" without defining retention or scope → Solution: Translate the compliance ask into a specific mechanism, retention period, and owner

This gap is why the same "insufficient audit evidence" finding shows up audit after audit.

As you can see, the real problem underneath is that Oracle gives you several distinct, purpose-built mechanisms — and treating them as one interchangeable "audit trail" is exactly what causes the mismatch above.

3. Working Upwards: From Understanding to Solution

Here's the layer-by-layer breakdown every CTO needs to internalize — and be able to repeat back to an auditor without a DBA translating in real time.

What's available in the Oracle Home (OS-level, diagnostic):

Trace files (.trc / .trm) — Per-session or per-process diagnostic detail, used for troubleshooting errors and performance — not designed to prove who changed what data.
Listener log — Connection attempts and listener events — useful for "who tried to connect," not "what did they do once inside."
Alert log — Instance-level events: startup, shutdown, errors, structural changes — the database's own operational diary, not a user activity record.

What's available inside the database — and what's actually switched on:

Two mechanisms live here, and only one of them is where Oracle's investment goes today. SYS.AUD$ is the table behind traditional (legacy) auditing, exposed through the DBA_AUDIT_TRAIL view (and DBA_FGA_AUDIT_TRAIL for Fine-Grained Audit records over SYS.FGA_LOG$). It's driven by old-style AUDIT statements and the AUDIT_TRAIL init parameter — familiar to most DBAs, but legacy: traditional/mixed-mode auditing was desupported starting with Oracle Database 21c, so new environments shouldn't design around this view. Its successor, Unified Auditing (12c onward), consolidates what used to be scattered across traditional auditing, FGA, Database Vault, Label Security, Real Application Security, Data Pump, and RMAN into one policy-driven store — AUDSYS.AUD$UNIFIED, queried through UNIFIED_AUDIT_TRAIL, controlled with CREATE AUDIT POLICY + AUDIT POLICY <name> instead of statement-by-statement AUDIT grants.

Here's the part that catches most CTOs off guard: on a fresh 12c+/19c install, Unified Auditing is already running — just not on your data. STARTUP, SHUTDOWN, and any AS SYSDBA / AS SYSOPER connection are audited unconditionally, no configuration required. Two predefined policies ship enabled out of the box: ORA_SECURECONFIG, which captures administrative and security-relevant actions — creating or dropping users, roles, and profiles; privilege grants; changes to audit policies themselves; Database Vault and Label Security actions — and ORA_LOGON_FAILURES, which captures failed login attempts, usually the first thing an auditor or incident responder asks for.

What none of that default coverage includes is your application. Everyday SELECT / INSERT / UPDATE / DELETE on business tables goes completely unaudited until your team writes and enables a policy for it — like the CREATE AUDIT POLICY ... ACTIONS UPDATE ON app.customers example below. Nothing in the defaults tells you who changed a customer's balance or read a sensitive record.

The one-line takeaway for a CTO: out of the box, Oracle audits itself — privileged accounts, security configuration changes, failed logins. It does not audit your business by default. If an auditor expects business-transaction visibility and only the default policies are running, that gap is a finding waiting to happen — and closing it is a deliberate design decision your team has to make, not something Oracle does for you.

What's an application vendor's responsibility, not the database's:

Business-transaction context — "Who approved this invoice, and why" is a business-logic audit trail — the application has to log it; the database only sees the resulting DML.
Field-level business meaning — The database can tell you a column changed; only the application knows what that column changing means to the business.

What's never available — and why that's by design:

A permanent backup of every transaction that ever happened → This doesn't exist, and shouldn't be expected to. Redo, undo, audit trail, and flashback data archive all operate on a retention window, not infinite history — which is precisely why Flashback retention is a deliberate, tuned setting, not a substitute for a real archival strategy.

A quick look under the hood (for the technical conversation with your DBA — not something a CTO needs to write, just recognize):

Enabling a Unified Audit policy on a specific, business-relevant action:

CREATE AUDIT POLICY audit_customer_updates
  ACTIONS UPDATE ON app.customers;
AUDIT POLICY audit_customer_updates;

Querying what Unified Auditing actually captured:

SELECT dbusername, action_name, object_name, event_timestamp
FROM unified_audit_trail
WHERE object_name = 'CUSTOMERS'
ORDER BY event_timestamp DESC;

That's the whole shift from legacy auditing: you define a policy around what matters to the business, and query one consolidated view — instead of piecing together SYS.AUD$, FGA, and OS logs separately.

Technical Issues:

Legacy SYS.AUD$ still relied on as the primary audit source — Solution: Migrate audit policy design to Unified Auditing
No defined Unified Audit policies beyond the defaults, so business activity goes uncaptured — Solution: Build policies around specific, named compliance requirements — don't assume ORA_SECURECONFIG covers your application
Flashback retention set arbitrarily, not against an actual recovery/audit need — Solution: Size retention against real RPO and audit windows, not a default
Trace files rotated out before an incident investigation can use them — Solution: Align trace/log retention with your incident response SLA

Non-Technical Issues:

Auditors, DBAs, and app teams use "audit trail" to mean three different things — Solution: Publish one shared glossary and use it in every audit conversation
Compliance asks written without specifying mechanism or retention — Solution: Translate every compliance clause into a named DB/app control before the audit
Application teams assume the database will "just log it" — Solution: Make business-transaction logging an explicit app requirement, reviewed at design time
No one owns reconciling what the auditor wants against what actually exists — Solution: Assign one accountable owner to bridge the audit ask and the technical reality

Audit Trail, Tracing, and Logging are not synonyms — they're three different answers to three different questions. Getting your auditors and your engineers speaking the same language about which is which is the eye-opener most CTOs don't realize they're missing until it costs them in a finding.

How Nabhaas helps you

If you've made it this far, you already sense there's a better way — in fact, you have a way ahead.

If you'd like Nabhaas to assist in your journey, remember — TAB is just one piece. Our Managed Delivery Service ensures your Oracle operations run smoothly between patch cycles, maintaining predictability and control across your environments.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

Series Week 27/52 — Zero Trust for Databases: Rethinking Access in OCI

Abhilash Kumar | Oracle ACE ♠ — Tue, 28 Jul 2026 07:32:20 +0000

Series Week 27/52 — Zero Trust for Databases: Rethinking Access in OCI

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

This article focuses on access control in OCI, and how I help you rethink who — and what — actually gets to touch your database.

Database Access Control

Access control does not change because your database moved to the cloud. What changes is who's watching, and how many new doors got added along the way.

Least privilege isn't a policy statement — it's the difference between an incident and a headline.

Last week's post drew the line between Encryption, Masking, Redaction, and Database Vault. This week, I want to zoom out one layer — to who is even allowed to reach the database in the first place, before any of those four controls come into play. In OCI, that question has more moving parts than most CTOs expect: IAM policies, compartments, network security groups, dynamic groups, and the database's own privilege model all sit in the same access chain.

1. Ground Zero: Where Challenges Start

Let's start with a plain canvas and understand our ground zero — most access problems in OCI start as convenience decisions that were never revisited.

Weekend-access-panic causes & corresponding solutions:

"It's in the cloud, so IAM handles security" → Solution: IAM controls who reaches the console/API — the database still has its own privilege model
One IAM policy grants manage database-family across the whole tenancy → Solution: Scope policies to a compartment, an environment, and a named group
Security Lists/NSGs left open on the DB listener port → Solution: Restrict ingress to only the app subnet or bastion, nothing broader
Shared "admin" credentials used by multiple team members → Solution: Individual named accounts, tied to IAM identity, always
DBAs hold both console access and unrestricted DB privileges → Solution: Separate cloud-infrastructure access from in-database privilege
Automation scripts run with a personal user's credentials → Solution: Use Dynamic Groups and Instance Principals scoped to the task
Break-glass/emergency access exists but isn't documented or logged → Solution: Define, log, and time-box emergency access explicitly
Compartments are structured by cost center, not by access boundary → Solution: Let compartments reflect who should — and shouldn't — see what
No one reviews who still has access after a project ends → Solution: Run periodic access recertification, not just onboarding

This is where most access-related incidents begin — not with an attack, but with a door nobody remembered was open.

As you can see, we haven't even touched Zero Trust architecture yet — there's a lot of basic hygiene to close first.

Cloud access is not one control — it's a chain. And a chain is only as strong as the link nobody's checked in months.

2. Underneath Ground Zero: Finding the Real Problem

Once you've understood your Ground Zero problems, you need to move to why access sprawls so quickly in OCI specifically — it's rarely negligence, it's usually speed.

Why "we locked it down" often doesn't hold up under review:

IAM policies were written once, at go-live, under deadline pressure → Solution: Treat IAM policy as a living artifact, reviewed every quarter
Compartment structure was inherited from a POC, never redesigned → Solution: Re-architect compartments around production access boundaries
Network security groups get one broad rule instead of several narrow ones → Solution: Write NSG rules per service, not per convenience
Database roles mirror OS roles instead of business function → Solution: Design DB roles around what a job actually needs to do
Dynamic Groups are underused, so scripts fall back to personal logins → Solution: Build automation identity into the architecture from day one
Zero Trust is treated as a firewall concept, not an identity concept → Solution: Verify every request — user, service, or script — every time
Access reviews happen only when an auditor asks for one → Solution: Make access recertification a scheduled operational task
IAM and Database Vault are managed by two different teams that don't talk → Solution: Bring cloud IAM and in-database privilege under one access narrative
"Temporary" access grants outlive the reason they were created → Solution: Expire access by default; renew deliberately, not by accident

This gap is why access reviews so often turn into surprises.

As you can see, this is less about any single misconfiguration and more about access decisions made in isolation, by different teams, at different times — with no single owner tracking the whole chain.

3. Working Upwards: From Understanding to Solution

Zero Trust for databases isn't a product — it's a discipline of never assuming trust just because a request came from inside the tenancy. Here's what that looks like in OCI, in plain language.

What least-privilege access actually looks like in OCI:

IAM Policies — Scoped to a specific compartment and group, granting only the verbs a role needs (e.g. use, not manage), never tenancy-wide.
Compartments — Structured as access boundaries first, cost boundaries second — Prod, Non-Prod, and DR isolated from each other by design.
Network Security Groups — Attached to the database's VNIC directly, allowing traffic only from named application NSGs, not open CIDR ranges.
Dynamic Groups & Instance Principals — Automation (including TAB) authenticates as itself, not as a person, with policy scoped to exactly its task.
OCI Vault (Secrets) — Database credentials stored and rotated centrally, never hardcoded in scripts or shared in chat.
Database Vault (in-DB) — Even a valid, authenticated session is restricted by realm and command rule inside the database itself.

Zero Trust means every layer — IAM, network, automation identity, and the database itself — verifies independently. None of them trust the others to have already checked.

A quick look under the hood (for the technical conversation with your cloud team — not something a CTO needs to write, just recognize):

An OCI IAM policy scoped to one compartment, one group, one verb — not tenancy-wide:

Allow group DBA-Prod-Readonly to use database-family in compartment Prod-DB

A Dynamic Group so automation authenticates as itself, not as a person:

Allow dynamic-group TAB-Automation to manage db-nodes in compartment Prod-DB
  where request.principal.tag.role='patching-agent'

That's the whole idea — the automation gets exactly one job's worth of access, and nothing about a human's session is involved.

The point for a CTO isn't the syntax — it's that every one of these grants can be scoped down to a compartment, a group, and a verb. The default OCI experience nudges toward broad grants because they're faster to write. Zero Trust is choosing the narrower grant every time, even when it's slower.

Technical Issues:

Broad IAM policies written for convenience, never narrowed post-go-live — Solution: Audit and re-scope every policy to compartment + verb level
NSGs allow traffic from entire subnets instead of specific services — Solution: Rewrite rules to source from named application NSGs only
Automation scripts authenticate with personal credentials — Solution: Migrate every script to Dynamic Groups and Instance Principals
Database roles don't map to least-privilege job functions — Solution: Redesign roles around task, not convenience or legacy habit

Non-Technical Issues:

Cloud team and DBA team manage access in separate silos — Solution: Create one access map spanning IAM, network, and in-database privilege
Access reviews are reactive, triggered only by audits — Solution: Schedule recertification as a standing operational cadence
"Temporary" access has no expiry or ownership — Solution: Default every grant to expire; require deliberate renewal
No one can produce a single answer to "who can reach this database" — Solution: Maintain one living access inventory, reviewed and owned

Zero Trust isn't about distrusting your team — it's about never letting distance from the data become distance from accountability.

How Nabhaas helps you

If you've made it this far, you already sense there's a better way — in fact, you have a way ahead.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

Series Week 26/52 — TDE, Database Vault & Data Masking: Closing the Compliance Loop

Abhilash Kumar | Oracle ACE ♠ — Wed, 22 Jul 2026 07:10:18 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

This article focuses on database security controls, and how I help you tell them apart before an auditor makes you do it the hard way.

Ground Zero: Where Challenges Start
Underneath Ground Zero: Finding the Real Problem
Working Upwards: From Understanding to Solution

Database Security

Every database has locks. Not every lock does the same job.

Encrypt it, mask it, redact it, restrict it — pick the wrong one, and the audit finds out before you do.

Most CTOs assume "we've secured the data" is a single checkbox. It isn't. Encryption, Data Masking, Redaction, and Database Vault solve four different problems, for four different audiences, at four different points in the data's life. Confusing them is the single most common finding I see walk into an IT audit unprepared.

1. Ground Zero: Where Challenges Start

Let's start with a plain canvas and understand our ground zero — the issues here are mostly a language and ownership problem before they are a technical one.

Weekend-audit-panic causes & corresponding solutions:

- "We're encrypted, so we're compliant" -> Solution: Encryption protects data at rest, not who sees it live

- Dev/Test teams see live PII in cloned environments -> Solution: Mask data before it ever lands in Non-Prod

- App reports show full card/Aadhaar numbers to support staff -> Solution: Redact on display, not just on disk

- DBAs have unrestricted SELECT on sensitive schemas -> Solution: Use Database Vault to separate duty, not just access
- Auditors ask "who can see this column" and nobody knows -> Solution: Map every control to a named data-protection objective

- Backup files carry the same exposure as production -> Solution: Extend TDE and masking policy to backups and exports

- One control is assumed to cover every regulatory ask -> Solution: Match RBI/IRDAI/DPDP clauses to the specific control that satisfies them

- Security bought as a product, not designed as a layer set -> Solution: Build a layered model — encrypt, restrict, mask, redact

- No one owns "data protection" end-to-end -> Solution: Assign a single accountable owner across DBA, App, and InfoSec

No one owns "data protection" end-to-end → Solution: Assign a single accountable owner across DBA, App, and InfoSec

This is where most compliance findings begin.

As you can see, we haven't even touched the technical configuration yet — there's a lot of clarity to build first.

Knowing which control answers which audit question is often tougher than deploying the control itself… period.

2. Underneath Ground Zero: Finding the Real Problem

Once you've understood your Ground Zero problems, you need to move to why these four controls keep getting collapsed into one in the CTO's mental model — and in the audit response.

Why "we're secure" often doesn't survive an audit:

- Encryption (TDE) is treated as a full data-protection plan -> Solution: Position TDE correctly — it only stops disk/media theft

- Masking and Redaction are used interchangeably in RFPs -> Solution: Separate them by where and when they apply, not just intent

- Database Vault is seen as "just another access control" -> Solution: Frame it as separation-of-duty, even from privileged DBAs

- No inventory of sensitive columns exists -> Solution: Classify data first — PII, PCI, PHI, financial — before choosing controls

- Non-Prod refresh cycles skip masking for "speed" -> Solution: Bake masking into the refresh pipeline, not an afterthought

- Redaction is applied at the app layer inconsistently -> Solution: Push redaction policy into the database so every consumer inherits it

- Compliance teams write policy DBAs were never shown -> Solution: Translate RBI/IRDAI/DPDP language into concrete DB controls

- Vendors sell "encryption" as a compliance silver bullet -> Solution: Ask "which specific audit clause does this satisfy" before buying

- No mapping between control and control owner -> Solution: Assign named ownership per control, tested per audit cycle

This gap is why the same audit finding repeats every year.

As you can see, this is a mix of classification gaps, ownership gaps, and vocabulary gaps — all of which look identical from the outside until an auditor asks a pointed question.

Addressing this confusion is critical before any control rollout can succeed. Every organization's data estate will have its own sensitive-data footprint, but this root confusion cannot be ignored.

3. Working Upwards: From Understanding to Solution

Segregate the four controls clearly — listed below is what every CTO needs to internalize and hand down to their teams, in plain language.

How four controls close one compliance loop:

TDE Encryption — Encrypts data at rest (tablespace/column level). Stops theft of disk, backup, or export files. Does NOT stop an authorized user querying live data.
Data Masking — Permanently or dynamically transforms data for Non-Prod or non-privileged use. Stops Dev/Test/BI/Support teams seeing real PII in cloned or shared environments.
Redaction — Obscures part of a live value at display/query time; the data underneath stays intact. Stops over-exposure on screens/reports (e.g. showing only the last 4 digits of a card).
Database Vault — Enforces separation of duty via command and realm restrictions. Stops even privileged DBAs and SYSDBA from reading sensitive application data.

Encryption protects the disk. Masking protects Non-Prod. Redaction protects the screen. Vault protects from privilege itself. An audit checks all four separately.

A quick look under the hood (for the technical conversation with your DBA — not something a CTO needs to write, just recognize):

TDE — encrypting a tablespace so the files on disk are unreadable without the key:

CREATE TABLESPACE app_data
  DATAFILE 'app_data01.dbf' SIZE 500M
  ENCRYPTION USING 'AES256' ENCRYPT;

--- But this is default in OCI if you are using Oracle Managed Keys

Redaction — masking a live column on the fly, without touching the underlying data:

BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema   => 'APP',
    object_name     => 'CUSTOMERS',
    column_name     => 'CARD_NUMBER',
    policy_name     => 'REDACT_CARD',
    function_type   => DBMS_REDACT.PARTIAL,
    function_parameters => '9,1,4,V,4,4',
    expression      => '1=1'
  );
END;

That one call is why a support agent can see "XXXX-XXXX-XXXX-4321" while the actual stored value never changes — the redaction happens purely at query time.

The point for a CTO isn't the syntax — it's that TDE is set once at the tablespace/column level, while Redaction is a policy your DBA can apply, adjust, or remove per column without any application change. Two different levers, two different audit conversations.

Technical Issues:

Sensitive columns not classified or tagged — Solution: Run a data classification pass before choosing any control
TDE assumed to cover application-layer exposure — Solution: Layer masking and redaction on top, don't stop at disk encryption
Masking policies inconsistent across refresh cycles — Solution: Automate masking as part of every Non-Prod refresh, no exceptions
Redaction configured only in the application, not the database — Solution: Centralize redaction policy at the DB layer so every client inherits it

Non-Technical Issues:

Compliance and DBA teams speak different vocabularies for the same requirement — Solution: Build a shared control-to-clause mapping document (RBI/IRDAI/DPDP -> specific DB control)
No single owner accountable for the full compliance loop — Solution: Name one owner who answers for encryption, masking, redaction, and Vault together
Controls procured reactively, post-incident or pre-audit — Solution: Build the control roadmap proactively, ahead of the audit calendar
Auditors get inconsistent answers from different teams — Solution: Rehearse the audit narrative internally before the real one lands

"We're secure" repeated without evidence — Solution: Maintain evidence artifacts per control, ready to produce on request

Closing the compliance loop isn't one control done well — it's four controls, each answering a different question, working together.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

Series Week 25/52 - API Logging - The Infosec headache of maintaining the logs - The Oracle solution

Abhilash Kumar | Oracle ACE ♠ — Sat, 11 Jul 2026 14:27:29 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

This week I'm blogging about a logging headache , a seemingly trivial topic but a data management nightmare. This blog is a about a CTO understanding a data management issue and ways to solve it.

For DBA & Technical Architects I have blogged about this earlier for 23ai , the same applies to 26ai as well. ( Blog below )

Abhilash Kumar | Oracle ACE ♠ for Nabhaas Cloud Consulting

May 5 '25

23ai - Series Part 1 - CLOB to JSON Migration Essentials

#oracle #sql #json #oci

13 min read

In a high-velocity digital ecosystem, managing the architectural balance between deep corporate visibility and system predictability is a constant tightrope walk. Your CISO and InfoSec teams rightfully require a "digital flight recorder" an un-omitted ledger capturing the precise request and response headers, tokens, and payloads across your entire application ecosystem to adhere to rigorous SOC2, PCI-DSS, or RBI/IRDAI mandates. However, when an application scales to millions of transactions per day, treating these highly structured, deeply nested API payloads as generic text inputs introduces a severe system-level performance tax.

Let me take explain this in 5 points

NOTE : We are only taking about the means of logging , what intelligence comes out of logging is a whole different subject

- The Digital Flight Recorder: It is the automated, real-time capture of the exact data payloads (the headers, metadata, and body) traveling between your applications, third-party services, and users.

- The "Who, What, and When" Audit Trail: It serves as a historical ledger that logs precisely which authenticated client made a request, what resource they accessed, when it happened, and how your system responded.

- The Foundation of Observability: Unlike standard system uptime metrics, API logging gives developers micro-level visibility, letting them trace data flows across distributed architectures to find the exact root cause of an application failure in seconds.

- The First Line of InfoSec Defense: It provides the critical telemetry required to detect security anomalies, such as credential stuffing attacks, unauthorized data exfiltration, or malicious API tampering.

- The Compliance Anchor: It acts as the immutable evidence required to pass stringent corporate and regulatory security audits (such as SOC2, ISO 27001, and PCI-DSS) by proving data privacy and access rules are being enforced.

1. Ground Zero: Where Challenges Start - The Storage Strain

At the application layer, developers look for the path of least resistance. API payloads typically rich, deeply nested JSON objects are dumped straight into relational schemas as unstructured CLOB (Character Large Object) text blocks. There was simply no other choice to hold it inside the databases.

You may ask why not varchar2 , the answer is obvious that it has a hard limit of 4000 bytes

Some example of these problems are here

[Legacy Text Architecture]
Incoming API JSON Payload  -->  Character String Conversion  -->  Opaque CLOB Storage Block

The Operational Reality: Under exhaustive, multi-threaded stress tests, dumping high volume API strings into character-based objects instantly creates an enterprise bottleneck. Because a standard CLOB stores data out of line and treats it as an un-indexed text block, the database engine spends massive amounts of CPU cycles on characterset conversions and memory marshaling. To InfoSec, it is a critical security audit trail; to your production database, it is an opaque wall of character text that slows down critical execution paths during peak business hours.

2. Underneath Ground Zero:

Peeking below the database surface at the OS, storage, and I/O tiers reveals why legacy CLOB-based logging inevitably degrades cluster predictability:

The Temp Segment Engine Strain: Continuous, high-concurrency write and read stress tests on CLOB columns heavily punish internal database temp segments and local LOB caches, starving core transactional tables of memory resources.
The Blind Query Bottleneck: To the database engine, a CLOB text column has zero structural semantic awareness. If an incident response team needs to parse a specific user_id or scan for an anomalous API error code inside a 5MB text payload, the engine is forced to perform brutal full-table scans or evaluate heavy regular expression filters across millions of rows, crippling system I/O.
The Tablespace Swelling: Raw character data lacks native structural compaction. Log tablespaces balloon rapidly, driving up OCI storage spends, expanding backup windows, and complicating your overall Disaster Recovery (DR) data synchronization SLAs.

So applications have typically used Oracle 19c CLOB as a defacto solution as there is no other alternative

3. Working Upwards:

Enter the JSON datatype : THE solution for API logging

The official Oracle Documentation for JSON Data Type is here

docs.oracle.com

Peeking below the database surface at the OS * storage costs tiers reveals why legacy character formats create a ticking technical debt time bomb for API log retention. When handling millions of high-velocity JSON payloads, developers usually rely on two native datatypes, both of which introduce severe infrastructure limitations under stress:

- The Hard Ceiling of VARCHAR2: While VARCHAR2 provides fast, in-line storage, it maxes out at a hard limit of 4,000 bytes (or 32,767 bytes with extended data types enabled). Modern API payloads—stuffed with verbose HTTP headers, nested object arrays, and security JWT tokens—frequently burst past this limit. If a single peak transaction payload hits 33KB, your logging engine throws an unhandled database exception (ORA-01461), silently crashing the logging pipeline or, worse, breaking the primary application runtime.

- The CLOB as a White Elephant: To bypass the size limits of VARCHAR2, teams blindly migrate log tables to CLOB (Character Large Object). On paper, it looks like a safe catch-all because it can hold gigabytes of text. In reality, it becomes an incredibly expensive "white elephant"—high maintenance, resource-intensive, and fundamentally unsuited for high-throughput microservices.

----------------------------------------------------------------------------------------------------
[CLOB Storage]
Table Block (In-Line Data) -------> [ Pointer Only ]
                                           |
                                           v
SecureFiles LOB Segment ----------> [ Out-of-Line CLOB Text Payload (Massive I/O Tax) ]

[varchar2] - Max Limit is 4000 Characters

----------------------------------------------------------------------------------------------------

Because CLOB data is typically stored out-of-line (away from the main table block), every single log entry forces the database to perform a separate, high-overhead I/O operation to write to the LOB segment. Under intensive, multi-threaded stress testing, this continuous swapping heavily punishes internal database temp segments and local memory caches, starving core transactional tables of memory resources.

Furthermore, because the engine treats the CLOB as an opaque, un-indexed text block, any attempt by InfoSec to scan for a specific compromised user_id inside a log requires the database to pull millions of these massive character streams into memory sequentially. You end up burning high-cost enterprise cloud storage and crushing your IOPS budget on an un-queryable, text-bloated repository.

So in short Applications will need to move away from CLOB to JSON , Application vendors need to invest technical knowledge in implementing this need of the hour requirements.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

OracleBootCamp : Chennai | OCI Linux & OCI Databases

Abhilash Kumar | Oracle ACE ♠ — Fri, 10 Jul 2026 12:57:38 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

Oracle Boot Camp: 8-Aug-2026

Welcome to the OCI Boot Camp, a premier, hands-on training program designed to bridge the gap between traditional enterprise systems and next-generation cloud architecture. Engineered for database administrators, system architects, and cloud engineers, this intensive boot camp provides an immersive technical deep-dive into deployment, lifecycle management, and infrastructure scaling. As organizations rapidly shift their mission-critical data assets to the cloud, mastering the specialized cloud environment becomes paramount. This program delivers the exact blueprint needed to build highly resilient, performant, and secure enterprise environments using Oracle’s second-generation cloud framework.

Session 1: OCI Linux & System Utilities

Oracle Linux on OCI is more than just an operating system—it is a highly optimized environment engineered for maximum performance, security, and tight integration with Oracle software. This segment focuses on leveraging purpose-built OS utilities and automation tools designed to streamline cloud operations, optimize kernel performance, and maintain zero-downtime environments.

Speaker : Abhilash Kumar Bhattaram [ Database & Cloud Architect | Founder - Nabhaas Cloud Consulting ]

Session 2: Understanding the OCI Class of Databases
OCI offers a comprehensive, tier-based suite of database cloud services tailored to different workloads, budgets, and operational requirements. This module breaks down the distinct architectural classes of Oracle databases in the cloud, guiding you through how to choose, deploy, and scale the right database solution for your enterprise needs—ranging from co-managed virtual machines to fully automated, self-driving database services.

Speaker : Abhilash Kumar Bhattaram [ Database & Cloud Architect | Founder - Nabhaas Cloud Consulting ]

Session 3: OCI - From Oracle MAA to Full Stack DR : AI Insights & Live Demo on OCI

Unlocking the full potential of Oracle MAA and how Full STack DR helps organizations

Speaker : Suraj Ramesh [ Lead Principal Product Manager - Oracle ]

Series Week 24/52 — Cloud Migration: Finding Your Path in the Database Migration Minefield

Abhilash Kumar | Oracle ACE ♠ — Thu, 09 Jul 2026 06:48:20 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

The Post-Migration Mirage

For many Chief Technology Officers (CTOs), the successful cutover of a core database to the cloud feels like the ultimate victory lap. The data has landed, the connection strings are updated, and initial performance metrics look stellar.
But there is a dangerous mirage that follows a cloud database migration: Hidden Downtime.

Unlike an abrupt database crash, hidden downtime is a slow-burn operational decay. It happens when day-to-day transactions process smoothly in production, but the underlying database ecosystem—specifically the disaster recovery (DR) standby instances, secondary cross-region sites, and replication pipelines—quietly falls out of sync. When a true disruption occurs and you try to failover or scale, the database tier collapses.
To ensure true, 24/7 predictability, forward-thinking CTOs look beyond the immediate "Go-Live" date. The ultimate challenge is navigating the dense maze of cloud onboarding options to find the exact database migration method that fits your specific application topology.

Ground Zero: The Database Configuration Drift

The root cause of post-migration database downtime begins long before cutover day, it starts with how the database is moved and how its configuration is maintained. Going to the cloud offers various technical pathways, but the overarching challenge is finding what fits your unique architecture. The initial migration must establish perfect baseline parity, but standard database operations and hasty migration choices quickly introduce fatal configuration drift.
To manage this drift effectively, organizations must introduce rigorous baseline metrics before, during, and after the migration process:

- Benchmarking Versions: Ensuring that source and target database patch levels, Timezone (TZ) files, and Release Updates (RUs) match exactly. Mismatched database versions between primary cloud instances and standby homes create silent dictionary incompatibilities that destroy failover viability.

- Benchmarking Downtime: Calculating the exact Maximum Tolerable Downtime (MTD) and Service Disruption windows during the migration planning phase. This dictates whether you can afford an offline dump or if your business dependencies mandate an active, zero-downtime replication strategy.

- Continuous Mock Drills: Simulating full database failovers and cutovers in non-production cloud environments. Without automated, recurring mock drills, hidden issues like un-synchronized Transparent Data Encryption (TDE) wallets or missing parameter definitions remain completely invisible until a production outage strikes.

Underneath Ground Zero: Analyzing the Impact

When we unearth the deeper architectural problems underneath Ground Zero, we find structural blindspots that completely undermine a database migration’s ROI:

1. The Database Maintenance Silo
Operational Reality: DBAs patch the primary database using automated cloud tooling but delay patching the standby database home to avoid disrupting active synchronization streams.

2. Post-Cutover Operational Risk: Upon failover, your application connects to a database running a mismatched PSU/RU version. This triggers immediate dictionary mismatches, unexpected query execution plan changes, or TDE wallet decryption failures—rendering the database instantly inaccessible to the application.

3. Identity and Access Management (IAM) Disconnect
Operational Reality: Cloud IAM policies are tightly scoped to specific instance IDs or Dynamic Groups in the primary database compartment. The cross-region database equivalents are frequently left out of the active policy definitions.
Post-Cutover Operational Risk: Handling the new landscape means ensuring continuous cloud permissions. Post-cutover, if permissions are asymmetric, the active database instances are starved of resources. They cannot read automated backup configurations from Object Storage or fetch critical encryption keys from the Vault, breaking recovery SLAs.

4. Ambient Telemetry Failure Operational Reality: Database monitoring agents are bound to regional aggregators. Because the standby database sits quietly in a passive state, monitoring configurations are often left unverified for production-scale log volume.

5. Post-Cutover Operational Risk: Right when you need telemetry the most (during a crisis), your database dashboards go completely dark. Engineering teams cannot debug post-cutover stability issues or efficiently handle the new infrastructure landscape because no performance metrics are being collected.

Working Upwards: The Managed Service Remedy

To bridge this operational chasm, predictable CTOs do not rely on generic, manual runbooks that treat migration as a point-in-time infrastructure task. Instead, they shift to a modern, automated managed service model designed to systematically solve database onboarding complexities and handle the operational realities of the post-cutover landscape.

*Automated Migration Pipeline Validation : * Instead of cross-checking parameters by hand, use automated tools to continually audit version alignment, timezone files, and initialization parameters (PROCESSES, SESSIONS) between the source, target, and standby environments throughout the migration lifecycle. This catches silent, breaking variations before traffic is cut over.

Dynamic Replication & Catch-Up Automation :
During a complex migration, primary systems continue to drift as active production data accumulates. A mature managed service uses intelligent orchestration to continuously monitor data lag across replication streams (like OCI GoldenGate or Data Guard), automatically applying catch-up protocols to ensure zero data loss during the final switchover window.

Coordinated Lifecycle and Multi-Version Patching :
Treat the data tier as a unified, multi-environment fabric. Managed orchestration ensures that when a target cloud environment is spun up, its accompanying standby and DR instances are instantly provisioned, patched, and matched to the primary database's Release Update (RU) level, eliminating version silos during cutover execution.

The Takeaway: Navigating the OCI Database Migration Maze

A successful cloud database migration isn't a single event; it is an ongoing state of operational alignment. Because going to the cloud offers various technical pathways, the ultimate challenge is finding the exact method that fits your business constraints.
Oracle Cloud Infrastructure (OCI) supports an array of robust database migration methods, each serving a highly specific purpose:

- OCI GoldenGate Replication: For continuous, active-active or active-passive real-time data integration, enabling near-zero downtime database migrations for mission-critical workloads.

OCI Data Migration Service (DMS): For a fully managed, guided, and automated database move that simplifies online and offline migration phases.

- Logical Dump Exports (Data Pump): The ideal choice for schema-level restructuring, selective data migrations, metadata filtering, and multi-version database upgrades where a clean slate is required.
Logical Application & Database Cutover: Orchestrating precise microservice traffic switches alongside data synchronicity at the edge using DNS and load balancing adjustments.

The Reality Check

There is absolutely no "one-size-fits-all" database migration template. Every application carries its own distinct database dependencies—from connection pool behavior and legacy PL/SQL packages to strict latency sensitivities and compliance profiles. The challenge isn't just moving the data; it is selecting the right migration vehicle, benchmarking version drifts, tracking downtime windows, and running mock drills so that hidden downtime isn't baked into your cloud topology from day one.
By matching your specific application profile with the right OCI database migration technical path, and anchoring it with a managed service approach that enforces continuous, automated parity, you eliminate the hidden blindspots completely.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

Series Week 23/52 - OCI DR Environments: The Managed Service Blindspot

Abhilash Kumar | Oracle ACE ♠ — Sat, 20 Jun 2026 07:51:31 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

DR : The grey zone

Many Chief Technology Officers (CTOs) feel a false sense of security once they migrate to the cloud and turn on managed Disaster Recovery (DR) services.

"With a few clicks, your entire stack is replicated across regions."

But there is a hidden blindspot in cloud-managed DR. While Oracle Cloud Infrastructure (OCI) Full Stack DR does an incredible job of orchestrating infrastructure failover, it creates a massive operational gap for application deployment. If your day-to-day deployment pipelines only target production, your DR environment quietly becomes a time capsule—outdated, unpatched, and bound to fail when you need it most.

Let's look at how predictable CTOs bridge this gap using a structured approach.

Ground Zero

Let us first look at some common things that create the DC<->DR gap

Database Patching & PSU Alignment: While OCI Data Guard replicates data perfectly, it does not automatically apply Database Bundle Patches (BPs) or Patch Set Updates (PSUs) to the standby database home. Oracle Data Guard provides a Standby first approach , so patching begins with the standby.

Continuous Application Patching & Versioning: Pipelines are rarely configured to push application updates to the standby environment, leaving the DR application layer outdated.

Environment Variable & Config Sync: Missing or outdated environment secrets, database connection pool sizes, third-party API keys, and feature flags that exist in production but were never copied to the standby site.

Operating System & Kernel Parity: Out-of-sync OS patches, security fixes, and missing dependencies (e.g., specific Python libraries or system packages) on standby compute instances.

Ingress & Egress Network Rules (NSGs/Security Lists): Forgetting to mirror firewall changes. When a failover happens, traffic is blocked because the DR site's Network Security Groups lack the updated ports or IP whitelists.

Database Parameters & Keystore Sync: Missing initialization parameter updates (e.g., processes, sessions) or un-synchronized TDE (Transparent Data Encryption) wallets and keystores on the standby database, preventing it from opening securely or handling production loads.

IAM Policies & Dynamic Groups: Missing permissions for the DR instances to access required OCI resources (like Object Storage or Secret Management) in the secondary region.

DNS & TLS/SSL Certificate Management: Expired or missing SSL certificates on the standby load balancers, causing secure traffic to fail immediately upon DNS switchover.

Third-Party Webhooks & Integrations: Failure to register the DR IP addresses/URLs with external vendors (like payment gateways or auth providers), resulting in broken integrations post-failover.

Log Forwarding & Monitoring Agents: Observability tools (e.g., Datadog, Splunk, or OCI Logging) are frequently unconfigured on the DR side, leaving operations completely blind right after a failover.

Underneath Ground Zero : unearthing more DR problems

The Database Maintenance Silo (Database Patching & Parameters)

Operational Reality: Database Administrators (DBAs) patch the primary database using automated OCI tooling but skip the standby home to avoid breaking Data Guard replication streams.
The Blast Radius: Upon failover, the application connects to a database running a different PSU/RU version. This triggers immediate dictionary mismatches, unexpected query execution plan changes, or TDE wallet decryption failures—rendering the database inaccessible to the app.

The Production-Only Pipeline Bias (Application Patching & Versions)

Operational Reality: Standard CI/CD workflows are engineered for a linear paths (Dev >>> QA >>> Prod). The DR region is treated as an infrastructure target rather than an application deployment target.
The Blast Radius: The DR site remains a time capsule. If you failover, you are rolling back your software version by months, breaking backward compatibility with current database schemas.

Static Configuration Amnesia (Environment Variables & Config Sync)

Operational Reality: Configuration changes, feature flags, and secrets are often injected manually during hotfixes or live troubleshooting in production, bypassing the repository.
The Blast Radius: The application boots up at the DR site but crashes instantly because it is pointing to expired API keys, old token endpoints, or inadequate database connection pool sizes designed for QA-level loads.

The "Immutable Infrastructure" Paradox (OS & Kernel Parity)

Operational Reality: Primary compute instances get live OS patches via OCI Ksplice, but standby instances—often turned off or pilot-lighted to save costs—miss these dynamic runtime updates.
The Blast Radius: When Full Stack DR starts the standby instances, they boot up with vulnerable kernels, missing shared libraries, or mismatched security dependencies, causing binaries to fail on execution.

Asymmetric Network Evolution (Security Lists, NSGs, & Whitelists)

Operational Reality: Network security teams open ports or whitelist client IPs reactively on the primary Virtual Cloud Network (VCN) during new integrations without replicating the rules to the DR VCN.
The Blast Radius: The infrastructure fails over perfectly, but application traffic drops at the edge. External APIs cannot hit your DR endpoints, and internal microservices cannot communicate across subnets.

Identity & Access Management Disconnect (IAM Policies & Dynamic Groups)

Operational Reality: IAM policies are tightly scoped to instance IDs or Dynamic Groups in the primary region's compartment. The cross-region DR equivalents are left out of the policy definitions.
The Blast Radius: Post-failover, the active application instances are starved of cloud permissions. They cannot read configuration files from OCI Object Storage, fetch keys from the OCI Vault, or write application logs.

The Edge Security Bottleneck (DNS & TLS/SSL Certificates)

Operational Reality: SSL/TLS certificates are renewed via automated tools (like Let's Encrypt) tied to the active, live domain routing to the primary load balancer. Standby balancers don't receive the active challenge responses.
The Blast Radius: When DNS switches traffic to the DR site, users are greeted with massive browser security warnings ("Your connection is not private"), breaking automated API clients and dropping user traffic.

Third-Party Siloed Handshakes (Webhooks & Vendor Integrations)

Operational Reality: External ecosystems (payment processors, SMS gateways, ERP connectors) require explicit IP/domain whitelisting for security. Teams forget that a DR site uses a completely different public IP CIDR block or secondary URL.
The Blast Radius: The core application works, but transactions fail. Payment gateways reject checkout requests because the traffic originates from an unapproved DR IP address.

Post-Failover Flying Blind (Log Forwarding & Monitoring)

Operational Reality: Monitoring agents (Datadog, Splunk, OCI Logging) are bound to hostname configurations or regional aggregators. Because the DR site is quiet, these agents are either disabled or unconfigured to handle production-scale log volume.
The Blast Radius: Right when you need telemetry the most (during a crisis), your dashboards go completely dark. Engineering teams cannot debug the post-failover stability issues because no logs or metrics are being collected.

Working Upwards: From Understanding to Solutioning the DR

To bridge the operational chasm discovered Underneath Ground Zero, predictable CTOs don’t just write more manual runbooks. They architect a unified framework that aligns OCI's native infrastructure capabilities with modern, continuous application delivery.
Here is how you address each specific blindspot by working upwards into an automated, dual-region ecosystem:

Unified Lifecycle Management (Database Patching & Parameters)

The Solution: Use automated OCI CLI workflows to orchestrate rolling out of Database Bundle Patches simultaneously to both Primary and Standby database homes. Ensure database system parameter changes etc. are part of your change management system. Data is replciated in Standby patches needs to be manually applied.

Dual-Target CI/CD Pipelines (Application Patching & Versions)

The Solution: Redesign your deployment pipelines to treat the DR region as an active deployment target. When code hits production, the binaries and container images are automatically pushed to both regions. The standby environment receives the updated application packages without scaling up compute resources, keeping versions perfectly mirrored.

Externalized & Synced State (Environment Variables & Config Sync)

The Solution: Move all configuration parameters and secrets out of local environments and into OCI Vault or centralized configuration servers. Replicate these configurations cross-region automatically so that changes made to production pool sizes or feature flags are instantly available to the DR standby stack.

Automated Golden Image Pipelines (OS & Kernel Parity)

The Solution: Transition from mutable compute patching to an automated Image Lifecycle Pipeline. Build a single, hardened, patched Custom Image or Container base weekly. Deploy this single artifact to both primary and standby target compartments, guaranteeing bite-for-bite OS and dependency parity.

Infrastructure as Code Symmetry (Network Security Lists & NSGs)

The Solution: Mandate that all VCN, NSG, and Security List modifications occur via Terraform or OpenTofu modules. Use variables to apply identical structural rules to both the primary and standby region VCNs during a single terraform apply.

Cross-Regional IAM Prototyping (IAM Policies & Dynamic Groups)

The Solution: Write OCI IAM policies using dynamic group syntax that encompasses instances in both regional compartments. Ensure that policy grants read/write access to resources (like Object Storage buckets and Key Vaults) in both regions, allowing instances to activate with full operational permissions out-of-the-box.

Centralized Edge Automation (DNS & TLS/SSL Certificates)

The Solution: Implement multi-region certificate managers or automated OCI Certificates workflows that deploy and auto-renew SSL certificates to both primary and standby load balancers simultaneously, ensuring zero certificate errors on edge routing switchover.

Automated Vendor Registry Sync (Third-Party Webhooks & Integrations)

The Solution: Maintain pre-registered secondary public IP blocks/URLs with critical external vendors, or use OCI Flexible Load Balancers with reserved IPs that are pre-whitelisted within your external vendor ecosystems.

Ambient Telemetry & Mock Log Forwarding (Log Forwarding & Monitoring)

The Solution: Keep monitoring agents permanently active on standby nodes, configured to route telemetry to a unified cross-region dashboard. Run synthetic health check traffic through the standby nodes continuously to verify that monitoring and logging pipelines are alive and functional before a disaster happens.

The Tradeoff: OCI Full Stack DR vs. Manual Deployments

When deciding how to manage this synchronization, organizations must evaluate where they sit on the spectrum of automation. Relying solely on manual processes or trying to build an entirely bespoke DR orchestration framework from scratch presents severe trade-offs.
Operational Dimension OCI Full Stack DR (Managed Infrastructure Automation) Manual / Bespoke Deployments (The Infrastructure Layer)

Recovery Time Objective (RTO) Minutes. Automates volume replication, database switchovers, and compute provisioning natively. Hours to Days. Prone to human error, typos, and sequence mistakes during a crisis.
Complexity & Upkeep Low. Managed service maintained by Oracle; automatically updates alongside OCI platform changes. High. Requires maintaining massive, fragile internal scripts and runbooks that quickly go out of date.
Application Layer Awareness Infrastructure Only. Doesn't inherently know if your custom application v2.4 matches your configuration variables. Customizable but Brittle. Can be scripted to manage apps, but fails when underlying infra changes dynamically.

What Works Best for Your Organisation?
The ideal operational architecture is not an "either/or" choice—it is a hybrid model that maximizes the strengths of both managed infrastructure and automated application pipelines.

+--------------------------------------------------------------------------------+
|                  Tradeoff between Full Stack DR and  managed DR                |
+--------------------------------------------------------------------------------+
|                                                                                |
|   +------------------------------------+  +--------------------------------+   |
|   |        OCI FULL STACK DR           |  |      DUAL CI/CD AUTOMATION     |   |
|   +------------------------------------+  +--------------------------------+   |
|   | * Database Data Guard Switchover   |  | * Continuous App Version Parity|   |
|   | * Block/Boot Volume Replication    |  | * Automated OS Patching        |   |
|   | * Compute Provisioning & Scaling   |  | * Config & Secret sync         |   |
|   +------------------------------------+  +--------------------------------+   |
|                     |                                     |                    |
|                     +-----------------+-------------------+                    |
|                                       v                                        |
|                     Result: Zero-Drift, RTO-Optimized DR                       |
+--------------------------------------------------------------------------------+

A hybrid model also works , this requires a good control on your IT Infrastructure

For Enterprise & Highly Regulated Stacks: The best approach is to let OCI Full Stack DR handle the infrastructure muscle (compute states, storage attachment, network routing), while configuring your CI/CD pipelines to dual-deploy application artifacts and configurations to both sites. This eliminates the "Managed Service Blindspot" entirely.
For Small Scale / Monolithic Stacks: If dual-region CI/CD pipelines introduce too much operational overhead for a small team, utilize OCI Full Stack DR alongside automated user-scripts (run via OCI Compute Instance Configurations) to pull the latest production configurations dynamically from an OCI Object Storage bucket upon initialization.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
download here

AUTOUPG_HOME - A smart way to manage Oracle GI & RU On Prem patches across versions for multiple database environments

Abhilash Kumar | Oracle ACE ♠ — Fri, 19 Jun 2026 14:21:47 +0000

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

Managing multiple Oracle patches

The purpose of this blog is to understand how patches are being managed even before patching.

More ofthen tha not you have identified the environment you want to patch , but when you have atleast 50+ databases to deal with do you have a way to manage patches , espeically when some databases still need to work on a slightly older releases due to application dependencies

It is difficult to remeber with hunderds of other things one has to remember , A typical problems in understanding patching nomenclature is below

p6880880_190000_Linux-ARM-64.zip --> This latest OPatch 

p38906621_190000_Linux-ARM-64.zip --> This is OJVM for 19.31

It's not possible to understand what the patch is for just by looking at the patch file name.

If you want to get started on autoupgrade , the below blog is a good read

Abhilash Kumar | Oracle ACE ♠ for Nabhaas Cloud Consulting

Jun 17

autougpgrade.jar - Provision & switch Oracle Homes ( Hands on lab scenario to move OH from 19.19 to 19.31 and rollback to 19.19 )

#oracle #oci #patch #rollback

32 min read

Reference : Official Doc on autoupgrade
https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/about-oracle-database-autoupgrade.html

Enter AUTOUPG_HOME

AUTOUPG_HOME is a logical folder structure I jave created for my own efficiency to manage multiple patches and environments.

I have a base Autoupgrade Home /u01/autoupg-home with the following sub folders

autoupg-config - Contains all my config files for patching , upgrade , downloads and any config file I intend to use autoupgrade.jar for
autoupg-keystore - Contains the keystore for using autoupgrade.jar , typically you set it up once and forget about it.
autoupg-logs - Contains all log files generated by autoupgrade.jar
autoupg-sw - The repository for downloading patches , typically I would have sub folders under this for each GI & RU ( feel free to customize it as needed )

[oracle@oel8-lab01 ~]$ export AUTOUPG_HOME=/u01/autoupg-home
[oracle@oel8-lab01 ~]$ env | grep AUTO
AUTOUPG_HOME=/u01/autoupg-home

[oracle@oel8-lab01 ~]$ cd $AUTOUPG_HOME
drwxr-xr-x. 2 oracle oinstall      56 Jun 19 01:49 autoupg-config
drwxr-xr-x. 2 oracle oinstall      90 Jun 19 01:34 autoupg-keystore
drwxr-xr-x. 3 oracle oinstall      42 Jun 19 01:28 autoupg-logs
drwxr-xr-x. 6 oracle oinstall      70 Jun 19 01:24 autoupg-sw
-rw-r--r--. 1 oracle oinstall 7016621 Jun 19 01:20 autoupgrade.jar

A simple tree structure of AUTOUPG_HOME

[oracle@oel8-lab01 autoupg-home]$ tree
.
├── autoupg-config
│   ├── 19.31-RU-download.cfg
│   └── key-store.cfg
├── autoupg-keystore
│   ├── cwallet.sso
│   ├── cwallet.sso.lck
│   ├── ewallet.p12
│   └── ewallet.p12.lck
├── autoupg-logs
│   └── cfgtoollogs
│       └── patch
│           └── auto
│               ├── autoupgrade_patching_err.log
│               ├── autoupgrade_patching.log
│               ├── autoupgrade_patching_user.log
│               ├── config_files
│               │   └── autoupg_patching.cfg
│               ├── examiner
│               │   └── examiner2026_06_19_01_32_49.json
│               ├── lock
│               └── sql
│                   └── login.sql
├── autoupgrade.jar
├── autoupg-sw
│   ├── 19.28-RU
│   ├── 19.29-RU
│   ├── 19.30-RU
│   └── 19.31-RU
└── logs

Config Files & Download locations for Each GI/RU

I use in my lab Linux ARM64 so below is an example for downloading 19.91 RU for Linux ARM64

[oracle@oel8-lab01 autoupg-home]$ cat /u01/autoupg-home/autoupg-config/19.31-RU-download.cfg
global.global_log_dir=/u01/autoupg-home/autoupg-logs
global.keystore=/u01/autoupg-home/autoupg-keystore
install1.patch=OPATCH,OJVM,DPBP,AU,RU:19.31
install1.folder=/u01/autoupg-home/autoupg-sw/19.31-RU
install1.target_version=19
install1.platform=arm.x64

Downloading to desired folders

Now lets fire up the config file to get the dedicated patches downloaded to the desired locations.

[oracle@oel8-lab01 autoupg-home]$ java -jar ./autoupgrade.jar -config /u01/autoupg-home/autoupg-config/19.31-RU-download.cfg -patch -mode download
AutoUpgrade Patching 26.3.260401 launched with default internal options
Processing config file ...
Loading AutoUpgrade Patching keystore
AutoUpgrade Patching keystore is loaded

Connected to MOS - Searching for specified patches

----------------------------------------------------------
Downloading files to /u01/autoupg-home/autoupg-sw/19.31-RU
----------------------------------------------------------
DATABASE RELEASE UPDATE 19.31.0.0.0 (REL-APR2026)
    File: p39034528_190000_Linux-ARM-64.zip - VALIDATED

OPatch 12.2.0.1.51 for DB 19.0.0.0.0 (Apr 2026)
    File: p6880880_190000_Linux-ARM-64.zip - VALIDATED

OJVM RELEASE UPDATE 19.31.0.0.0
    File: p38906621_190000_Linux-ARM-64.zip - VALIDATED

DATAPUMP BUNDLE PATCH 19.31.0.0.0
    File: p39196236_1931000DBRU_Generic.zip - VALIDATED

autoupgrade.jar 26.3 (April 2026)
    File: autoupgrade.jar - VALIDATED
----------------------------------------------------------

Now Lets have a look at the AUTOUPG_HOME tree structure , you can see organized patches , this is pretty useful when dealing with large number of databases to have the patches available prior to downtime windows.

[oracle@oel8-lab01 autoupg-home]$ tree
.
├── autoupg-config
│   ├── 19.31-RU-download.cfg
│   └── key-store.cfg
├── autoupg-keystore
│   ├── apikey
│   ├── cwallet.sso
│   ├── cwallet.sso.lck
│   ├── ewallet.p12
│   └── ewallet.p12.lck
├── autoupg-logs
│   └── cfgtoollogs
│       └── patch
│           └── auto
│               ├── aru
│               │   ├── aru.log
│               │   ├── aru_releases.xml
│               │   ├── aru_user.log
│               │   └── ous.log
│               ├── autoupgrade_patching_err.log
│               ├── autoupgrade_patching.log
│               ├── autoupgrade_patching_user.log
│               ├── config_files
│               │   ├── autoupg_patching.cfg
│               │   └── autoupgrade.json
│               ├── examiner
│               │   ├── examiner2026_06_19_01_32_49.json
│               │   ├── examiner2026_06_19_01_57_59.json
│               │   ├── examiner2026_06_19_01_58_40.json
│               │   └── examiner2026_06_19_01_59_31.json
│               ├── lock
│               └── sql
│                   └── login.sql
├── autoupgrade.jar
├── autoupg-sw
│   ├── 19.28-RU
│   ├── 19.29-RU
│   ├── 19.30-RU
│   └── 19.31-RU
│       ├── autoupgrade.jar
│       ├── p38906621_190000_Linux-ARM-64.zip
│       ├── p39034528_190000_Linux-ARM-64.zip
│       ├── p39196236_1931000DBRU_Generic.zip
│       ├── p6880880_190000_Linux-ARM-64.zip
│       └── patches_info.json
└── logs

17 directories, 28 files
[oracle@oel8-lab01 autoupg-home]$

Patch Info

Note that each patch download has a file called patches_info.json, this a super useful feature to find description about the patches being downloaded

Use the below jq script

jq -r '
["TYPE","DESCRIPTION","PLATFORM","FILE","SHA1","SHA256"],
(.patches[] |
 [
   (if .description|test("RELEASE UPDATE") then "RU"
    elif .description|test("OPatch") then "OPATCH"
    elif .description|test("OJVM") then "OJVM"
    elif .description|test("DATAPUMP") then "DPBP"
    else "PATCH" end),
   .description,
   (.platform // "Generic"),
   .files[0].name,
   .files[0].checksum,
   .files[0]["checksum-256"]
 ]) | @tsv
' patches_info.json | column -t -s $'\t'

The tabular details of each patch that was downloaded in the corresponding folder is shown as below

TYPE    DESCRIPTION                                        PLATFORM          FILE                               SHA1                                      SHA256
RU      DATABASE RELEASE UPDATE 19.31.0.0.0 (REL-APR2026)  Linux ARM 64-bit  p39034528_190000_Linux-ARM-64.zip  35FCD029A7814A0960F1A0C700122D80CC1FA8EE  8B40287BA8B83746C527E285E039EE444F8E8E9A8391986EBF40588BBE46A92A
OPATCH  OPatch 12.2.0.1.51 for DB 19.0.0.0.0 (Apr 2026)    Linux ARM 64-bit  p6880880_190000_Linux-ARM-64.zip   4E6CB6C6F3FE33A092B2D570026596F4895E8605  D5D4692F89BE451C021F931125768BC68E5BEAF711FED7842361D65936EC19C2
RU      OJVM RELEASE UPDATE 19.31.0.0.0                    Linux ARM 64-bit  p38906621_190000_Linux-ARM-64.zip  A87F6A4B14D5851767CB5B1C7D089C1601E2F038  A4A8E7EFB5EB4BFE91C4A97C74A6702762A5AF2D8A5DEFEDB1042DD2F3E7BFB3
DPBP    DATAPUMP BUNDLE PATCH 19.31.0.0.0                  Generic           p39196236_1931000DBRU_Generic.zip  E711E3024AA6C4C336D7291CE1E7D0419C311C52  F39745219BCC9D8BC8FD1262EF787FF742F7F84F6C59A817B1F014ADA49B778F

So.. essentially organize all your patches before even you begin patching, that is what AUTOUPG_HOME helps to do.

How Nabhaas helps you

If you’ve made it this far, you already sense there’s a better way — in fact, you have a way ahead.

TAB - Whitepaper ,
download here

Managed Delivery Services - Whitepaper ,
[download here](https://www.nabhaas.com/_files/ugd/dab815_96198a0627d64f75a3d3a2dce9bf185d.pdf