6 New Features for Oracle Exadata System Software Release 19.x

Several new features were introduced for the various versions of Oracle Exadata System Software Release 19.x.

• What's New in Oracle Exadata Database Machine 19.3.0
  
• What's New in Oracle Exadata Database Machine 19.2.0
  
• What's New in Oracle Exadata Database Machine 19.1.0
  

6.1 What's New in Oracle Exadata Database Machine 19.3.0

The following features are new for Oracle Exadata System Software 19.3.0:

• Persistent Memory Data Accelerator
  
• Persistent Memory Commit Accelerator
  
• Support for Oracle Exadata X8M Systems
  
• Instant Failure Detection for X8M Systems
  
• KVM for Virtual Environments
  
• Faster Encrypted Table Smart Scans
  
• Smart Aggregation
  
• Smart In-Memory Columnar Cache with Row IDs
  
• Smart In-memory Columnar Cache with Chained Rows
  
• Encryption of System Logs to Remote Destinations
  
• Update a Single SNMP User Definition
  
• Securing Storage Server Software Processes with Memory Protection Keys
  
• Default XFS File System for X8M Servers
  
• Oracle Linux Kernel to Unbreakable Enterprise Kernel 5 and Oracle Linux Distribution Upgraded to Oracle Linux 7.7
  
• Software Certification Ends for Exadata Database Machine X2 Servers
  

6.1.1 Persistent Memory Data Accelerator

Oracle Exadata Storage Server can now use a Persistent Memory (PMEM) Cache in front of Flash Cache. Known as Persistent Memory Data Accelerator, the PMEM cache uses Intel Optane™ DC Persistent Memory Modules (DCPMM). The Database Server uses remote direct memory access (RDMA) to enable 10x faster access latency to remote persistent memory.

Since the persistent memory is used as a shared cache, caching capacity effectively increases by 10x compared to directly using the persistent memory modules as expensive storage. This arrangement makes it cost effective to apply the benefits of persistent memory to multi-terabyte databases.

See Persistent Memory and RDMA for details.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0
• Oracle Database 19c
• Oracle Exadata Storage Server X8M-2

6.1.2 Persistent Memory Commit Accelerator

Consistent low latency for redo log writes is critical for OLTP database performance, since transactions are committed only when redo logs are persisted. Furthermore, slow redo log persistence affects critical database algorithms. With the persistent memory commit accelerator, Oracle Database 19c uses Remote Direct Memory Access (RDMA) to write redo records in persistent memory on multiple storage servers. By using RDMA, the redo log writes are up to 8x faster, and excellent resilience is provided because the redo log is persisted on multiple storage servers.

On each storage server, the persistent memory area contains only the recently written log records and persistent memory space is not required for the entire redo log. Therefore, hundreds of databases can share the persistent memory area, enabling consolidation with consistent performance.

See Persistent Memory and RDMA for details.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0
• Oracle Database 19c
• Oracle Exadata Storage Server X8M-2

6.1.3 Support for Oracle Exadata X8M Systems

A new class of Database and Storage Server, designated X8M, are designed to utilize RDMA over Converged Ethernet. Known as RoCE (pronounced rocky), RDMA over Converged Ethernet is the combination of using the existing Remote Direct Memory Access (RDMA) networking verbs, in association with the InfiniBand™ Trade Association (IBTA) standards based extensions for Converged Ethernet to enable high speed fabrics over Ethernet layer 2 and 3 networks. RoCE shares a common API infrastructure with InfiniBand, differing only at the physical and link layers. All existing Oracle Exadata high-performance architecture and tuning is compatible with the new network.

Oracle Exadata X8M-2 and X8M-8 Database Servers utilize 100Gb/sec RDMA Network cards, which enables higher IO performance, and, when used in conjunction with Oracle Exadata X8M-2 Storage Servers with persistent memory acceleration, experience up to 10x lower latency for RDMA reads. All Oracle Exadata X8M-2 Storage Servers use the 100Gb/sec RDMA network cards, however the Extended Storage Server (XT) does not receive the persistent memory acceleration. High Capacity and Extreme Flash Storage Servers for the X8M generation receive 1.5 TB of persistent memory per server.

See Hardware Components of Oracle Exadata Database Machine in the Oracle Exadata Database Machine System Overview for details.

The Oracle Database and Oracle Grid Infrastructure software installations on Oracle Exadata X8M database servers must meet the minimum release requirements listed in Oracle Linux Kernel to Unbreakable Enterprise Kernel 5 and Oracle Linux Distribution Upgraded to Oracle Linux 7.7.

Oracle Exadata X8M servers must use Oracle Exadata System Software release 19.3.0 or later.

6.1.4 Instant Failure Detection for X8M Systems

