5 New Features for Oracle Exadata System Software Release 20.x

Several new features were introduced for Oracle Exadata System Software release 20.x.

• What's New in Oracle Exadata System Software Release 20.1.0
  

5.1 What's New in Oracle Exadata System Software Release 20.1.0

The following features are new for Oracle Exadata System Software Release 20.1.0:

• Exadata Secure RDMA Fabric Isolation
  
• Smart Flash Log Write-Back
  
• Fast In-Memory Columnar Cache Creation
  
• Cell-to-Cell Rebalance Preserves PMEM Cache Population
  
• Control Persistent Memory Usage for Specific Databases
  
• Application Server Update for Management Server
  

5.1.1 Exadata Secure RDMA Fabric Isolation

Exadata Secure RDMA Fabric Isolation enables strict network isolation for Oracle Real Application Clusters (Oracle RAC) clusters on Oracle Exadata systems that use RDMA over Converged Ethernet (RoCE).

Secure Fabric provides critical infrastructure for secure consolidation of multiple tenants on Oracle Exadata, where each tenant resides in a dedicated virtual machine (VM) cluster. Using this feature ensures that:

• Database servers in separate clusters cannot communicate with each other. They are completely isolated from each other on the network.
• Database servers in multiple clusters can share all of the storage server resources. However, even though the different clusters share the same storage network, no cross-cluster network traffic is possible.

Exadata Secure RDMA Fabric Isolation uses RoCE VLANs to ensure that network packets from one VM cluster cannot be seen by another VM cluster. VLAN tag enforcement is done at the KVM host level, which means that security cannot be bypassed by any software exploits or misconfiguration on the database server VMs.

See Using Exadata Secure RDMA Fabric Isolation.

Minimum requirements:

• Oracle Exadata System Software release 20.1.0
• Oracle Exadata X8M-2
• Deployment must contain VM clusters using Oracle Linux KVM
• Oracle Grid Infrastructure:
  • 19.6.0.0.200114 with patches
  • 18.8.0.0.191015 with patches
  • 12.2.0.1.191015 with patches
  • 12.1.0.2.190716 with patches
• Oracle Database:
  • 19.6.0.0.200114 with patches
  • 18.8.0.0.191015 with patches
  • 12.2.0.1.191015 with patches
  • 12.1.0.2.180831
  • 11.2.0.4.180717

Refer to My Oracle Support Doc ID 888828.1 for details about the required patches.

5.1.2 Smart Flash Log Write-Back

On High Capacity Oracle Exadata Storage Servers, all redo log entries must be written to the hard disk drives (HDDs). Even though Exadata Smart Flash Log prevents occasional log write outliers, the total log write throughput is still bound by the HDDs. Consequently, log writes can become a performance bottleneck when I/O bandwidth is saturated on the HDDs, either because of high-volume redo log activity or because of other I/O-intensive activities such as Golden Gate log mining, log archiving, and RMAN backup and restore.

The Smart Flash Log Write-Back feature automatically and transparently stores the entire contents of redo log files using Exadata Smart Flash Cache in Write-Back mode, thereby eliminating the HDDs as a potential performance bottleneck. Depending on the system workload, overall log write throughput can improve up to 250%.

Smart Flash Log Write-Back works transparently in conjunction with Exadata Smart Flash Log. Smart Flash Log Write-Back boosts overall log write throughput, while Exadata Smart Flash Log continues to prevent log write latency outliers.

Smart Flash Log Write-Back works with Oracle Data Guard Primary and Standby databases, boosting throughput for online redo log files and standby redo log files.

If flash cache space resource management is configured in the IORM plan, then caching of redo log files is included in the space accounting for each multitenant container database (CDB) or non-CDB database.

Minimum requirements:

• Oracle Exadata System Software release 20.1.0.
• Oracle Exadata Database Machine X7.
• Exadata Smart Flash Cache in Write-Back mode.
• Oracle Database in ARCHIVELOG mode.

5.1.3 Fast In-Memory Columnar Cache Creation

Columnar cache with in-memory database formats are created when data is read from the hard disks, where it is stored in the hybrid columnar format. With this feature, columnar cache with in-memory database formats are also created when reading data in an intermediate format from the flash cache.

This feature provides a significant performance improvement for columnar cache creation, especially when there are concurrent workloads utilizing hard disk IO bandwidth. For example, a backup that utilizes the hard disk bandwidth no longer needs to share that bandwidth with the in-memory columnar cache creation. As a result, both the backup and the in-memory columnar cache creation run faster.

See In-Memory Columnar Format Support in the Oracle Exadata System Software User's Guide for more information about the in-memory columnar cache format.

Minimum requirements:

• Oracle Exadata System Software release 20.1.0

5.1.4 Cell-to-Cell Rebalance Preserves PMEM Cache Population

Data rebalancing may occur for a variety of reasons. For example, a rebalance operation might happen to maintain data redundancy when a hard disk suffers a real or predictive failure. When a rebalance operation moves data to a different storage server, some of the data might be cached in the persistent memory (PMEM) cache, also known as Persistent Memory Data Accelerator.

Commencing with Oracle Exadata System Software release 20.1.0, relevant PMEM cache entries are automatically replicated to the target storage server when a rebalance operation moves data to a different storage server.

This feature builds on existing features that preserve data in Exadata Smart Flash Cache during cell-to-cell rebalance operations, resulting in more consistent application performance after a rebalance operation.

Minimum requirements:

• Oracle Exadata System Software release 20.1.0.
• Oracle Exadata Database Machine X8M.

5.1.5 Control Persistent Memory Usage for Specific Databases

This feature introduces pmemcache and pmemlog, which are two new directives for the interdatabase IORM plan. With these directives, you can control persistent memory usage for specific databases and ensure that valuable persistent memory resources are reserved for mission-critical databases, especially in consolidated environments.

You can set pmemcache=off to prevent the specified database from using the persistent memory (PMEM) cache. Likewise, setting pmemlog=off prevents the specified database from using the PMEM log. By default, all databases can use persistent memory for caching and logging.

You can check the current IORM plan settings by issuing the command LIST IORMPLAN DETAIL in CellCLI.

See Using IORM to Control Database Access to Flash and PMEM Resources and Controlling Access to PMEM Cache and PMEM Log in the Oracle Exadata System Software User's Guide for more information.

Minimum requirements:

• Oracle Exadata System Software release 20.1.0
• Oracle Exadata X8M

5.1.6 Application Server Update for Management Server

In this release, Eclipse Jetty replaces Oracle WebLogic Server as the application server engine that is used internally by Oracle Exadata System Software, in particular Management Server (MS).

Oracle Exadata System Software does not need most of the sophisticated functionality provided by Oracle WebLogic Server. Consequently, moving to Eclipse Jetty delivers the following benefits:

• Speed — Eclipse Jetty is a light-weight web server, which consumes considerably fewer system resources than a full-featured application server, like Oracle WebLogic Server. Consequently, Eclipse Jetty can perform the required tasks more efficiently and free up resources to improve system performance across the board.

• Security — As a light-weight web server, Eclipse Jetty improves security by presenting fewer attack vectors. Furthermore, the security of Eclipse Jetty is demonstrated by its use in a wide variety of projects and products, both in development and production.

Minimum requirements:

• Oracle Exadata System Software release 20.1.0.