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
Parent topic: What's New in Oracle Exadata Database Machine
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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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.
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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.
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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.
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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
Parent topic: What's New in Oracle Exadata Database Machine 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
Parent topic: What's New in Oracle Exadata Database Machine 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
Parent topic: What's New in Oracle Exadata Database Machine 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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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
- 19c
- 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
Parent topic: What's New in Oracle Exadata Database Machine 19.3.0
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:
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
Parent topic: What's New in Oracle Exadata Database Machine 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
Parent topic: What's New in Oracle Exadata Database Machine 19.2.0
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
Parent topic: What's New in Oracle Exadata Database Machine 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.
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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
Parent topic: What's New in Oracle Exadata Database Machine 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 predicateA < 5
, then there is no reason to evaluateZ < 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
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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)
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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
Related Topics
Parent topic: What's New in Oracle Exadata Database Machine 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 sameDB_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
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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
Parent topic: Secure Eraser Updates
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
Parent topic: Secure Eraser Updates
6.3.7.3 Secure Eraser Improvements and New Features
- 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)
Parent topic: Secure Eraser Updates
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
Related Topics
Parent topic: What's New in Oracle Exadata Database Machine 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
Related Topics
Parent topic: What's New in Oracle Exadata Database Machine 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
Parent topic: What's New in Oracle Exadata Database Machine 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
Parent topic: What's New in Oracle Exadata Database Machine 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.
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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)
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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:
Minimum requirements:
- Oracle Exadata System Software release 19.1.0
Parent topic: Security Improvements
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 likecelladmin
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
Parent topic: Security Improvements
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
Parent topic: Security Improvements
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 calledcellofl
. The usercellofl
and groupcelltrace
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 requiringroot
user privilege. The new operating system userexawatch
and groupexawatch
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:
Parent topic: Security Improvements
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.
Related Topics
Parent topic: Security Improvements
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.
Parent topic: Security Improvements
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:
Minimum requirements:
- Oracle Exadata System Software release 19.1.0
Parent topic: Security Improvements
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.
Parent topic: Security Improvements
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:
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0
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)
Parent topic: What's New in Oracle Exadata Database Machine 19.1.0