Step into my daily life as a DBA from routine tasks to the awkward gotchas to all of the really cool things that make the oracle database “AMAZING”.
Introduction As a DBA, data modeling is part of the job; working with developers, reviewing table design, implementing proper constraints and much more. In an earlier post about performance tuning, I talk about some practical steps that can be taken to fix performance problems. However, sometimes those problems could be “self-inflicted” and I ended that
Updated 24th September 2026 A Brief Primer: Constraints Constraints are database objects that help enforce business rules and ensure data integrity. They are typically defined on tables and their columns. They include: I talk a lot more about constraints in a previous post: about database constraints. What are Constraint States? In Oracle, it is possible
It’s patching season once again, and as a good oracle technologists I patch my environments to ensure security, fix bugs and enjoy new features. Additionally, Oracle provides us the autoupgrade utility which helps simplify the patching process. In my earlier post about using autoupgrade for my very first time, I downloaded autoupgrade and used it
Autoupgrade Patching: Cycling Between Oracle Homes Read More »
Brief Primer: Locks, Blocks and Transactions In an earlier post, I talked about locks and transaction concurrency. A lock is a mechanism used by Oracle to restrict access to a shared resource. Also, in another post, the importance of indexing foreign key columns, I explore how these locks on child tables can lead to blocking.
Introduction DML WAIT[NOWAIT], introduced in 23.26.2.0.0, helps to specify how long a DML statement should wait to acquire a lock before rolling back the DML statement and returning session control to the user. The general syntax is: You can specify whether to wait forever, not at all or for n seconds, milliseconds or microseconds. The
Introduction In a relational database, defining constraints can help ensure data integrity, improve data consistency, enhance SQL query performance, and, in the case of foreign keys, ensure referential integrity. I talk a lot more about constraints in a previous post about database constraints. In a separate post, I also talk about locks and transaction concurrency
Imagine that at your local superstore(Walmart, Target, etc.), when you got to the parking lot, you had to get a number and wait till you got called to proceed into the store to do your shopping(however long that takes) and then leave, consequently freeing up space for the next person to come in. This sounds
INTRODUCTION I was recently confronted with an error ORA-01502 error. This occurred as I was attempting to perform a DML operation on a table. Initially, I was surprised but after some digging I managed to get to the bottom of the issue. Here’s what happened. SETUP Firstly, we create a sample table, create a unique
A bit of Background I have been reading a lot about autoupgrade. I see lots of oracle technologists talking about it on their blogs and videos and they recommend it. Having got tired of watching from the sidelines, wondering what all the fuzz is about and also due to my own enormous FOMO, I decided
Most data problems don’t come from bad SQL — they come from bad assumptions. And the worst one is believing that constraints can be “handled in the application.” They can’t. They never could. The moment data is touched by an ETL job, a script, an integration, a migration, or a future rewrite, every application‑level rule evaporates. The database is the only place where integrity actually persists. Datatypes, keys, foreign keys, checks, and assertions aren’t optional features — they’re the backbone of reliable systems. If the data matters, the constraints belong in the database. Full stop.
