Blog

Do You Actually Need Oracle Enterprise Edition? DBA’s Guide to Evaluating Oracle Deployments.

tim.marshall@dbvisit.com (Tim Marshall) — Fri, 15 May 2026 01:02:51 GMT

Evaluating Oracle Standard Edition, Enterprise Edition, and Disaster Recovery Options for Modern DBA Environments

For many, Oracle Enterprise Edition (EE) has become the default choice for production Oracle deployments. If the workload is considered important, EE is assumed to be the “safe” option.

Setting Up Oracle Hybrid Disaster Recovery with Transparent Data Encryption (TDE)

Vijayganesh Sivaprakasam — Thu, 14 May 2026 05:25:02 GMT

Introduction

Over the last few blogs, we have looked at TDE and its impact on Oracle hybrid and multi-cloud deployments. This included: How OCI’s TDE makes hybrid environments more complex, what TDE is, and Oracle SE on OCI hybrid environment architectures.

One question that keeps coming up from customers and partners is, “Can I actually run Oracle Standard Edition on-premise and use OCI as my DR site?” The short answer is “yes”, and in this blog, I’ll walk through a step-by-step process for configuring an Oracle hybrid DR setup with an on-premises primary and an OCI DBCS standby.

Whether you are running Enterprise Edition or Standard Edition, this blog aims to give you the clarity you need to get it right the first time.

What you need to figure out first

Before diving into configuration, there are a few important questions worth answering:

Which Oracle version best supports this cleanly?
What parameters govern TDE behaviour across environments?
Is Standard Edition supported, or is this Enterprise-only?
How straightforward is it to create a standby database in OCI?
What are the actual steps involved in getting everything running?

Let’s address each of these as we go.

Getting the version right matters more than you think

Not all Oracle visions support hybrid DR with OCI. Therefore, the very first step is to ensure your database is on a version and release that supports hybrid DR with OCI.

In version 19.16, Oracle introduced the TABLESPACE_ENCRYPTION parameter, which supersedes the older ENCRYPT_NEW_TABLESPACE parameter. This newer parameter is central to making hybrid setups work properly.

Understanding TABLESPACE_ENCRYPTION (this is the important part)

This parameter accepts three values, each suited to a different environment and use case:

AUTO_ENABLE – This is the default on OCI DBCS. It ensures that every new tablespace is automatically encrypted. On OCI, this setting cannot be changed, regardless of licensing.

MANUAL_ENABLE – This is the default for on-premises environments. Tablespaces are only encrypted if you explicitly specify encryption.

DECRYPT_ONLY – This value ensures that tablespaces are not encrypted at all. It is available only for on-premises environments.

For hybrid DR, this is the critical piece: on-premises primary must be set to DECRYPT_ONLY.

For detailed reference, Oracle’s official documentation on this parameter is available at: Oracle TABLESPACE_ENCRYPTION Documentation

Why DECRYPT_ONLY matters for hybrid DR

To successfully configure a hybrid environment where OCI serves as the DBCS standby, the on-premises primary must have TABLESPACE_ENCRYPTION set to DECRYPT_ONLY.

Here is why it matters: when your OCI environment becomes the primary (during a switchover or failover), any new tablespaces it creates will be encrypted by default. The DECRYPT_ONLY setting on the on-premises standby ensures that those tablespaces are decrypted when they arrive, keeping the standby environment functional and consistent. This is actually where many previous hybrid DR attempts fell over.

(Figure 1: Hybrid DR architecture – On-premises primary with OCI DBCS standby)

Step-by-step setup: Enterprise Edition setup

Below is the complete process for setting up the standby database in OCI DBCS with an on-premises primary, for Enterprise Edition.

On-premises primary configuration

Start by creating the keystore directory and setting the essential parameters:

$ mkdir /etc/oracle/keystore/PROD

SQL> ALTER SYSTEM SET tablespace_encryption = DECRYPT_ONLY SCOPE=SPFILE;

SQL> ALTER SYSTEM SET wallet_root = '/etc/oracle/keystore/PROD' SCOPE=SPFILE;

SQL> ALTER SYSTEM SET standby_file_management = AUTO SCOPE=SPFILE;

SQL> STARTUP FORCE;

SQL> ALTER PLUGGABLE DATABASE ALL OPEN;

SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE;

Next, configure the TDE keystore and generate the master encryption key:

SQL> ALTER SYSTEM SET tde_configuration = 'KEYSTORE_CONFIGURATION=FILE' SCOPE=BOTH;

SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY <password>;

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE

FROM KEYSTORE IDENTIFIED BY <password>;

SQL> ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE

IDENTIFIED BY <password> WITH BACKUP CONTAINER=ALL;

OCI standby configuration

On the OCI side, ensure the following parameters are in place:

tde_configuration = 'KEYSTORE_CONFIGURATION=FILE'

wallet_root = '/etc/oracle/keystore/PROD'

tablespace_encryption = AUTO_ENABLE

-- (This is the default on OCI and need not be explicitly set)

Important: Copy the encryption keys from the primary to the standby’s wallet_root directory before proceeding.

Creating the standby with RMAN duplicate

With both environments configured, you can create the standby database using RMAN’s duplicate command. Before running it, make sure that the standby environment is reachable from the primary, the standby database is in NOMOUNT state, and your TNS and listener entries are properly configured.

We assume that you have provisioned the OCI DBCS environment with the same version as the primary, dropped the default database, and retained the unique database name to ensure it remains properly tied to the OCI console for patching and backups.

$ rman TARGET sys/xxxxx@prod AUXILIARY sys/xxxxx@stby

RMAN> DUPLICATE TARGET DATABASE

FOR STANDBY

FROM ACTIVE DATABASE

DORECOVER

SPFILE

SET db_unique_name = 'stdby' COMMENT 'Is standby'

NOFILENAMECHECK;

Enabling managed recovery

Once the standby database is created, enable managed recovery to begin applying redo data:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

USING CURRENT LOGFILE DISCONNECT FROM SESSION;

From this point, you can activate the standby database for failover or perform a switchover for planned migrations. After activation, if you need to recreate the standby on-premises, you can restore the database as decrypted using the "Restore as Decrypted" approach.

What about Standard Edition?

The good news is that this hybrid DR approach works for Standard Edition as well! There is one notable difference: the standby_file_management parameter must be set to MANUAL on the on-premises environment, rather than AUTO.

Where most people struggle (and why we built StandbyMP disaster recovery for Oracle SE)

In practice, the challenge isn't the theory, it's the operational detail. For example:

Getting the encryption parameters right
Managing the wallet and keys
Copying the keys correctly between environments
Not breaking things during role transitions

If you are using Dbvisit StandbyMP, the process becomes significantly simpler. StandbyMP automates many of the tasks that would otherwise require manual intervention, including:

Setting the TABLESPACE_ENCRYPTION parameter in the on-premises environment
Configuring TDE settings, wallet roots, and encryption keys
Copying encryption keys to the standby database
PLUS, all of its normal DR actions such as log management, DR testing, zero-data-loss switchovers, monitoring, and notifications.

One critical reminder: always remember your TDE wallet password. Losing it can lock you out of your encrypted data permanently.

(Figure 3: Dbvisit StandbyMP automating the hybrid DR configuration)

For detailed configuration and setup instructions with Dbvisit StandbyMP, visit:OCI Hybrid Configuration Guide.

Conclusion

Setting up Oracle hybrid disaster recovery between an on-premises primary and an OCI standby is absolutely achievable. The key lies in understanding how TDE behaves across both environments and ensuring that the right parameters, especially TABLESPACE_ENCRYPTION, are configured correctly from the start.

For Enterprise Edition users, the process is well-defined: configure your keystore and wallet, set DECRYPT_ONLY on-premises, and let RMAN handle the duplication. For Standard Edition users, Dbvisit StandbyMP removes much of the manual burden, making hybrid DR accessible even without an Enterprise licence. You can access this through our free trial.

Whatever your edition, the most important takeaway is this: plan your encryption strategy before you build your standby. A little foresight here saves a great deal of troubleshooting later. And above all, never forget your TDE wallet password.

Check out the other blogs in our TDE series:

Blog #1: Oracle TDE and Hybrid Disaster Recovery: Why It Breaks & How to Fix It

Blog #2: What is Oracle TDE?

Blog #3:Oracle TDE Licensing: What you need to know

Blog: 4: Oracle TDE wallet setup: What DBAs get wrong and how to get it right

Three wise men and a database - Do you actually need Oracle Enterprise Edition?

tim.marshall@dbvisit.com (Tim Marshall) — Thu, 14 May 2026 04:47:32 GMT

Few Oracle topics generate as much discussion as the choice between Enterprise Edition and Standard Edition.