Exadata uses heartbeats to detect the failure of various components. Server failure detection normally requires many missed heartbeats to avoid a false failure diagnosis. Exadata uses remote direct memory access (RDMA) on the RoCE network to quickly confirm server failures. Since RDMA uses hardware, the remote ports respond quickly even when the server is heavily loaded.

Instant failure detection is a unique technology that works transparently and enables incredible availability for OLTP applications.

6.1.5 KVM for Virtual Environments

KVM is the virtualization technology used with Oracle Exadata systems configured with RoCE interconnects. KVM provides kernel level hypervisor support, so the host kernel and KVM guest kernel are the same. Oracle Exadata Deployment Assistant (OEDA) is used to create KVM guests and clusters, and a KVM guest uses SR IOV virtual functions for RoCE network connectivity.

Xen is not supported for Oracle Exadata systems configured with RoCE interconnects, and KVM is not supported on Oracle Exadata systems configured with InfiniBand interconnects.

See Managing Oracle VM Domains using KVM for more information.

6.1.6 Faster Encrypted Table Smart Scans

Scans of encrypted tables stored in the in-memory columnar format have been improved by decrypting columns only when needed. Columns in the SELECT set or predicates are the only columns decrypted, not the entire flash cache cacheline. If the first predicate does not return any matches, then the columns for the second predicate are not accessed. This feature has up to 30% faster encrypted smart scans and reduced storage server CPU usage.

For example, consider the following query:

SELECT ename FROM emp 
WHERE job LIKE ‘%VP’ AND sal + bonus > 500000

Only the projected columns (ename) and one or more predicated columns are decrypted. The salary in data regions that do not have a VP are not accessed.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0
• Oracle Database In-Memory option

6.1.7 Smart Aggregation

SUM and GROUP BY SQL operations are now smart scan enabled with in-memory columnar format. This feature benefits SQL statements with a low degree of parallelism, such as the following example:

SELECT dept, sum(sal) FROM emp
WHERE country=‘USA’ GROUP BY dept;

Description of the illustration dbmso_smart_aggregation_with_cc.png

Performance benefits of this feature include:

• Reduces data sent to the database server
• Improves CPU utilization on the database server
• Queries run up to 2x faster

Minimum requirements:

• Oracle Exadata System Software release 19.3.0
• Oracle Database 18c
• Oracle Database In-Memory option

6.1.8 Smart In-Memory Columnar Cache with Row IDs

Oracle Exadata System Software evaluates the predicate in a DML statement to determine the rows of interest. These rows are sent back from the storage servers to the database servers, which then uses the ROWIDs to update the rows. This feature expands this functionality to return ROWIDs for data stored in columnar compression format.

For example, consider the following SQL query:

UPDATE weather_history SET temp = (temp – 32) * (5/9)
WHERE country = 'ENGLAND'

Smart scan is used to find the rows that satisfy country = 'ENGLAND' using ROWID values returned from a previous phase of the command processing.

This feature can improve the performance of DML statements by up to 5x.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0
• Oracle Database release 18.3.0.0.180717DBRU

6.1.9 Smart In-memory Columnar Cache with Chained Rows

Wide tables, large rows or row migration on update can create chained rows. Smart In-memory Columnar Cache works by creating optimized Single Instruction Multiple Data (SIMD) representation for chained rows when the head and tail pieces fit in the same 1 MB region. This results in up to 3x faster scans for wide tables.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0

6.1.10 Encryption of System Logs to Remote Destinations

Management Server (MS) on storage servers and database servers supports the syslogconf attribute, which enables log transfer configuration. This feature adds encryption transfer support for rsyslog.

See Encrypting System Log Information for more information.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0

6.1.11 Update a Single SNMP User Definition

This feature adds new syntax to ALTER CELL and ALTER DBSERVER commands to allow SNMP V3 users to be added, altered, and deleted individually instead of configuring all users in one command string. This features makes it easier to change the password for an individual SNMP user.

See ALTER CELL and ALTER DBSERVER for details.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0

6.1.12 Securing Storage Server Software Processes with Memory Protection Keys

Memory Protection Keys is a hardware feature found in Oracle Exadata X7-2 and newer systems. Memory Protection Keys provide a thread local permission control on memory pages without incurring the high cost of Page Table Entry (PTE) modifications and Translation Look-aside Buffer (TLB) flushes.

The Exadata storage server process that performs block IO (cellsrv) and the processes that perform smart scans (celloflsrv) are now enhanced to run with memory protection keys. This feature is enabled out of the box with no tuning needed. Each thread in these processes needs to obtain access to the appropriate memory protection key before it can access the data. Any access to a piece of memory that does not have the correct key traps the process. This enhances the security and robustness of the storage server processes by eliminating a class of potential memory corruptions.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0
• Oracle Exadata X7-2

6.1.13 Default XFS File System for X8M Servers

