Upgrade from OEL 6 to 7

Oracle 19c does not support OEL 6 so it is now time to upgrade my vm’s to OEL 7.

These are the steps:

  1. Make sure you have repositories ol6_x86_64_latest and ol6_x86_64_addons configured and enabled.
  2. Update to the latest OEL 6 version
    • yum update -y
  3. Install required packages
    • yum install redhat-upgrade-tool preupgrade-assistant preupgrade-assistant-el6toel7 preupgrade-assistant-el6toel7-data-0 preupgrade-assistant-tools preupgrade-assistant-ui openscap
  4. Run the upgrade assessment
    • preupg
  5. Review the output and if the assessment reports any fail, needs_action, or needs_inspection issues, read the remediation instructions for these issues and perform any required actions before proceeding with the upgrade.
  6. Download the ISO file from Edelivery.oracle.com. Choose version OEL 7.5.
  7. Copy the ISO to the server
  8. Run the upgrade tool
    1. redhat-upgrade-tool-cli –iso=V975367-01.iso –debuglog=/tmp/upgrade.log –cleanup-post
  9. Reboot the system to start the upgrade

Enjoy !

error DIA-49803 on adrci purge

I am a big fan of automation. I don’t like to do the same thing over and over, so after reading the post about purge/rotate oracle trace and log files from Fred Denis I started testing his scripts to implement them.

Everything was perfect until I run adrci purge to clean rdbms old files from Oracle 12.1 and got error DIA-49803.

MOS to the rescue and after digging I found note:
2341825.1 -Purge Does Not Work In 12.2 If ADRCI Is Used To Access An Older ADR Home, which is exactly my case.

So the recommendation is simple: use the version of ADRCI that is shipped with the version of the database ($ORACLE_HOME/rdbms/bin/adrci).

For the record: This server has Grid 12.2 and RDBMS 12.1 and 12.2.

OPatch update for EMGC

Download the latest version from here.

For EMGC 13.1 and above , select the version as “13.9.0.0.0” (Release- OPatch 13.9.0.0.0). Unzip the file into a staging directory like /u01/stage/.

Stop OMS with $ORACLE_HOME/emctl stop oms -all where OH is the middleware home.

Run: java -jar <STAGE_DIR>/6880880/opatch_generic.jar -silent oracle_home=$ORACLE_HOME

To validate the installation run $ORACLE_HOME/OPatch/opatch version

The output should match the value from the readme file.



TFA collections very slow

Working with Oracle you already know that one day you will have to upload a tfa diagcollect log to Oracle Support.

As I always update TFA as soon as a new version comes out it was just a matter of running it. Right now the latest version is 18.4.2 and can be download here.

I did and wow … nothing happened. It hanged forever doing I do not know what.

Logs from the diagcollect were not helpful and neither strace.

I uploaded the files manually following MOS note: 2291539.1 and then filed another SR to support about the TFA issue.

A couple of days later and the analyst came with a workaround: set trimfiles=OFF

If you want to know more about TFA take a look at my OTN Brazil article here.

ORA-28040: No matching authentication protocol

We deployed a new app last week and got the error ORA-28040: No matching authentication protocol while establishing a connection to the database.

It turns out that this app was using an embedded Oracle client 11.1 hence this error.

Oracle recommends that you upgrade your client software to match the current server software, which in my case is Oracle 12.2.

To fix this error you can upgrade the client or config the new parameter
SQLNET.ALLOWED_LOGON_VERSION_SERVER according to the documentation:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/upgrd/required-tasks-complete-upgrading-oracle-database.html#GUID-433E0DB9-026E-4322-A8FF-BA0E108AB28B

MOS 1957995.1 says that the default for the SQLNET.ALLOWED_LOGON_VERSION_SERVER setting has changed in 12.2 from 11 to 12. So if your client is not at least 11.2.0.3 or includes the CPUOCT2012 patch you will not be able to use the 12 setting.

It looks accurate as client 11.1 fails to connect to Oracle 12.2 and client 11.2 works: