Rethink Oracle Standard Edition Two on Amazon RDS for Oracle

Organizations are adopting the cloud as the standard and actively evaluating their database needs. Amazon Relational Database Service (Amazon RDS) for Oracle is a managed service that makes it easy to set up, operate, and scale Oracle deployments in the cloud. This helps migrate your legacy Oracle database to Amazon RDS for Oracle and, as a result, reduce the need to refactor and change existing application components.

Oracle Database Enterprise Edition (EE) has become the standard for many organizations. However, if you perform a more in-depth database assessment, you may find that not every application needs all the features of Oracle EE.

Oracle Database Standard Edition (SE) now comes as Oracle database Standard Edition Two (SE2) for Oracle 12c and 19c. Oracle SE2 is a relational database management system (RDBMS) with core features of the Oracle database included in it. SE2 has a variety of features that you can use to support enterprise-class workloads. With the additional SE2 features enabled on Amazon RDS such as Amazon RDS Multi-AZ and Amazon RDS for cross-Region automated backups, you can try using SE2 to help you save cost on your applications.

By switching to SE2, you can optimize your Oracle Database license usage. You can provision it with the Amazon RDS for Oracle License Included (LI) option. Applications using no or minimum EE features are recommended candidates for migrating to Oracle Database SE2. Instance sizes up to 16 vCPUs and 128 GiB memory (4xlarge instances) can be provisioned using the LI option or Bring Your Own License (BYOL) options. To help determine which option you want to run your Oracle Database on, please refer to Amazon RDS for Oracle FAQs.

In this post, we discuss different operating options of Oracle databases on Amazon Web Services (AWS), show you the different features between SE and EE on Amazon RDS for Oracle, including tools to transition from EE to SE.

Operating options for Oracle databases on AWS

You have four options for running Oracle Database on AWS:

• Amazon RDS for Oracle, which is a managed database service that helps simplify the provisioning and management of Oracle databases
• Amazon RDS Custom for Oracle, which automates database administration tasks and operations, while making it possible for you as a DBA to access and customize your database environment and operating system
• Running a self-managed Oracle Database directly on Amazon Elastic Compute Cloud (Amazon EC2), which allows you to install and run Oracle databases on EC2 instances
• Running a self-managed Oracle Database directly on VMware Cloud on AWS, which allows you to run Oracle databases in vSphere virtualized environments

Amazon RDS frees you from database management to focus on innovation and application development by managing time-consuming database administration tasks, including provisioning, backups, software patching, monitoring, and hardware scaling. Amazon RDS for Oracle makes it easy to use replication to enhance availability and reliability for production workloads. The Multi-AZ deployment option allows you to run mission-critical workloads with high availability and use built-in automated failover to a synchronously replicated secondary database in case of a failure. RDS for Oracle read replicas within a Region or across Regions and Amazon RDS for Oracle cross-Region automated backups provide a disaster recovery (DR) solution for critical workloads to meet Recovery Point Objective (RPO) and Recovery Time Objective (RTO) goals for your application.

Amazon RDS Custom for Oracle is a managed database service for legacy, custom, and packaged applications that require access to the underlying operating system and database environment. Amazon RDS Custom for Oracle automates setup, operation, and scaling of databases in the cloud while granting you access to the database and underlying operating system to configure settings, install patches, and enable native features to meet the dependent application’s requirements.

Running self-managed Oracle Database directly on Amazon EC2 gives you full control over the setup of the infrastructure and the database environment. Running the database on Amazon EC2 is very similar to running the database on your own server. You have full control of the database and have operating system-level access, so you can run monitoring and management agents and use your choice of tools for data replication, backup, and restoration. Furthermore, you have the ability to use every optional module available in Oracle Database. However, this option requires you to set up, configure, manage, and tune all the components, including EC2 instances, storage volumes, scalability, networking, and security, based on AWS architecture best practices. With fully managed Amazon RDS, this is all taken care of for you.

