Oracle Database Updates & Release Notes

This page describes the features and behavioral changes that are new in Release Update 19.7.

SQL Macros (SQM)

You can create SQL Macros (SQM) to factor out common SQL expressions and statements into reusable, parameterized constructs that can be used in other SQL statements. Starting with Oracle Database release 19c, version 19.7, SQL table macros are supported. SQL table macros are expressions, typically used in a FROM clause, to act as a sort of polymorphic (parameterized) view.

SQL macros increase developer productivity, simplify collaborative development, and improve code quality.

View Documentation

This page describes the features and behavioral changes that are new in Release Update 19.8.

Database In-Memory Base Level

Database In-Memory is an option to Enterprise Edition. Database In-Memory now has a new Base Level feature. This allows the use of Database In-Memory with up to a 16GB column store without triggering any license tracking.

This feature allows you to use Database In-Memory without having to license the option. The column store is limited to 16GB when using the Base Level. This helps to show the value of Database In-Memory without having to worry about licensing issues.

View Documentation

CellMemory Level

You can use the CellMemory feature without enabling the IM column store by setting

INMEMORY_FORCE=CELLMEMORY_LEVEL

and

INMEMORY_SIZE=0

.

This feature allows you to use CellMemory without incurring the overhead of enabling the IM column store.

View Documentation

This page describes the features and behavioral changes that are new in Release Update 19.9.

Oracle Grid Infrastructure SwitchHome

You can use the -switchGridHome option with gridSetup.sh to switch from one Oracle Grid Infrastructure home to another.

You can use the -switchGridHome option for patching and upgrading Oracle Grid Infrastructure. Use the -switchGridHome option to switch from the source Oracle Grid Infrastructure home to the patched Oracle Grid Infrastructure home. All Oracle Clusterware and Oracle Restart services start from the patched Oracle Grid Infrastructure home automatically.

View Documentation

Support for DBMS_CRYPTO Asymmetric Key Operations

Starting with this release, the DBMS_CRYPTO PL/SQL package supports asymmetric key operations, in addition to the existing support for symmetric key operations.

To implement the support for asymmetric key operations, the following procedures have been added to the DBMS_CRYPTO package:

• PKENCRYPT
• PKDECRYPT
• SIGN
• VERIFY

View Documentation

This page describes the features and behavioral changes that are new in Release Update 19.10.

Ability to Use Multiple Kerberos Principals with a Single Database Client

Starting with this release, when you configure Kerberos authentication for an Oracle Database client, you can specify multiple Kerberos principals with a single Oracle Database client.

To enable this functionality, you will need to create a separate credential cache for each user in the client and then use the connect string to specify the user.

In previous releases, you were restricted to one Kerberos principal for each Oracle Database client.

View Documentation

DBMS_CLOUD Package

Oracle provides two core mechanisms to work with data in object stores, as part of the new DBMS_CLOUD package or manually defining external tables.

Using DBMS_CLOUD provides benefits and additional functionality that goes beyond DDL and is fully compatible with Oracle Autonomous Database. Oracle strongly recommends leveraging the new DBMS_CLOUD package over manual external table creation.

View Documentation

New Database Initialization Parameters for Database Resident Connection Pooling (DRCP)

New database initialization parameters, MIN_AUTH_SERVERS and MAX_AUTH_SERVERS, have been added to configure Database Resident Connection Pooling (DRCP).

MIN_AUTH_SERVERS and MAX_AUTH_SERVERS allow the number of processes used to handle session authentication for DRCP to be configured for optimal usage.

View Documentation

Oracle Blockchain Table

Blockchain tables are append-only tables in which only insert operations are allowed. Deleting rows is either prohibited or restricted based on time. Rows in a blockchain table are made tamper-resistant by special sequencing and chaining algorithms. Users can verify that rows have not been tampered. A hash value that is part of the row metadata is used to chain and validate rows.

Blockchain tables can be used to implement blockchain applications where the participants trust the Oracle Database provider, but want means to verify that their data hasn’t been tampered with. The participants are different database users who trust the Oracle Database provider to maintain a verifiable, tamper-resistant blockchain of transactions. All participants must have privileges to insert data into the blockchain table. The contents of the blockchain table are defined and managed by the application, with a few added metadata fields maintained by Oracle Database. By leveraging a trusted provider with verifiable crypto-secure data management practices, such applications can avoid the distributed consensus requirements. This provides most of the protection of the distributed peer-to-peer blockchains, but with much higher throughput and lower transaction latency compared to peer-to-peer blockchains using distributed consensus.

View Documentation

