Oracle upgraded but still using files from old install

[Jeanine Kone]

I upgraded one of my Oracle instances from 8.0.6 to 8.1.7. Both versions were already installed on the machine. This instance happened to be the last instance still using 8.0.6. Instead of deinstalling the software, I made the oh so wise choice of leaving it out there (just in case I needed to use it later).

I have been running the instance on 8.1.7 for about a month now. I just decided to go ahead and remove the old 8.0.6 software. Only to find out that two of the fles could not be deleted because they were still in use! I verified by using fuser that the files (8.0.6/bin/oracle and 8.0.0/lib64/libdsbtsh8.sl are being used by the Oracle background processes of my upgraded instance. The instance has been started and stopped several time using 8.1.7 since the upgrade.

There is a large job running now - but once it is done, I plan to stop the instance and then try to delete the files. I am hoping that it will start back up without them (praying actually).

Can anyone shed some light for me as to why this might be happening? And if my plan will work?

Thanks, Jeanine

[Christopher McCray_1]

Are your environment variables (ie. LD_LIBRARY_PATH) pointing to 8.1.7?

Hope this helps

Chris

[Jeanine Kone]

All ENV variable check out fine. Of course, that is for my current session (but, it is set each time I log in by my .profile, so I can be fairly certain that they are identical to the last time I restarted the database).

[Sanjay_6]

Hi Jeanine,

Did you run root.sh after installing the new version of oracle. The root.sh file is in $ORACLE_HOME. Also did you modify the listener.ora file in /etc which is sourced at the time of Listener startup. If you have removed an oracle home or an oracle instance, you should remove the corresponding entry from the listener.ora file.

Hope this helps.

Regds

[Jeanine Kone]

Well - 8.1.7 was installed over a year ago (I have several other databases using it). I have to assume I ran the root.sh at the time (who can remember that far back).

Yes, I did modify the listener (in $ORACLE_HOME/network/admin) to reflect the upgraded version, as well as the the /etc/oratab file.

[A. Clay Stephenson]

You may need to relink these Oracle binaries or run chatr to tell the executable to follow SHLIB_PATH or LD_LIBRARY_PATH.

[Sanjay_6]

Hi Jeanine,

The two files mentioned by you are taken from the oracle_home env variable at the time of database startup.

See if you can download lsof from the link below and then use lsof to find the process using these files.

You can download lsof from this link,

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.64/

Once you have downloaded and installed lsof, use lsof using this syntax,

lsof path_to_file/file_name

Hope this helps.

Regds

[Jeanine Kone]

I have already determined which processes are using the file with fuser (all of th ebackground processes associated with the upgraded instance). Will lsof tell me anything different (we are not really allowed to download and use software from the web...)?

[Jeanine Kone]

Thanks everyone for the suggestions. I figured it out. It was pretty stupid really. When I used the fuser to check which process was using the file, it gave me the oracle user and the PID. I did a ps -ef on the specified PIDs and sure enough, they were for the background processes of the "cptest" databases. What I neglected to notice at the time was the date the processes were started. Also, had I done a ps -ef | grep cptest, instad of using the PID, I would have seen there were multiples. Turns out that these processes were for a "dead" instance of the database (the other dba had, a few weeks ago, attempted to start the instance with the wrong oracle_home - we fixed it - but apparently did not notice the leftover processes). The way I noticed really, was when I shut down the database instance, tried to remove the files, could not, and then noticed that the processes were still there.

Thanks again for the suggestions.

[T G Manikandan]

Jeanine,
I have some points.

I am facing lot of problems like the same you have mentioned in the 8.1.5 and 8.1.7 versions with me.

1.SOme of the applications which are running on the system(custom applications) the executables are referring the 8.1.5 libraries.You cannot do anything about that.
If you do a chatr you can find which executable is still referring the old libraries.
The only way then is create a link 8.1.5 to refer to 8.1.7.


2.The Oracle path even after install is not updated in the user profiles.
They are still working with the old one.

3.There are some applications which have executables that can be built by the user.
Whenever you run some commands the executable is created,that time the executable takes the oracle library installed on the system.If this is the case then you can rebuild that executable by giving the new path of oracle.i have some Tuxedo applications like that.

before you look in carefully before going ahead for deletion.

Thanks

[Bill Thorsteinson]

Check the contents of the ortab file likely located
in the /etc directory.

One of the fields indicate the ORACLE_HOME to use for the
database. It is likely set to the old version.

The quick update from 8.0.x is
to shut the database down,
change the ORACLE_HOME entry
in oratab, and restart the
database. There is also an entry in it init parameter
file for compatability with
the prior version. You can
change this when you are comfortable that the new version is working OK.

There are also scripts that can be run as SYS and SYSTEM
to complete the upgrade

[Jeanine Kone]

As I mentioned - the problem has been corrected. All future posts will recieve 0 points.....