Running a self-managed Oracle Database directly on VMware Cloud on AWS allows you to run Oracle databases in vSphere virtualized environments. VMware Cloud on AWS is an integrated cloud offering jointly developed by AWS and VMware. Like Amazon EC2, you have full control of the database and have operating system-level access. You can run advanced architectures like Oracle Real Application Cluster (RAC) and Oracle RAC extended clusters (across different Availability Zones) in VMware Cloud on AWS.

If you decide to use SE2, you have multiple options for hosting it in AWS: you can run SE2 on an Amazon EC2 server or a Bare Metal server, or you can run it on AWS-managed Amazon RDS.

Licensing options for Oracle Database on AWS

You can run Amazon RDS for Oracle under two different licensing models: License Included (LI) or Bring Your Own License (BYOL).

In the LI service model, you don’t need to separately purchase Oracle licenses; the Oracle Database software has been licensed by AWS. In this model, if you have an active AWS Premium Support account, you should contact AWS Premium Support for both Amazon RDS and Oracle Database-specific service requests. The LI model is only supported on Amazon RDS for Oracle Database SE2.

Under the BYOL model, you can use your existing Oracle Database licenses to run Oracle databases in Amazon RDS. To run a DB instance under the BYOL model, you must have the appropriate Oracle Database license (with Software Update License & Support). Under this model, you continue to use your active Oracle support account and contact Oracle directly for Oracle Database-specific service requests. If you have an active AWS Premium Support account, you can contact AWS Premium Support for Amazon RDS-specific issues. Amazon RDS supports the BYOL model only for Oracle Database EE and Oracle Database SE2.

Amazon RDS for Oracle supports both licensing models, and with the LI option, you can quickly provision Amazon RDS for Oracle with SE2. You can run Oracle on Amazon EC2 under the BYOL licensing model.

Oracle Database SE2 and Amazon RDS

Let’s do a feature comparison between SE2 running on a self-managed EC2 instance or on-premises server and running on Amazon RDS for Oracle.

The core capabilities of SE2 remain the same when running on premises or on self-managed EC2 instances or on Amazon RDS, but the high availability of the database can be managed using Multi-AZ configuration in the Amazon RDS.

When Multi-AZ is enabled, a standby database is automatically created in another Availability Zone, and the automatic failover is triggered when the primary database fails or if the Availability Zone in which that primary database is running becomes unavailable.

There is no TDE encryption available for data at rest in SE2 when running on self-managed Amazon EC2 or an on-premises server, however Oracle Native Network Encryption (NNE) and TLS/SSL Security are available for encrypting data in transit. For SE2 running in Amazon RDS, AWS Key Management Service (AWS KMS) allows either an Amazon generated key or a customer generated key to be stored and used to encrypt data at rest, and Oracle NNE and TLS/SSL are available for encrypting data in transit.

There is no Oracle diagnostic pack available in SE for monitoring and tuning. But Oracle Statspack is available in SE2, which you can use to quickly gather detailed analysis of the performance of the database. When you run SE2 in Amazon RDS for Oracle, you can monitor it with Amazon CloudWatch, Amazon RDS Performance Insights, and Amazon RDS Enhanced Monitoring, in addition to Oracle Statspack reports, for database performance monitoring and analysis.

There are no automated backups available with SE2 running on a self-managed Amazon EC2 server; for backups, you must write scripts and test them before implementing them to perform regular backups. Amazon RDS offers automated backups that can be retained up to 35 days, as well as on-demand backups that can be retained for an indefinite period of time using the Amazon RDS snapshots capability.

When running SE2 on an EC2 instance, you must use a self-managed script to create the backup and store it at a remote location for DR purposes, but with Amazon RDS cross-Region automated backup, which includes both snapshots and archived redo logs, you can achieve cost-effective cross-Region DR with a low RPO and reduced RTO compared to self-managed scripting.

