7 New Features for Oracle Exadata System Software Release 18

Several new features were introduced for Oracle Exadata System Software Release 18.

• What's New in Oracle Exadata Database Machine 18c (18.1.0)
  
• Oracle Exadata Database Machine X7 New Features
  The following new features are available with Oracle Exadata Database Machine X7:

7.1 What's New in Oracle Exadata Database Machine 18c (18.1.0)

The following features are new for Oracle Exadata System Software 18c (18.1.0):

• In-Memory OLTP and Consolidation Acceleration
  
• In-Memory Columnar Caching on Storage Servers
  
• Oracle Exadata Storage Server Cloud Scale Software Update
  
• Faster Oracle Exadata Database Server Software Update
  
• Improved Ethernet Performance in Oracle VM
  
• Performance Improvement Following Disk Online Completion
  
• Improved High Availability After Flash Failures
  
• IORM Maximum Utilization Limit Applies to Flash Devices
  
• OEDA Command Line Interface
  

7.1.1 In-Memory OLTP and Consolidation Acceleration

Oracle Exadata Storage Servers add a new memory cache in front of flash memory. This is similar to how the current flash cache is in front of hard disks. This feature provides 100 microsecond (µs) online transaction processing (OLTP) read IO latency, which is 2.5 times lower than the 250 μs flash OLTP read IO latency. You can use existing memory upgrade kits to add more memory to storage servers to take advantage of this feature.

Cell RAM cache is a cache in front of the Flash Cache on storage servers and is extension of the database cache. It is faster than the Flash Cache, but has smaller capacity. When buffers are aged out of the database buffer cache, the database notifies the cells so that the cell RAM cache can be populated with these buffers according to caching policies. These buffers are exclusively cached in the cell RAM cache. If a data block needs to be returned to the database buffer cache, then the buffer, if present, is evicted from the cell RAM cache. The cell RAM cache is an exclusive cache — the data block is present only in the cell RAM cache or in the database buffer cache, but not in both.

During read operations, if a data block is not found in the database buffer cache (cache miss), then the database issues a read for the data block from the cell. CELLSRV checks the RAM cache before accessing a lower layer in the IO stack (flash memory or hard disk):

• If the data block is found in the RAM cache, then the data block is returned synchronously to the database. If the data block is going to be cached in database buffer cache, then the storage server evicts the data block from RAM cache.

• If the data block is not found in RAM cache, then the storage server looks in the Flash cache. If the data block is not found in the Flash cache, then the data block is read from disk. The data block is returned to the database, but the data block is not added to the RAM cache.

During write operations, the database issues a write for a data block to the storage server. Cell Server (CELLSRV) checks the RAM cache before accessing a lower layer in the IO stack (Flash Cache or hard disk):

• If the data block is found in the RAM cache, then CELLSRV invalidates the corresponding cache line in the RAM cache, and sends the data block to the lower layer to be written to disk. The RAM cache is not populated.

• If the data block is not found in RAM cache, then the storage server sends the data block to the lower layer to be written to disk. The RAM cache is not populated.

Unlike the flash cache, the RAM cache on the storage servers is an exclusive cache — the data block stored is present either in RAM cache or in the buffer cache of the database, but not both. When the database evicts a data block from buffer cache, it instructs CELLSRV to populate the data block in the RAM cache. CELLSRV populates the RAM cache in an asynchronous manner.

In the event of storage server failure on the primary mirror, the database sends the RAM cache population to the secondary mirror, so that the blocks are now cached in the RAM cache for the secondary mirror. When the primary mirror comes back to online state, the blocks are populated back in the primary mirror’s RAM cache.

A new Memory Cache section is available in the AWR report for monitoring RAM cache status and activities.

Minimum requirements:

• Oracle Exadata System Software 18c (18.1.0)

• Oracle Exadata Storage Server X6 or X7

• Oracle Database version 12.2.0.1 April 2018 DBRU or 18.1 or higher

7.1.2 In-Memory Columnar Caching on Storage Servers

Oracle Exadata System Software release 12.2.1.1.0 introduced the support for In-Memory Columnar Caching on Oracle Exadata Storage Servers for Exadata Hybrid Columnar Compression tables. Oracle Exadata System Software 18c (18.1.0) extends the support for In-Memory Columnar Caching on storage servers for additional table types, specifically uncompressed tables and OLTP compressed tables.

