Thinking about downgrading from Oracle Enterprise to Standard Edition?

You are using an Oracle Enterprise Edition and thinking about downgrading to the Standard Edition? In this case, you must be sure that your applications are compatible. It’s not something easy to check. Here are a few ideas.

Why?

Why do you want to downgrade to the Standard Edition? For licensing costs, of course. Today, it is difficult to find a server with only a few cores. And Oracle Enterprise Edition is licenced per number of cores which are physically in the machine. You change your hardware and you will find that you cannot have a machine with the same number of cores. Even if the performance is fine, you will need to buy more software licenses because of those new multicore processors.

Another reason is virtualization. You want to consolidate your servers, but you don’t want to pay database software licenses for all your datacenter capacity.

So the Standard Edition is a good alternative: besides the fact that they are chaper, the licenses are counted per socket and not per core.

Oracle Standard Edition doesn’t have all features, but you can accept that. The reduction in the cost of licenses can compensate several days of development, tuning or administration, as well as the acquisition of third party tools to compensate what is missing on SE (for example dbvisit standby for high availability).

But you need to identify those features that you are using and that come with Enterprise Edition only

1. Read feature availability

The features available only in Enterprise Edition are listed in the documentation which shows which ones are available in Standard Edition or Enterprise Edition.

So the first thing to be done is to read that list and mark what you know you are using.

But there are two problems:

• It’s sometimes difficult to understand. For example, do you see clearly that you can’t send e-mails for Enterprise Manager notifications when you don’t have diagnostic Pack?
• You probably don’t know all what you (or your developers, your application) use.

2. Query feature usage

Oracle comes with a nice view about feature usage. DBA_FEATURE_USAGE_STATISTICS. It’s nice because you have information about what you used, with comments, dates, etc. And it’s also exposed in Cloud Control.

But did you ever try to match that with the documentation from the link above? That’s difficult:

• some Enterprise Edition features are not checked. For example, the usage of materialized view is shown, but without the distinction about those using query rewrite (which is an EE feature)
• some subset of features triggers usage even when they should not (for example the Locator part of Spatial do not need Spatial option)

3. Import to standard

One important thing to do is to import into a Standard Edition and check what fails with an ‘ORA-00439: feature not enabled’ error. Because what is nice is that when you install Standard Edition the features not available are supposed to be disabled at link time.

One tip: you probably need to import metadata only so you want to import it in a small database. But when you do that you will see that your datafiles are increasing because of the initial segment size. This is because the ‘deferred segment creation’ is an Enterprise Edition feature. So the tip is:

impdp … content=metadata_only transform=”storage:n”

The big advantage when testing the import is that you are already testing the migration procedure, because it’s the only way to migrate from Enterprise Edition to Standard Edition.

The problem is that it warns you only about static feature – those in your data model. Not about the usage. For example you will know that you can’t create bitmap indexes. But you will not know that you will not be able to do bitmap plan conversion from regular indexes.

Testing the import guarantees that the migration can be done, but you should test the application on a SE database with data in order to validate usage and performance.

4. Try and test

After having checked everything, from the obvious which is documented, to the little things we know by experience, I usually advise the customer to test. Install a test database in Standard Edition. Test the application, test the monitoring, test the administration procedures (no online operation, no flashback database,…). If you plan to migrate with minimum downtime with a replication tool (such as dbvisit replicate) you can start to replicate to a Standard Edition database. Then you will be able to test the read-only use cases, such as reporting, which may suffer from the lack of some optimizer features (adaptive plans, result cache,…)

5. Decide

Then you will decide if you are ready to downgrade to Oracle Standard Edition. Of course, it will no be transparent. You will have to find some workarounds. The decision is just a balance between the cost reduction and the time you can spend to do manually what was automatic in EE.