The following table summarizes the comparison between Oracle Database SE2 and Amazon RDS for Oracle with SE2.

Amazon RDS for Oracle: Comparing editions

Now let’s compare features between Amazon RDS for Oracle with Enterprise Edition and Standard Edition.

There is no difference in standard RDBMS functionality between EE and SE2. For more information about Oracle licensing, options, and packages offered under EE and SE2, see Licensing Information.

The automatic database backup capability is available for both EE and SE2 in Amazon RDS for Oracle, with regular daily scheduled backups that can be retained for up to 35 days. The automated backup feature of Amazon RDS enables point-in-time recovery (PITR) of your DB instance, which allows you to restore your DB instance to any second during your retention period, up to the last 5 minutes. In addition to regular automated backups, you can also take manual on-demand snapshots when necessary, which you can retain for an unlimited time period. Amazon RDS supports cross-Region automated backups for Amazon RDS for Oracle for versions 12.1 (starting from 12.1.0.2.v10) and higher. This feature is supported for Amazon RDS for Oracle customers who use any edition of Oracle Database with the LI or BYOL models. The Amazon RDS cross-Region automated backup feature enables the disaster recovery capability for mission-critical workloads by allowing you to restore your database to a specific point in time within your backup retention period.

You can monitor database instances using CloudWatch, which collects near-real-time metrics such as CPU, storage, and memory utilization. With Enhanced Monitoring, you can monitor the operating system of your database instance in real time when metrics are collected at an interval you define, from 1 second to 5 minutes. Enhanced Monitoring metrics are useful when you want to see how different processes or threads on a database instance use the CPU. Performance Insights is a database performance monitoring and tuning feature that helps you quickly assess the load on your database, and determine when and where to take action. With the Performance Insights dashboard, you can visualize the database load and filter the load by waits, SQL statements, hosts, or users.

You can also implement Oracle Enterprise Manager (OEM) Cloud Control on premises or in AWS. You can monitor RDS for Oracle instances using OEM monitoring. Amazon RDS for Oracle supports Management Agent for both EE and SE2. The Tuning and Diagnostics Packs are only available with the Enterprise Edition of the Oracle Database, which provides an AWR report that collects, processes, and maintains performance statistics for problem detection and self-tuning purposes. For SE2, Statspack reports collect the same metrics in order to quickly analyze the performance of the database instance. Oracle SQL plan management (SPM) is available in SE2, which ensures that runtime performance doesn’t degrade due to execution plan changes, however use of baselines is limited to one per SQL statement. Additionally, the SQLT (SQLTXPLAIN) tool can help you to diagnose slow-running SQL statements.

When Multi-AZ is configured for Amazon RDS for Oracle, it automatically provisions and maintains a synchronously replicated standby replica in a different Availability Zone than where the primary database is running. This feature is available for both EE and SE2. If any problems are encountered with the primary database, Amazon RDS automatically switches to the standby copy to provide high availability and data durability for your application.

The encryption of data at rest in Amazon RDS for Oracle uses AWS KMS to manage encryption keys that are created by either Amazon or you, and it’s available for both EE and SE2. On a database instance running with Amazon RDS encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots. Amazon RDS also supports Transparent Data Encryption (TDE) for EE (through the Oracle Advanced Security option in Enterprise Edition).

You can encrypt communications between your application and your Oracle Database instance using SSL/TLS , where Amazon RDS creates an SSL certificate and installs the certificate on the DB instance when the instance is provisioned. Amazon RDS also supports Oracle native network encryption (NNE) for all editions of Oracle Database.

Database Activity Streams (DAS) for Amazon RDS for Oracle provides a near-real-time stream of all audited statements (SELECT, DML, DDL, DCL, TCL) used in your DB instance. The feature is available for both EE and SE2.