For years, Oracle Enterprise Edition (EE) has been treated as the default choice for serious production environments. In many organisations, the decision is barely questioned. If the database matters, you buy EE. If disaster recovery matters, you add Data Guard. If security matters, you add more packs. If performance matters, you add more packs again. And if the budget matters, well, you are in trouble.

That approach has become so normalised that many teams never stop to ask a simple question:

Do we actually need all of this?

To explore that question, I sat with the three people in my organisation who spend most of their time working with DBAs and Solution Architects on Oracle architecture, disaster recovery, and real-world customer environments around the globe:

> Vijayganesh Sivaprakasam, Oracle ACE and Head of Customer Services
> Alex Masharov, Head of Product and Development
> Tim Marshall, Head of Product Marketing

What followed was less a formal interview and more a candid DBA conversation about Oracle licensing, feature sprawl and overengineering.

The interesting part was not that any of them argued against EE. Quite the opposite. All three were very clear that EE absolutely has its place.

The real discussion was about how often organisations buy it by default without fully understanding whether they actually need it.

Why Enterprise Became the Default

Alex Masharov put it bluntly.

“Oracle has been the enterprise database for decades. They were first, they built the reputation early, and they’ve maintained this aura of enterprise capability ever since.”

That reputation matters. For many IT leaders, EE simply feels safer. It is the option associated with large banks, global enterprises, massive workloads, and mission-critical systems.

Tim Marshall agreed, pointing out that Oracle themselves position EE as the primary offering.

“It’s the version most heavily promoted across Oracle’s ecosystem. Partners sell it, enterprise customers expect it, and it becomes the assumed default.”

And once you are in the EE ecosystem, there is always another feature or pack available:

> Active Data Guard
> Advanced Security
> Partitioning
> Diagnostics Pack
> Tuning Pack
> RAC
> GoldenGate

The result is that Oracle EE often becomes less of a product choice and more of a long-term commercial direction.

The Problem: Most Organisations Don’t Use What They Pay For. And Oh Boy Are Paying For It.

This was the point all three interviewees returned to repeatedly.

Vijayganesh Sivaprakasam estimated that in many enterprise environments, organisations may only actively use 20 to 30 per cent of the advanced features they are licensed for.

“People often buy Enterprise first and only later ask whether they actually need those features.”

That observation will feel familiar to many DBAs.

Environments are frequently designed around theoretical future requirements rather than actual current workloads. Teams buy for scale they may never reach. Features they may never use. Problems they may never have.

Tim Marshall highlighted another important nuance that often gets lost.

“Enterprise itself does not suddenly unlock everything. The really expensive capabilities usually come when you start layering on additional options.”

And those options add up quickly.

Partitioning. Active Data Guard. Advanced Security. GoldenGate. RAC. Diagnostics. Tuning.

Each one is pushing the costs up further.

The result is that many organisations are not just paying for EE. They are paying for an entire stack of “just in case” capabilities.

The Biggest Misconception About Standard Edition

One of the funniest moments in the discussion came when Vijay answered the question:

“What is the biggest misconception people have about SE?”

His answer was immediate: “A lot of people don’t even realise it exists".

It sounds ridiculous, but there is truth in it.

SE rarely gets the same visibility or attention in Oracle conversations. In many cases, organisations jump straight into EE discussions without seriously evaluating whether SE could meet their requirements.

That is unfortunate because Oracle SE is far more capable than many people realise.

You still get the same core Oracle database engine. You still get Oracle stability, Oracle tooling, Oracle compatibility, Oracle backup and recovery, Oracle SQL, and Oracle ecosystem support. What you lose are certain advanced enterprise features and scalability options.

So the important question becomes: do you actually need those features?

Where SE Fits Surprisingly Well

The discussion became particularly interesting when we moved away from licensing theory and into real workloads. According to the group, SE is often an excellent fit for:

> Mid-sized production systems
> Departmental applications
> Regional business systems
> Transactional workloads
> Internal enterprise platforms
> Standard reporting environments
> Many customer-facing applications

In other words, a large percentage of real-world Oracle deployments.

Alex noted that many environments are nowhere near the scale limits people imagine.

“There’s often this assumption that every important workload automatically requires Enterprise. But a lot of systems are simply not pushing the boundaries that would justify it".

This is particularly true in modern infrastructure environments where hardware itself has become extremely powerful.

The reality is that many databases spend most of their lives under relatively predictable workloads.

So What Are the Actual Limitations of SE?

This is where the conversation became more balanced and realistic.

Nobody argued that SE can replace EE everywhere.

It cannot. There are absolutely workloads where EE is the correct answer. The team identified several scenarios where EE genuinely becomes important:

> Massive concurrency and scale
> Very large databases requiring advanced partitioning
> RAC clustering requirements
> Heavy in-memory analytics
> Regulatory requirements around advanced encryption
> Real-time reporting from standby databases
> Extreme performance tuning needs
> Very high-end enterprise security controls

And, historically, one of the biggest deciding factors has been disaster recovery. Specifically: Oracle Data Guard.

The Data Guard Requirement that Used to Necessitate EE

For many DBAs, the lack of native Data Guard support in SE has traditionally been the dealbreaker.

That single limitation often forced organisations into Enterprise Edition, even when the rest of the EE feature set was unnecessary.

This is where the conversation naturally shifted toward StandbyMP.

The team was careful not to position StandbyMP as “better than Data Guard” in every scenario. Again, this was not about pretending Enterprise Edition has no value.

Instead, the discussion focused on outcomes. What are organisations actually trying to achieve?

In most cases, the answer is fairly simple:

> Reliable disaster recovery
> Low downtime
> Minimal data loss
> Easier DR testing
> Intuitive / low-stress failover
> Confidence during incidents
> A standby database that actually works

And that is where StandbyMP significantly changes the SE conversation.

The Rise of “Good Enough” Database Architecture

One of the more interesting themes that emerged from the discussion was the idea that many organisations may be over-engineering their database environments.

Not maliciously. Not incompetently. Just cautiously.

DBAs and architects are often asked to design for every possible future scenario. Nobody wants to be blamed later for not choosing the “enterprise” option. But over time, that mindset creates complexity.

More features. More moving parts. More licensing. More operational overhead.

And ironically, complexity itself often becomes the bigger risk.

As Tim Marshall noted, many organisations are effectively paying for future flexibility rather than current business needs.

That does not mean Enterprise Edition is wrong. It simply means the evaluation process should probably be more honest.

So, Do You Actually Need Enterprise Edition?

The answer, frustratingly, is: Sometimes.

EE remains an exceptional platform for:

> Extremely large environments
> Advanced enterprise workloads
> Specialised security requirements
> High-end performance tuning
> Real-time standby reporting
> Complex clustering requirements

But the interviews made one thing very clear.

A huge number of Oracle environments never fully utilise the capabilities they are paying for.

And once you introduce StandbyMP into the equation, SE becomes viable for far more production workloads than many organisations realise.

That does not mean “everyone should downgrade.” It means SE deserves serious evaluation before EE becomes the automatic assumption.

Because in many cases, organisations are not choosing between 'good' and 'bad', they are choosing between:

> Complexity and simplicity
> Overprovisioning and right-sizing
> Theoretical future needs and practical current requirements

And increasingly, many DBAs are realising that simpler architectures are often easier to operate, easier to recover, and significantly cheaper to maintain.

What is the Bottom Line $$$ Saved?

The cost difference between Oracle SE and EE is enormous, despite the technical gap in many environments being nowhere near as large as people assume.

This is the part of the Oracle conversation that often gets overlooked.

Most DBAs already know Oracle Enterprise Edition is expensive. What many organisations underestimate is how quickly the costs escalate once additional EE options are introduced:

> Active Data Guard
> Partitioning
> Diagnostics Pack
> Tuning Pack
> Advanced Security
> RAC
> GoldenGate

These are not small add-ons. Many are licensed separately and charged per core, dramatically increasing both upfront licensing and long-term support costs.

Oracle SE operates in a completely different pricing model. Instead of core-based licensing, SE uses a socket-based licensing model with support for up to:

> 2 CPU sockets
> 8 cores and 16 CPU threads per database instance

For many mid-sized production environments, that is more than enough compute power.

The financial impact becomes very significant very quickly. Even relatively modest Oracle environments can reduce licensing costs by 60-80% over five years when moving from Oracle EE + Data Guard to Oracle SE + StandbyMP.

For example, in a relatively small 4-core deployment:

Oracle EE + Data Guard 5-year TCO: approximately $279,000
Oracle SE + StandbyMP 5-year TCO: approximately $69,000

That represents savings of roughly:

$210,000 over five years
Approximately 75% lower cost

The numbers become even more dramatic in larger environments.

In an 8-core deployment:

Oracle EE + Data Guard 5-year TCO: approximately $800,000
Oracle SE + StandbyMP 5-year TCO: approximately $170,000

That is a difference of approximately:

$630,000 over five years
roughly 79% savings

