Enhanced Diagnosability of Oracle Database
Diagnosability of database issues is enhanced through a new attention log, as well as classification of information written to database trace files. The new attention log is written in a structured format (XML or JSON) that is much easier to process or interpret and only contains information that requires attention from an administrator. Trace files now contain information that enables easier classification of trace messages.
Enhanced diagnosability features simplify database administration and improve data security.
SQL*Net Improved Diagnosability
Starting with Oracle Database 21c, a connection identifier is available for each network connection. The connection identifier uniquely identifies a connection in trace and logs of different network elements and helps in correlating diagnostic data from these elements.
When a SQL*Net connection has multiple hops, such as from a client to Oracle Connection Manager (CMAN) and then to a server, correlating diagnostic information from the existing logs and traces becomes difficult. However, with the availability of a connection identifier, you can now easily correlate diagnostics, track network data traffic, and resolve connectivity errors.
Persistent Memory Database
The Persistent Memory Database (PMEM) support feature enables you to place database files directly on non-volatile memory. The underlying file store is FsDirect, a pointer-switching PMEM file system that supports atomic writes of Oracle Database data blocks. The FsDirect PMEM file store provides the external interface for map and access the Oracle database directly in persistent memory.
Queries can read directly from PMEM without first copying data into the database buffer cache, avoiding data redundancy and unnecessary I/O.
Oracle Persistent Memory Database is ideal for providing high performance with small-scale databases such as those used in Microservices, Sharding, and Read Replicas. Oracle Persistent Memory Database delivers higher transaction rates and fast response-time, achieving unprecedented levels of performance for small-scale systems.
DAX-Enabled File Systems
You must use an XFS-based Data Analytics Accelerator (DAX) file system as the file store for the Persistent Memory (PMEM) database.
You can use a PMEM file store for database data files and control files. For performance reasons, Oracle recommends that you store redo log files as independent files in the file system.
New Database Initialization Parameters for Database Resident Connection Pooling (DRCP)
New database initialization parameters,
MAX_AUTH_SERVERS, have been added to configure
Database Resident Connection Pooling (DRCP).
allow the number of processes used to handle session authentication
for DRCP to be configured for optimal usage. Authentication
server statistics can be viewed in
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.
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
Multi-Mount DBFS Client
DBFS (Database File System) provides a file system interface for
storing files/directories in the Oracle database.
dbfs_client, helps in exposing a DBFS in a database
user as a mount point for the OS. The current version of
dbfs_client can service only the DBFS of a single
Databases can have a number of PDBs each having their own DBFS
that they use to store various files (e.g trace files, import dump,
user files etc). There can be about 100 PDBs and hence a 100 DBFS
to be serviced concurrently. In order to cater to this environment
dbfs_client needs be able to service multiple DBFS
owned by different users across databases. Currently a
dbfs_client instance can service only one DBFS. Hence,
to service 100 DBFS the same number of
instances would be required. Currently in DBFS, there does not
exist a single point of control that can manage all these different
dbfs_client instances. This could make the management
and monitoring of different client instances burdensome for
This enhanced version of
dbfs_client is capable of
servicing DBFS of multiple database users. This means that
dbfs_client can handle multiple mount points, each
mount point services DBFS under one database user. This enhanced
dbfs_client is referred to as MUMV (Multi
User Mount Version) and the earlier version of
dbfs_client is referred to as SUMV (Single User Mount
Version). The new version of
dbfs_client can be
started in SUMV mode or MUMV mode. If started in SUMV mode, its
behavior is the same as the earlier version.
DBFS provides a file system interface for storing
files/directories in the Oracle database. Existing single-mount
DBFS clients (
dbfs_client) could mount only one
user’s DBFS file system. DBFS therefore required multiple
DBFS client processes to support multiple file systems on the same
host’s DBFS file system. This enhanced DBFS multi-mode client
can manage different mount points within a single DBFS client
process. DBFS client with multi-mount support provides better ease
of use and improved performance. Multi-mount DBFS client scales
seamlessly to 100s of PDBs and DBFS client can be started as either
MUMV (Multi User Mount Version) or SUMV (Single User Mount Version)
Near Zero Brownout for Planned Maintenance
Planned maintenance and unplanned outages restart the database instances, but planned maintenance allows for preparation. Near Zero Brownout for Planned Maintenance reduces reconfiguration time for an instance targeted for a planned maintenance operation.
Near Zero Brownout for Planned Maintenance increases the availability of the database during online maintenance operations.
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
Read-Only Oracle Home Default
Read-only Oracle homes, where all configuration data and log files reside outside of the read-only Oracle home, are the default option for Oracle Database installations and upgrades.
Read-only Oracle homes enable an easy, flexible, and software-image based deployment of Oracle software that can automatically and seamlessly be distributed across multiple servers. Read-only Oracle homes also enable patching and updating of Oracle Database without extended downtime, as patching simply means replacing a given set of binaries in a defined location.