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
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.
- Oracle Exadata System Software release 19.3.0
- Oracle Database 19c
- Oracle Exadata Storage Server X8M-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.
- Oracle Exadata System Software release 19.3.0
- Oracle Database 19c
- Oracle Exadata Storage Server X8M-2
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 Database Machine high-performance architecture and tuning is compatible with the new network.
Oracle Exadata Database Machine 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 Database Machine X8M-2 Storage Servers with persistent memory acceleration, experience up to 10x lower latency for RDMA reads. All Oracle Exadata Database Machine 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.
The Oracle Database and Oracle Grid Infrastructure software installations on Oracle Exadata Database Machine 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 Database Machine X8M servers must use Oracle Exadata System Software release 19.3.0 or later.
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.
KVM for Virtual Environments
KVM is the virtualization technology used with Oracle Exadata Database Machine 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 Database Machine systems configured with RoCE interconnects, and KVM is not supported on Oracle Exadata Database Machine systems configured with InfiniBand interconnects.
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.
- Oracle Exadata System Software release 19.3.0
- Oracle Database In-Memory option
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;
Performance benefits of this feature include:
- Reduces data sent to the database server
- Improves CPU utilization on the database server
- Queries execute up to 2x faster
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.
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.
Fast Smart In-memory Columnar Cache Creation
The run-time analyzer finds the best compression algorithm, reusing the dictionary created in-line during the analysis. This provides faster symbol lookup and insert using the new dictionary data structure. The Single Instruction Multiple Data (SIMD) optimized columnar cache creation reuses data from the first pass scan in the flash cache. The result is much faster reads from the flash cache, with an up to 35% improved speed in columnar cache creation.
This feature applies to Exadata Hybrid Columnar Compression tables only.
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.
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.
Securing Storage Server Software Processes with Memory Protection Keys
Memory Protection Keys is a hardware feature found in Oracle Exadata Database Machine 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.
Default XFS File System for X8M Servers
To further improve the security of Oracle Exadata Database Machine, 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.
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:
- 220.127.116.11.191015 with patches or
- 18.104.22.168.190716 with patches
- 22.214.171.124.190716 with patches
- 126.96.36.199.0.190716 with patches
- 188.8.131.52.0.190716 with patches
- Oracle Database:
- 184.108.40.206.0.190716 with patches
- 220.127.116.11.0.190716 with patches
Refer to My Oracle Support Doc ID 888828.1 for details about the required patches.
Software Certification Ends for Exadata Database Machine X2 Servers
Software certification ends for Oracle Exadata Database Machine X2 servers. This includes the following servers:
- Oracle Exadata Database Machine X2-8 Database Server
- Sun Fire X4170 Oracle Database Servers
- Sun Fire X4170 M2 Oracle Database Servers
- Sun Fire X4800 Oracle Database Servers
- Oracle Exadata Storage Server X2-2
- Oracle Exadata Storage Server with Sun Fire X4270 M2 Servers
- Oracle Exadata Storage Server with Sun Fire X4275 Servers
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
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
Oracle Exadata Storage Server X8-2 Extended (XT)
A new storage configuration is available starting with Oracle Exadata Database Machine 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’
- Oracle Exadata System Software release 19.2.0
- Oracle Exadata Rack X4
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.
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.
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.104.22.168.180717
- Oracle Database and Oracle Grid Infrastructure 12c Release 2 (22.214.171.124.0)
- Minimum version 126.96.36.199.180717
- Oracle Database and Oracle Grid Infrastructure 12c Release 1 (188.8.131.52.0)
- Minimum version 184.108.40.206.180831
- Oracle Database 11g Release 2 (220.127.116.11.0)
- Minimum version 18.104.22.168.180717
- Requires Oracle Grid Infrastructure release 22.214.171.124.180831 or higher
- Oracle Database 11g Release 2 (126.96.36.199.0)
- Minimum version 188.8.131.52.28
- Requires Oracle Grid Infrastructure release 184.108.40.206.180831 or higher
- Installation of the Oracle Database software is a manual task for this release and is not covered by OEDA.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 220.127.116.11.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.
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)
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.
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.
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.
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.
USE_LARGE_PAGES Default Value Set To AUTO_ONLY
Starting with Oracle Database 19c, AUTO_ONLY is the new default value for the USE_LARGE_PAGES database initialization parameter.
When USE_LARGE_PAGES is set to AUTO_ONLY, if SGA_TARGET is specified in the initialization parameter file, then the database calculates how many HugePages are needed to create the SGA and reconfigures the total number of HugePages in the operating system. If there are no pre-provisioned HugePages on the system, then the database automatically requests the amount of HugePages it needs from the operating system. If the request is successful, then the database start up proceeds. If the operating system cannot find enough HugePages to satisfy the request for the database, then the database start up fails.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.