Sharing knowledge is the ultimate key to gaining knowledge..
The only two things that stay with you for life
are you & your knowledge !
Live while you can!
Teach & inspire while you could &
Smile while you have the teeth.. 😉
In high‑availability database environments, About Interview discussion often centers on how systems react when things go wrong ., especially in mission‑critical deployments like Oracle RAC (Real Application Clusters). One of the most common interview questions DBAs face is: In a 3‑node RAC, if one node goes down, how does instance recovery occur?
Understanding this not only helps you ace interviews but also equips you with real‑world insights into RAC's fault‑tolerance mechanics.
Assume Its 2 AM. Alerts are firing. CPU is maxed out, connections are piling up, and the application team is already asking for an ETA.
You SSH into the server, open psql, and start your usual routine - check pg_stat_activity, look at locks, scan logs, maybe run a few custom queries you’ve built
over the years. Fifteen minutes in, you still don’t have the full
picture.
This is exactly where things break down in production - - not because PostgreSQL lacks visibility, but because the data is scattered.
That is where pg_gather changes the game.
Most Oracle outages do not begin with hardware failure.
They start with a bad deployment, an accidental delete statement, a broken batch job, or a developer connecting to the wrong pluggable database at 2 AM. In a large multitenant environment, that usually means one application becomes corrupted while dozens of other applications inside the same CDB continue running normally.
Years ago, recovering from that kind of incident often meant painful decisions. Either accept application-level data loss or restore the entire database and impact every tenant sharing the environment. Neither option was ideal for production systems running critical workloads.
Selecting a database today isn’t just about technology - it's a strategic business decision. In production environments, the choice between PostgreSQL and Oracle Database affects scalability, reliability, compliance, and cost for years. As a DBA, architect, or infrastructure engineer, understanding the trade-offs between these systems can save significant headaches during implementation and future growth.
If you have been running PostgreSQL in production for a while, you have probably seen this pattern. Everything looks fine on the surface, queries are tuned, indexes are in place, and yet the system slows down at regular intervals. No obvious reason. No runaway query. Just sudden latency.
In many of these cases, the real issue is not in the foreground workload but in the background engine, specifically checkpoints.
If you have spent years tuning Oracle Database, HugePages is probably second nature to you. You would not even think about running a large SGA without it.
Now, when moving into PostgreSQL, many DBAs assume memory works differently or that HugePages are optional. Technically, they are optional. Practically, ignoring them in a serious production system is a mistake I have seen more than once.
PostgreSQL relies heavily on shared memory, especially for its buffer cache. As systems scale and memory grows into tens or hundreds of GB, the way Linux manages memory pages starts to matter a lot. That is where HugePages step in.
In this article, I will walk through how HugePages behave in PostgreSQL, how they differ from Oracle, and what actually matters when you enable them in real production environments. More importantly, I will share the kind of operational lessons you only learn after seeing systems misbehave at 2 AM.
"Can we give this user access, but make sure they cannot change anything?"
Before Oracle AI Database 26ai, DBAs usually handled this by creating a
separate reporting user, granting only
SELECT, removing DML
privileges, or depending on carefully designed roles. That approach works
when access is cleanly designed from the beginning. But in real production
systems, users often collect privileges over time. Support users get
emergency grants, application users may have broader access than expected,
and batch accounts sometimes have privileges that nobody wants to touch
during an incident.
A PostgreSQL performance issue rarely starts with one bad setting.
In production, it usually looks like this: the application team says the database is slow, CPU is not always high, storage graphs look confusing, and nobody changed anything “major”. Then we check deeper and find long transactions, dead tuples, stale statistics, unused indexes, chatty application queries, or checkpoint pressure.
A PostgreSQL table can grow quietly for weeks before anyone notices. The application team says they already deleted old data. Storage still looks high. Queries are touching more blocks than expected. Autovacuum is running, but the table does not seem to become smaller. This is where many DBAs first realize that DELETE in PostgreSQL is not the same as physically removing rows from the table file.
PostgreSQL uses MVCC, so old row versions remain inside the table until VACUUM can clean them. This is normal behavior, not a bug. The problem starts when dead tuples grow faster than VACUUM can remove them, or when long-running transactions prevent cleanup. Then you get table bloat, index bloat, stale statistics, poor plans, unnecessary I/O, and sometimes transaction ID wraparound pressure.
Some journeys do not begin with a plan. They begin with curiosity, consistency, and a simple intention to share what we learn.
My Oracle ACE journey is one such journey.