To further improve the security of Oracle Exadata, the new X8M servers will use the XFS file system for bare metal, KVM guests, and storage servers.

New partitions are created for /home, /tmp, /var, and /var/log/audit.

Minimum requirements:

• Oracle Exadata System Software release 19.3.0
• Oracle Exadata X8M servers

6.1.14 Oracle Linux Kernel to Unbreakable Enterprise Kernel 5 and Oracle Linux Distribution Upgraded to Oracle Linux 7.7

This release upgrades Oracle Linux to Unbreakable Enterprise Kernel (UEK) 5, (4.14.35-x.el7uek.x86_64). Oracle Linux Kernel UEK5 introduces support for persistent memory, ROCE, and KVM on Exadata. The Linux distribution is upgraded to Oracle Linux 7.7.

Minimum requirements to upgrade to Oracle Exadata System Software release 19.3.0:

• Oracle Grid Infrastructure:
  • 19c
    • 19.5.0.0.191015 with patches or
    • 19.4.0.0.190716 with patches
  • 18.7.0.0.190716 with patches
  • 12.2.0.1.0.190716 with patches
  • 12.1.0.2.0.190716 with patches
• Oracle Database:
  • 19.4.0.0.0.190716 with patches
  • 18.7.0.0.0.190716 with patches
  • 12.2.0.1.0.181016
  • 12.1.0.2.0.180831
  • 11.2.0.4.0.180717

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

6.1.15 Software Certification Ends for Exadata Database Machine X2 Servers

Software certification ends for Oracle Exadata Database Machine X2 servers. This includes the following servers:

• Sun Fire X4170 M2 Server
• Sun Fire X4800 Server
• Sun Fire X4270 M2 Server

6.2 What's New in Oracle Exadata Database Machine 19.2.0

The following features are new for Oracle Exadata System Software 19.2.0:

• Support for New Hardware - X8 Servers
  
• Exadata Extended (XT) Storage Server
  
• Changes to IORM flashcachesize Attribute and Hard Disk I/O Limits
  

6.2.1 Support for New Hardware - X8 Servers

This release includes support for the following hardware:

• Oracle Exadata Database Machine X8-2

• Oracle Exadata Database Machine X8-8

• 14 TB high-capacity drives for Exadata Storage Server X8-2

Minimum requirements:

• Oracle Exadata System Software release 19.2.0

6.2.2 Exadata Extended (XT) Storage Server

A new storage configuration is available starting with Oracle Exadata X8-2. The XT model does not have Flash drives, only 14 TB hard drives with HCC compression. This is a lower cost storage option, with only one CPU, less memory, and with SQL Offload capability turned off by default. If used without the SQL Offload feature, then you are not required to purchase the Oracle Exadata System Software license for the servers.

If you purchase the Oracle Exadata System Software license for the servers and want to enable the SQL Offload capability for the XT storage servers, then you can use this CellCLI command on each XT storage server to dynamically enable the SQL Offload feature:

$ cellcli -e 'ALTER CELL enableSmartStorage=true' 

Minimum requirements:

• Oracle Exadata System Software release 19.2.0

• Oracle Exadata Rack X4

6.2.3 Changes to IORM flashcachesize Attribute and Hard Disk I/O Limits

The flashcachesize IORM attribute and the hard disk I/O limit have been changed:

• The IORM flashcachesize attribute can now be used to over-provision the total flash cache.
• The IORM maximum utilization limit does not apply to hard disks.

See Monitoring IORM Utilization and Understanding I/O Resource Management in the Oracle Exadata System Software User's Guide for details.

Minimum requirements:

• Oracle Exadata System Software release 19.2.0

6.3 What's New in Oracle Exadata Database Machine 19.1.0

The following features are new for Oracle Exadata System Software 19.1.0:

• Oracle Linux Upgraded to Oracle Linux 7.5
  
• Automated Cloud Scale Performance Monitoring
  
• Faster Smart Scans Using Column-level Checksum
  
• Enhanced OLTP High Availability During Cell Outages and Flash Failures
  
• Support for Host and ILOM on Separate Network
  
• DB_UNIQUE_NAME Support for Multiple Clusters Sharing Exadata Storage
  
• Secure Eraser Updates
  
• Server Time Synchronization Uses Chrony
  
• Quorum Disk Manager Service Change
  
• Audit Rules File
  
• Customizable SYSLOG Format
  
• USE_LARGE_PAGES Default Value Set To AUTO_ONLY
  
• Caching Large Copy Writes in Exadata Smart Flash Cache
  
• Security Improvements
  
• Deprecated Features in Oracle Exadata System Software Release 19.1.0
  
• Desupported Features in Oracle Exadata System Software Release 19.1.0
  

6.3.1 Oracle Linux Upgraded to Oracle Linux 7.5