Oracle Instant Client Support for Linux for ARM

Starting with Oracle Database 19c Release Update (19.10), Oracle Instant Client is available on Linux for ARM (aarch64).

You can install Oracle Instant Client by downloading either the zip files or RPMs from the Oracle Instant Client download page on Oracle Technology Network (OTN).

View Documentation

Support Per-PDB Capture for Oracle Autonomous Database

To securely capture and replicate individual PDB changes to Oracle Autonomous Database, you can now use Oracle GoldenGate to provide per-PDB capture.

You can now provide local user credentials to connect to an individual PDB in a multitenant architecture Oracle Database, and replicate the data from just that PDB to an Oracle Autonomous Database. You no longer need to create a common user with access to all PDBs on the multitenant container database (CDB) to replicate a PDB to an Oracle Autonomous Database. Instead, you can now provision a local user with a predefined set of privileges to the source PDB that you want to capture. All LogMiner and Capture processing takes place only in this PDB, and only data from this specific PDB is captured and written to the Oracle GoldenGate trail. As part of this feature, the behavior for V$LOGMNR_CONTENTS changes, depending on whether you connect to a PDB, or connect to the CDB$ROOT.

View Documentation

Updated Support for Micro Edition Suite (MES) for FIPS 140.2

Starting with this release, Oracle Database supports Micro Edition Suite (MES) version 4.5 for FIPS 140.2.

The Micro Edition Suite (MES) version 4.5 updates include four new CVEs in the RSA BSAFE MES library, support for the rules that FIPS 140.2 requires, and access to the updated NZ/ZT library from the Crypto Foundation.

This enhancement enables the Oracle Database FIPS 140.2 configuration to benefit from new features and security improvements available from the latest RSA BSAFE MES library.

View Documentation

This page describes the features and behavioral changes that are new in Release Update 19.11.

Application Continuity Protection Check

Application Continuity Protection Check (ACCHK) provides guidance on the level of protection for each application that uses Application Continuity and assists you to increase protection, if required.

ACCHK identifies which application configuration is protected to help you make an informed decision about which configuration to use for maximum protection or how to increase protection level for an application configuration. ACCHK also provides diagnostics for an unsuccessful failover.

View Documentation

Immutable Tables

Immutable tables are insert-only tables in which existing data cannot be modified. Deleting rows is either prohibited or restricted based on the insertion time of the rows.

Immutable tables protect data against unauthorized modification by insiders. This includes database administrators or compromised users who have access to insider credentials. Immutable tables also prevent accidental data modification that may be caused by human error.

View Documentation

New Database Initialization Parameter for Database Resident Connection Pooling (DRCP)

A new database initialization parameter, DRCP_DEDICATED_OPT, has been added to configure Database Resident Connection Pooling (DRCP).

With DRCP, when the number of application connections to the broker is less than the maximum pool size, a “dedicated optimization” makes DRCP behave like dedicated servers. With this optimization, DRCP tends towards a one-to-one correspondence between application connections and DRCP server processes even if those processes are not currently doing database work. Setting DRCP_DEDICATED_OPT to NO turns off the optimization and reduces the tendency of the pool to grow towards its maximum size until necessary. This helps keep the number of DRCP server processes small when statement execution concurrency is low, therefore reducing memory usage on the database host.

View Documentation

Oracle Fleet Patching and Provisioning Zip Copy Image Transfer

Starting with Oracle Grid Infrastructure 19c Release Update (19.11), Oracle FPP enables you to install the gold images without transferring them to the target host. You can make the gold images available as zip files, either on a shared file system (NFS) or target hosts.

The Zip copy image transfer feature avoids errors and timeout for deployments with low bandwidth or high latency networks between the Oracle FPP Server and targets. This enables deployments in different data centers.

View Documentation

This page describes the features and behavioral changes that are new in Release Update 19.12.

Gradual Database Password Rollover for Applications

Starting with this release update, an application can change its database passwords without an administrator having to schedule downtime.

To accomplish this, a database administrator can associate a profile having a non-zero limit for the PASSWORD_ROLLOVER_TIME password profile parameter, new with this release, with an application schema. This allows the database password of the application user to be altered while allowing the older password to remain valid for the time specified by the PASSWORD_ROLLOVER_TIME limit. During the rollover period of time, the application instance can use either the old password or the new password to connect to the database server. When the rollover time expires, only the new password is allowed.

Before this enhancement, an administrator normally took the application down when the application database password was being rotated. This is because the password update requires changes on both the database and the application side. With the gradual database password rollover enhancement, the application can continue to use the older password until the new password is configured in the application.

