Gradual Database Password Rollover for Applications

,

Starting with the Oracle Database 21c release, 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 used 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. It is an Oracle 21c feature backported to Oracle 19.12 RU.

Check out:

https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-authentication.html#GUID-ACBA8DAE-C5B4-4811-A31D-53B97C50249B

/0 Comments/by

Bug 32008819

,

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)

/0 Comments/by

Oracle Database 19c RU, RUR, and BP Jul 2021 Known Issues

, , ,
Read more
/0 Comments/by

Critical Patch Update for July 2021

, , ,

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

/0 Comments/by

Security Features of Oracle Database 12c

Read more
/0 Comments/by

Using Transaction Guard

,
Read more
/0 Comments/by

In-Memory Base Level

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

/0 Comments/by

Transporting Data to a Different Operating System

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

/0 Comments/by

Ability to Control Heartbeats in United Mode and Isolated Mode PDBs

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

/0 Comments/by