With Oracle Exadata System Software release 19.1.0, the operating system used on the database servers and storage servers has been updated to Oracle Linux 7.5. The Oracle Linux kernel UEK4 that has been used in previous releases continues to stay the same.

The following Oracle Database and Oracle Grid Infrastructure software releases are supported with Oracle Exadata System Software release 19.1.0 and Oracle Linux 7.5.

Oracle Exadata System Software 19.1.0 and later supports the following Oracle Database software releases:

• Oracle Database and Oracle Grid Infrastructure 19c
• Oracle Database and Oracle Grid Infrastructure 18c
  • Minimum version 18.3.0.0.180717
• Oracle Database and Oracle Grid Infrastructure 12c Release 2 (12.2.0.1.0)
  • Minimum version 12.2.0.1.180717
• Oracle Database and Oracle Grid Infrastructure 12c Release 1 (12.1.0.2.0)
  • Minimum version 12.1.0.2.180831
• Oracle Database 11g Release 2 (11.2.0.4.0)
  • Minimum version 11.2.0.4.180717
  • Requires Oracle Grid Infrastructure release 12.1.0.2.180831 or higher
• Oracle Database 11g Release 2 (11.2.0.3.0)
  • Minimum version 11.2.0.3.28
  • Requires Oracle Grid Infrastructure release 12.1.0.2.180831 or higher

  • Installation of the Oracle Database software is a manual task for this release and is not covered by OEDA.

    Note:

    There are no further bundle patches for Oracle Database 11g Release 2 (11.2.0.3.0). The patching end date for this release was August 27, 2015.

Refer to New Features and Changes in the Oracle Linux 7 Release Notes for information about the Oracle Linux 7 release.

6.3.2 Automated Cloud Scale Performance Monitoring

Starting with Oracle Exadata System Software release 19.1.0, Exadata Database Machine provides automated, cloud-scale performance monitoring covering a wide range of sub-systems, including CPU, memory, file system, IO, and network. This feature combines artificial intelligence, years of real-world performance triaging experience, and best practices.

Oracle Exadata System Software can automatically detect performance issues and figure out the root cause without human intervention. Examples of how this feature operates include:

• If a spinning process is taking up all the resources on the system and impacting database performance, Oracle Exadata System Software automatically detects the CPU spin, pinpoints the exact process that is causing the spin, and generates an alert.
• If the Oracle database is not properly configured with huge pages according to the best practice recommendation, Oracle Exadata System Software automatically detects the misconfiguration and generates an alert for the affected database instances.

There is no configuration required for this feature. To receive alerts, you must configure the notification mechanism. See Monitoring Requests and Alerts for Oracle Exadata Storage Server and ALTER DBSERVER.

As a part of this feature, Management Server (MS) is enabled on user domains (domU) in addition to storage servers, database servers (bare metal configuration), and management domains (dom0).

Minimum requirements:

• Oracle Exadata System Software 19.1.0

6.3.3 Faster Smart Scans Using Column-level Checksum

Checksum computation and validation helps to detect errors that may happen during storage or retrieval of data. A checksum is computed when a piece of data is written to Exadata Flash Cache and the checksum is verified on a subsequent read.

Prior to the Oracle Exadata System Software release 19.1.0, a checksum was computed on a block on flash after it was read. This block usually contains multiple columns, but a typical Data Warehousing query only accesses a few columns of a table. In Oracle Exadata System Software release 19.1.0, the unit of checksum computation is reduced to a single column. A checksum is computed for each column and stored in the column compression unit (CU) header. This optimization is enabled only for In-memory Columnar format on Exadata Smart Flash Cache.

The key benefits of the column level checksum approach are:

• Selective checksum computation: When smart scan reads a flash block containing the columns of interest, checksum verification is performed only for those specific column CUs even though there are many other columns present in the cache line. This reduces the amount of data on which the checksum is performed resulting in lower CPU usage. For example, consider the predicate A < 5 and Z < 10. The flash block where column A resides could contain columns B, C, and D. However, because B, C, and D are not referenced in the query, checksums are not performed for B, C, and D.

• Just in time checksum computation: Checksums are performed only when a column is processed. For example, consider the predicate A < 5 and Z < 10. Checksum is computed on the column CU for column A and the predicates are evaluated. If there are no rows satisfying the predicate A < 5, then there is no reason to evaluate Z < 10. Checksum computation is not performed on the column CU for column Z. This can greatly reduce the amount of data on which the checksum is performed resulting in lower CPU usage.

This feature is automatically enabled when you configure the INMEMORY_SIZE database initialization parameter and upgrade to Oracle Exadata System Software release 19.1.0; no further configuration is required to use this feature.

See Offloading of Data Search and Retrieval Processing in Oracle Exadata System Software User's Guide for more information.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0
• Exadata Smart Flash Cache
• Oracle Database In-Memory option

