19c important features

19c features 

Automatic flashback in standby following primary database flashback

DBA's often kill the blocking sessions and from 19c (not sure which patch set) 

we have new parameter called MAX_IDLE_BLOCKER_TIME parameter which helps to specifies the maximum number of minutes that a blocking session can be idle. After that point, the session is automatically terminated.

This parameter differs from the MAX_IDLE_TIME parameter in that MAX_IDLE_TIME applies to all sessions (blocking and non-blocking), whereas MAX_IDLE_BLOCKING_TIME applies only to blocking sessions. Therefore, in order for MAX_IDLE_BLOCKING_TIME to be effective, its limit must be less than the MAX_IDLE_TIME limit.

And the MAX_IDLE_TIME limit parameter is available from 12.2.0.1 version.

*******************************************************************************************

Configuring Fast-Start Failover in Observe-only Mode

Starting 19c , dataguard broker can be put in observe only mode instead performing FSFO. This will help to test the broker conditions that have met. There will be entries in the broker log or observer log indicating Fast start failover would have been initiated.

DGMGRL> ENABLE FAST_START FAILOVER OBSERVE ONLY;

*********************************************************************************************

Automatic flashback in standby following primary database flashback

******************************************************************************************

 EZConnect Enhancements

EZConnect is something very useful to make fast connection calls without requiring a TNS. Problem is that, until now, if you want to use some value pairs likes SDU, RETRY_COUNT, CONNECT_TIMEOUT, this wasn't possible and you would end-up using TNS. Now in 19c you will be able to write something like:

sqlplus user/pwd@//DB:1521/host?connect_timeout=100&transport_connect_timeout=10&retry_count=3

********************************************************************************************

How does DML redirect to standby works

In Oracle 19c, one can submit the DML to readonly standby database. the internals of the database detect a dml on standby and redirect that dml to primary apply it on primary and apply to standby back. However this require careful consideration of redo generation and identify the potential dml's or occasional dml;s that can go to standby.

The DML Redirection process breaks down in 5 steps:

The Client issues a DML against the read-only Standby Database

The standby notices it is DML and sends this DML towards the primary database using an internal Db-link

The primary executes the DML (which then generates redo)

This redo is a normal redo stream and together with the normal redo stream this is sent to the standby database

The standby database applies the received redo stream and releases the lock on the session so the session can see the result.

So consider before you put this feature in place and understand bandwidth and ideal candidates for DMLs that can run on standby.

*****************************************************************

 Auto upgrade utility

Autoupgrade is compatible with 12.2 and 18.5 and you need to download the kit from 2485457.1

Autoupgrade.jar is available default in 19c

How this works

Prevent Issues : Analyze and Fixup Modes

java -jar autoupgrade.jar -config config.txt -mode analyze

java -jar autoupgrade.jar -config config.txt -mode fixups

Simplifying Upgrade: Deploy and upgrade

java -jar autoupgrade.jar -config config.txt -mode deploy/upgrade

+++++++++++++++++++++++++++++++++++++

 DBCA Enhancements

19c, DBCA facilitates duplication of db with new “CreateDuplicateDB”

Requires easy connection string so that it duplicates the target db to wherever running .