Oracle 19c is now available for Oracle Cloud and Exadata. It’s not yet available for “on-premises”, but it will no doubt be available shortly. Well, hopefully.
19c is the terminal release of 12.2, which means that prior to Oracle’s versioning changes, it would have been referred to as 18.104.22.168. As of the time of writing, it will be supported for the next 4 years under Premium Support and 3 years under Extended Support.
This is probably going to be the version that those waiting to pull the plug on upgrading to 12c are going to move to as 18c is still quite buggy (especially for versions < 18.1.5)
Bear in mind that there is no support for 19c on Linux 6. The minimum versions of the O/S and kernels are as follows:
- Oracle Linux 7.4 with the Unbreakable Enterprise Kernel 4: 4.1.12-112.16.7.el7uek.x86_64 or later
- Oracle Linux 7.4 with the Unbreakable Enterprise Kernel 5: 4.14.35-1818.1.6.el7uek.x86_64 or later
- Oracle Linux 7.4 with the Red Hat Compatible kernel: 3.10.0-622.214.171.124.1.el7.x86_64 or later
- Red Hat Enterprise Linux 7.4: 3.10.0-6126.96.36.199.1.el7.x86_64 or later
- SuSE Linux Enterprise Server 12 SP3: 4.4.103-92.56-default or later
It’s been 17 years since I worked with an Oracle database running on SuSE, but there must be some hiding out there somewhere!
One thing to bear in mind, though, is that the upgrade to 19c on Exadata can be quite painful. If you moved to 18c and found it to be nice and (relatively) easy, don’t be surprised if 19c is trickier.
As we try and contain our excitement, here are some of the features I think are going to be the most useful.
This is only available in 19c and for Exadata or Oracle Cloud environments and is primarily designed for Oracle’s set of Autonomous databases (ATP, ADW).
The analysis into potential Automatic Indexes is done outside the application workflow to avoid impacting performance.
- Builds up an SQL repository – a profile of application performance.
- Creates invisible indexes for candidate indexes.
- Drops obsoleted indexes.
- Asks the optimizer whether the candidate indexes will produce a performance benefit.
- If the optimizer decides to use the indexes, they are onlined for either SQL statements which would benefit or the database as a whole.
- The use of these indexes is then monitored and any indexes not used in a “long time” are dropped.
Automatic indexes are useful for all workloads, but especially OLTP. Function-based indexes as are compressed indexes as long as they are compressed with “Advanced, Low”.
The use of Automatic Indexes can be monitored and managed via the DBMS_AUTO_INDEX package.
Quarantining of SQL Plans
Oracle Resource Manager allows you to specify criteria to define a runaway query and any SQL statement that exceeded the specified limits would be automatically be terminated.
However, nothing prevented an end user from continually issuing such statements, wasting valuable system resources. Starting in 19c, runaway SQL plans terminated by Resource Manager due to excessive consumption of CPU or I/O resources will be automatically quarantined. This will prevent these plans from executing again.
To “release” a SQL statement from quarantine, the DBA can tune the statement and force a new plan for the statement to be generated.
Automatic Flashback of standby databases
A standby database will now automatically Flashback if there is a Flashback operation on the primary database.
This helps keep the standby in sync with the primary as it avoids the DBA having to manually perform the procedure.
Built-in Privilege Analysis
Privilege Analysis was a feature exclusively for Database Vault in 12c. It is now available in the Enterprise Edition of 19c without the need for Database Vault.
Privilege analysis runs dynamic analysis of users and applications to find privileges and roles that are used and unused, which helps implement the least privilege best practices.
Active Standby DML Redirect
Almost all of my customers who use Data Guard leverage the Active Data Guard feature and its ability to make use of standby databases for reporting and backups.
In 19c, users can send such write requests to the standby. These writes are then transparently redirected to the primary database and written there first (to ensure consistency) and then the changes are shipped back to the standby.
For more info: