Oracle

Where it sits

Oracle Database occupies a particular position: it holds the records that core systems in large organisations are built around.

Banking systems, insurance policy systems, telecommunications billing, government records. Systems that have run for decades, process substantial volumes and cannot be wrong.

That position was earned. For a long period, when transaction volumes and reliability requirements were high, this was the database that handled them, and organisations that adopted it built extensively around it.

Understanding it means understanding both the capabilities that earned that position and the accumulation that followed.

Reading without waiting

One characteristic deserves particular attention because it addresses a problem that troubles many databases.

A query sees data as it was when the query began, even while other sessions modify it.

The consequence is that readers do not block writers and writers do not block readers.

This matters enormously in systems doing two things at once. A report scanning millions of rows runs while transactions continue. Without this behaviour, either the report waits for transactions to finish or transactions wait for the report, and in a system processing continuously neither is acceptable.

This is a substantial part of why Oracle became established in high volume transactional systems.

PL/SQL, and its consequences

PL/SQL is Oracle's procedural language for logic running inside the database: stored procedures, functions and triggers.

Its advantages are real. Processing where the data sits avoids moving large volumes to compute elsewhere, which for set based operations over substantial data is considerably faster.

Its consequences are equally real and take longer to appear.

Over years, business logic migrates into the database. A rule is implemented in a procedure because that was convenient. Another follows. Eventually a substantial portion of how the business works lives in PL/SQL, written by people who have left, documented nowhere.

This is not a criticism of the language. It is what happens when logic can live in the database and there is no discipline about whether it should.

The consequence appears when an organisation considers moving. The data is portable. The PL/SQL is not, and establishing what it does is the work that dominates such programmes.

Partitioning

A table is divided into partitions, typically by date.

The reason this matters is that operations on very large tables become impractical without it.

A query for one month reads one partition rather than years of data. Removing data older than seven years becomes dropping a partition, which is nearly instant, rather than deleting hundreds of millions of rows, which is slow and generates enormous amounts of undo information. Maintenance addresses one partition rather than the whole table.

For tables holding years of history, this is what keeps them workable.

Availability

Clustering allows several servers to access one database, so service continues when one becomes unavailable and capacity can be added.

This is one of the arrangements organisations with strict availability requirements have relied on, and Oracle's documentation covers the architecture and its requirements.

The modernisation question

Oracle appears constantly in modernisation planning, and the honest position is worth stating.

Where it holds core records reliably, replacing it should follow from a requirement rather than from cost alone. Migration is expensive, carries genuine risk to systems the business depends on, and delivers benefit only if there was a specific problem to solve.

Where it is being replaced, the assessment that matters is of the PL/SQL rather than of the data volume. Programmes estimated on data size and surprised by procedural code are a recurring pattern.

Who uses it

Oracle Database is used by database administrators, application developers and operations teams in large organisations, concentrated in banking, insurance, telecommunications, manufacturing and government.

Points to consider

Oracle Database is commercial software with several editions, and the official documentation is the reference for features and versions.

Licensing is complex and materially affects cost, including how it interacts with processor counts and virtualisation. This is not something to estimate informally, and it frequently drives architecture decisions.

Skills are specialised, particularly for administration and for PL/SQL, which is a planning consideration over a long horizon.

Logic placed in the database is efficient and increases what any future platform change involves. Being deliberate about what goes there is worthwhile, though most existing estates inherited the decision rather than making it.

Getting started

The official documentation covers SQL, PL/SQL, administration and the database's architecture. For anyone working with an existing system, understanding the consistent read behaviour and the partitioning in use explains most of how the database performs under the workload it carries.