An Oracle Database Survival Guide

When I started my sysadmin role, I inherited Oracle database instances running 12c and 19c. Coming from PostgreSQL, it felt like moving to a different planet. A planet where the documentation assumes you’ve been doing this for twenty years.

Here’s what I’ve learned, mostly the hard way.

It’s not PostgreSQL

The first thing to understand about Oracle is that almost nothing works the way you’d expect. The terminology is different, the tooling is different, and the licensing model will haunt your dreams.

Simple things take longer. Checking your tables, limiting query results, understanding how storage is organized. In Postgres these are one liners. In Oracle you’re reading documentation and querying system views. Small friction, but it adds up when you’re switching between the two all day.

Memory management is not optional

In Postgres you set shared_buffers and work_mem and you’re mostly fine. Oracle has an entire memory architecture you need to understand. The shared pool, the buffer cache, how they interact, how they fragment over time.

I learned this the hard way when things started breaking in production because memory settings hadn’t been reviewed since the instance was first configured years ago. In Oracle, memory is something you actively manage, not something you set once and forget.

Storage will surprise you

In PostgreSQL, I never thought about tablespaces. In Oracle, every table, index, and segment lives in a tablespace, and when one fills up, things stop working.

We had this happen. A table grew faster than expected, the tablespace hit its limit, and the application started throwing errors. The fix is simple, add more space. The real fix is monitoring everything so you catch it before it becomes a problem. I set up daily checks and alerts, and it hasn’t happened since.

Boring work. Essential work.

Sessions and locks

Oracle sessions carry a lot of state compared to Postgres connections. When something goes wrong, sessions pile up, queries hold locks, and other operations get blocked.

Learning to find the problematic session, understand what it’s doing, and decide whether to kill it or leave it alone became a regular part of my week. You get better at it with experience and a few mistakes.

Migrating between versions

Part of my job involved planning a migration from 12c on a legacy server to 19c on AWS. On paper it sounds straightforward. In practice, every step had surprises. Schema differences, deprecated features, queries that relied on behavior that changed between versions, driver compatibility issues.

The biggest lesson: assume nothing is backward compatible until you’ve tested it yourself. Documentation says it works. The application disagrees.

What Oracle taught me

Oracle is powerful, battle tested, and occasionally maddening. The tooling feels like it was designed for a different era, and the learning curve is steep.

But managing it in production taught me more about databases than years of working with Postgres did. Not because it’s better, but because it forces you to understand what’s happening under the hood. Memory, storage, sessions, backups, none of it is optional. Oracle makes you deal with it.

And honestly, it gave me a much deeper appreciation for PostgreSQL. Every time I go back to Postgres I’m grateful for how simple it makes things. But I’m a better DBA because of the time I spent with Oracle.