By extending the Database In-Memory format for uncompressed tables and OLTP compressed tables, smart scan queries on more table types can benefit from fast vector-processing in-memory algorithms on data stored in the storage flash cache. With this format, most in-memory performance enhancements are supported in Smart Scan including joins and aggregation. Database In-Memory format is space efficient and usually takes up less space than uncompressed or OLTP compressed formats. Storing data in Database In-memory format results in better storage flash cache space utilization.

Rewriting data from the traditional uncompressed or OLTP compressed format to Database In-Memory format is very CPU intensive. Oracle Exadata System Software has built-in intelligence to cache data in Database In-Memory format for regions that are not modified frequently.

Data from normal (unencrypted) as well as encrypted tablespaces can be cached in the in-memory columnar cache format.

Just as with Oracle Database In-Memory, the new Database In-Memory format is created by a background process so that it does not interfere with the performance of queries.

This feature is enabled by default when you configure the INMEMORY_SIZE database initialization parameter; no further configuration is required to use this feature. If INMEMORY_SIZE is not configured, then uncompressed tables and OLTP compressed table data is cached in Flash Cache in its native format and not in the Database In-Memory columnar format.

If you need to disable this feature, you can use a new DDL keyword CELLMEMORY with the ALTER TABLE command. See "Enabling or Disabling In-Memory Columnar Caching on Storage Servers" in Oracle Exadata System Software User's Guide.

Minimum requirements:

• Oracle Exadata System Software 18c (18.1.0)

• Oracle Database 12c release 1 (12.1.0.2) version 12.1.0.2.161018DBBP or Oracle Database 12c release 2 (12.2.0.1)

• Patch for bug 24521608 if using Oracle Database 12c release 1 (12.1.0.2)

• (Recommended) Patch for bug 26261327 (Enables better reverse offload functionality for complex queries)

7.1.3 Oracle Exadata Storage Server Cloud Scale Software Update

The Oracle Exadata Storage Server Cloud Scale Software Update feature introduces a brand new cloud-scale software update process for storage servers. You point the storage servers to a software store. The storage servers download new software in the background. You can schedule the preferred time of software update. Storage servers automatically upgrade the Oracle Exadata System Software in a rolling fashion while keeping the databases online. A single software repository can be used for hundreds of storage servers. This feature provides simpler and faster software updates for Cloud and On-Premise customers.

Each storage server downloads the software to its active partition, and then loads the software on its passive partition. The storage servers then reboot to the new version according to a specified schedule.

This feature improves scalability of software updates by allowing storage servers to update without dedicated patchmgr sessions. When updating hundreds of storage servers, administrators can use dcli to issue ALTER SOFTWAREUPDATE commands to set the software location and time parameters for all storage servers. Multiple software locations could be used for very large deployments to reduce contention.

See Scheduling Automated Updates of Storage Servers in the Oracle Exadata Database Machine Maintenance Guide for details.

Minimum requirements:

• Oracle Exadata System Software 18c (18.1.0). You can use this feature to install subsequent software updates.

7.1.4 Faster Oracle Exadata Database Server Software Update

The Oracle Exadata Database Server software update process now takes significantly less time than before and is up to 40% faster compared to previous releases. This helps reduce the cost and effort required to update the software on database server.

Minimum requirements:

• Oracle Exadata System Software 18c (18.1.0)

7.1.5 Improved Ethernet Performance in Oracle VM

Oracle Exadata System Software 18c (18.1.0) has optimized receive and transmit of Ethernet packets for systems using virtualization. This optimization provides significant network performance boost with lower network latency and improved CPU utilization on the management domain (dom0) and user domains (domU).

Minimum requirements:

• Oracle Exadata System Software 18c (18.1.0)

7.1.6 Performance Improvement Following Disk Online Completion

In previous releases, during Oracle ASM resync operations, if the cachelines are not cached in source storage server, even if they have been cached in target storage server, Oracle Exadata System Software evicts them from the flash cache of the target storage server. This potentially impacted primary mirrors, resulting in cache misses and degraded performance.

Starting with this release, Oracle Exadata System Software ensures that cachelines in the Oracle ASM resync chunk region that are already in the flash cache are preserved, instead of being invalidated. This helps prevent cache misses. This feature provides significant performance improvement compared to earlier version releases for during Oracle ASM resync operations.

