What's New in Oracle Exadata Database Machine 12.2.1.1.0

In-Memory Columnar Caching on Storage Servers

Oracle Exadata System Software release 12.2.1.1.0 can use fast vector-processing in-memory algorithms on data in the storage flash cache. This feature is available if you have licensed the Oracle Database In-Memory (Database In-Memory) option.

The Database In-Memory format cache offers a significant boost to the amount of data held in Database In-Memory format formats and to Smart Scan performance over and above that offered by the pure columnar Exadata Hybrid Columnar CompressionExadata Hybrid Columnar Compression format.

Oracle Exadata System Software release 12.1.2.1.0 added a columnar flash cache format which automatically stored Exadata Hybrid Columnar Compression data in pure columnar Exadata Hybrid Columnar Compression format in the flash cache. This release extends support for Exadata Hybrid Columnar Compression data to enable the cached data to be rewritten into Database In-Memory format and enabling ultra-fast single instruction, multiple data (SIMD) predicates to be used in Smart Scan. With this format, most in-memory performance enhancements are supported in Smart Scan including joins and aggregation.

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

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

This feature is enabled by default when the INMEMORY_SIZE database initialization parameter is configured and the user does not need to do anything to get this enhancement. See INMEMORY_CLAUSE_DEFAULT in Oracle Database Reference for information about INMEMORY_SIZE. If INMEMORY_SIZE is not configured, then the Exadata Hybrid Columnar Compression format columnar cache is still used exactly as in 12.1.2.1.0.

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

Minimum requirements:

Oracle Database 12c release 1 (12.1.0.2), minimum software version required is 12.1.0.2.161018DBBP or
Oracle Database 12c release 2 (12.2.0.1)
Patch for bug 24521608

Related Topics

Oracle Database In-Memory Guide

Columnar Flash Cache for Encrypted Tablespace

In Oracle Exadata System Software 12.2.1.1.0,columnar flash cache support has been extended to encrypted tablespaces. If you have licensed the Oracle Database In-Memory (Database In-Memory) option, the encrypted tablespace data is stored in in-memory columnar format on storage flash cache. If you have not licensed the option, the encrypted tablespace data is stored in pure columnar Exadata Hybrid Columnar Compression format on storage server flash cache.

Minimum requirements:

Oracle Database 12c release 1 (12.1.0.2), minimum software version required is 12.1.0.2.161018DBBP or
Oracle Database 12c release 2 (12.2.0.1)
Patch for bug 24521608

Set Membership in Storage Indexes

In Oracle Exadata System Software release 12.2.1.1.0, when data has been stored using the in-memory format columnar cache, Oracle Exadata Database Machine stores these columns compressed using dictionary encoding. For columns with fewer than 200 distinct values, the storage index creates a very compact in-memory representation of the dictionary and uses this compact representation to filter disk reads based on equality predicates. This feature is called set membership. A more limited filtering ability extends up to 400 distinct values.

For example, suppose a region of disk holds a list of customers in the United States and Canada. When you run a query looking for customers in Mexico, Oracle Exadata Storage Server can use the new set membership capability to improve the performance of the query by filtering out disk regions that do not contain customers from Mexico. In Oracle Exadata System Software releases earlier than 12.2.1.1.0, which do not have the set membership capability, a regular storage index would be unable to filter those disk regions.

Minimum requirements:

Oracle Database 12c release 1 (12.1.0.2), minimum software version required is 12.1.0.2.161018DBBP or
Oracle Database 12c release 2 (12.2.0.1)
Patch for bug 24521608

Storage Index to Store Column Information for More Than Eight Columns

In Oracle Exadata System Software releases earlier than 12.2.1.1.0, storage indexes can hold column information for up to eight columns. In Oracle Exadata System Software release 12.2.1.1.0, storage indexes have been enhanced to store column information for up to 24 columns.

Space to store column information for eight columns is guaranteed. For more than eight columns, space is shared between column set membership summary and column minimum/maximum summary. The type of workload determines whether set membership summary gets stored in storage index.

See Set Membership in Storage Indexes for more information.

5x Faster Oracle Exadata System Software Updates

Updating Oracle Exadata System Software now takes even less time. The Oracle Exadata System Software update process is now up to 2 times faster compared to 12.1.2.3.0, and up to 5 times faster compared to releases earlier than 12.1.2.3.0. A faster update time reduces the cost and effort required to update the software.

Faster Performance for Large Analytic Queries and Large Loads

