8.0.6 client and 9.0.2 database

[sem]

I can not connect from my Forms 6i, patch 17 on XP SP1 to Oracle EE 9.2.0.5 on Solaris. I can connect from that Forms to 9.2.0.5 on HP. The same with other products from that 8.0.6 home.

All settings seem to be correct, but I get coredump.

I found a strange entry in sqlnet.trc file:
nnfun2a: address for name "arsenal" not found

The issue is that arsenal is the name of another (8.1.7) database on that box. For my experiment I removed it from listener.ora, tnsnames.ora, restarted listener, but it still occurs in sqlnet.trc file.

Does anybody have any ideas?

Regards, Dima

http://seminihin.narod.ru

 

[SantaMufasa]

Sem,

Can you please post these items:

1) contents of your listener.ora file
2) results of a "uname -a"
3) contents of your /var/opt/oracle/oratab

Mufasa
(aka Dave of Sandy, Utah, USA)
[

http://www.dasages.com:

Providing low-cost remote Database Admin services]
Click here to join Utah Oracle Users Group on Tek-Tips if you use Oracle in Utah USA.

 

[sem]

$ uname -a
SunOS barselona 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-60

$ cat $TNS_ADMIN/listener.ora
# LISTENER.ORA Network Configuration File: /app/oracle/product/920/network/admin/listener.ora

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = barselona)(PORT = 1521))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
      )
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /app/oracle/product/920)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = dwh)
      (ORACLE_HOME = /app/oracle/product/920)
      (SID_NAME = dwh)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = arsenal)
      (ORACLE_HOME = /app/oracle/product/817)
      (SID_NAME = arsenal)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = barsa)
      (ORACLE_HOME = /app/oracle/product/920)
      (SID_NAME = barsa)
    )
  )


$ cat /var/opt/oracle/oratab
#

# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by the Database Configuration Assistant when creating
# a database.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third filed indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
#*:/app/oracle/product/817:N
arsenal:/app/oracle/product/817:Y
# *:/app/oracle/product/920:N
# *:/app/oracle/product/920:N
barsa:/app/oracle/product/920:Y
#*:/app/oracle/product/920:N
dwh:/app/oracle/product/920:N

Regards, Dima

http://seminihin.narod.ru

 

[SantaMufasa]

For my experiment I removed it ("arsenal") from listener.ora, tnsnames.ora, restarted listener, but it still occurs in sqlnet.trc file.

When you removed references to "arsenal" from listener.ora and tnsnames.ora, do you also have a set of listener.ora and tnsnames.ora files in both "/app/oracle/product/817/network/admin" and "/app/oracle/product/920/network/admin"? Since "arsenal" is your default instance on the server "barselona", you will be defaulting to the listener.ora and tnsnames.ora that reside in the "/app/oracle/product/817/network/admin" path. If you didn't remove references to "arsenal" from both paths (especially in "/app/oracle/product/817/network/admin") Oracle will still attempt to establish TNS connectivity to "arsenal" by virtue of the references that still exist in "/app/oracle/product/817/network/admin".

Is this scenario the case?

Mufasa
(aka Dave of Sandy, Utah, USA)
[

http://www.dasages.com:

Providing low-cost remote Database Admin services]
Click here to join Utah Oracle Users Group on Tek-Tips if you use Oracle in Utah USA.

 

[sem]

Yes, I:
1. Removed entry from listener.ora
2. Redefined ORACLE_HOME, ORACLE_SID and TNS_ADMIN to point to barselona instance and database
3. export PATH=$ORACLE_HOME/bin:$PATH
4. Launched lsnrctl from $ORACLE_HOME/bin (paranoid)

I also verified that correct lsnrctl has started and correct listener.ora was used from the utility itself. From trace file I new that the name was resolved correctly:

nnfotrv1: translated "barsa" to (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.10.37) (PORT = 1521))) (CONNECT_DATA = (sid = barsa)))
----
Ok, no more mysteries with arsenal, it was specified as my local variable on client . When I removed it the word has disappeared from the trace file. So long so good, now I have a trace file without suspicious entries


Regards, Dima

http://seminihin.narod.ru

 

[SantaMufasa]

Sem,

I found 74 entries when I Googled for "nnfun2a: address for name". Since I don't know which of the 74 apply to your case, I'll point you to that resource and hope that at least one of those 74 references will provide you with an answer. If that is true, please post the resolution here.

Good luck.

Mufasa
(aka Dave of Sandy, Utah, USA)
[

http://www.dasages.com:

Providing low-cost remote Database Admin services]
Click here to join Utah Oracle Users Group on Tek-Tips if you use Oracle in Utah USA.

 

[sem]

Dave, do you think that I'm so lazy to post my question here before googling? I've also metalinked it, but without success. I can not open an iTAR because Forms 6i is dissuported and the whole process is quite slow even with silver support :-(

This question was asked in hope that somebody knew an answer and not to utilize somebodys search capabilities, so I'd ask you to not waste your time as most probably you're moving the same way as I did.


Regards, Dima

http://seminihin.narod.ru

 

[SantaMufasa]

Actually, Sem, I've never considered you to be lazy . I just didn't know if you had looked there yet and did not want to leave a stone unturned. Frankly, my overwhelming impression of your post was, "If Dima doesn't know the answer, then no one knows the answer."

Sorry for not helping in your quest. I just didn't want you to think that no one was interested in your problem by no one responding.

Mufasa
(aka Dave of Sandy, Utah, USA)
[

http://www.dasages.com:

Providing low-cost remote Database Admin services]
Click here to join Utah Oracle Users Group on Tek-Tips if you use Oracle in Utah USA.

 

[sem]

Thank you, Dave, I appreciate your help, but I also appreciate your time
And I can't stand people asking their questions before any attempt to solve a problem on their own.

Regards, Dima

http://seminihin.narod.ru