Browsed by
Month: July 2016

Database psu patch july 2016: cannot find -lodbcinst

Database psu patch july 2016: cannot find -lodbcinst

It’s patching time again. So on one of our test systems we gave the july 2016 bundle a go. It’s a simple system, just a plain database with the april bundle applied. No grid infrastructure, no asm, just a plain simple database system.

The sequence is the same as always. Unzipping, conflict check, nothing new. In our case, no conflicts were found so the next step is opatch apply.

All went good until a certain point the make command failed on:

Make failed to invoke "/usr/bin/make -f isqora 
   ORACLE_HOME=/u01/app/oracle/product/"....'/usr/bin/ld: cannot find -lodbcinst
collect2: error: ld returned 1 exit status
make: *** [/u01/app/oracle/product/] Error 1
The following make actions have failed :
Re-link fails on target "isqora".

This doesn’t look good.
The good thing is that opatch creates a backup and it’s pretty easy to restore it. It just tells you how to do it.

In the meanwhile there is already a mos-note: New DocumentMake Failed To Invoke “/usr/bin/make -f isqora” ‘/usr/bin/ld: cannot find -lodbcinst for While Applying Patch 23054246 (Doc ID 2163593.1)

To save you some time from reading it, the summary is simple. This error comes from the unixODBC package which is not installed on the system.
after installing the x86_64 and i686 version, opatch succeeded successfully.

What’s odd is that if we check the prerequisite packages for eg RHEL in following mos-note: Requirements for Installing Oracle Database 12.1 on RHEL6 or OL6 64-bit (x86-64) (Doc ID 1529864.1) it does not show any indication that this package is mandatory.

For general information about the install notes, this mos-note is useful as well: Master Note of Linux OS Requirements for Database Server (Doc ID 851598.1)

I checked some linux versions for 12c database prerequisite packages, but no luck. No reference found to unixODBC being mandatory now.

I decided to install a clean OEL version (an older image of OEL67 which was the first available I had) and then I used the preinstall rpm coming from the public-yum from oracle.
It’s stunning that in the official rpm does not include the new mandatory rpm’s.

[root@oel67 ~]# rpm -aq |grep -i rdbms
[root@oel67 ~]# rpm -qa |grep -i unixodbc
[root@oel67 ~]#

So conclusion, if you are about to install a new system, don’t forget to install the unixodbc binaries as well.

As always, questions, remarks? find me on twitter @vanpupi

Acfs: it’s all about permissions

Acfs: it’s all about permissions

It all starts with creation of a database on a Database appliance which failed with the error

Validation of server pool succeeded.
Registering database with Oracle Restart
PRCR-1006 : Failed to add resource ora.demodb.db for demodb
PRCR-1071 : Failed to register or update resource ora.demodb.db
CRS-2566: User 'oracle' does not have sufficient permissions to operate on resource 'ora.redo.datastore.acfs', which is part of the dependency specification.
DBCA_PROGRESS : DBCA Operation failed.


One of the things … is it due to running on the ODA or is it a general cluster issue?
It was easy to verify as this customer had another ODA on which everything just works smoothly. So we started to compare the environments. One tiny little thing appeared to be different: the ACL.

On a working ODA:

[grid@ODA_A-1 ~]$ crsctl status resource ora.redo.datastore.acfs -p |grep ACL
[grid@ODA_A-1 ~]$ 


On this one:

[grid@ODA_B-1 ~]$ crsctl status resource ora.redo.datastore.acfs -p|grep ACL
[grid@ODA_B-1 ~]$ 

Sooo there we have it.
The first intention to do is to do a crsctl modify or a crsctl setperm.
Let’s switch to a demo system as this is acfs and not oda related.

So it’s playtime!
On the demo environment we have an acfs volume:

[root@demo-rac12-01 ~]# crsctl status resource ora.dg_advm.advmvol01.acfs
STATE=ONLINE on demo-rac12-01, ONLINE on demo-rac12-02, ONLINE on demo-rac12-03

[root@demo-rac12-01 ~]#

If we verify the ACL we see the same configuration as on the ODA:

[root@demo-rac12-01 ~]# crsctl status resource ora.dg_advm.advmvol01.acfs -p |grep ACL
[root@demo-rac12-01 ~]#

Yes I know, I did this as root and you could get this information as grid as well.
So let’s do the instinctive thing and try to modify the resource:

[root@demo-rac12-01 ~]# crsctl modify resource ora.dg_advm.advmvol01.acfs -attr "ACL='owner:root:rwx,pgrp:root:r-x,other::r--,user:oracle:r-x'"
CRS-4995:  The command 'Modify  resource' is invalid in crsctl. Use srvctl for this command.
[root@demo-rac12-01 ~]#

And now we have to be careful with googling things. If you start googling this error, you will find several pages suggesting to use the -unsupported flag. But there is no reason to do so 🙂
By the way, this same errors is thrown to you if you try to crsctl setperm.

Let’s assume the cluster is right (he mostly is), then a srvctl modify must exist and indeed there is!

[root@demo-rac12-01 ~]# srvctl modify filesystem -h

Modifies the configuration for the file system.

Usage: srvctl modify filesystem -device <volume_device> [-user {[/+ | /-]<user> | <user_list>}] [-path <mountpoint_path>] [-node <node_list> | -serverpool <serverpool_list>] [-fsoptions <options>] [-description <description>] [-autostart {ALWAYS|NEVER|RESTORE}] [-force]
-device <volume_device> Volume device path
-user <user>|<user_list> Add (/+) or remove (/-) a single user, or replace the entire set of users (with a comma-separated list) authorized to mount and unmount the file system
-path <mountpoint_path> Mountpoint path
-node <node_list> Comma separated node names
-serverpool <serverpool_list> Comma separated list of server pool names
-fsoptions <fs_options> Comma separated list of file system mount options
-description <description> File system description
-autostart {ALWAYS|NEVER|RESTORE} File system autostart policy
-force Force modification (ignore dependencies)
-help Print usage
[root@demo-rac12-01 ~]#

So it seems we need to find out which device we’re using. This is simple:

[root@demo-rac12-01 ~]# crsctl status resource ora.dg_advm.advmvol01.acfs -p |grep VOLUME_DEVICE
[root@demo-rac12-01 ~]#

There we have it. So now it ‘s just syntax. Remember the difference in ACL, so we need to add user:oracle:r-x and sometimes we’re lucky, it’s not too hard.

[root@demo-rac12-01 ~]# /u01/app/ status resource ora.dg_advm.advmvol01.acfs -p |grep -i acl
[root@demo-rac12-01 ~]# /u01/app/ modify filesystem -device /dev/asm/advmvol01-438 -user /+oracle
[root@demo-rac12-01 ~]# /u01/app/ status resource ora.dg_advm.advmvol01.acfs -p |grep -i acl
[root@demo-rac12-01 ~]# 

Removing it, isn’t too hard either:

[root@demo-rac12-01 ~]# /u01/app/ modify filesystem -device /dev/asm/advmvol01-438 -user /-oracle
[root@demo-rac12-01 ~]# /u01/app/ status resource ora.dg_advm.advmvol01.acfs -p |grep -i acl
[root@demo-rac12-01 ~]#


As always, questions, remarks? find me on twitter @vanpupi