Understand WebSphere GC

What you are seeing is the standard 'sawtooth' pattern of GC. The heap is made up of the nursery and tenured areas. In the nursery the GC performs whats called a scavenge operation

which is a small gc only within the nursery area which will likely account for the smaller jumps you observed in the graph. When you click perform GC it will generate a 'full gc' which

will instigate both a scavenge operation on the nursery area and a mark sweep compact on the tenured area which is why there was a sudden drop in the graph at that time.

GC would have performed that full gc operation as and when it was required and up until then it had not been required and it only happened because you forced a full gc.

It is important to understand that the heap is there to be used so if you see it well used this is a good thing as long as it is performing ok.

Apache httpd SSL Certificate Administration

https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs

https://knowledge.digicert.com/solution/SO10262.html

Oracle RAC Trouble Shooting

$GRID_HOME/bin/crsctl query crs softwarepatch -l
$GRID_HOME/bin/crsctl query crs releasepatch
$GRID_HOME/bin/crsctl query crs releasepatch
$GRID_HOME/bin/crsctl check crs
$GRID_HOME/bin/crsctl stop crs -f
$GRID_HOME/bin/crsctl check crs
$GRID_HOME/bin/crsctl stat res ora.drivers.acfs -init
$GRID_HOME/bin/crsctl stat res ora.drivers.acfs -init
$GRID_HOME/bin/crsctl enable crs
$GRID_HOME/bin/crsctl enable crs .... success.
$GRID_HOME/bin/crsctl start crs -wait
$GRID_HOME/bin/crsctl check crs
$GRID_HOME/bin/crsctl stop rollingpatch
$GRID_HOME/bin/crsctl query crs activeversion -f
$GRID_HOME/bin/crsctl query crs activeversion -f
$GRID_HOME/bin/crsctl stat res ora.drivers.acfs -init
$GRID_HOME/bin/crsctl stat res ora.drivers.acfs -init
$GRID_HOME/bin/crsctl check crs
$GRID_HOME/bin/crsctl query crs releasepatch
$GRID_HOME/bin/crsctl query crs activeversion -f

crsctl status res -t 
crsctl status res -t -init 
<GI_HOME>/bin/kfod op=patches 
<GI_HOME>/bin/kfod op=patchlvl 
crsctl query crs activeversion -f 
crsctl query crs softwareversion 
crsctl query crs releaseversion 
<GI_HOME>/OPatch/opatch lsinventory detail -oh $ORACLE_HOME 
<DB_HOME>/OPatch/opatch lsinventory detail -oh $ORACLE_HOME 

CRS-6706: Oracle Clusterware Release patch level ('2104789788') does not match Software patch level ('448950863'). Oracle Clusterware cannot be started.

CRS-6706: Oracle Clusterware Release patch level ('nnn') does not match Software patch level ('mmm') (Doc ID 1639285.1)

For 12.1 version :

Execute"<GI_HOME>/crs/install/rootcrs.sh -patch" as root user on the problematic node and the patch level should be corrected.

For 12.2

Execute"<GI_HOME>/crs/install/rootcrs.pl -prepatch"  "<GI_HOME>/crs/install/rootcrs.pl -postpatch"and as root user on the problematic node and the patch level should be corrected.

If still not working, you can try below solution:

Patching 12.2.0.1 Grid Infrastructure gives error CRS-6706: Oracle Clusterware Release Patch Level ('748994161') Does Not Match Software Patch Level (Doc ID 2348013.1)

CAUSE

This issue was caused by rootcrs.sh -prepatch not run successfully before patching.  The user ran rootcrs.sh -unlock because rootcrs.sh -prepatch failed, and then applied the patch manually. 
 

SOLUTION

 Please use the following steps to complete the patching:

1.  Run the following command as the root user to complete the patching set up behind the scenes:
#GI_HOME/bin:>  ./clscfg -localpatch

2.  Run the following command as the root user to lock the GI home:
#GI_HOME/crs/install:>  ./rootcrs.sh -lock

3.  Run the following command as the root user to start the GI:
#GI_HOME/bin:>  ./crsctl start crs

Recreate Oracle Inventory

 ls -l  $ORACLE_HOME/oraInst.loc /var/opt/oracle/oraInst.loc

OraDB12Home1

./runInstaller -silent -attachHome ORACLE_HOME="/app/oracle/product/12.2.0.1" ORACLE_HOME_NAME="OraDB12Home1"

$ find . -name installActions*
./cfgtoollogs/oui/installActions2017-08-30_02-21-33PM.log
$ grep -i oracle_home_name ./cfgtoollogs/oui/installActions2017-08-30_02-21-33PM.log
INFO: setting ORACLE_HOME_NAME=OraDB12Home1. A default value was calculated as per oraparam.ini
INFO: Computed ORACLE_HOME_NAME = OraDB12Home1
INFO: Setting the value  for ORACLE_HOME_NAME variable
INFO: Setting variable 'ORACLE_HOME_NAME' to 'OraDB12Home1'. Received the value from the command line.
INFO: Setting the 'OracleHomeName ( ORACLE_HOME_NAME )' property to 'OraDB12Home1'. Received the value from the command line.
INFO: ORACLE_HOME_NAME is not settable, hence not setting the value