There have been 3 editions of Oracle's "Standard Edition" released. These are "Standard Edition" (SE), "Standard Edition One" (SE1) and "Standard Edition 2" (SE2). Each edition has its own licensing conditions. It is Oracle's desire to have clients move to a newer set of licensing conditions that results in a new "edition" being born much to the angst of clients. By ending support of particular editions, clients are being forced to make a decision. Oracle is relying on that decision to be "move to the next edition" - but many clients are not following that advice - and many clients are looking at alternatives. This post details what we believe the leading alternatives are.
Note that the tables in this post can only be correctly viewed in the desktop version.
The table below shows the three Standard Editions from Oracle, whilst all allow 'Extended Support' up to the same date, this assumes you have upgraded to the SE/SE1 terminal release of 22.214.171.124. If you are on older versions you may be subject to earlier dates than that shown. Another difference was that the availability to purchase licenses for SE and SE1 have now passed and clients can only purchase SE2.
What happens beyond July 2021 ? SE and SE1 will end extended support at the terminal release, whereas SE2 will either be replaced by something new or will continue into new versions of the Oracle database.
If you do remain on SE or SE1 (or SE2 at an unsupported release version), you will be subject to "Sustaining Support", the following information about Oracle's sustaining support policy has been copied from http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf and included here:
With Sustaining Support, you receive technical support, including access to our online support tools, knowledgebases, and technical support experts. You benefit from:
Major product and technology releases
Access to My Oracle Support
Fixes, updates, and critical patch updates created during the Premier Support stage
Upgrade scripts created during the Premier Support stage.
Sustaining Support does not include:
New updates, fixes, security alerts, data fixes, and critical patch updates
New tax, legal, and regulatory updates
New upgrade scripts
Certification with new third-party products/versions
Certification with new Oracle products.
For more specifics on Premier Support, Extended Support, and Sustaining Support, please refer to Oracle’s “Technical Support Policies.”
This also introduces a new question - will there be a "Standard Edition 3" and if so, what new restrictions will it bring? Will it allow RAC? Will it restrict thread count? What clients are really asking is - is there a future for my use of Oracle Standard Edition regardless of what 'Edition' it is? The answers to these questions will be revealed in the future - but will clients wait for details from Oracle or will you choose to plan your roadmap now without Oracle Standard Edition? An even more complex thought is to consider is whether anything beyond SE2 will exist at all?
Some clients choose to migrate to Oracle Enterprise Edition (EE), we have assisted several clients through this process. If the additional cost is justified (note that RAC is licensed separately for EE whereas SE and SE2 do not charge additional for RAC), then the client has to work through a "license migration" with Oracle whereby a complex calculation is performed by Oracle that credits the money paid by the client in the current year and credits this against the Enterprise Edition licenses. Then it is a matter of ensuring the client has the correct binaries for the database. The problem with this process is the difficulty to purchase the Enterprise Database at a discount, I am sure if there was a large number of SE editions to migrate something could be arranged, but that is not your typical SE client who normally has less than 5 instances licensed. You can migrate from SE or SE1 to either SE2 or EE; and you can migrate from SE2 to EE. Oracle does not permit downgrades.
Challenges you will face
If you migrate away from Oracle, you will be faced having to perform the following tasks, your technical implementation of Oracle and its applications and what the migration target is will determine how significant these tasks are:
Re-write SQL code in the application layers that are passed to the database;
Re-tune SQL for a different system and implement different data optimisation designs in the target database;
Evaluate and re-write integration to and from the database, even if it is just a batch extract or import script; or
Re-write &/or modify Oracle PL/SQL Code and depending upon the target database, move the logic from within the database (PL/SQL and Triggers) to Server-Side processing within the application layers.
Then there is the often under-estimated task of testing. A change of underlying database will require for development unit testing, integrations or system test, and completed with a full end-to-end user acceptance test. This effort is significant on development staff, administrators and users alike.
All non-Oracle targets will represent a large challenge if any of the following are true:
Application Express (APEX or HTML DB) or Web PL/SQL is used;
Java Procedures are used; or
C Programs are used in Oracle's proprietary C call interface (OCI).
Assuming that EE is out of the question, there are a multitude of options available for you to choose from. Too many, and that is why we have presented what we believe are 9 leading options for Standard Edition clients to consider. We have broken this up into 3 on-premise proprietary databases; 3 open source databases; and 3 database cloud services.
In addition to a brief background on each option, we look at the following attributes:
License cost impact - on a relative scale, how large will be the impact to your budget to license the option;
Migration cost impact - how compatible the source and target systems are and the likely impacts that lead to complexity and time to design and resolve;
Application code change cost impact - the amount of changes that would be required to make to your application to cater for the new target database. This is very subjective as the application technology may determine the extent of compatibility;
Skills transfer cost impact - how much effort and hence cost is required to have existing resources become skilled in the new technology; and
Strength of local support - how easily is the new technology supported for you and will this be an equally strong offering as from Oracle currently or is it better or worse.
If you are not interested in all the detail, then have a look at the summary of the options presented with broad Low/Medium/High ratings against these attributes. The importance of each attribute will be specific to your individual requirements. We have listed the options in what we believe would be the best likely outcome for a majority of Oracle Standard Enterprise Edition use cases, but your specific use case could result in a different ranking. For example, the nature of your PL/SQL Code could result in PostgreSQL being just as an expensive choice as MySQL. Our ranking reflects the likelihood that it will lead to a less expensive outcome that will meet typical requirements of an Oracle Standard Edition use case.
Open Source Databases
Database Cloud Services
* The Oracle RDBMS PAAS will likely be replaced by an Autonomous Database Service at some point after the Autonomous Database for OLTP release. This could change pricing, but will not decrease the attribute ratings of the ability to migrate from Standard Edition.
Migrate to the Oracle compatible Tibero database
Tibero is a very attractive option to consider due to the high compatibility with Oracle - and deliberately targets migrating from Oracle to Tibero. We have a post that details the Tibero database, see the related posts section at the base of this post.
Tibero has both a Standard Edition and Enterprise Edition. The key difference is that only the Enterprise Edition has an equivalent clustering capability to Oracle's RAC. However, we believe that with Tibero being new to the market, very attractive pricing for Enterprise Edition including clustering (TAC) can be obtained that would be worth considering as this will open the door to many of Tibero's EE options which are all included at no additional charge that could represent the next level of capability, performance, scalability and security that you would require.
The Tibero Standard Edition, whilst not offering TAC, has a more generous restriction of 4 CPU Sockets without a thread restriction. If your system does not require TAC, then it is highly likely that migrating to Tibero will allow you to operate on very powerful hardware and scale your migrated system to significant capability. Tibero Standard Edition also includes an equivalent to Oracle's Active DataGuard and therefore could replace any investment in DBVisit replication that you have - or is completely compatible with DBVisit and you may continue using that solution if you prefer.
Tibero has a migration tool included that migrates Oracle databases to Tibero. This includes the migration of Oracle's PL/SQL to Tibero's PL/SQL. As the Tibero database is designed with Oracle compatibility as a primary feature, your applications would require little change to use the Tibero application and hence represents a very fast option to change databases.
Another key attribute is that the same skills used to manage your Oracle database can be applied to the Tibero database. This enables a quick transition in capability from one technology to the other that many clients do not consider when prioritising options. The staff turnover and internal costs of new technology adoption can be significant. In the case of Tibero, the existing capabilities can be kept, and the differences are relatively minor and mainly concern more complex implementations of Tibero.
Support is similar to that of Oracle whereby you can have a partner offer you a managed service or you can access a support portal direct.
Migrate to SQL Server
Microsoft SQL Server is proving to be a very popular choice for Enterprises and is the main competitor to Oracle for on-premise databases. It is often the case that Oracle clients run on Linux or Unix and therefore will have to migrate to a SQL Server on Windows. The SQL Server offering for Linux is still a very young offering that will serve as a good alternate in the future, for the time being we are only considering SQL Server on Windows.
Microsoft has a SQL Server Migration Assistance (SSMA) that can migrate an Oracle database to a SQL Server instance. Whilst the tool does automate much of the discovery, there are significant differences between Oracle's PL/SQL and Microsoft T-SQL. It is highly likely that this will then cause major changes to how an application interacts with the new SQL Server.
The other major source of incompatibility is differences in data types. Examples are decimal rounding in numbers and the Oracle date datatypes support a much more granular level of fractional time compared to SQL Server, and there are no equivalents for time based intervals. These would require custom approaches that would likely have conversions to be performed in SQL Server and changes to application code to cater for differences.
The skills difference between Oracle and SQL Server is significant, however with SQL Server being a leading offering, it is likely that your personnel will already have some skills in SQL Server and be very motivated to learn more. However, this will take time and it is likely that optimising for SQL Server will not be an immediate skill and there could be some short-term performance impacts identified during testing.
Support with Microsoft is well established in Australia with both the vendor and the partner community.
Migrate to MySQL Enterprise Edition
The Enterprise Edition includes commercial support and features that clients are likely to want to use. Particularly clustering and DR requirements.
The data migration is reasonable as the data types are quite compatible, but the PL/SQL to MySQL 'Routines' is likely to cause major re-design. There are language differences in the MySQL Routines that are reasonably fundamental and will require significant effort and re-coding.
There is a significant skills difference between Oracle and MySQL, however it is highly likely that Oracle personnel will already possess a familiarity with MySQL or adapt to it reasonably quickly. There are extensive resources for MySQL on the web and Oracle maintains detailed documentation for the Enterprise Edition.
Support for MySQL Enterprise will be through Oracle in the same manner that Oracle Standard Edition is supported through My Oracle Support.
Open Source Databases
Migrate to MariaDB
MariaDB was born after Oracle acquired the rights to MySQL and is a community developed open source product in the same fashion as PostgreSQL. It maintains complete compatibility with MySQL community edition and has replaced the MySQL storage engine 'InnoDB' with 'XtraDB' claiming additional capabilities.
MariaDB TX (the OLTP edition as opposed to AX which is used for OLAP) includes the ability for active-active clusters and other high availability features for larger deployments of databases.
Interestingly, MariaDB has taken an approach to be more compatible with the Oracle RDBMS than Oracle's own MySQL. It has support for PL/SQL that will result in less manual changes. There are improvements in recent releases of subquery performance that would be acceptable in Oracle but previously would be concerning in MariaDB (and MySQL) and this is often a significant effort to overcome as it may result in database re-design - however, the likelihood of this becoming a real problem has decreased in recent releases.
MariaDB also has commercial support offerings that has access to the engineering teams.
Migrate to PostgreSQL
The attractiveness of PostgreSQL is that there is no vendor - it has strong community support and is constantly being developed by a large development base worldwide. No vendor, no license fees. As one ISV said to me - they would be in charge of their own destiny rather than relying on a vendor. The reality is that the "destiny" relies on a collection of unknown developers, even if there are many thousands - and the governance process that they have in place. It appears that PostgreSQL is managed maturely and is very rich in features and performance that has attracted cloud providers including Amazon, Microsoft & Google to adopt PostgreSQL in their database service offerings (discussed further below).
There is also the very mature 'PostGIS' extension for geographical objects including geometry types and spatial features. This is an important consideration if you wish to add this capability to your system as Oracle Standard Editions do not have this capability - only the 'Spatial' option is available on Oracle's Enterprise Edition.
PostgreSQL has significant compatibility with Oracle, the PL/pgsql language is very close to Oracle's PL/SQL, the main difference being how they treat transactions, this has to be overcome with design changes. The data types are quite compatible, the main difference concerns the use of timestamps to get the granularity of date fields required. There are several migration tools available to assist the process. Many migrations from Oracle to PostgreSQL have been performed, so there is significant detail available online.
The challenge with PostgreSQL is clustering and operating with large data volumes and user activity. Significant effort may be required to move beyond 'simple' implementations of PostgreSQL and before making any decision to use PostgreSQL as the target you want to ensure that all your DR and scalability requirements can be addressed.
Being an open source product, the support is community based, whilst genuine bugs would be addressed by the community in time, the real effort is in properly discovering, replicating and documenting the bug so that the community may act on it. Minor grievances and wish lists, whilst seldom addressed by vendors, are not likely to be better served by open source unless you establish a contributing team and develop inline with the stated product direction.
Speaking to clients about the use of PostgreSQL the two challenges they have faced is obtaining strong local developer support for problems that enterprises face, and obtaining local support - there are support options out there, but the comprehensive support offerings appear to be outside of Australia and our timezones can impact this.
Migrate to MySQL Community Edition
Oracle is the owner of MySQL and as such has both a community edition and proprietary editions. The differences between those editions are not documented here - needless to say that the proprietary edition, "Enterprise Edition" will have far more capability than the community edition - and is documented above. This section refers to the community edition.
MySQL caters for different storage engines, you would normally migrate to the 'InnoDB' storage engine. The data migration itself won't be too difficult, but the PL/SQL to MySQL 'Routines' is likely to cause major re-design. There are language differences in the MySQL Routines that are reasonably fundamental and will require significant effort and re-coding.
Support for the MySQL community edition is not as straightforward as for other open source products, however, the community edition does benefit from Oracle maintaining the Enterprise Editions and any bugs encountered in those versions that would affect the community edition would be made available. There is a strong development community and forums for the product, commercial support of the community edition does not appear to be readily available.
Database Cloud Services
Rather than own a database that you must maintain yourself, you could decide to move away from the ownership concept altogether and move to a database service in the cloud. Applications will have to change to be able to use database service and the application itself should be moved to the cloud to have fast immediate access to the database. The technology of the application will determine whether it can be migrated and operated in the cloud - so this will be an additional consideration as opposed to remaining on-premise.
When calculating the ROI on embarking on migrating to a database cloud service, it is important that the savings of infrastructure and related infrastructure resources are taken into consideration as well as any savings that could be achieved by a different DR architecture utilising the database services as the cloud providers will already provide you with redundancy at the hardware level.
On-Premise and Open Source databases listed above are also available as a service from leading cloud providers - if your target is one of these databases, then using the equivalent cloud service is also an alternative for you to consider. The individual cloud services are not reviewed here - and whilst they are the same database, the cloud provider may impose restrictions on the database. For example, PostgreSQL allows the installation of many extensions that greatly enhance the database, but the extensions allowed by Amazon, Google and Microsoft is different per provider and limited. The following reviewed databases above are available from the leading cloud providers in the table below -
Below is a list of cloud service providers and the databases that they support as a service that represent a possible migration target.
Oracle Cloud Platform Services
The Oracle RDBMS database has three services on Oracle Cloud: Database Cloud Service; Database Cloud Service - Bare Metal; and Database Exadata Cloud Service. These all represent different use cases, it is most likely that Standard Edition customers will be satisfied with the simplest offering, Database Cloud Service.
This service allows you to choose an 11g or 12c instance and can be configured for high availability and also caters for Oracle Application Express. There are multiple tiers of pricing depending upon the features you desire and are priced per Oracle CPU required.
Being an Oracle database, the only complexity in migrating will be if your database performs operating system functions by calling out from the database, whilst that would need to be re-designed, the remaining migration would be 100% as the destination system is the same as the target and migration methods of restoring from backup are plausible.
The application would have to change in how it connects to the database service, but this would be relatively minor, all other aspects including skills required would remain unchanged and represent a very efficient migration target that minimises risk to your organisation.
Support would also remain unchanged apart from being issued new CSI's by Oracle for the new cloud service.
The new Autonomous Database service is 18c of the database (which means the 2018 main release of database 12.2 - each calendar year will contain a major release to the 12.2 database) combined with artificial intelligence routines driven by machine learning to tune, secure, maintain and monitor the database. At the time of writing only the Data Warehouse (OLAP) version has been released to the Cloud, the OLTP release is due in June 2018 but it is not known whether that includes the Australian data centre or that will be at a later date.
The pricing is not known, however we suspect that this will be at a premium price point compared to the existing database service, however the functionality that we have been exposed to for Autonomous Database holds significant promise and it is likely that clients of Oracle Standard Edition who migrate to the Autonomous Database service will rest assured knowing that they have a highly tuned, maintained and secure instance that allows them to concentrate on their application and related business.
Redshift on Amazon is primarily meant for Data Warehouse engagements and therefore unlikely to be a suitable candidate for Oracle Standard Edition clients.
Amazon has a migration tool that targets the migration of Oracle onto PostgresSQL, MySQL, MariaDB and Aurora. The tool has the ability to convert Oracle's PL/SQL for Aurora and we believe this is most likely going to be the best candidate within the Amazon RDS suite. There are incompatibilities which the tool identifies allowing you to alter to compatible in the source or to alter once in the destination.
The pricing is for continual use of a database instance based on storage and I/O rate (requests to the database). It is quite possible that this pricing model is extremely efficient - particularly for development or test instances that have only a partial set of data with smaller usage.
Support is readily available through a strong partner network for the Aurora and other cloud services that Amazon provides.
SQL Azure is not SQL Server as a service, it is its own unique database - even though it has complete compatibility to SQL Server. It is different to the "SQL Server on Virtual Machines" service that is also offered on Microsoft Azure.
If migrating using Microsoft's tools, you use the SQL Server Migration Assistant to migrate to a local SQL Server instance and then you migrate that instance into Azure SQL once all issues are resolved. There are third party products available that allow you to go direct from Oracle to Azure SQL. Migrating to Azure SQL will have the same challenges as migrating to SQL Server.
There will be a similar impact upon the skills required to manage your Azure SQL instance as you would with SQL Server, but as stated previously, it is likely that the team will be highly motivated to learn this product and become experts.
Support would be a similar arrangement to that of Amazon - the vendor, Microsoft would provide all product support through support portals and also give you access to architects and advisors, but partners would provide a more local support experience.
Options not considered
Other On-Premise Databases
The typical profile of a DB2 client is often much larger than that of an Oracle Standard Edition client - there was no particular attribute of IBM's DB2 that warranted inclusion. It would normally be a consideration for Enterprise Edition clients, but is unlikely to be a strategic target for Standard Edition clients.
This was not included due to the minor use of Informix in the Australian market - and this will have a major impact on the resources available, skills transfer and local support capability.
Other Open Source Databases
The Ingres database has a rich history but is now deemed too niche with minimal use to be considered as a serious target for Oracle Standard Edition. Whilst still being maintained, and a cloud service from IBM for Ingres is available, the support and resource availability would be relatively poor and clients would be better served by PostgreSQL which was spawned from the Ingres code.
Other Database Cloud Services
Oracle on AWS
Migrating to Oracle on Amazon RDS does not really solve any problem because you have to bring your own license - if you choose to use Amazon's included Oracle license, then your existing licenses cannot be used and you in effect, purchase the licenses again with Amazon.
Cloud Spanner on Google Cloud
It is unlikely that a system being run on one of the Oracle Standard Editions is a prime candidate for Cloud Spanner. Cloud Spanner has no triggers, no PL/SQL, it is purely a data repository. All business logic has to be contained within the application layers. It is highly likely that the database design will have to be completely re-done and allow for Spanner's sharding. User security is performed through a IAM model rather than SQL standards. Surprisingly, the SQL in Google Spanner is not ANSI SQL compliant. Unsurprisingly, the impact to skill changes are significant as migrating to Cloud Spanner would be a major undertaking that should not be done in-house but with an experienced partner.
Oracle Database Exadata Cloud at Customer
This is a service where clients have a database hosted and maintained by Oracle as a Service using Oracle Engineered Systems (Exadatas) to provide the service hosted in your own data centre. We do not believe that this expense and extreme capability represents a suitable target for a Standard Edition client.
Your Oracle Standard Edition Roadmap
At a high level, you have four broad choices:
Do nothing and continue with Sustaining Support when Extended Support ends. SE and SE1 will eventually encounter operating system compatibility issues and security vulnerabilities;
Migrate to another proprietary database either run on-premise or hosted in the cloud;
Migrate to another open source database either run on-premise or hosted in the cloud; or
Migrate to a database service.
There is no clear and obvious choice - determining the right choice is driven by your requirements and any related strategy that may be already known. We work with clients in discovering and ratifying that strategy. We work with you on designing and executing the migration strategy. It is not a straight forward exercise, but with the right expertise and planning the transition to a new database can be a rewarding outcome for the business that can enable many new capabilities and potentially lower total cost of ownership.
Read more about our Data Management services