Oracle: Performance, Licensing and Knowing When to Move

Oracle is a genuinely capable database that many organisations run because a decision was made fifteen years ago and nobody has revisited it since.

Both halves of that sentence matter. Dismissing Oracle as legacy is wrong — it does things at scale that alternatives struggle with. Assuming you still need it because you always have is equally wrong, and considerably more expensive.

Where it genuinely earns its cost#

Very large transactional workloads with demanding consistency and availability requirements. Real Application Clusters, Data Guard and partitioning are mature and battle-tested at a scale most alternatives have not matched.

Complex analytical SQL over large data volumes. The optimiser is decades old and it shows, in a good way.

Applications that require it. If you run Oracle E-Business Suite, PeopleSoft or a vendor application certified only on Oracle, the database is not a separate decision.

Deep existing expertise. A team fluent in Oracle tuning is a real asset, and migrating away means losing that advantage.

Licensing — where the money actually goes#

More organisations get hurt by Oracle licensing than by Oracle technology. The principles worth knowing:

Processor licensing counts cores, adjusted by a factor depending on processor type. The count is of cores where the software could run, not where it happens to run.

Virtualisation is the classic trap. Depending on the hypervisor and configuration, Oracle's position may be that you must license every processor in a cluster the database could migrate to — not just the host it is on. Organisations have received unexpected seven-figure bills from exactly this. If you run Oracle virtualised, understand your specific position before an audit rather than during one.

Options and packs are separately licensed and easy to use accidentally. Partitioning, Advanced Compression, Diagnostics and Tuning Pack, and others are installed by default and can be used unintentionally — including by a DBA running a performance report. Usage is recorded, and it is recoverable in an audit.

Named User Plus has minimums per processor, so the cheaper metric is not always cheaper.

Audits happen. Keep your own records of what is deployed, what is licensed and what options are enabled. The time to discover a gap is not when the letter arrives.

Practical control: run the licensing scripts yourself periodically, disable options you do not use, and get a specialist review before any significant infrastructure change. This is one of the few areas where external expertise reliably pays for itself.

Performance basics that resolve most problems#

The majority of Oracle performance complaints come down to a small number of causes:

Missing or unusable indexes. The most common, and the easiest to fix — though an index applied to a column wrapped in a function will not be used, which surprises people.

Bad statistics. The optimiser makes decisions from statistics about your data. Stale statistics produce bad plans. Ensure gathering is running and actually completing.

Plan instability. The same query suddenly runs slowly because the plan changed. SQL Plan Management exists to pin known-good plans.

Excessive round trips. An application making thousands of small calls where one set-based statement would do. Usually an ORM used carelessly, and usually the biggest single win available.

Contention. Locking, hot blocks, sequences without caching.

The diagnostic path is well-trodden: capture what the session is actually waiting on, look at the execution plan, check the statistics. AWR and ASH reports are excellent — and note that both are licensed features under the Diagnostics Pack, which is precisely the trap described above.

Assessing a migration honestly#

Moving off Oracle is a legitimate strategy and it is oversold in both directions.

It is easier than it used to be for standard relational workloads. PostgreSQL in particular has closed much of the functional gap, and managed services remove much of the operational burden.

It is harder than a vendor demo suggests when you have PL/SQL packages, database-resident business logic, Oracle-specific SQL, or applications certified only on Oracle. Migration tools convert schema and simple procedures well; complex PL/SQL and performance characteristics need real work.

An honest assessment covers:

The saving is real and the migration cost is usually underestimated. Start with a non-critical database to build genuine capability, rather than proving the concept on the system that cannot fail.

If you are staying#

• Know your licence position before someone else tells you
• Disable unused options so they cannot be triggered accidentally
• Keep patching current — Oracle's quarterly critical patch updates matter
• Use Data Guard if availability matters; it is mature and works
• Do not run it on hardware sized by guesswork — this is licensed per core, so oversizing is directly expensive in a way it is not elsewhere

FAQ#

Is Oracle still relevant?#

For very large transactional systems and for organisations running Oracle applications, yes. For a new standard business application, most teams would choose PostgreSQL or a managed cloud database and be well served. Relevance depends entirely on the workload.

How much does Oracle actually cost?#

Enormously variable, and list price is rarely what organisations pay. The costs that surprise people are not the initial licence but the annual support, the options enabled accidentally, and virtualisation exposure. Model total cost over five years, not the first invoice.

Should we migrate to PostgreSQL?#

If your workload is standard relational, your PL/SQL footprint is small, and your applications support it — the case is often strong. If you have deep database-resident logic or vendor certification constraints, the migration cost can exceed the saving. Assess honestly rather than ideologically.

What is the biggest licensing risk?#

Virtualisation. The gap between what an organisation believes it must license and Oracle's position on clustered hypervisors has produced some of the largest unexpected bills in enterprise IT. Know your position in advance.

Can we run Oracle in the cloud?#

Yes — on Oracle's own cloud, and on other providers with licensing implications that vary by configuration. Bring-your-own-licence rules differ per platform. This is another area where checking before deploying is much cheaper than after.

Why did our query suddenly get slow?#

Most often the execution plan changed, usually after statistics were gathered or data volume shifted. Compare the current plan to a previous one; SQL Plan Management can pin a known-good plan while you investigate.

Do we need a dedicated DBA?#

For a significant Oracle estate, yes — or a support contract with people who have that depth. Oracle rewards expertise more than most databases, in both performance and licence exposure, and the cost of not having it tends to arrive all at once.

What else is coming for Oracle