1. System Overview
  2. What's New in Oracle Exadata Database Machine
  3. What's New in Oracle Exadata Database Machine 19.1.0

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

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.

For more information about Oracle Linux 7, refer to the Oracle Linux 7 Documentation.

Oracle Database Software Minimum Required Version

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.

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

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 new 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
  • INMEMORY_SIZE database initialization parameter

Enhanced OLTP High Availability During Cell Outages and Flash Failures

Oracle Exadata System Software release 19.1.0 introduces a new feature that further enhances the OLTP high availability caused by cell outages and flash failures. This feature provides better 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 new 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
  • Exadata Write Back Flash Cache on High Capacity storage servers
  • Exadata Database Machine X6 or later (due to flash cache size requirements)

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

Related Topics

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, 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

Related Topics

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

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

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 Database Machine 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

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
  • An option to erase data disks only, and exclude system disks (--erase_data_only)
  • Support for erasing individual devices (--devices_to_erase)

See SecureEraser 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)

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

Related Topics

Quorum Disk Manager Service Change

Oracle Exadata Database Machine 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 Machine 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

Related Topics

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 Database Machine 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 Database Machine.

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

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

Security Improvements

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

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:

Minimum requirements:

  • Oracle Exadata System Software release 19.1.0

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:

Minimum requirements:

  • Oracle Exadata System Software release 19.1.0

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:

Minimum requirements:

  • Oracle Exadata System Software release 19.1.0
  • Oracle Linux 7

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:

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. A white-listed set of system calls are allowed to be made from cell server and cell offload server. For certain white-listed 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.

Related Topics

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.

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:

Minimum requirements:

  • Oracle Exadata System Software release 19.1.0

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.

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

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.

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.

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)