In addition to the new clause PASSWORD_ROLLOVER_TIME in the CREATE PROFILE and ALTER PROFILE statements, the ALTER USER statement has a new clause, EXPIRE PASSWORD ROLLOVER PERIOD. The ACCOUNT_STATUS column of the DBA_USERS and USER_USERS data dictionary views have several new statuses indicating values to indicate rollover status.

Oracle Memory Speed Support for PMEM Devices

Oracle recommends that you use Oracle Database with the Oracle Memory Speed (OMS) file system to fully utilize the potential of persistent memory (PMEM) devices safely in data centers.

With PMEM as the backing device, OMS utilizes a memory-mapped file hosted on an XFS-based, DAX-enabled file system to perform I/O operations. You must export the PMEM device as a file using a DAX-enabled file system, such as XFS.

This page describes the features and behavioral changes that are new in Release Update 19.16.

Enhancements for Identity and Access Management Integration with Oracle Database Environments

Available for Oracle Database release 19.16 are enhancements to the integration of Identity and Access Management (IAM) users with Oracle Database Environments.

• Additional Oracle Database environments: The full list of supported Oracle Database environments is as follows:
  • Oracle Autonomous Database on Dedicated Exadata Infrastructure
  • Oracle Autonomous Database on Shared Exadata Infrastructure
  • Oracle Base Database Service
• Ability to use the IAM user name and password to retrieve an IAM token: Retrieving a token using an IAM user name and password or secure external password store (SEPS) is more secure than using the password verifier method of database access.

View Documentation

Oracle Data Guard Redo Decryption for Hybrid Disaster Recovery Configurations

Available for Oracle Database release 19.16, Oracle Data Guard enables you to decrypt redo operations in hybrid cloud disaster recovery configurations where the Cloud database is encrypted with TDE and the on-premises database is not.

Hybrid disaster recovery is often considered a quick-stepping stone to cloud adoption. By enabling the ability to quickly configure disaster recovery even in cases where on-premises databases might not already be encrypted with TDE, the steps required to configure hybrid disaster recovery environments are reduced while still ensuring that redo data is still encrypted during the transportation process.

To enable this feature, Oracle Database introduces the TABLESPACE_ENCRYPTION initialization parameter, which enables you to control the automatic encryption of tablespaces in both the primary and standby databases, for on-premises and Oracle Cloud Infrastructure (OCI) environments. For example, an on-premises database can be unencrypted and an OCI database can be encrypted.

View Documentation

This page describes the features and behavioral changes that are new in Release Update 19.18.

All Time Zone Files (DST) Included in Release Updates (RUs)

Starting with Oracle Database 19c RU 19.18.0, all available DST patches are installed with the RU, and deployed into the Oracle_home/oracore/zoneinfo directory. Installing DST patches does not affect database operation. However, installing the patches with the RU makes it easier for you to adjust the timezone version of your database, if you have a requirement to do so. For example, if you are using Transportable Tablespaces, or Full Transportable Export/Import, then you must ensure that your source and target databases are using identical character sets and identical time zone settings. With this change, you can more easily choose to change your destination database to use a different time zone file version than the default.

By default, AutoUpgrade changes the database time zone to the latest available level. If you don’t want the time zone to be upgraded, then you must explicitly set the local parameter timezone_upg in your AutoUpgrade configuration file to no. For example:

upg1.timezone_upg=no

If you choose to use an older database time zone file, then set the database environment variable ORA_TZFILE to the older time zone file. The time zone files are located in Oracle_home/oracore/zoneinfo. By using the environment variable ORA_TZFILE, you can override the default of using the highest-numbered time zone file.

View documentation:

• Choosing a Time Zone File
• RUs contain now all available DST patches
• Create a database with NON-DEFAULT Time Zone

This page describes the features and behavioral changes that are new in Release Update 19.20.

In-Memory Eligibility Test

Many workloads benefit from Database In-Memory, however some may not. The In-Memory Eligibility Tool determines if a given workload would benefit or not benefit from Database In-Memory and assesses its eligibility for use of this feature. Eligibility is gauged by the percentage of analytical activity in the workload. If you are planning to implement Database In-Memory, you can use this tool to quickly identify and filter out databases that are ineligible - those where analytic activity is low and where you would see no substantive gain from the use of Database In-Memory. You can then focus your Database In-Memory deployment on databases whose workload includes more intense analytic activity and could therefore benefit substantially. The higher the percentage of analytical activity in the workload, the more benefit you gain from Database In-Memory.

View Documentation