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.. 😉
Oracle DBA interviews, especially for senior roles, usually go beyond definitions. The discussion often moves quickly into troubleshooting, recovery, RAC, Data Guard, patching, GoldenGate, and real production scenarios.
Below are some recent Oracle DBA interview questions reportedly asked in a product-based organization, along with practical answers and the checks I would expect a DBA to discuss during an interview.
I recently completed the Oracle 1Z0-1157-26 – Agentic AI Foundations Associate exam.
I had been reading and learning about AI agents, MCP, vector search and some of the newer AI capabilities around Oracle for a while, so this certification came at a good time. I decided to go through the complete learning path rather than preparing only from an exam point of view. And I think that is the right way to approach this one.
The first warning often appears during a DR drill. Redo transport is healthy, managed recovery is running, and the standby looks ready. Then Data Guard Broker reports insufficient standby redo logs, or apply lag starts rising after an online redo log resize even though the network has no visible problem.
This is why I do not validate standby redo logs only by checking whether rows exist in V$STANDBY_LOG. The count must be correct for every redo thread, the sizes must match the primary redo layout, RFS must actually be using them, and the same preparation should exist on the current primary for the next role transition.
There is another misconception worth clearing up early. Standby redo logs improve how received redo is stored and applied. They do not convert asynchronous transport into a guaranteed zero-data-loss service. Protection mode, transport progress and apply progress are three different parts of the Data Guard path.
I recently worked on an Oracle database that could be started normally from SQL*Plus, but failed every time Clusterware tried to start it through srvctl. The error returned by Clusterware was ORA-12547: TNS:lost contact.
The final fix was to relink the database Oracle Home, but I did not reach that conclusion from the error message alone. The useful clues came from comparing SQL*Plus and SRVCTL startup behaviour, noticing what was happening to the Oracle executable during the SRVCTL attempt, and then going back through the last database startup and patching history.
Every Oracle DBA has experienced that moment when monitoring alerts suddenly explode across the dashboard. Everything was running smoothly, and then without a warning - the CPU utilization jumps to 95%, applications slow down, and users start reporting performance issues.
One of the most frustrating parts of such incidents is when nothing obvious changed. No deployments, no schema modifications, and no new batch jobs. Yet the database is clearly struggling.
In many real-world cases, the root cause is surprisingly subtle: a change in optimizer statistics leading to a different execution plan. Oracle's automatic statistics gathering is powerful, but it is not always perfect and especially when data distribution is skewed or histograms behave unexpectedly.
In this article, we will walk through a real-world Oracle CPU spike investigation. You will see the step-by-step troubleshooting approach using AWR, execution plan history, and histogram analysis. We’ll also cover how the issue was fixed using manual statistics and SQL plan baselines to stabilize performance.
That automatic restart can make crash recovery appear simpler than it really is. Recovery time still depends on checkpoint activity, WAL volume, storage performance and the availability of required WAL files. A database that normally starts in seconds can behave very differently after a write-heavy workload or storage incident.
I have seen queries drop from seconds to milliseconds after adding one correct index. I have also seen OLTP systems become slower because every column was indexed without understanding the workload. Both situations are common.
Indexes are powerful, but they are not free. They reduce unnecessary reads for SELECT queries, but they add cost to INSERT, UPDATE, DELETE, storage, statistics gathering, and maintenance. A good DBA does not create indexes blindly. A good DBA checks the SQL pattern, data volume, selectivity, execution plan, and write workload before touching production.
Database automation has removed plenty of manual effort, but it has not removed operational accountability. Oracle can now automate provisioning, patching, backup, scaling, and parts of performance management. At the same time, applications are becoming more distributed, security boundaries are expanding, and AI workloads are placing new demands on enterprise data.
A database backup can finish successfully and still fail during recovery.
That usually sounds strange until encryption enters the picture. RMAN backup is available, archive logs are available, Data Guard is in sync, but during restore someone asks the real question: where is the TDE wallet or master key?
This is where many production environments become risky. TDE wallets are present on database servers, Java keystores are owned by middleware teams, SSH keys are copied between hosts, certificates are renewed manually, and old wallet backups are kept in folders nobody wants to touch.
After more than 12 years of working with production databases, I have learned that performance problems do not always begin with one terrible query.
Sometimes it is several smaller things happening together. One session is using slightly more CPU, another is holding a lock, a background job is running longer than expected, and storage latency has quietly increased. None of them looks disastrous alone, but together they make the whole system struggle.
A common reaction is to increase redo log size and move on. Sometimes that is required, but it is not always the real fix. Redo log sizing controls how frequently Oracle switches logs. It does not reduce the amount of redo generated by bad SQL, unnecessary indexes, row-by-row commits, or poorly designed batch jobs.
This post looks at Oracle redo log sizing from a production DBA angle. We will check log switch frequency, estimate redo generation rate, review MTTR guidance, discuss common failure scenarios, and compare the idea briefly with PostgreSQL WAL pressure.
AWR used to be simple when most databases were single-instance, single-tenant, and all important workload stayed on the primary database.
That world is mostly gone.
Today, one CDB may host multiple PDBs. Reporting may run on Active Data Guard. Read traffic may be pushed toward True Cache. Replication may be handled through GoldenGate or XStream. When performance breaks, the first question is no longer just “what was the top wait event on the database?”
A database incident rarely begins when the monitoring system raises an alert. It usually begins weeks earlier - with an unreviewed execution plan, an ignored capacity trend, an oversized privilege, or a recovery procedure that nobody has tested.
By the time the DBA receives the call, the database is often exposing an operational weakness that was already present. The immediate symptom may be exhausted storage, a failed deployment, excessive I/O, or a missing object, but the underlying cause is frequently a gap in engineering discipline.
I have seen expensive Oracle platforms fail because nobody noticed that the Fast Recovery Area was growing rapidly. I have also seen relatively modest PostgreSQL environments remain stable for years because the team consistently reviewed changes, monitored capacity, controlled access, and tested recovery.
If you have ever recovered an Oracle database and opened it with RESETLOGS, chances are someone whispered or shouted—the dreaded question: “Are all my old backups now useless?” Lets set the record straight: in modern Oracle releases, your old backups are still very much usable, and panicking is optional.
In this post, I wil walk you through why this myth exists, how Oracle’s handling of RESETLOGS has evolved over the years, and what you should do to ensure your recovery strategy remains solid. We will cover the mechanics of RESETLOGS, explain the differences between pre-10g version and modern behaviour, and share some practical tips I have learned from managing production environments with terabytes of data. By the end, you you will understand why you can sleep a little easier after recovery and make smarter backup decisions.
If you have worked in production environments long enough, you have probably seen this situation before. An alert fires in the middle of your daily shift appears.. as "CPU is at 90%. The database must be overloaded."
Infrastructure teams immediately start discussing scaling CPU, adding cores, or moving the database to a bigger server. But experienced DBAs know something important: High CPU utilization does not automatically mean the database is the bottleneck.
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.