Database Technologies...!

Oracle - 12.2.0.1 When applying RU JAN_2019 DB/GI patch on 2 node RAC using rolling method, apply phase on node 1 failed with below errors, CRS-4698: Error code 2 in retrieving the patch level CRS-1154: There was an error setting Oracle ASM to rolling patch mode. CRS-4000: Command Start failed, or completed with errors. 2019/08/28 01:18:08 CLSRSC-430: Failed to start rolling patch mode All prerequisite and verification phases were successful and a quick search showed that this error (CRS-1154) can occur  if ASM rebalance operation was running during the patch apply. In our scenario no REBAL was going and the systems were almost idle as it was off peak hours. Strange enough second attempt with " opatchauto resume" went through without any errors. Also haven't come across this error code during the patch apply on node 2 of same cluster or any of the other clusters patched.

Below is a quick way to access all client databases to get the output of a specific query. This can be really helpful during audits where particular parameter or configuration is checked throughout all the databases. In the example cloud control host (Running RHEL 7.5) is used to check whether flashback is enabled on every client database. First generate TNS names of client databases based on tnsnames.ora, cat tnsnames.ora | grep -iv "(" | grep -i "=" | cut -d = -f 1 > db_list.out Then run the simple bash script below, #!/bin/bash export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/db_1 export PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/oracle/bin:/u01/app/oracle/product/12.1.0.2/db_1/bin:/bin LOC=/home/oracle/audit_outs cat $LOC/db_list.txt | while read line do export ORACLE_SID=$line sqlplus -S -M "HTML ON" dbsnmp/"<password>"@"$line"<<E

After the restore of rman backup the recover session might return errors similar to below, This is  a common scenario but still it seems there are difficulties in understanding the reason why rman is asking for more logs.  So when rman complains on set of missing logs, find the oldest log it is asking and check the first_time/next_time values of particular log from (g)v$archived_log .  If the value returned is older than the restored control file time ( select checkpoint_time from v$datafile ) and between the backup start time, it is required to provide a valid backup of the archive log or in a situation where backup is not available consider opening the database with inconsistencies. In the scenario shown in above image, the minimum log rman was asking was sequence 777682 of thread 1. For this sequence this was a archive log generated at 11.10 AM 26th July while the controlfile restored was from 11.50 AM 26th July. So we need to provide the correct backup. Depending