Skip to Content
avatar image
Former Member

BRCONNECT nightmares with RAC/ASM

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

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Oct 31, 2015 at 07:16 AM

    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.
    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      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.
  • avatar image
    Former Member
    Oct 31, 2015 at 08:14 AM

    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

    Add comment
    10|10000 characters needed characters exceeded