RU Apr 2020 installed

RU Update 19.7 done.

Environment : Exadata, X7-2, 4 node, RAC Cluster

 

opatch lspatches

30805684;OJVM RELEASE UPDATE: 19.7.0.0.200414 (30805684)

30869156;Database Release Update : 19.7.0.0.200414 (30869156)

29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

 

No error, works perfect. 👍

 

So we can go on to test Upgrades with „autoupgrade“ for the RAC DB’s …..

 

Oracle Cloud „follow up“

Follow up:  „How to setup a CentOS instance and connect via ssh“

Login to the „Oracle Cloud“ via browser

go to -> Compute -> Instance

create a new instance

But before going on setup a ssh-key

 


ssh-keygen -t rsa -N "" -b 2048 -C "oracloud" -f /Users/user/.ssh

 

Now you are ready to start the setup and therefore upload the public key before

starting the installation. (id_rsa.pub) The public key upload is mandatory!

 

After a few minutes the setup is done. restart the instance

Check the instance

For the connect via ssh use the Linux User „opc“  in the Oracle Cloud and your „public-IP address

The „opc“ user has no Login password!

 

When the instance started and a „Login screen“ came up with

„user“ and „password“ you forget to upload the public-key during setup

 

Here the standard Login after correct setup


ssh opc@158.101.166.239 
[opc@pg11 ~]$ 

 

For root Login enter

sudo su

[root@pg11 opc]#

You need no root password!

 

That’s it you are logged in start with your work and have fun

The Oracle Cloud documentation for this setup is not very handy

I hope that these few lines help you to get a new machine in the Oracle Cloud fast up and running

forever free :-)

 

 

 

 

 

 

 

 

 

Autonomous Health Framework (AHF) available

Bildschirmfoto 2019-10-28 um 19.36.24

Oracle released the new Autonomous Health Framework since one week. It is very interesting to go through the list of new and changed features.

Yes after a very long time we had one Tool which bring everything together:

  • one single Interface
  • all diagnostics tools in one bundle makes everything easier
  • Automatic proactive compliance checks helps to fix problems
  • Diagnostic when the failure occur ensures you get everything for the resolution

To get familiar go to Oracle Support and Download the AHF Framework. You find everything while open the Doc ID 2550798.1

Download install and have fun :-)

In the meantime I did an installation on a Exadata X7 4 Node RAC and it works perfect. The old data of tfactl and exachk will be moved to the new directories and everything starts very smooth. Easy and smooth Setup. Now we have the Tools in one location on the Compute Nodes.

 

 

12.2 Grid Patching lesson learned

What happend?

During the last month I updated manually the TFA Software.

I  do this update while the TFA release installed via the Patchset is an older Version. This happens while Oracle Support adds the TFA release which is available while they create the Patchset.

Last weekend I start Patching GI Software 12.2 to RU Oct 2018 on a 4 Node Exadata Cluster

As best practice I do the installation manually and not via opatchauto.

First activity is:

/u01/app/12.2.0.1/grid/crs/install/rootcrs.sh -prepatch

This ends with the following error message:

2019/03/09 13:36:12 CLSRSC-46: Error: ‚/u01/app/12.2.0.1/grid/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar‘ does not exist
2019/03/09 13:36:12 CLSRSC-152: Could not set ownership on ‚/u01/app/12.2.0.1/grid/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar‘
Died at /u01/app/12.2.0.1/grid/crs/install/crsutils.pm line 7573.
The command ‚/u01/app/12.2.0.1/grid/perl/bin/perl -I/u01/app/12.2.0.1/grid/perl/lib -I/u01/app/12.2.0.1/grid/crs/install /u01/app/12.2.0.1/grid/crs/install/rootcrs.pl -prepatch‘ execution failed

The following Doc ID 2409411.1 describes how to fix this by modifying two files. I should be fixed in Grid Release 18. 

$GRID_HOME/crs/sbs/crsconfig_fileperms.sbs
$GRID_HOME/crs/utl/<node>/crsconfig_fileperms

remove the following two entries.
unix %ORA_CRS_HOME%/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar %HAS_USER% %ORA_DBA_GROUP% 0644
unix %ORA_CRS_HOME%/suptools/tfa/release/tfa_home/jlib/jewt4.jar %HAS_USER% %ORA_DBA_GROUP% 0644

I made the changes but it did not fix the problem. So I can’t go on with the Patching. For me it looks like a problem with the file permissions.

So next research on MOS and I found this important Doc ID 1931142.1:

„How to check and fix file permissions on Grid Infrastructure environment“

Yes, this was the solution :-)

cd /u01/app/12.2.0.1/grid/crs/install/

./rootcrs.sh -init

Using configuration parameter file: /u01/app/12.2.0.1/grid/crs/install/crsconfig_params

As an add on in the note you can check after the „-init“ the complete GI Installation with the following cluvfy command.

cluvfy comp software -n all -verbose

Verifying Software home: /u01/app/12.2.0.1/grid …2894 files verified
Verifying Software home: /u01/app/12.2.0.1/grid …PASSED

Verification of software was successful.

CVU operation performed: software
Date: Mar 11, 2019 10:10:11 AM
CVU home: /u01/app/12.2.0.1/grid/
User: oracle

This is very helpful. Finally I start the GI Patching without any problems

Lesson learned

„It is a good idea to check from time to time the status of the Software via cluvfy.“