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.
Within an individual PDB, you can limit access to the shared In-Memory Area by setting INMEMORY_SIZE to a different value. For example, in a CDB with 100 PDBs, you could set INMEMORY_SIZE to 16G at the CDB level and then set INMEMORY_SIZE to 10G in one PDB, to 6G in a second PDB, and to 0 in the remaining PDBs.
It is the Oracle21c feature backported to Oracle19c 19.8 RU.
For more information see:
If you want to perform a cross-platform upgrade, you need to know the restrictions and guidelines of this method.
When using DBUA or performing a manual upgrade for Oracle Database, you cannot directly migrate or transport data in a database on one operating system to another operating system. For example, you cannot migrate data in an Oracle database on Solaris to an Oracle 19c database on Windows using DBUA. You must follow procedures specific to your operating system platforms.
To see the platforms that support cross-platform data transport, run the following query using SQL*Plus:
You now can control the size of the batch of heartbeats that use Oracle Key Vault or OCI KMS (OCI Vault) for centralized key management. The HEARTBEAT_BATCH_SIZE initialization parameter, new with this release, enables you to set the heartbeat batch size. The duration of the heartbeat period defaults to 3 seconds.
This enhancement benefits the situation where you have a very large deployment of PDBs (for example, 1000) that use Oracle Key Vault. By setting the heartbeat batch size, you can stagger the heartbeats across batches of PDBs to ensure that for each batch a heartbeat can be completed for each PDB within the batch during the heartbeat period, and also ensure that PDB keys can be reliably fetched from an Oracle Key Vault server and cached in the persistent state.
For more information see:
Query v$sql_monitor is slow. the execution plan shows ‘Full Table Scan’ on Fixed table ‘X$KESWXMON’.
The fix for 28789533 is first included in:
Oracle 188.8.131.52 APR 2021 DB RU
Since Oracle Database 12.2, due to designing change, it becomes no limitation of max entries of the password file, and the “entries” argument of ‘orapwd’ command is deprecated, and password file is made auto-extensible, and prior to 184.108.40.206, password file is made auto-extensible ORA-01996 will happen when the number entries in Password file exceeds the “entries” value prior to 220.127.116.11. Even though the “entries” argument is deprecated, no error happens if the user specifies it explicitly on ‘orapwd’ command.
According to the description of the online documentation prior to Oracle Database 12.2, the actual number of allowable entries can be higher than the number of specified entries, because the ‘orapwd’ utility continues to assign password entries until an operating system block is filled. For example, if your operating system block size is 512 bytes, it holds four password entries. The number of password entries allocated is always a multiple of four. When you exceed the allocated number of password entries, you must create a new password file. To avoid this necessity, allocate more entries than you think you will ever need.