With EE, you can configure the Oracle DB instance replication using the Oracle Data Guard feature, but the same feature isn’t available in SE2. You can create a replica for your primary RDS for Oracle DB instance with EE in mounted mode or in read-only mode using Oracle Active Data Guard.

The following table summarizes the comparison between Amazon RDS for Oracle using EE or SE2.

Now let’s look at the high availability and disaster recovery features in both EE and SE2. Recovery Time Objective (RTO) and the Recovery Point Objective (RPO) are two key metrics to consider when developing a DR plan. RTO is the targeted amount of time for a recovery to complete in the event of failure. RPO is the targeted amount of time during which data is at risk for loss in the event of a failure. For example, an RPO of 30 minutes means that you could lose up to 30 minutes’ worth of data when a disaster occurs.

For high availability in Amazon RDS for Oracle, Multi-AZ deployments are available for all Oracle Database editions supported by Amazon RDS. When you enable the DB instance to run as a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronously replicated standby replica in a different Availability Zone than where your primary database is running. Updates to your DB instance are synchronously replicated at the storage level across Availability Zones to the standby copy in order to keep both in synchronization and protect your latest database updates against DB instance failure with zero data loss. In case of an infrastructure failure, Amazon RDS performs an automatic failover to the standby, so that you can resume database operations as soon as the failover is complete. Failover times are typically 60–120 seconds. However, large transactions or a lengthy recovery process can increase the failover time. You can also initiate a manual failover through the Amazon RDS API. Amazon RDS provides an SLA with a monthly uptime percentage of 99.95%.

When automated backups are turned on for your DB instance, Amazon RDS automatically performs a full daily snapshot of your data. The snapshot occurs during your preferred backup window. It also captures Oracle archive redo logs to Amazon Simple Storage Service (Amazon S3) every 5 minutes as updates to your DB instance are made. Archiving the redo logs is an important part of your DR process and PITR process. Amazon RDS creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases. You can create a new DB instance by restoring from a DB snapshot. You provide the name of the DB snapshot to restore from, and then provide a name for the new DB instance that is created from the restore. You can’t restore from a DB snapshot to an existing DB instance; a new DB instance is created when you restore. You can use the restored DB instance as soon as its status is available. The DB instance continues to load data in the background. This is known as lazy loading. If you access data that hasn’t been loaded yet, the DB instance immediately downloads the requested data from Amazon S3, and then continues loading the rest of the data in the background.

When you initiate PITR, redo logs are applied to the most appropriate daily backup in order to restore your DB instance to the specific requested time. Amazon RDS supports cross-Region automated backups for Amazon RDS for Oracle. When this feature is enabled, the snapshots and archive redo log backups captured and retained in the source Region where your RDS instance resides are automatically replicated to a second Region. Amazon RDS then maintains the snapshot and archived logs according to your chosen backup retention period to enable the PITR capability in the destination Region. This feature is ideal if you need a cost-effective DR capability that helps save on compute and, in some cases, licensing costs until a PITR is needed in another Region.

Before you consider a cross-Region DR strategy, you need to evaluate whether an in-Region DR solution meets your needs or not. As we explained before, highly available Multi-AZ deployment is usually sufficient for a DR strategy within one Region in an AWS Cloud environment for many organizations.

The following table summarizes the HA and DR capabilities of Oracle EE and SE2 on Amazon RDS for Oracle.

How to transition from EE to SE2

In this section, we discuss how to assess features that you can replace in SE2, and how to migrate to Amazon RDS for Oracle. For more information about the SE2 features, limits, and licensing of SE2, and how to remain compliant, refer to the FAQ or talk to your Oracle partner.

Assess features you can replace in SE2

Numerous blog posts and scripts are available to help you assess migrating from EE to SE2. You can start with the script called options_packs_usage_statistics.sql provided by Oracle support document 1317265.1. When you run this script against your database, it produces a comprehensive report on feature, option, and management pack usage in your database. You can use this to determine whether you’re using all the Oracle options that you have licensed for, or if you can use SE2 and use the features and options in SE2 to run your application.

