Oracle on Ivan Luminaria

Oracle on Linux: the kernel parameters nobody configures

Tue, 24 Feb 2026 08:03:00 +0100

The client was a logistics company running Oracle 19c Enterprise Edition on Oracle Linux 8. Sixty concurrent users, a custom ERP application, about 400 GB of data. The server was a Dell PowerEdge with 128 GB of RAM and 32 cores.

The complaints were vague but persistent: “The system is slow.” “Morning queries take twice as long as two months ago.” “Every now and then everything freezes for a few seconds.”

AWR, ASH and the 10 minutes that saved a go-live

Tue, 10 Feb 2026 08:03:00 +0100

Friday, 6:40 PM. I already had my jacket on, ready to leave. The phone buzzes. It’s the project manager.

“Ivan, we have a problem. The system is crawling. The go-live is tomorrow morning.”

It’s not the first time I’ve received a call like that. But the tone was different. This wasn’t the usual vague complaint about slowness. This was panic.

I reconnect to the VPN, open a session on the client’s Oracle 19c database. First thing I do is a quick check:

Users, Roles and Privileges in Oracle: Why GRANT ALL Is Never the Answer

Tue, 27 Jan 2026 08:03:00 +0100

It has happened to me more than once: I walk into an Oracle environment and find the same situation. Every application user connected as the schema owner, with the DBA role granted. Developers, batch jobs, reporting tools — all running with the same privileges as the user that owns the tables.

When you ask why, the answer is always some variation of: “This way everything works without permission issues.”

Sure. Everything works. Until the day a developer runs a DROP TABLE on the wrong table. Or a batch import does a TRUNCATE on a production table thinking it is in the test environment. Or someone runs a DELETE FROM customers without a WHERE clause.

Oracle Partitioning: when 2 billion rows no longer fit in a query

Tue, 23 Dec 2025 08:03:00 +0100

Two billion rows. You do not reach that number in a day. It takes years of transactions, movements, daily records piling up. And for all that time the database works, queries respond, reports come out. Then one day someone opens a ticket: “the monthly report takes four hours.”

Four hours. For a report that six months earlier took twenty minutes.

It is not a bug. It is not a network issue or slow storage. It is the physics of data: when a table grows beyond a certain threshold, the approaches that worked stop working. And if you did not design the structure to handle that growth, the database does the only thing it can: read everything.

From Single Instance to Data Guard: The Day the CEO Understood DR

Tue, 16 Dec 2025 08:03:00 +0100

The client was a mid-sized insurance company. Three hundred employees, an in-house management application running on Oracle 19c, a single physical server in the ground-floor server room. No replica. No standby. No disaster recovery plan.

For five years everything had worked. And when things work, nobody wants to spend money protecting against problems they’ve never seen.

The day everything stopped #

On a Wednesday morning in November, at 8:47 AM, the primary data group’s disk suffered a hardware failure. Not a logical error, not a recoverable corruption. A physical failure. The RAID controller lost two disks simultaneously — one had been degraded for weeks without anyone noticing, the other gave out suddenly.