Oracle Database 21c now available on Oracle Exadata

Oracle Database 21c, the latest Innovation Release, has just been released for Exadata, and with it comes a bevy of new features and enhancements specifically designed to take advantage of the Exadata Database Machine!

Before we go too far, Oracle Database 21c, just like its predecessor 19c includes a dizzying array of features. You can get a quick overview of what's in Oracle Database 21c by watching this short video by Andy Mendelsohn, Executive VP of Oracle Database Server Technologies, and taking a quick read of this blog post from Willie Hardie. For those of us that like a little old-school reading of the manuals, the "Learning Database New Features" book covers all the new features and links to the rest of the documentation library to get you up to speed with anything that grabs your attention.

For those keen to get started with Oracle Database 21c on Exadata, you'll need to be on Exadata System Software 21.2.x for full offload support and upgrade your GI/ASM version to 21c as well. As always, get the latest information from MOS Note 888828.1, including the latest Oracle Exadata Deployment Assistant (OEDA), which has been updated to support Oracle Database 21c.

Innovation Release

Oracle Database 21c is an Innovation Release. Innovation Releases enable customers to rapidly adopt new and enhanced functionality for use cases and applications that could benefit from them. New features in Oracle Database 21c include Blockchain Tables, Native JSON Datatype, SQL Macros, and Javascript execution inside the Oracle Database. Customers should be aware that Innovation Releases have shorter support windows compared to Long Term Releases such as Oracle Database 19c. Customers adopting Innovation releases should be prepared to upgrade to the next database release within one year after the next database release ships.

For the latest Oracle Database 21c availability and support windows on all on-premises platforms (including Exadata) and in Oracle Cloud (including Autonomous Database Services) please refer to MyOracle Support (MOS) note 742060.1.

Let's get back to the features and optimizations in Oracle Database 21c specifically for and on Exadata.

New features in Oracle Database 21c for Exadata

Automatic Indexing enhancements

Introduced in Oracle 19c, Automatic Indexing is a significant step forward in DBA and developer productivity. When enabled, Automatic Indexing constantly monitors database workload, and identifies, creates, and verifies new indexes. This results in faster processing that benefits your application and users. For example, suppose a proposed index, created as an invisible index, doesn't improve performance. In this case, the index is dropped, and the process repeats, albeit with the SQL that corresponds to the not-so-useful index added to an exclusion list to avoid repeating the same test and outcome. Effectively allowing the algorithm to learn from its own mistakes.

If you're not quite ready to completely hand over this task to the Oracle Database, you can run Automatic Indexing in REPORT ONLY mode. So you can get recommendations for new indexes and test the efficacy in a non-production database before creating the index in production.

In its initial release, Automatic Indexing allowed you to limit which schemas it would consider. But Automatic Indexing considered all the tables within those schemas. In 21c, we have increased the granularity of control you have when configuring Automatic Indexing. For example, you can now include or exclude individual tables. This level of control is instrumental to avoid cursor invalidations on critical SQL statements when the index is created initially.

Oracle RAC Cache Fusion Hardening

As most (hopefully all  ) databases running on Exadata are implemented with Oracle Real Application Clusters (RAC), administrators would be aware of the importance of the Global Cache Service Process (LMS) processes and their role in Oracle RAC Cache Fusion. I don’t want to trivialize what these processes do by glossing over them and the internals of Oracle RAC Cache Fusion, but we could spend quite a lot of time doing so - so let’s leave that for another day.

Returning to the topic at hand, the LMS processes do the bulk of the work communicating between database instances when dealing with cache fusion requests. The number of LMS processes is dependent on the number of CPU cores, and they run in higher priority mode. Foreground processes communicate with remote LMS processes running on the remote instance for lock and data block requests. For the purposes of this section, we’re concerned specifically about LMS in the context of instance availability. When processing Cache Fusion requests, LMS can encounter different issues in the form of asserts/internal errors for various reasons such as discrepancies or errors in lock states. However, unlike in the previous releases, LMS will try to recover the error and continue preventing an expensive instance crash. This feature introduced in Oracle Database 21c is known as Oracle RAC Cache Fusion Hardening and enhances high availability by reducing the chances of an instance crash. Ultimately, this makes LMS more robust. This preventative mechanism elevates Oracle and Exadata’s availability even further for mission-critical databases and environments that have consolidated many databases into the Multitenant architecture.

Database In-Memory - CellMemory Level (also backported to 19.8)

Back in Exadata System Software 12.2.1.1.0, we introduced the ability for Exadata Storage Servers to use Flash Cache for storing data in the Database In-Memory format. This is known as the In-Memory Columnar Cache on Storage Servers or "CellMemory". This effectively extends the In-Memory area beyond the database servers into the storage servers allowing much more data to be accessed in this format and for this data to be available for processing with the same fast vector-processing in-memory algorithms as in the database tier. The upshot is that by using both Database Server memory, and the In-Memory Columnar Cache on Storage Servers, you would be able to access significantly more data in the pure in-memory format than if you only used real memory in the Database Servers.

Before Oracle Database 21.3 (and 19.8), the CellMemory feature on Exadata also had to specify a value for INMEMORY_SIZE in order to enable Database In-Memory. From 21.3 (and 19.8), you can now set INMEMORY_SIZE = 0 and INMEMORY_FORCE = CELLMEMORY_LEVEL to take advantage of the Exadata CellMemory feature without allocating the In-Memory column store in the database instances. Remember that this does not affect or change the behavior of the In-Memory Column Cache on Storage Servers feature and you still have to license Database In-Memory to use the feature.

Reverse Connection Support using CMAN Tunnels

For Exadata deployments in highly secure environments, a common requirement is to prevent inbound connections to the database (which sounds somewhat antithetical to why you would deploy a database in the first place if not to connect to it...), allowing only outbound connections. This can be useful to ensure the database, and therefore data is only being used by trusted and known endpoints within a network. But how do you actually connect to the database under such circumstances? Surely you aren't running application code directly on your Exadata Database Servers and pushing data out? No, you're probably not doing this, but what you may want to do is ensure incoming connections to the database are coming from those known and trusted endpoints in your network.

Enter Connection Manager (CMAN). In Oracle 21c, CMAN can be used to create secure tunnels - think ssh tunnels - between the CMAN server, where inbound connections from applications are directed, and a CMAN client running on the database servers. The below diagram shows CMAN clients on the Exadata Database Servers that have created a pool of secure connections back to the CMAN server in the trusted network. Clients and applications connect to the CMAN server in the trusted zone which in turn uses a secure tunnel to connect the client to the database. Simples (c)!

As I mentioned at the start of this post, there are a vast array of new features and optimizations in Oracle Database 21c, and we have only touched on a few that benefit from, or are enhanced by Oracle Exadata. I thoroughly recommend you take a look at the Learning Database New Features guide in the documentation and keep an eye on this and other blogs at blogs.oracle.com/database for regular updates on features.

In the coming weeks and months, we plan on bringing you more posts on Oracle Database 19c and 21c, and of course Oracle Exadata. Stay tuned!