6.3.4 Enhanced OLTP High Availability During Cell Outages and Flash Failures

Oracle Exadata System Software release 19.1.0 enhances application performance after the failure of a flash device or storage server by partially duplicating hot data in the flash cache of multiple storage servers.

If a cell goes offline or a flash device fails, then the databases redirect IOs to use secondary mirrors for data read operations because the primary mirrors are unavailable due to the outage. However, the secondary mirrors might not be in the flash cache of the respective cell, so the databases must read the data from hard disks. This can negatively impact application performance due to flash cache misses.

With this feature, Oracle Exadata System Software prefetches the secondary mirrors of the OLTP data that is most frequently accessed into the flash cache. This prefetching is done as a background task. Oracle Exadata System Software automatically manages the secondary mirrors in the flash cache in an optimal way so that newer or more active secondary mirrors replace the cold data in the cache. In addition, when a flash device is replaced, this feature also ensures that the newly replaced flash device is made more current (warmed up) before redirecting database read operations to the new flash device. Thus, this feature provides better high availability for application performance by greatly reducing the secondary mirror flash cache misses during cell or flash device failures and flash device replacements.

This feature is useful for OLTP workloads only. Oracle Exadata System Software does not cache the secondary mirrors for scan data. Also, this feature is only enabled for write-back Flash Cache. No secondary mirror caching is done for write-through Flash Cache.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0
• Oracle Database 19c
• Exadata Write Back Flash Cache on High Capacity storage servers
• Exadata Database Machine X6 or later (due to flash cache size requirements)

6.3.5 Support for Host and ILOM on Separate Network

Previously Exadata servers and Integrated Lights Out Manager (ILOM) needed to use the same Administrative network for certain features to function properly, like alert notification in Oracle Exadata System Software. Oracle Exadata System Software release 19.1.0 or later eliminates this network dependency while maintaining all the features previously supported.

This feature helps improve security by enabling you to configure a separate network for ILOM so that the Exadata servers and ILOM are completely separate from each other.

See Configuring a Separate Network for ILOM in Oracle Exadata Database Machine Installation and Configuration Guide.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.6 DB_UNIQUE_NAME Support for Multiple Clusters Sharing Exadata Storage

You can now use the same DB_UNIQUE_NAME value for databases that share the same storage. This feature enables Oracle Multitenant clustered databases sharing the same storage cells to have the same DB_UNIQUE_NAME.

In previous releases, multiple clusters could share Exadata storage if the DB_UNIQUE_NAME value for each instance was globally unique across all clusters. In Oracle Exadata System Software release 19.1.0, each cluster can have its own DB_UNIQUE_NAME namespace. This means matching DB_UNIQUE_NAME values are allowed between different clusters. For example, in prior releases, cluster1 and cluster2 could have only one database (either in cluster1 or cluster2) with the DB_UNIQUE_NAME parameter set to db1. In this release, if each cluster configures ASM-scoped security, then both clusters can have a database with the DB_UNIQUE_NAME parameter set to db1.

This feature eliminates the need for different clusters that share Exadata storage to coordinate the DB_UNIQUE_NAME assignments to avoid a name conflict. Each cluster is free to choose any DB_UNIQUE_NAME value, without having to coordinate with other clusters, as long as ASM-scoped security is configured for each cluster.

When ASM-scoped security is configured, the ASM cluster name is used to qualify the DB_UNIQUE_NAME for access to the storage servers. The metrics and stats collected for each database also use the asmcluster.database name qualification in various areas including I/O Resource Management (IORM), Flash Cache, quarantines, and cell offloading.

WARNING:

If you configure databases to have the same DB_UNIQUE_NAME, then those databases cannot be backed up to Oracle Zero Data Loss Recovery Appliance. The DB_UNIQUE_NAME for each database instance must be unique within the scope of the Oracle Zero Data Loss Recovery Appliance.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0
• Each database with the same DB_UNIQUE_NAME must be in a different Oracle ASM cluster
• ASM-scoped security configured for each Oracle ASM cluster

6.3.7 Secure Eraser Updates

With Oracle Exadata System Software release 19.1.0, various improvements were made to Secure Eraser.

• Automatic Upgrading of Multi-pass Disk Erasure to Secure Eraser
  
• Automatic Secure Eraser as Part of Imaging
  
• Secure Eraser Improvements and New Features
  

6.3.7.1 Automatic Upgrading of Multi-pass Disk Erasure to Secure Eraser

If you specify to erase disks using 1pass, 3pass, or 7pass method, Oracle Exadata System Software automatically uses the optimal Secure Eraser method, if it is supported by the underlying hardware.