Additionally, certain features may not be available in SE2, such as Oracle Partitioning. To replace the table partitioning feature available in EE, you can implement a similar feature in SE2 using sub-tables in place of partitions, creating a view on top of those sub-tables, and then writing some INSTEAD OF triggers. This solution controls the DML statements hitting that particular table. For more information about table partitioning in SE2, see Implementing table partitioning in Oracle Standard Edition: Part 1.

Your ability to monitor, view, analyze, and resolve performance bottlenecks is constrained by the inability to add Diagnostic Packs and Tuning Packs to SE2. You can use Performance Insights and Enhanced Monitoring to gather SQL query response time, wait statistics, and CPU utilization, which provides DBAs and developers with the tools necessary to minimize CPU utilization while improving SQL query response time on SE2. This is done without the need for OEM’s Diagnostic Packs, Tuning Packs, or access to AWR tables. For more information, see Analyzing performance management in Oracle SE using Amazon RDS for Oracle.

The SQL plan stability is vital to maintain query consistency. Stored outlines, hints, and SQL plan management (SPM) offerings can help fix your SQL query plans in SE2. For more information about SPM offerings in SE2, see Managing your SQL plan in Oracle SE with Amazon RDS for Oracle.

Another feature that enterprise customers are using is Transparent Data Encryption (TDE) in Oracle EE to meet requirements for data-at-rest encryption. With some TDE implementations, you can encrypt tables, rows, and columns to achieve a granular level of encryption. However, the most common configuration is encrypting the whole database with TDE. SE2 when hosted in AWS can use AWS KMS to encrypt the data at rest. When encryption is enabled for an RDS for Oracle DB instance, the encryption is enabled for all logs, backups, and snapshots of that database. For more information about the different options for database encryption on AWS, refer to Architecting for database encryption on AWS.

The tools, scripts, and posts we’ve mentioned in this section can all help you use the features in SE2 to run your application successfully.

Migrating Oracle databases from EE to Amazon RDS for SE2

For migrating an Oracle database to Amazon RDS with EE or SE or self-managed Oracle database on Amazon EC2, you can choose Oracle database native tools like Oracle Data Pump, Oracle Export and Import, as well as Oracle Materialized Views to refresh the data in the target database. Similarly, Oracle GoldenGate is a tool for a full load, real-time change data capture (CDC), and continuous replication of the data for migration and for HA and DR purposes. You can use it to perform minimal-downtime data migration from on-premises databases to the target RDS for Oracle or Oracle database running on Amazon EC2.

AWS Database Migration Service (AWS DMS) can support several migration and replication strategies, including a bulk upload at a point in time and a minimal downtime migration using CDC, or migration of only a subset of the data. AWS DMS supports sources and targets in Amazon EC2, Amazon RDS, and on-premises infrastructures because no client install is required. An alternative method is to use Oracle Data Pump for the initial load and AWS DMS to replicate changes from the Oracle SCN point where data dump has stopped. For more information about AWS DMS, visist the AWS DMS User Guide.

Summary

In this post, we discussed the feature differences between Oracle Database Standard Edition Two (SE2) and the Enterprise Edition (EE). We also looked at backup and HA and DR capabilities that you can add to SE2 when it’s hosted in Amazon RDS for Oracle. We also discussed how to replace some of the features of EE in SE2 databases. Finally, we touched upon migration options for migrating EE to SE2 on Amazon RDS for Oracle platforms or to self-managed Oracle Database on Amazon EC2.

Share your questions or feedback in the comments section.

About the Authors

Manash Kalita is an Amazon Web Services Senior Database Specialist Solutions Architect for ASEAN, having extensive experience in Enterprise Cloud Architecture.

Sachin Vaidya is an Amazon Web Services Senior Database Specialist Solutions Architect for US region, having extensive experience in Enterprise Cloud Architecture.