Minimum requirements:

• Oracle Exadata System Software 18c (18.1.0)

7.1.7 Improved High Availability After Flash Failures

Overall system performance after flash failures has been improved. Previously, after a flash failure, Oracle ASM would start reading from the disks on the affected Oracle Exadata Storage Server as soon as flash resilvering completes. However, the storage server would still have a fewer than normal number of flash devices, so performance on that storage server was affected. Starting with Oracle Exadata System Software 18c (18.1.0), Oracle ASM starts reading from the disks only after all failed flash devices are replaced on that storage server.

Minimum software required:

• Oracle Exadata System Software 18c (18.1.0)

7.1.8 IORM Maximum Utilization Limit Applies to Flash Devices

Starting with Oracle Exadata System Software release 18c (18.1.0), using LIMIT in an I/O Resource Management (IORM) plan directive or max_utilization_limit in an intra-database resource plan directive restricts the I/O utilization for a database on flash devices as well hard disks.

The concept of maximum utilization limit (LIMIT) is supported by IORM. In addition to specifying the resource allocation values, you can also provide a maximum utilization limit for a given database. This directive ensures that the database never utilizes I/O resources beyond the specified limits. For example, if a production and test database are sharing the Exadata cell, then you could specify LIMIT for the test database to limit the I/O utilization for the test database.

If a maximum utilization limit is specified, then excess capacity is never used by the databases. It is possible that the disks are running below full capacity when maximum utilization limits are specified.

See ALTER IORMPLAN or Understanding I/O Resource Management.

Minimum software required:

• Oracle Exadata System Software 18c (18.1.0)

7.1.9 OEDA Command Line Interface

The Oracle Exadata Deployment Assistant (OEDA) command-line interface (oedacli) is a new interface you can use to update an existing es.xml file. These updates are called Actions. An Action is a single atomic task. An example of an Action might be to create a new Guest. An Action can have many sub commands; however, most actions are single commands. Examples of multi-command steps are CLONE GUEST and CLONE CELL.

You can use oedacli to help with various Exadata life cycle management tasks, such as:

• Add node to or remove node from a Virtual Cluster on Oracle Exadata Database Machine

• Add database home to or remove database home from physical cluster

• Add or remove storage cells

• Resize Oracle ASM disk groups

• Add or remove additional databases

• Add or remove additional database homes to an Oracle VM cluster

See About the OEDA Command Line Interface in the Oracle Exadata Database Machine Installation and Configuration Guide for details.

Minimum software required:

• Oracle Exadata System Software 18c (18.1.0)

• Oracle Exadata Deployment Assistant (OEDA), August 2017 release

7.2 Oracle Exadata Database Machine X7 New Features

The following new features are available with Oracle Exadata Database Machine X7:

• Do Not Service LED on Storage Servers
  
• Online Flash Disk Replacement for Oracle Exadata Storage Server X7
  
• New Configuration for System Partitions on Storage Servers
  
• Secure Boot
  

7.2.1 Do Not Service LED on Storage Servers

Powering off an Oracle Exadata Storage Server in a cluster with reduced redundancy may cause Oracle ASM disk group force dismount and compromise data availability. To prevent human errors such as mistakenly powering off the wrong storage server, on Oracle Exadata Database Machine X7 come with a new Do Not Service LED. This LED indicates whether it is safe to power off the Oracle Exadata Storage Server for services. Starting with Oracle Exadata System Software release 18.1, the Do Not Service LED is turned on automatically in real-time when redundancy is reduced to inform system administrators or field engineers that the storage server should not be powered off for services.

For example, if a storage server or disk is offline, Oracle Exadata System Software automatically turns on the Do Not Service LED on the storage servers that contain the partner disks to indicate these servers should not be turned off for servicing. When redundancy is restored, Oracle Exadata System Software automatically turns off the Do Not Service LED to indicate that the storage server can be powered off for servicing.

See the following for additional details:

• Exadata Storage Server X7-2 LEDs in the Oracle Exadata Database Machine Maintenance Guide

• LIST CELL in the Oracle Exadata System Software User's Guide

Minimum requirements:

• Oracle Exadata System Software release 18.1.0.0.0