As disks get larger and larger, the traditional multi-pass overwrite methods such as 1-pass, 3-pass and 7-pass take more time to complete than the erasure method used by Secure Eraser. For example, a 10 TB hard drive can take more than 4 days for 7-pass erase, but only 1 minute using Secure Eraser. See Securely Erasing Database Servers and Storage Servers for a table of supported hardware and estimated erasure times.

It is much faster and more secure to use Secure Eraser on the disks when it is supported. The Secure Eraser methods used in DROP CELL and DROP CELLDISK are the same as those in the Secure Eraser feature and are fully compliant with NIST SP-800-88r1 standard.

See DROP CELL and DROP CELLDISK for more information.

Minimum requirements:

• Oracle Exadata System Software 19.1.0
• Oracle Exadata Database Machine X5-2 or later

6.3.7.2 Automatic Secure Eraser as Part of Imaging

When re-purposing an Oracle Exadata Rack, it is typically a two-part process where you would first use the Secure Eraser feature introduced in Oracle Exadata System Software release 12.2.1.1.0 to securely erase the data first and then re-image the rack with the desired Oracle Exadata image.

Starting with Oracle Exadata System Software release 19.1.0, Secure Eraser is automatically started during re-imaging if the hardware supports Secure Eraser. This significantly simplifies the re-imaging procedure while maintaining performance. Now, when re-purposing a rack, you only have to image the rack and the secure data erasure is taken care of transparently as part of the process.

See Overview of Secure Erasure in Oracle Exadata Database Machine Security Guide for more information.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

• Oracle Exadata Database Machine X5-2 or later

6.3.7.3 Secure Eraser Improvements and New Features

In this release, the following new features and command options were added to Secure Eraser:

• The timezone is now included with the timestamps in the certificate
• Support for erasing individual devices (--devices_to_erase)

See Secure Eraser Syntax in Oracle Exadata Database Machine Security Guide for more information.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0
• Oracle Exadata Database Machine X5-2 or later (for crypto erase)

6.3.8 Server Time Synchronization Uses Chrony

Starting with Oracle Exadata System Software release 19.1.0, Exadata database servers and storage severs running Oracle Linux 7 no longer use ntpd. Instead, chrony is used to synchronize the system clock on the servers with NTP servers. chrony can usually synchronize the system clock faster and with better time accuracy compared to ntpd.

When you upgrade from Oracle Linux 6 to Oracle Linux 7, the NTP server settings are migrated to chrony.

All Oracle Grid Infrastructure and Oracle Database releases certified with Oracle Linux 7 also support chrony.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.9 Quorum Disk Manager Service Change

Oracle Exadata database servers and storage servers running Oracle Linux 7 use the target service instead of the tgtd service for the Exadata Quorum Disk Manager.

During the upgrade from Oracle Linux 6 to Oracle Linux 7, Oracle Exadata database servers that use Quorum Disk Manager are migrated to use the new underlying target service. The migration can be done in a rolling fashion. The administration interface for the Quorum Disk Manager remains the same and can be used if any changes are needed after the upgrade to Oracle Linux 7.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.10 Audit Rules File

During the upgrade from Oracle Linux 6 to Oracle Linux 7 on Exadata database servers, the Oracle Linux 6 audit settings are migrated and moved into to the audit file 01-exadata_audit.rules. Rules that are not specific to Oracle Exadata are not migrated during the upgrade. You must reconfigure these rules separately. Oracle recommends creating and maintaining a custom audit rules file for rules that are not specific to Oracle Exadata.

See Operating System Activity Monitoring on Oracle Exadata Storage Servers in the Oracle Exadata System Software User's Guide for more information.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.11 Customizable SYSLOG Format

A new cell and database server attribute, syslogFormat, can be used to change the standard syslog format to any format desired.

When the attribute is set, Management Server (MS) modifies the /etc/rsyslog.conf file to contain the format string specified, and restarts the syslog daemon. Setting syslogFormat to an empty string removes the format change and the default format is restored.

See ALTER CELL in Oracle Exadata System Software User's Guide or ALTER DBSERVER in Oracle Exadata Database Machine Maintenance Guide for details.

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.12 USE_LARGE_PAGES Default Value Set To AUTO_ONLY

On Oracle Exadata, starting with Oracle Database 19c, the default value for the USE_LARGE_PAGES database initialization parameter is AUTO_ONLY. This setting provides a simple mechanism allowing databases to automatically use large memory pages (also known as huge pages) to contain the Oracle Database System Global Area (SGA) without any system administration effort.

During startup, when USE_LARGE_PAGES=AUTO_ONLY, the database calculates the number of large pages required by the SGA and dynamically requests them from the operating system. If the request is successful, the database starts up with the SGA contained in the large memory pages. If the operating system cannot satisfy the requirement, then the database fails to start.

Note:

To maximize performance and stability, Oracle recommends always using large memory pages for the SGA. However, dynamic acquisition of large memory pages can fail when system memory is fragmented or when multiple databases start concurrently. Consequently, Oracle recommends setting USE_LARGE_PAGES to ONLY.

In line with these recommendations, new databases created using Exadata automation tools are configured with USE_LARGE_PAGES=ONLY by default. This includes databases created using Oracle Exadata Deployment Assistant (OEDA) and databases created on a cloud-based Exadata deployment (using Exadata Database Service).

When USE_LARGE_PAGES=ONLY, the database fails to start if insufficient large pages are available to contain the SGA. In this case, the system administrator must configure the operating system to ensure enough large pages are available to cover all databases.

6.3.13 Caching Large Copy Writes in Exadata Smart Flash Cache

Building on optimizations introduced in Exadata System Software 12.2.1.1.0 that enable Faster Performance for Large Analytic Queries and Large Loads, large writes associated with data file copy operations are now eligible for caching when the hard disk drives (HDDs) are busy. This optimization enables the storage server to utilize spare flash capacity and I/O bandwidth to deliver consistently better overall performance.

Minimum requirements:

• Oracle Database 21c (21.1)

6.3.14 Security Improvements

With Oracle Exadata System Software release 19.1.0, various security improvements were introduced.

• Access Control for RESTful Service
  
• Password Expiration for Remote Users
  
• Advanced Intrusion Detection Environment (AIDE)
  
• Implementing the Principle of Least Privilege to Improve Security
  
• Increased Security for Storage Server Processes
  
• SSHD ClientAliveInterval Changed to 600 Seconds
  
• Stronger Password Requirements
  
• Upload DIAGPACK to Oracle ASR Manager using HTTPs
  

6.3.14.1 Access Control for RESTful Service

Oracle Exadata System Software release 19.1.0 or later introduces a new capability for users to configure access control lists on the HTTPs access to the Exadata RESTful service. Users can specify a list of IP addresses or IP subnet masks to control who can access the RESTful service via HTTPs. Alternatively, if the RESTful service is not used, users can choose to disable HTTPs access to the node altogether. This feature applies to both Oracle Exadata Database Server and Oracle Exadata Storage Server.

See the following topics for more information:

• ALTER CELL
• CREATE CELL
• ALTER DBSERVER
• CREATE DBSERVER

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.14.2 Password Expiration for Remote Users

You can now configure password expiration for remote users that use access the Exadata RESTful service or use ExaCLI. On the Exadata server, you can set attributes to configure password expiration time and whether the user is allowed to remotely change an expired password. Additional attributes can be set to specify the length of the warning period before the password expires, and how long after the password expires before the user account is locked.

Note:

This feature applies only to remote users and does not apply to operating system users like celladmin or oracle.

If these attributes are set on the server, then when a user attempts to connect to an account with an expired password, one of two things happens:

• If the server is configured to permit changing the password remotely, then the user is prompted to change the password immediately.
• If the server does not allow changing the password remotely, then the user is presented with an error indicating the password is expired and they will need assistance in getting it changed.

See the following topics for more information:

• Security Policies for Oracle Exadata Storage Servers
• DESCRIBE DBSERVER
• DESCRIBE CELL

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.14.3 Advanced Intrusion Detection Environment (AIDE)

Oracle Exadata System Software release 19.1.0 adds support for Advanced Intrusion Detection Environment (AIDE) to help guard against unauthorized access to the files on your Exadata system. AIDE is a security feature that reports any malicious or unplanned change to the system. AIDE creates a database of files on the system, and then uses that database to ensure file integrity and to detect system intrusions.

See the following topics for more information:

• Guarding Against Unauthorized Operating System Intrusions
• https://en.wikipedia.org/wiki/Advanced_Intrusion_Detection_Environment

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.14.4 Implementing the Principle of Least Privilege to Improve Security

Security best practices require that each process run with the lowest privileges needed to perform the task. The following processes now run as non-privileged users:

• Smart Scan processes

  The processes that perform a smart scan on the Oracle Exadata Storage Server used to run with the root user privilege. Performing predicate evaluation does not require root privileges. Starting with Oracle Exadata System Software release 19.1.0, these smart scan processes are owned by a new operating system user called cellofl. The user cellofl and group celltrace are automatically created when you perform a Software Update to Oracle Exadata System Software release 19.1.0.

• Select ExaWatcher processes

  The ExaWatcher infrastructure is responsible for collecting and archiving system statistics on both the Oracle Exadata Database Servers and Oracle Exadata Storage Servers. Some of the commands that collect iostat, netstat, ps, top, and other information have been modified to run without requiring root user privilege. The new operating system user exawatch and group exawatch are automatically created when you perform a Software Update on the Oracle Exadata Storage Server, Oracle Exadata Database Server, and within a virtual machine running on the Oracle Exadata Database Server.