Temp writes and temp reads are used when large joins or aggregation operations don't fit in memory and must be spilled to storage. In Oracle Exadata System Software releases earlier than 12.2.1.1.0, temp writes were not cached in flash cache; both temp writes and subsequent temp reads were from hard disk only. In Oracle Exadata System Software release 12.2.1.1.0, temp writes are sent to flash cache so that subsequent temp reads can be read from flash cache as well. This significantly speeds up queries that spill to temp if they are temp I/O bound. For certain queries, performance can improve up to four times faster. This is comparable to putting the temporary tablespace entirely in flash. Write-back flash cache has to be enabled for this feature to work.

Prior to Oracle Exadata System Software release 12.2.1.1.0, there was a size threshold for writes to the flash cache. Most writes over 128 KB are routed straight to disk because these writes are not expected to be read any time soon. For example, direct load writes, flashback database log writes, archived log writes, and incremental backup writes would bypass flash cache. Starting with Oracle Exadata System Software release 12.2.1.1.0, the flash cache algorithms have been enhanced to redirect such large writes into the flash cache, provided that such large writes do not disrupt the higher priority OLTP or scan workloads. Such writes are later written back to the disks when the disks are less busy. This feature allows Oracle Exadata Storage Server to utilize additional spare flash capacity and I/O bandwidth to provide better overall performance.

Note that this feature is supported on all Oracle Exadata Database Machine hardware except for V2 and X2 storage servers. On X3 and X4 storage servers, flash caching of temp writes and large writes is not supported when flash compression is enabled.

New statistics and report sections related to this feature were added to Automatic Workload Repository (AWR) reports in Oracle Database 18c (18.1.0), also available in the 12.1.0.2.0 July 2017 DBBP and the 12.2.0.1.0 Oct 2017 RUR.

Minimum requirements:

Oracle Exadata Database Machine X3-2 or later
Oracle Exadata System Software 12.2.1.1.0
Oracle Database (one of the following):
- Oracle Database 11g release 2 (11.2) with the fix for bug 24944847 applied
- Oracle Database 12c release 1 (12.1) — 12.1.0.2.0 July 2017 DBBP
- Oracle Database 12c release 2 (12.2.0.1) — 12.2.0.1.0 Oct 2017 RUR
- Oracle Database 18c (18.1.0)

Secure Eraser

Oracle Exadata System Software software releases 12.2.1.1.0 or later provide a secure erasure solution, called Secure Eraser, for every component within Oracle Exadata Database Machine. This is a comprehensive solution that covers all Exadata Database Machines V2 and higher, including both 2-socket and 8-socket servers.

In earlier versions of Oracle Exadata Database Machine, you could securely erase user data through CellCLI commands like DROP CELL ERASE, DROP CELLDISK ERASE, or DROP GRIDDISK ERASE. However, these DROP commands only cover user data on hard drives and flash devices. Secure Eraser sanitizes all content, not only user data but also operating system, Oracle Exadata System Software, and user configurations. In addition, Secure Eraser covers a wider range of hardware components including hard drives, flash devices, internal USB, and ILOM.

The Secure Eraser securely erases all data on both database servers and storage servers, and resets InfiniBand switches, Ethernet switches, and power distribution units back to factory default. You can use this feature to decommission or repurpose an Oracle Exadata machine. The Secure Eraser completely erases all traces of data and metadata on every component of the machine.

For details on the Secure Eraser utility, see Oracle Exadata Database Machine Security Guide.

Cell-to-Cell Offload Support for Oracle ASM-Scoped Security

To perform cell-to-cell offload operations efficiently, storage servers need to access other storage servers directly, instead of through a database server.

If you have configured Oracle ASM-scoped security in your Exadata environment, you need to set up cell keys to ensure storage servers can authenticate themselves to other storage servers so that they can communicate with each other directly. This applies to Oracle ASM resync, resilver, rebuild and rebalance operations, and database high-throughput write operations

Adding an Additional Network Card to Oracle Exadata Database Machine X6-2 Database Servers

Oracle Exadata Database Machine X6-2 database servers offer a highly available copper 10 Gbps network on the motherboard, and an optical 10 Gbps network via a PCI card on slot 2.

Starting with Oracle Exadata System Software release 12.2.1.1.0, you can add an additional Ethernet card if you require additional connectivity. The additional card can provide either dual port 10 GbE optical connectivity (part number X1109A-Z) or dual port 10 GbE copper connectivity (part number 7100488). You can install this part in PCIe slot 1 on the Oracle Exadata Database Machine X6-2 database server.

