DBMS_LOB.APPEND RAISES ORA-22275 WHEN CLOB RETURNED BY XMLSERIALIZE() GETS APPENDED TO ANOTHER CLOB
REDISCOVERY INFORMATION:

Error signaling Function: koklnflushint

The fix for 32008819 is first included in 19.11.0.0.DBRU:210420 (APR 2021) DB Release Update(DB RU)

Oracle has released its Critical Patch Update for July 2021 to address 327 vulnerabilities across multiple products. A remote attacker could exploit some of these vulnerabilities to take control of an affected system. CISA encourages users and administrators to review the Oracle July 2021 Critical Patch Update and apply the necessary updates.
https://lnkd.in/d7fVVQQ

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:
https://lnkd.in/dVkq-TH

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:

SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME;
If the source platform and the target platform are of different endianness, then you cannot use the RMAN CONVERT DATABASE  command. This process requires both the source and target platform to be the same endian value. Your available options are Data Pump replication, Data Pump export/import, or Transportable Tablespace, with an RMAN CONVERT TABLESPACE. If the platforms are of the same endianness, then no conversion is necessary and data can be transported as if on the same platform.

For more information see:

Oracle Database Administrator’s Guide for a discussion of transporting data across platforms

Oracle Database Backup and Recovery User’s Guide for information on using the RMAN CONVERT DATABASE and RMAN CONVERT TABLESPACE commands

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:

https://docs.oracle.com/en/database/oracle/oracle-database/21/asoag/configuring-united-mode2.html#GUID-B4B3CCD1-B10B-4CA8-AA54-57A27AAB58D0

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 19.11.0.0 APR 2021 DB RU