[Starting December 2015, SE and SE1 have been replaced by SE2 and have disappeared from Oracle’s Technology Price List.]
With the advent of open source relational database platforms, many organizations must be looking at Oracle Enterprise Edition(EE) pricing and calling it outrageous. Not to mention the drying up of budgets in this economy. You can’t do anything for the sunk cost of the existing EE licenses. However, even for new purchases, switching to an entirely different database platform can be impractical. Some companies make compromises and go with Standard Edition(SE), or for single-node installations, Standard Edition ONE(SE1).
PROs
First let’s go over the PROs, which basically is just about $. But here are the specifics:
- For Oracle SE, the clusterware (Grid Infrastructure) is free, unlike EE.
- Oracle Database SE’s licensing costs is about 1/3 of EE (processor-perpetual)
- Oracle SE only charges by sockets, which means that you can have unlimited cores per processor. But you’re limited to 4 socket in the entire RAC cluster.
CONs
What are the pitfalls of using Oracle SE? Here are a few considerations to be taken when choosing to use Standard Edition:
Release Management
Strict release procedures should be in place. Database changes should not be released to a production environment running SE without shutting down the application first. This is particularly true for applications that have a lot of data. The limitations of SE such as the inability to build index online makes releasing schema changes on-the-fly very difficult.
Application Testing
The database should best be running only a few key, well-tested applications, rather than a big assortment of different applications. The lack of Database Resource Manager in SE means that applications are left to consume resources(cpu cycles, etc) freely. A big assortment of different applications particularly those firing ad-hoc or dynamically composed SQL statements is prone to give you grief.
Data Warehousing/Bitmap Indices
Datawarehouses most likely shouldn’t be hosted on an SE database due to the lack of bitmap indexes on SE. Applications that have a lot of data also are not good candidates to run on SE. SE’s lack of multi-channel RMAN backup makes RMAN backups very time consuming for big databases. You can consider other ways of backing up big databases, such as using SAN snapshots. However, RMAN is an essential part of the Oracle backup strategy. So this comes down to hosting only small datasets on SE. How small should it be? Roughly the databases would best be less 300GB. Otherwise, RMAN full backups will take a long long time.
Transportable Tablespaces
Transportable Tablespaces is not available with SE. So as you sync production data to a development database, you’ll have to rely on other utilities such as data pump export/import or the legacy export/import. Those utilities take a long time to dump out and import data.
Parallel Operations
All parallel operations are disabled on SE. This applies to parallel query, parallel index creation, parallel data pump export/import, etc, etc.
Virtual Private Database(VPD) / Fine Grained Security
Virtual Private Database(VPD) / Fine Grained Security are not available for SE. This means it’s harder to allow a broader user base and use that feature to automatically make only a subset of data visible based on the users’ credentials/profile.
Options
Options are only available for EE only. So no partitioning, active data guard, advanced compression, etc, etc.
In Conclusion
In essence, anything that allows the database to scale is taken off on SE. To be able to live with SE, you have to practice discipline, testing your applications thoroughly and making sure that SQL statements fired at the SE database are not resource-hogging surprises(this one may be tough to do). Manage the release management procedures, shutdown the applications first, then apply database schema changes and build indexes. Keep things simple and small. Huge tables or indexes will definitely give you a lot of problems down the road for SE.
If you go with open source relational database platforms, those certainly have their own limitations. Their pros and cons vary. Some of their features are comparable to Oracle EE. For example, Postgresql can do online index creation whereas Oracle SE cannot. Some are even weaker than Oracle SE. For example, MySQL cannot do a true hotbackup w/o blocking ongoing DMLs.
When a company can afford to purchase Enterprise Edition licenses, functionally it is really the best you can get. But if it’s not feasible and you choose to stick with Oracle by using SE, then you’ll need to prepare to be strict on your procedures and don’t expect you’d have easy solutions when problems happen. Tuning into that mindset would make using SE a lot easier. You really do get only what you paid for.