post-Oracle 9.2 upgrade issue

[Cara Tock]

Background:

We recently upgraded from Oracle 8.1.6 to Oracle 9.2 on HPUX 11.00. A new listener was configured and is running for Oracle 9.2

After the upgrade, I noticed that the sqlnet.log was becoming very large and was aiding in filling up the file system quickly.

Troubleshooting:

Using the find command, I located a residual link from 8.1.6.
/orasrv/8.1.6 -->/u01/oracle/product/8.1.6/bin/oracle/

I removed this link as it is no longer needed and hoped that this would resolve the issue.

sqlnet.log entry that is being logged repeatedly:

Fatal OSN connect error 12545, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=beq)(PROGRAM=/u01/oracle/product/8.1.6/bin/oracle)(ARGV0=oracleplab)(ARGS='(DESCRIPTION=(LOC
AL=YES)(ADDRESS=(PROTOCOL=beq)))')(DETACH=NO))(CONNECT_DATA=(CID=(PROGRAM=)(HOST=hp9000n)(USER=root))))

VERSION INFORMATION:
TNS for HPUX: Version 2.3.4.0.0 - Production
Oracle Bequeath NT Protocol Adapter for HPUX: Version 2.3.4.0.0 - Production
Time: 25-OCT-05 16:30:02
Tracing not turned on.
Tns error struct:
nr err code: 12206
TNS-12206: Message 12206 not found; No message file for product=NETWORK, facility=TNS
ns main err code: 12545
TNS-12545: Message 12545 not found; No message file for product=NETWORK, facility=TNS
ns secondary err code: 12560
nt main err code: 515
TNS-00515: Message 515 not found; No message file for product=NETWORK, facility=TNS
ns main err code: 12545
TNS-12545: Message 12545 not found; No message file for product=NETWORK, facility=TNS
ns secondary err code: 12560
nt main err code: 515
TNS-00515: Message 515 not found; No message file for product=NETWORK, facility=TNS
nt secondary err code: 2
nt OS err code: 0


Please advise additional troubleshooting for this issue. I am out of ideas currently.

Please note: I am also checking the Oracle FAQ & support web sites for an answer. Have not found one yet. If/when I do, I will update this entry.

Thank you in advance for your help.

[B. Hulst]

Hi,

You could switch off the logging in listener.ora...

Regards,
Bob

[Steven E. Protter · Accepted solution]

Go through tnsnames.ora and listener.ora

Make sure everything referred to in there can be accesses with the tnsping utility.

Your configuration appears to have problems, but her error codes are unfamiliar to me.

SEP

[Cara Tock]

Thank you for your responses. I will review the Oracle files suggested & respond back.

[Cara Tock]

I am able to do a tnsping of the prior listener instance name. The new listener instances name is mlab.

$tnsping plab

USER=oracle /home/oracle $ tnsping plab

TNS Ping Utility for HPUX: Version 9.2.0.6.0 - Production on 26-OCT-2005 15:58:58

Copyright (c) 1997 Oracle Corporation. All rights reserved.

Used parameter files:
/u01/oracle/product/9.2/network/admin/sqlnet.ora

Used HOSTNAME adapter to resolve the alias
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SID=*)(SERVICE_NAME=plab.))(ADDRESS=(PROTOCOL=TCP)(HOST=plab)(PORT=1521)))
OK (10 msec)
USER=oracle /home/oracle$

Please note: the sqlnet

The DBA & I have been reviewing many files and are not finding where there is a reference to the old listener instance, plab.

Any additional suggestions would be appreciated.

Thank you.

[TwoProc]

If I had to guess (from looking at the error), you've got a cronjob running periodically as root that is somehow still trying to connect to the old database in the old ORACLE_HOME (which I'm guessing still exists) in bequeath mode.

But, that's just me guessing as to what I'd start looking for. This could be possible if the database kept the same name, but the ORACLE_HOME changed (from xxx/xxx/xxxx/8.1.6 to xxx/xxx/xxxx/9.2.0), and you're still getting some part of a resolution b/c even though the ORACLE_HOME location changed the ORACLE_SID didn't, and you're getting somewhat partial resolution b/c the ORACLE_SID is valid in /etc/oratab file.

So, you're possibly getting a "mixed" solution for some program which was hard-coding the environment variables for ORACLE_HOME, etc and also possibly using some scripts which are dynamically setting the environment.

An example would be that your TNS_ADMIN variable points to the new ORACLE_HOME/network/admin directory, and your ORACLE_HOME directory (and possibly path) may include the old ORACLE_HOME directory.

... Just a guess that might be it.

[Patti Johnson]

Also look for extra copies of your tnsnames.ora file. Oracle will use a tnsnames.ora file in your $HOME directory if it exists, before looking to $TNS_ADMIN or $ORACLE_HOME/network/admin.

The host name in the error is hp9000n - what is running on that server? The root account on that server is trying to access your 8i db. Could this be some sort of monitoring job as John suggests? Does the frequency of the errors indicate a pattern?

Patti

[Cara Tock]

Thank you all for your assistance.

I checked the crontabs. No Oracle monitoring jobs there. Was a good idea to recheck these.

I am suspecting Openview monitoring at this point because the date/time stamp on the sqlnet.log file in /homeroot is the same as
/var/opt/OV/dbspi/dsi/oracle/osm/plab.dat (the old Oracle listener/ instance name). I am newer to HP Openview, however, I have a colleague that will be getting me up to speed so...I will post a reply whether or not Openview config/monitoring needs to be changed.

[Cara Tock]

All - This issue was tracked down to be Openview-related. While dbspi was not running, the dbspi logging was still logging errors related to the previous Oracle version 8.1.6.

Thank you to all who posted suggestions.

[Cara Tock]

Was Openview-related issue. dbspi, while not running (strange) was logging line entries related to Oracle 8.1.6. I talked with my colleague, we stopped the Openview agent and will be changing the config.

Thanks again for the assistance.