BRCONNECT nightmares with RAC/ASM

[russell_day2]

Objective:

I am trying to get brconnect to run a check on a RAC system.  I am logged in on the RAC as <sid>arm

Problem:

1. "brconnect -u / -c -f check" fails with a confusing miasma of errors, but basically "connect to instance PRD1 failed"
2. "brconnect -u /@PRD -c -f check" fails with "CONNECT /@PRD IN SYSOPER MODE"  login denied.
3. "brconnect - u system/password@PRD -c -f check" runs successfully.
4. "brconnect - u system/password@PRD -c -f check" fails like case 1 fails

Details:

-rwsrwsr--. 1 oracle oinstall 10045572 Sep  5 03:44 brarchive

-rwsrwsr--. 1 oracle oinstall 10130301 Sep  5 03:44 brbackup

-rwsrwsr--. 1 oracle oinstall 12150398 Sep  5 03:44 brconnect

-rwsrwsr--. 1 oracle oinstall 10600820 Sep  5 03:44 brrecover

-rwsrwsr--. 1 oracle oinstall  6230300 Sep  5 03:38 brrestore

-rwsrwsr--. 1 oracle oinstall 12624124 Sep  5 03:44 brspace

-rwxr-xr-x. 1 oracle oinstall  6841351 Sep  5 03:38 brtools

My analysis:

I see two problems:

• It works as "system/password@SID" but not as "-u /@SID" so there is a problem with user <sid>arm or ops$<sid>adm.
• It works as "system/password@SID" but not as "system/password" so there is a problem with sqlnet.ora/tnsnames.ora.

This may or may not be correct - I am just trying to prove that I am making an effort here.

I have monkeyed around with sqlnet.ora and tnsnames.ora.

Attached files:

• tnsnames_world.txt contains tnsnames.world and sqlnet.world as the world-view versions,
• tnsnames_noworld.txt contains tnsnames.noworld and sqlnet.noworld as the "unworlded" versions.

I am clearly doing something totally bozo here but I cannot work out what it is.  If you figure it out, you may start your post with "You idiot!"  Otherwise please be nice...

Thanks for your help,

Russ

tnsnames_world.txt.zip

tnsnames_noworld.txt.zip

[russell_day2]

And another thing:

uid=1027(prdadm) gid=1004(sapsys) groups=1004(sapsys),1005(oinstall),1006(oradba),1107(dba),1008(oper),1009(sapinst),1010(asmoper),1012(asmdba)

So <sid>adm belongs to dba, oper, asmoper, asmdba.

The system in question is an OEL Linux system.  <sid>adm is managed by a directory.  I think AD.  User Oracle is not.

I have been told that AD only manages the primary group - other group assignments are totally under the control of the /etc/groups file.  That's what I've been told.

R

[russell_day2]

I did not mention that both tnsnames/sqlnet versions work exactly the same way:

• brconnect -u system/password@PRD works
• brconnect -u /@PRD cannot log on
• brconnect -u system/password cannot connect
• brconnect -u / cannot connect.

[russell_day2]

I also accidentally discovered this:

• If brconnect is owned by <sid>adm:sapsys then
  • "brconnect -u / -c -f check" connects and runs
  • but it cannot access the ASM disks and fails early on.