As a result of these changes, the number of processes running as the root user is significantly reduced which improves security on Oracle Exadata servers.

This feature is automatically enabled by performing a software update to Oracle Exadata System Software release 19.1.0. No additional configuration is required.

See the following topics for more information:

• Understanding User Accounts
• Offloading of Data Search and Retrieval Processing
• ExaWatcher Charts

6.3.14.5 Increased Security for Storage Server Processes

The secure computing (seccomp) feature in the Oracle Linux kernel is used to restrict the system calls that can be made from a process.

The Oracle Linux kernel has a few hundred system calls, but most of them are not needed by any given process. A seccomp filter defines whether a system call is allowed or restricted. Seccomp filters are installed for cell server and cell offload server processes automatically on an upgrade. An allowlist of system calls are allowed to be made from cell server and cell offload server. For certain allowlist system calls, the seccomp filters perform an additional validation of the arguments.

Seccomp filters provide a higher level of security for the cell processes. This feature is automatically enabled in Oracle Exadata System Software release 19.1.0.

6.3.14.6 SSHD ClientAliveInterval Changed to 600 Seconds

The ClientAliveInterval parameter causes the SSH client to time out automatically after a period of inactivity, which is specified in seconds. When the specified time limit has been reached, if no data has been received from the client, SSHD sends a message through the encrypted channel to request a response from the client. If no response is received from the server side, then the connection is discarded. Previously ClientAliveInterval was set to 2 hours on the storage servers and 24 hours on the database servers. These large values were required to keep the dcli calls made from patchmgr from timing out.

The patchmgr utility has also been modified. dcli calls made from patchmgr use run-time parameters to extend the timeout limit. This prevents the calls from timing out if there is no communication from the server for more than 10 minutes.

If you require a long-running connection to the database servers, such as when taking operating system backups, you can specify a larger value for ClientAliveInterval in the /etc/ssh/sshd_config file. You must restart the SSH service for changes to take effect. After the long running operation completes, you must remove the modification to the ClientAliveInterval and restart the SSH service.

6.3.14.7 Stronger Password Requirements

When creating operating system users on the database servers and storage servers, the new Exadata default password policy rules are:

• Minimum characters: 8
• Minimum numbers: 1
• Minimum lowercase characters: 1
• Minimum uppercase characters: 1
• Minimum special characters: 1
• Maximum consecutive repeating characters: 3
• Maximum consecutive repeating characters of the same class: 4
• Minimum number of different characters: 8
• Minimum days for password change: 1
• Maximum days for password change: 60
• Dictionary words are not valid or accepted.
• The last ten passwords cannot be reused

Note:

Passwords that were created before the new restrictions were added in Oracle Exadata System Software release 19.1.0 will continue to work without issue. If you use SSH equivalence, then you should notice no difference.

See the following topics for more information:

• Default Security Setting Enacted by OEDA
• Security Policies for Oracle Exadata Storage Servers

Minimum requirements:

• Oracle Exadata System Software release 19.1.0

6.3.14.8 Upload DIAGPACK to Oracle ASR Manager using HTTPs

For enhanced security, you can configure Management Server (MS) and Oracle ASR Manager to upload diagnostic packages using HTTPs.

See Enabling Automatic Diag Pack Upload for ASR for information.

6.3.15 Deprecated Features in Oracle Exadata System Software Release 19.1.0

The following features are deprecated in this release, and may be desupported in a future release:

• Deprecation of Interleaved Grid Disks
  
• Deprecation of nfsimg Images
  

6.3.15.1 Deprecation of Interleaved Grid Disks

The interleaving option for grid disks has been deprecated. Attempts to create interleaved grid disks will be automatically converted to a normal grid disk creation.

Interleaved grid disks created before Oracle Exadata System Software release 19.1.0 continue to work as they did in previous releases.

6.3.15.2 Deprecation of nfsimg Images

When imaging or re-imaging an Oracle Exadata Database Machine server, starting with Oracle Exadata System Software release 19.1.0, NFS images have been deprecated. Use the PXE option with ISO image files instead of NFS image files.

The Secure Eraser package (secureeraser_label.zip) also contains ISO images instead of NFS images starting with Oracle Exadata System Software release 19.1.0.

The relevant sections in the documentation have been updated to reflect this change.

• Imaging a New System in the Oracle Exadata Database Machine Installation and Configuration Guide has the updated imaging instructions
• Securely Erasing Oracle Exadata Database Machine in the Oracle Exadata Database Machine Security Guide has the updated Secure Eraser instructions

6.3.16 Desupported Features in Oracle Exadata System Software Release 19.1.0

Oracle Exadata V2 is no longer certified, starting with Oracle Exadata System Software release 19.1.0. The current certification information can be found in Exadata System Software Certification (My Oracle Support Doc ID 2075007.1)