• Oracle Grid Infrastructure:

  • Release 12.1.0.2 July 2017 BP with ARU 21405133

  • Release 12.1.0.2 October 2017 BP or later

  • Release 12.2.0.1 July 2017 BP with ARU 21405125

  • Release 12.2.0.1 October 2017 BP or later

• Oracle Exadata Database Machine X7-2 or X7-8 (storage servers only)

7.2.2 Online Flash Disk Replacement for Oracle Exadata Storage Server X7

Previous generations of Oracle Exadata Database Machine allowed for online flash disk replacement in Oracle Exadata Storage Server X7-2 Extreme Flash, but flash disk replacement in Oracle Exadata Storage Server X7-2 High Capacity still required server downtime. Starting with Oracle Exadata Database Machine X7-2L and X7-8, flash disks in Oracle Exadata Storage Server X7-2 High Capacity can also be replaced online without server downtime.

Oracle Exadata System Software constantly monitors flash disk health. If a flash disk fails or experiences poor performance, then the disk can be replaced right away. If a flash disk enters predictive failure, then, to ensure redundancy, flash disk should not be replaced until:

• Oracle ASM disk rebalance completes if the device is used as data grid disk

• Flash cache flush completes if the device is used for flash cache

Oracle Exadata System Software automatically monitors the progress of Oracle ASM disk rebalance and flash cache flush operations and sends a notification to users once the flash disk can be safely replaced without compromising redundancy. In any case, when it's safe to replace a flash disk, Oracle Exadata System Software automatically prepares the flash disk for online replacement and moves the flash disk to dropped for replacement status to indicate it's ready to be replaced. In addition, Oracle Exadata System Software automatically turns on the attention LED on the flash card and turns off the power LED on the card to help identify the card to replace.

System administrators or field engineers can open the chassis without shutting down the storage server, easily identify the card by the LED pattern, and replace the disks.

See Performing a Hot Pluggable Replacement of a Flash Disk in Oracle Exadata Database Machine Maintenance Guide for details.

Minimum requirements:

• Oracle Exadata Storage Server X7-2 Extreme Flash

• Oracle Exadata System Software release 18.1.0.0.0 and Oracle Exadata Storage Server X7-2 High Capacity or Oracle Exadata Database Machine X7-8

7.2.3 New Configuration for System Partitions on Storage Servers

Previous generations of Oracle Exadata Database Machine use portions of two disks at slot 0 and 1 as system partitions. This is where the operating system and Oracle Exadata System Software are installed. Starting with Oracle Exadata Database Machine X7, there are two M.2 disks dedicated for system partitions. All hard disks on Oracle Exadata Storage Server X7-2 High Capacity and all flash disks on Oracle Exadata Storage Server X7-2 Extreme Flash are dedicated now for data storage only.

This configuration separates the system I/Os from the data I/Os and improves the performance on data disks at slot 0 and 1. Storage server disks now can be created on the entire disks at slot 0 and 1 and have a uniform size across all disks.

Additionally, Oracle Exadata System Software creates system partitions on the M.2 disks with the latest Intel Rapid Storage Technology enterprise (Intel RSTe) RAID, which delivers faster performance and better data protection compared to the traditional software RAID.

Oracle Exadata System Software also supports online replacement of the M.2 disks. The M.2 disks can be replaced without server downtime.

See Maintaining the M.2 Disks of Exadata Storage Servers in Oracle Exadata Database Machine Maintenance Guide for details.

Minimum software required:

• Oracle Exadata System Software 18c (18.1.0)

• Oracle Exadata Database Machine X7-2 or Oracle Exadata Database Machine X7-8

7.2.4 Secure Boot

Secure Boot is a method used to restrict which binaries can boot the system. With Secure Boot, the system UEFI firmware will only allow boot loaders that carry the cryptographic signature of trusted entities. In other words, anything run in the UEFI firmware must be signed with a key that the system recognizes as trustworthy. With each reboot of the server, every component in the boot sequence is verified. This prevents malware from hiding embedded code in the boot sequence.

• Intended to prevent boot-sector malware or kernel code injection

• Hardware-based code signing

• Extension of the UEFI firmware architecture

• Can be enabled or disabled through the UEFI firmware

See Restricting the Binaries Used to Boot the System in Oracle Exadata Database Machine Security Guide for details.

Minimum software required:

• Oracle Exadata System Software release 18c (18.1.0)

• Oracle Exadata Database Machine X7-2 or X7-8

• Bare metal installation