After you install the network card and connect it to the network, Oracle Exadata System Software release 12.2.1.1.0 automatically recognizes the new card and configures the two ports as eth6 and eth7 interfaces on the database server. You can use these additional ports for providing an additional client network, or for creating a separate backup or disaster recovery network. On a database server that runs virtual machines, you could use this network card to isolate traffic from two virtual machines.

Automatic Diagpack Upload for Oracle ASR

In Oracle Exadata System Software release 12.2.1.1.0, Management Server (MS) communicates with Oracle ASR Manager to upload a diagnostic package containing information relevant to the Oracle ASR automatically. In earlier releases you had to manually upload other diagnostics information after an automatic service request (SR) has been opened. By automating this step, this feature significantly reduces the turnaround time of Oracle ASRs.

This feature adds two new attributes to the AlertHistory object:

The new serviceRequestNumber attribute shows the associated service request number.
The new serviceRequestLink attribute shows the URL to the associated service request number.

Other feature highlights include:

The diagnostic package RESTful page (https://hostname/diagpack/download?name=diagpackname) has a new column showing a link to the corresponding service request.
Oracle ASR alert emails include SR links.

To enable Automatic Diagpack Upload for Oracle ASR, you must enable http_receiver in the Oracle ASR Manager:

To check if http_receiver is enabled, run the following command from Oracle ASR Manager:
```
asr show_http_receiver
```

To enable the http_receiver, use the following command, where port is the port the http_receiver listens on.

asr enable_http_receiver -p port

Note:

The port specified here has to be the same as the asrmPort specified for the subscriber on the database server or on the storage server. The following commands show how to verify the asrmPort on a database server and storage server.

DBMCLI> LIST DBSERVER ATTRIBUTES snmpSubscriber 
     ((host=test-engsys-asr1.example.com, port=162,community=public, 
type=ASR,fromIP=10.242.0.55,asrmPort=16168))

CellCLI> LIST CELL ATTRIBUTES snmpSubscriber
     ((host=test-engsys-asr1.example.com,port=162,community=public,
type=ASR,asrmPort=16168))

If you do not want to automatically upload diagnostic data to a service request, you can run ALTER CELL diagPackUploadEnabled=FALSE to disable the automatic upload.

Minimum software required: Oracle ASR Manager Release 5.7

Related Topics

CREATE DIAGPACK and LIST DIAGPACK Commands Available for Oracle Exadata Database Servers

The diagnostic package feature, which is available for storage servers, is now available for database servers as well. Management Server (MS) on database servers automatically collects customized diagnostic packages that include relevant logs and traces upon generating a database server alert. This applies to all critical database server alerts. Timely collection of diagnostic information prevents rollover of critical logs.

MS on database servers sends the diagnostic package as an email attachment for every critical email alert. Users can create hourly custom diagnostic packages by providing the start time and duration using the new CREATE DIAGPACK DBMCLI command.

See CREATE DIAGPACK and LIST DIAGPACK in the Oracle Exadata Database Machine Maintenance Guide for details.

Rescue Plan

In Oracle Exadata System Software releases earlier than 12.2.1.1.0, after a Oracle Exadata Database Server or Oracle Exadata Storage Server rescue, you must re-run multiple commands to configure items such as I/O Resource Management (IORM) plans, thresholds, and storage server and database server notification setting.

In Oracle Exadata System Software release 12.2.1.1.0, there is a new attribute called rescuePlan for the cell and dbserver objects. You can use this attribute to get a list of commands, which you can store as a script. You can then run the script after a cell rescue to restore the settings.

For details on the rescuePlan attribute, see Oracle Exadata Database Machine Maintenance Guide.

Support for IPv6 Oracle VM and Tagged VLANs

Oracle Exadata System Software release 12.2.1.1.0 supports IPv6 Oracle VM and tagged virtual LANs (VLANs) using Oracle Exadata Deployment Assistant (OEDA).

IPv6 VLANs are now supported on the management network. In earlier releases, this was not supported.

See Oracle Exadata Database Machine Installation and Configuration Guide.

Management Server Can Remain Online During NTP, DNS, and ILOM Changes

If you are changing NTP, DNS, or ILOM parameters, the Management Server (MS) can remain online during the operation and does not need to be restarted.

New Charts in ExaWatcher

In Oracle Exadata System Software release 12.2.1.1.0, GetExaWatcherResults.sh generates HTML pages that contain charts for IO, CPU utilization, cell server statistics, and alert history. The IO and CPU utilization charts use data from iostat, while the cell server statistics use data from cellsrvstat. Alert history is retrieved for the specified timeframe.

For details, see ExaWatcher Charts in the Oracle Exadata Database Machine Maintenance Guide.

New Metrics for Redo Log Writes

New metrics are available to help analyze redo log write performance.

Previously, when Automatic Workload Repository (AWR) reported an issue with redo log write wait time for database servers, the storage cells often indicated no issue with redo log write performance. New metrics help to give a better overall picture. These metrics provide insight into the following concerns:

Is the I/O latency high, or is it some other factor (for example, network) ?
How many redo log writes bypassed Flash Log ?
What is the overall latency of redo log writes on each cell, taking into account all redo log writes, not just those which were handled by Flash Log ?

Oracle Exadata System Software release 12.2.1.1.0 introduces the following metrics related to redo log write requests:

FL_IO_TM_W: Cumulative redo log write latency. It includes latency for requests not handled by Exadata Smart Flash Log.
FL_IO_TM_W_RQ: Average redo log write latency. It includes write I/O latency only.
FL_RQ_TM_W: Cumulative redo log write request latency. It includes networking and other overhead.

To get the latency overhead due to factors such as network and processing, you can use (FL_RQ_TM_W - FL_IO_TM_W).
FL_RQ_TM_W_RQ: Average redo log write request latency.
FL_RQ_W: Total number of redo log write requests. It includes requests not handled by Exadata Smart Flash Log.

To get the number of redo log write requests not handled by Exadata Smart Flash Log, you can use (FL_RQ_W - FL_IO_W).

Quarantine Manager Support for Cell-to-Cell Rebalance and High Throughput Write Operations

Quarantine manager support is enabled for rebalance and high throughput writes in cell-to-cell offload operations. If Oracle Exadata System Software detects a crash during these operations, the offending operation is quarantined, and an less optimized path is used to continue the operation.

The quarantine types for the new quarantines are ASM_OFFLOAD_REBALANCE and HIGH_THROUGHPUT_WRITE.

See Quarantine Manager Support for Cell-to-Cell Offload Operations in the Oracle Exadata System Software User's Guide for details.

ExaCLI and REST API Enabled for Management Server

Both ExaCLI and REST API are enabled for Management Server (MS) on the database servers.

You can now perform remote execution of MS commands. You can access the interface using HTTPS in a web browser, or curl. See Oracle Exadata Database Machine Maintenance Guide for more information.

New Features in Oracle Grid Infrastructure 12.2.1.1.0

The following new features in Oracle Grid Infrastructure 12.2.1.1.0 affect Oracle Exadata Database Machine:

Oracle ASM Flex Disk Groups

An Oracle ASM flex disk group is a disk group type that supports Oracle ASM file groups.

An Oracle ASM file group describes a group of files that belong to a database, and enables storage management to be performed at the file group, or database, level. In general, a flex disk group enables users to manage storage at the granularity of the database, in addition to at the disk group level.

See Managing Flex Disk Groups in Oracle Automatic Storage Management Administrator's Guide.

Oracle Flex ASM

Oracle Flex ASM enables Oracle ASM instances to run on a separate physical server from the database servers.

If the Oracle ASM instance on a node in a standard Oracle ASM cluster fails, then all of the database instances on that node also fail. However, in an Oracle Flex ASM configuration, Oracle 12c database instances would not fail as they would be able to access another Oracle ASM instance remotely on another node.

With Oracle Flex ASM, you can consolidate all the storage requirements into a single set of disk groups. All these disk groups are mounted by and managed by a small set of Oracle ASM instances running in a single cluster. You can specify the number of Oracle ASM instances with a cardinality setting.

Oracle Flex ASM is enabled by default with Oracle Database 12c release 2 (12.2). Oracle Exadata Database Machine ships with cardinality set to ALL, which means an Oracle ASM instance is created on every available node. See the following topics for details:

About Oracle Flex ASM in Oracle Automatic Storage Management Administrator's Guide
Managing Oracle Flex ASM in Oracle Automatic Storage Management Administrator's Guide
About Oracle Flex ASM Clusters Networks in Oracle Grid Infrastructure Installation and Upgrade Guide for Linux

Faster Redundancy Restoration After Storage Loss

Using Oracle Grid Infrastructure 12c Release 2 (12.2), redundancy restoration after storage loss takes less time than in previous releases.

A new REBUILD phase was introduced to the rebalance operation. The REBUILD phase restores redundancy first after storage failure, greatly reducing the risk window within which a secondary failure could occur. A subsequent BALANCE phase restores balance.

Oracle Grid Infrastructure release 12.1.0.2 with DBBP 12.1.0.2.170718 also includes the Oracle ASM REBUILD phase of rebalance.

Note:

In Oracle Grid Infrastructure 12c release 2 (12.2), rebuild is tracked in V$ASM_OPERATION via a separate pass (REBUILD). In Oracle Grid Infrastructure 12c release 1 (12.1), both rebuild and rebalance phases are tracked in the same pass (REBALANCE).

Related Topics

Manually Rebalancing Disk Groups

Dynamic Power Change

You can adjust the value of the ASM_POWER_LIMIT parameter dynamically.

If the POWER clause is not specified in an ALTER DISKGROUP statement, or when rebalance is implicitly run by adding or dropping a disk, then the rebalance power defaults to the value of the ASM_POWER_LIMIT initialization parameter. You can adjust the value of this parameter dynamically. The range of values for the POWER clause is the same for the ASM_POWER_LIMIT initialization parameter.

The higher the power limit, the more quickly a rebalance operation can complete. Rebalancing takes longer with lower power values, but consumes fewer processing and I/O resources which are shared by other applications, such as the database.

See Tuning Rebalance Operations in Oracle Automatic Storage Management Administrator's Guide.

Quorum Disk Support in Oracle Universal Installer

You can specify a quorum failure group during the installation of Oracle Grid Infrastructure.

On Oracle Exadata Storage Servers, quorum disk groups are automatically created during deployment. A quorum failure group is a special type of failure group that is used to store the Oracle Clusterware voting files. The quorum failure group is used to ensure that a quorum of the specified failure groups are available.

The installer for Oracle Grid Infrastructure 12.2 was updated to allow you to specify quorum failure groups during installation instead of configuring the quorum failure group after installation using the Quorum Disk Manager utility.

See Identifying Storage Requirements for Oracle Automatic Storage Management in Oracle Grid Infrastructure Installation and Upgrade Guide for Linux

New Features in Oracle Database 12c Release 2 (12.2.0.1)

The following new features in Oracle Database 12c release 2 (12.2.0.1) affect Oracle Exadata:

Database Server I/O Latency Capping

On very rare occasions there may be high I/O latency between a database server and a storage server due to network latency outliers, hardware problems on the storage servers, or some other system problem with the storage servers. Oracle ASM and Oracle Exadata Storage Server software automatically redirect read I/O operations to another storage server when the latency of the read I/O is much longer than expected. Any I/Os issued to the last valid mirror copy of the data are not redirected.

This feature works with all Exadata Storage Software releases. You do not have to perform any configuration to use this feature.

Minimum software required: Oracle Database and Oracle Grid Infrastructure 12c release 2 (12.2.0.1.0)

Exadata Smart Scan Offload for Compressed Index Scan

In Oracle Exadata Storage Server Software 12.1.2.3.0 and prior releases, smart scan offload supported normal uncompressed indexes and bitmap indexes.

In Oracle Exadata Storage Server Software 12.2.1.1.0, smart scan offload has been implemented for compressed indexes. Queries involving compressed index scan on Oracle Exadata can benefit from this feature.

Minimum software required: Oracle Database 12c release 2 (12.2.0.1.0) and Oracle Exadata Storage Server software release 12.2.1.1.0

Exadata Smart Scan Offload Enhancements for In-Memory Aggregation (IMA)

Oracle Exadata Storage Server software supports offloading many SQL operators for predicate evaluation. The In-Memory Aggregation feature attempts to perform a "vector transform" optimization which takes a star join SQL query with certain aggregation operators (for example, SUM, MIN, MAX, and COUNT) and rewrites it for more efficient processing. A vector transformation query is similar to a query that uses bloom filter for joins, but is more efficient. When a vector transformed query is used with Oracle Exadata Storage Server release 12.1.2.1.0, the performance of joins in the query is enhanced by the ability to offload filtration for rows used for aggregation. You will see “KEY VECTOR USE” in the query plan when this optimization kicks in.

In Oracle Exadata Storage Server software release 12.2.1.1.0, vector transformed queries benefit from more efficient processing due to the application of group-by columns (key vectors) to the Exadata Storage Index.

Additionally, vector transformed queries that scan data in in-memory columnar format on the storage server can offload processing of aggregation work. These optimizations are automatic and do not depend on user settings.

Minimum software required: Oracle Database 12c release 2 (12.2.0.1.0) and Oracle Exadata Storage Server software release 12.2.1.1.0

Exadata Smart Scan Offload Enhancements for XML

When XML data is stored using a SecureFiles LOB of less than 4 KB, the evaluation in a SQL WHERE clause of Oracle SQL condition XMLExists or Oracle SQL function XMLCast applied to the return value of Oracle SQL function XMLQuery can sometimes be offloaded to an Oracle Exadata Storage Server.

Minimum software required: Oracle Database 12c Release 2 (12.2.0.1.0) and Oracle Exadata Storage Server software release 12.2.1.1.0.

Exadata Smart Scan Offload Enhancements for LOBs

In Oracle Exadata Storage Server 12.2.1.1.0, offload support has been extended for the following LOB operators: LENGTH, SUBSTR, INSTRM CONCAT, LPAD, RPAD, LTRIM, RTRIM, LOWER, UPPER, NLS_LOWER, NLS_UPPER, NVL, REPLACE, REGEXP_INSTR, TO_CHAR.

Exadata smart scan offload evaluation is supported only on uncompressed inlined LOBs (less than 4 KB in size).

Minimum software required: Oracle Database 12c release 2 (12.2.0.1.0) and Oracle Exadata Storage Server software release 12.2.1.1.0.

New Features in Oracle Exadata Snapshots

Hierarchical snapshot databases

You can create space-efficient snapshot databases from a parent that is itself a snapshot. This allows for hierarchical snapshot databases. The parent snapshot is also space-efficient, all the way to the base test master. Multiple users can create their own snapshots from the same parent snapshot. The set of snapshots can be represented as a tree, where the root of the tree is the base test master. All the internal nodes in the tree are read-only databases and all the leaves in the tree are read/write databases. All Oracle Exadata features are supported on the hierarchical snapshot databases. For hierarchical snapshot databases, because there is performance penalty with every additional depth level of the snapshot, Oracle recommends having a snapshot tree with a maximum depth of 10.
Spare Test Master databases

You can also create and manage a sparse test master, while having active snapshots from it. This feature allows the sparse test master to sync almost continuously with Oracle Data Guard, except for small periods of time when users are creating a snapshot directly from the sparse test master. This feature utilizes the hierarchical snapshot feature described above, by creating read-only hidden parents. Note that Oracle Exadata snapshot databases are intended for test and development databases only.
Sparse backup and recovery

When you choose to perform a sparse backup on DB0, the operation copies data only from the delta storage space of the database and the delta space of the sparse data files. A sparse backup can be either in the backup set format (default) or the image copy format. RMAN restores sparse data files from sparse backups and then recovers them from archive and redo logs. You can perform a complete or a point-in-time recovery on sparse data files. Sparse backups help in efficiently managing storage space and facilitate faster backup and recovery.

See Oracle Database Backup and Recovery User’s Guide for information about sparse backups.

Minimum hardware: Storage servers must be X3 or later

Minimum software: Oracle Database and Grid Infrastructure 12c release 2 (12.2), and Oracle Exadata Storage Server software release 12.2.1.1.0.

Oracle Linux Kernel Upgraded to Unbreakable Enterprise Kernel 4 and Oracle VM Upgraded to 3.4.2

This release upgrades Oracle Linux to Unbreakable Enterprise Kernel (UEK) 4, (4.1.12-61.28.1.el6uek.x86_64). For systems using virtualization, the DOM0 is upgraded to Oracle VM 3.4.2. This enables you to use Oracle Linux 6 on the dom0. The Linux kernels used on the dom0 and domU are now unified.

For systems previously using virtualization on the compute nodes, you must upgrade the Oracle Grid Infrastructure home to release 12.1.0.2.161018DBBP or later in all domU’s before upgrading the Oracle Exadata Storage Server software to release 12.2.1.1.0. The Oracle Exadata Storage Server software upgrade to release 12.2.1.1.0 requires you to upgrade all the domU’s first before you upgrade the dom0. This requirement is enforced by the patchmgr software.

If you use Oracle ASM Cluster File System (Oracle ACFS), then you must apply the fix for bug 22810422 prior to the upgrade of the Oracle Grid Infrastructure home to enable Oracle ACFS support on the UEK4 kernel. In addition, Oracle recommends that you install the fix for bug 23642667 on both the Oracle Grid Infrastructure home and the Oracle Database home to increase OLTP workload performance.