PostgreSQL Shared Buffers: A Production DBA Guide

A PostgreSQL server had just returned from planned operating-system maintenance. Recovery completed cleanly, connections were available, and the database log showed nothing unusual. Yet application latency was several times higher than before the restart, read IOPS had increased, and the first recommendation was to increase shared_buffers.

That may help, but it is not a diagnosis. The PostgreSQL cache is cold after a restart. A shared-buffer miss may be served by the operating-system page cache or may reach storage. A query can also have an excellent cache-hit ratio and still be slow because it processes millions of cached blocks. On the write side, dirty buffers bring WAL, the background writer, client backends, and the checkpointer into the same performance path.

This article explains what PostgreSQL keeps in shared buffers, how cache hits and misses should be interpreted, and what happens when pages are modified. It also covers practical sizing, monitoring SQL, common production failures, and the operational differences Oracle DBAs should expect when moving from the SGA buffer cache to PostgreSQL.

Oracle RAC - Oracle DBA Interview Questions with Practical Answers

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.

My Learning and Exam Experience – Oracle Agentic AI Foundations Associate [1Z0-1157-26]

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.

Oracle Standby Redo Logs: The Gap Most DBAs Miss

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.

ORA-12547 from SRVCTL While SQL*Plus Startup Works – Tracing It Back to a Post-Patching Relink Issue

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.

Oracle CPU Spike After Statistics Gathering: A Real-World Optimizer Investigation

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.

Split Brain in Oracle RAC: What Every DBA Must Know

   If you have worked with Oracle RAC long enough, you know the cluster is only as strong as its communication layer. Most days, RAC behaves beautifully ; instances coordinate, cache fusion works seamlessly, and life is good. But when inter-node communication breaks down, things can get ugly very quickly.

PostgreSQL Crash Recovery: An Oracle DBA’s View

  The first PostgreSQL crash I handled felt unusually quiet. I was prepared to mount the database, check the required logs and start a recovery procedure. Instead, PostgreSQL detected the unclean shutdown, replayed WAL and opened the database without any DBA command.

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.