Even when aggressive EE discounting is applied, the cost gap remains substantial.

This is why the conversation matters.

For many organisations, the question is no longer:

“Can we technically run on Enterprise Edition?”

Of course they can.

The better question is:

“Are we paying hundreds of thousands of dollars for features we genuinely require?”

For many Oracle deployments, the real opportunity is simply right-sizing the architecture to match actual business requirements instead of theoretical future needs.

And that is why this conversation matters.

Learn more. Read our white paper Standard vs. Enterprise Edition: Right-sizing your Oracle licensing

This paper explores the SE vs. EE decision from a technical perspective, helping organisations determine when SE is sufficient, when EE is necessary, and how to design a robust SE environment that delivers strong performance without the higher price tag.

Oracle TDE wallet setup: What DBAs get wrong and how to get it right

Vijayganesh Sivaprakasam — Wed, 29 Apr 2026 23:13:59 GMT

Collaborate 2026: From Queenstown to Kaizen!

tim.marshall@dbvisit.com (Tim Marshall) — Thu, 23 Apr 2026 05:07:21 GMT

At Dbvisit, Collaborate is more than just an annual event. It is a chance for our global team to come together, reflect, learn, and invest in how we grow as a company.

This year’s event started with a bit more excitement than planned. A large part of the team was flying down from Auckland just as Cyclone Vaianu was getting a lot of attention. Flight notifications, a few nervous moments, some last-minute flight changes, and more than one person refreshing weather apps like it was their full-time job.

Build an Out-of-Region Standby in 24 Hours

alex.masharov@dbvisit.com (Alex Masharov) — Fri, 10 Apr 2026 05:06:03 GMT

Unfortunately, hostilities in the Middle East are directly affecting data centres, forcing many IT teams to ask the very real question: what happens if our data centre or region is no longer available?

Oracle Transparent Data Encryption (TDE) Wallet Setup

Vijayganesh Sivaprakasam — Sun, 08 Feb 2026 23:21:38 GMT

Oracle TDE Wallet Setup: What it is, how it works, and best practices

Oracle TDE Licensing: What you need to know

Vijayganesh Sivaprakasam — Mon, 02 Feb 2026 03:15:29 GMT

Oracle Transparent Data Encryption (TDE) is widely used to secure data at rest—but its licensing is one of the most misunderstood aspects of Oracle Database.

The confusion comes from one fact:

TDE licensing changes depending on edition, environment, and cloud provider

In this guide, I break down:

Whether Oracle TDE is free
How licensing differs across editions
What changes in Oracle Cloud (OCI)
Why licensing decisions directly impact hybrid disaster recovery

This is Blog #3 in a deep dive into Oracle TDE:

Blog #1 -Oracle TDE and Hybrid Disaster Recovery: Why It Breaks & How to Fix It
Blog #2 - What is Oracle TDE?
Blog #4 -Best practice TDE wallet creation & management

Microsoft SQL Server Standby Licensing Guidance

tim.marshall@dbvisit.com (Tim Marshall) — Fri, 30 Jan 2026 05:42:22 GMT

How Microsoft SQL Server Standby database licensing works:

Disaster Recovery 101 for SQL Server – Core Concepts & Strategies

JOHN@jmorehouse.com (John Morehouse) — Fri, 23 Jan 2026 05:23:07 GMT

I have always loved LEGO; it appeals to my technical nature. Some of my earliest memories are of sitting on the floor, surrounded by LEGO blocks, completely absorbed in building something that existed only in my head. What stuck with me wasn’t just the creativity, but the process, the discipline. I learned that skipping steps almost always meant I ended up with something very different from what I intended. The pieces fit, but the result wasn’t right, so I would pull them apart and rebuild them properly. That experience feels very familiar in SQL Server Disaster Recovery. Cutting corners early almost always means rework later, usually at the worst possible time.

When I talk to DBAs and IT managers about SQL Server disaster recovery (DR), I’m still surprised by how many teams are running with poorly implemented solutions, or sometimes no DR at all for truly business-critical databases. That’s risky, and it’s usually fixable. I’ve always been passionate about disaster recovery, and that’s why I’m partnering with Dbvisit as their ambassador to help promote better DR practices.

This post kicks off a new series where I’ll share practical lessons and deep dives into HA/DR technologies for SQL Server. In this post, we’ll start with the core concepts of SQL Server DR, then in upcoming posts we’ll get hands-on with Log Shipping, run through live demos, and look at what really works (and what doesn’t) in the field.