After 12c Upgrade: ORA-28040: No matching authentication protocol

An application could not connect to the Oracle Database that was upgraded to 12c (12.1.0.2). Whenever it tried connecting, the database would return the error ORA-28040: No matching authentication protocol back to the application.

Bug 14575666 states:
In 12.1, the default value for the SQLNET.ALLOWED_LOGON_VERSION parameter (deprecated now) has been updated to 11. This means that database clients using pre-11g JDBC thin drivers cannot authenticate to 12.1 database servers unless the SQLNET.ALLOWED_LOGON_VERSION parameter is set to the old default of 8.

Solution:
As the SQLNET.ALLOWED_LOGON_VERSION is a deprecated parameter, although it will work but will keep flooding your ALERT LOG file, it's best to use the updated parameter(s):

Add the below line(s) in the SQLNET.ORA file on the database server:

SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8

Hope this helps...

Oracle Linux 7.1 Installation on VMWARE for Oracle Databases

Required Software:

1. VMWARE Workstation
2. Linux 7.1 Installation ISO (V74844-01.iso) from edelivery.com.oracle

Let's get started:

Step 1: Create a new Virtual Machine on VMWARE.

This is something very usual so I wont be getting into details.

Use Bridged Networking if you want to assign the VM it's own IP Address

Choose your location accordingly.

Add the ISO image of Linux Installation to the CD ROM. Then start the Virtual Machine.

Step 2: Start the Virtual Machine

Let's start with the OS Installation:

Next screen is where most of the Installation Configuration will take place. Let's take it one-by-one.

Date and Time - change the settings as per your wish/requirement

Installation Destination: 
You can let the installation to Automatically partition the disk (recommended), else Configure it as per your requirement. 

Software Selection:

Choose Server with GUI on the left, and the following Add-Ons on the right:

 - Java Platform

 - Compatibility Libraries

 - Development Tools

Network and Host name:
If you miss this step, you may have a tough time to configure your VM later on. This is where the installation is a bit different from Linux 7 - for which there are many guides already available on the Internet.

Swipe the ON/OFF button to show ON.
Also, change the host name as per your preference.

This will take the IP address from the DHCP server of the router your laptop/PC is connected to. So, we will set it manually. 

Click Configure, and add the IP Address, Netmask (255.255.255.0) and Gateway as per your network preferences.

KDump - can stay enabled or disabled as per your wish.

So finally the Installation Summary should look like the below. Click 'Begin Installation'.

While the OS starts installing, you can set the root password, and any User Creations if required.

After the reboot, accept the license to proceed. 

Voola... Your Linux 7.1 Virtual Machine is ready for use! 

Feel free to drop in any queries you may have.

RMAN BACKUP AS COPY failing with ORA-00600 [kfioTranslateIO03] [17090]

Recently, I migrating a standalone database 'rnwphoto' from file system to ASM. I decided to go with the BACKUP AS COPY strategy, to save on downtime. But I was stuck for a long time trying to make the copy, but was being haunted by its failure.

Let's get to the background information. 

Database Standalone Home: /u01/app/oracle/product/11.2.0/dbhome_1 --> This is the Oracle Home used by rnwphoto database.

To convert the database to ASM based RAC, we installed GI in the GRID_HOME (/u01/app/11.2.0/grid) and RAC DB Home (/u01/app/oracle/product/11.2.0/dbhome_2)

Issue:

RMAN> BACKUP AS COPY DATABASE FORMAT '+DATA_DG'; 

