Oracle — Frequently Asked Questions
Practical answers on running Oracle — licensing traps that surface in audits, whether to migrate off, Standard versus Enterprise, RAC and Data Guard, and what actually drives performance problems.
Licensing answers here are general orientation, not contractual or legal advice. Oracle agreements vary and the details decide the outcome — get a specialist opinion before an audit, not during one.
Licensing#
Why do Oracle costs surprise people?#
Because usage accrues silently. Features from separately licensed options and management packs can be enabled and used without any obvious signal, sometimes by a monitoring tool doing what it was installed to do. The cost arrives later, back-dated, during an audit.
The defence is knowing what is in use rather than what was intended — checking feature usage from the database itself, on a schedule, and treating any surprise as urgent.
Standard Edition or Enterprise Edition?#
Standard where it meets the requirement — it is substantially cheaper and covers a great deal of ordinary workload. Enterprise when you genuinely need features exclusive to it.
The trap is architectural drift: a system designed on Standard gradually adopts a feature that requires Enterprise, and nobody notices the licensing consequence until much later. Review feature usage against edition periodically, not once.
How does virtualisation affect licensing?#
Considerably, and this is where the largest disputes arise. How cores are counted in a virtualised or clustered environment depends on the vendor's policies and your contract, and the boundaries that count are not always the ones your infrastructure team assumes.
Never assume that isolating a workload technically also isolates it contractually. Get this reviewed before designing the platform, because redesigning afterwards is far more expensive.
What about running Oracle in the cloud?#
Licensing in cloud environments follows specific vendor policies that differ by provider and by whether you bring your own licence. It is a contractual question with technical consequences.
The general advice holds: establish the licensing position before the architecture, not after.
Staying or leaving#
Should we migrate off Oracle?#
Sometimes, and rarely as easily as the business case suggests. Straightforward applications using mostly standard SQL can move to a cheaper engine with real savings.
The cost lives in what is not standard: stored procedures in vendor-specific dialect, features with no direct equivalent, integrations built over decades, and the operational knowledge your team has. Migrations frequently cost more than several years of licences.
Assess honestly per application rather than as an estate-wide decision — see enterprise architecture for how to run that assessment.
If we stay, how do we reduce cost?#
Consolidate onto fewer servers that are actually kept busy, with the licensing boundary in mind. Move workloads that do not need Oracle to something else. Check whether you are paying for options nobody uses. Right-size non-production environments, which are frequently licensed as though they were production.
Availability and performance#
Do we need RAC?#
Only for a specific availability or scalability requirement you can state. It adds real complexity, licensing cost and operational demand, and it does not protect against the failures teams most often actually experience — a bad change, a corrupted table, a full disk.
Many organisations are better served by a well-tested standby and a rehearsed recovery process than by a cluster nobody has failed over deliberately.
Data Guard — worth it?#
For disaster recovery, generally yes, and it is far simpler to reason about than clustering. The qualification is the same as for every recovery mechanism: it is worth what your last successful test says it is worth.
Fail over deliberately, on a schedule, and record how long it took and what broke in the application layer. That second part is usually the surprise.
What causes most Oracle performance problems?#
In practice: missing or stale statistics, poorly written SQL, missing or unusable indexes, and contention from jobs overlapping with peak load. Rarely the hardware.
Capture a baseline while performance is acceptable. Without one, "it is slow" has nothing to be compared against, and tuning becomes guesswork.
Should we be tuning it ourselves?#
Yes for the ordinary work — statistics, indexes, obviously bad queries. Note that some of the diagnostic and tuning tooling requires separately licensed packs, so confirm entitlement before using it, because using it is what creates the liability.
Operations#
How often should we patch?#
Follow the quarterly cycle, applying to a test environment first. Databases running years behind accumulate both vulnerabilities and an upgrade that grows harder every quarter.
What is the most common operational gap?#
Backups that have never been restored, and a recovery only one person can perform. Both are invisible until the day they matter, and on that day they are the whole problem.
Test the restore, record how long it took, and make sure at least two people can do it.
Our version is out of support. How urgent is that?#
Urgent. No security patches, limited vendor help when something goes wrong, and an upgrade path that lengthens with every release you fall behind. Treat it as a scheduled project now rather than an emergency later, and check the support end date for your current version before planning anything else.