Starting backup at 09-SEP-15 
allocated channel: ORA_DISK_1 
channel ORA_DISK_1: SID=8 device type=DISK 
allocated channel: ORA_DISK_2 
channel ORA_DISK_2: SID=69 device type=DISK 
allocated channel: ORA_DISK_3 
channel ORA_DISK_3: SID=132 device type=DISK 
allocated channel: ORA_DISK_4 
channel ORA_DISK_4: SID=72 device type=DISK 
channel ORA_DISK_1: starting datafile copy 
input datafile file number=00001 name=/u01/app/oracle/rnwphoto/system01.dbf 
channel ORA_DISK_2: starting datafile copy 
input datafile file number=00002 name=/u01/app/oracle/rnwphoto/sysaux01.dbf 
channel ORA_DISK_3: starting datafile copy 
input datafile file number=00005 name=/u01/app/oracle/rnwphoto/example01.dbf 
channel ORA_DISK_4: starting datafile copy 
input datafile file number=00003 name=/u01/app/oracle/rnwphoto/undotbs01.dbf 
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_1 terminated unexpectedly 
channel ORA_DISK_1 disabled, job failed on it will be run on another channel 
RMAN-03009: failure of backup command on ORA_DISK_2 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_2 terminated unexpectedly 
channel ORA_DISK_2 disabled, job failed on it will be run on another channel 
RMAN-03009: failure of backup command on ORA_DISK_3 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_3 terminated unexpectedly 
channel ORA_DISK_3 disabled, job failed on it will be run on another channel 
RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
RMAN-00571: =========================================================== 
RMAN-03009: failure of backup command on ORA_DISK_4 channel at 09/09/2015 11:12:22 
RMAN-10038: database session for channel ORA_DISK_4 terminated unexpectedly 

ASM alertlog didnt show any errors or warnings.
In the database alertlog you will see that each time the RMAN command fails with  --> ORA-00600 [kfioTranslateIO03] [17090] 

A similar issue and it's resolution is shown in the Doc ID 1336846.1 
As per this document, this issue occurs due to multiple reasons and one of them is a permission issue... 

1. Check the group owner required on 'oracle' binary file to access ASM successfully:

[grid@node1-riz lib]$ cat $ORACLE_HOME/lib/config.c | grep ASM 
#define SS_ASM_GRP "asmadmin"     >>>> 
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP}; 

2. Let's check the group owner of all ORACLE_HOME/bin/oracle binary:

Grid Home:
[grid@node1-riz ~]$ ls -latr $GRID_HOME/bin/oracle 
-rwsr-s--x 1 grid oinstall 169802036 Sep 3 12:22 /u01/app/11.2.0/grid/bin/oracle 

RAC Database Home:
[oracle@node1-riz ~]$ ls -lart /u01/app/oracle/product/11.2.0/dbhome_2/bin/oracle -rwsr-s--x 1 oracle asmadmin 192296439 Sep 3 13:30 /u01/app/oracle/product/11.2.0/dbhome_2/bin/oracle

rnwphoto Standalone Database Home: 
[oracle@node1-riz ~]$ ls -lart $ORACLE_HOME/bin/oracle 
-rwsr-s--x 1 oracle oinstall 192296337 Sep 2 19:41 /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle 
>>>>> *****************************************************  <<<<<

Do you see it? If not, read ahead...

Point #1 states that 'asmadmin' should be the group owner of the $ORACLE_HOME/bin/oracle

Let's ignore the Grid Home findings - as that's not a part of the problem. It's just for your information.

RAC Database Home works fine with the ASM -- as the group owner of the 'oracle' binary is 'asmadmin'

Standalone Database Home was created much before there was a Grid Home, so it still has 'oinstall' as the group owner of the 'oracle' binary file. 

Solution:
In the Standalone Oracle Home, change the ownership of the 'oracle' binary from oracle:oinstall to oracle:asmadmin --- and WOOOLA !!! 

WARNING: You need a downtime to make this change. If you change the ownership without shutting the database(s), then expect all the databases running on that ORACLE_HOME to CRASH!!!

My Photography Slideshow

Many of you may or may not know, that I am not only passionate about Oracle and new technologies, but also passionate about Photography. 

I am working on creating a small slideshow to showcase some of my special work - just to keep you even more relaxed. 

If you wish to check it out, you can visit my:

Facebook Page: https://www.facebook.com/rizwanwangdephotography
500px: https://500px.com/rizwanwangde

I'm back...

Hi Folks,

I am back ! This blog has been dormant for way too long now. There are so many things I could have shared in the past year but lost on all those opportunities. I promise to make it up, and post as regularly as possible. 

Other than the daily stuff, my short term major goals are as below:

1. EM12cR3 Setup on HP-UX 

2. DataGuard 12c Setup - ASM <--> Filesystem

Regards,

Rizwan Wangde