| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Problem upgrading to Oracle 7.2.3 on HP
In article <884028839.1881407490_at_dejanews.com>,
UMESH.X.TIWARI_at_x400gw.ameritech.com says...
> Did you try 'lsnrctl' command?
>
> In article <01bd1959$c375c160$54699ecf_at_windows-pc>,
> "Mark A. Bryan" <mabryan_at_cyberramp.net> wrote:
> >
> > If anyone can give me a solution for this problem, I would greatly
> > appreciate it!
> >
> > The client I work for has a working database running under version 7.2.2 on
> > HP-UX 9.0. They want to go to HP-UX 10.20, but cannot until Oracle is
> > upgraded to 7.2.3. I have installed version 7.2.3 (successfully, I think).
> > I am able to use SQL*Plus and SQL*DBA to connect to the database using
> > either version 7.2.2 or 7.2.3. However, at 7.2.3, none of my PC clients
> > can connect to the database via SQL*Net. I noticed there was no
> > "tnsnames.ora" file in $ORACLE_HOME/network/admin, so I copied the one from
> > 7.2.2 and restarted "tnslsnr". Nothing. Next, I saw that "tcpctl" and
> > "tcputl" were also missing from $ORACLE_HOME/network/admin, so I tried to
> > reinstall TCP. They still didn't show up, so I copied them from 7.2.2,
> > also. When I ran "tcpctl start", it said it could not find "orasrv". So,
> > as "root", I copied "orasrv" from 7.2.2's "bin" directory. Now "tcpctl
> > start" started up just fine. Still, no PC clients can connect to the
> > database.
> >
> > First, I am concerned that I had to copy so many files from a previous
> > version of Oracle, and that they did not get created by the install. Is it
> > possible that I missed something in the install?
> >
> > Second, why can't my PC clients connect to the 7.2.3 database? I can
> > "tnsping" the 7.2.3 instance from other HP machines, but DB Links don't
> > work from databases on those machines. (Actually, "tnsping" was acting
> > kind of flaky; first it found the 7.2.3 instance, then it didn't).
> >
> > Again, any help would be appreciated. I can make a few more educated
> > guesses, but nothing that feels like it will work.
> >
> > Thanx,
> >
> > Mark A. Bryan
> > DBA Master
> > (but not Installation Master)
>
> -------------------==== Posted via Deja News ====-----------------------
> http://www.dejanews.com/ Search, Read, Post to Usenet
>
Hi Mark,
This is just a series of thoughts of anything at all that might be worth exploring, not what I think has gone wrong. Hopefully something might spark an idea.
Did you pick all the SQL*Net V1 and V2 and the TCP protocol products from the orainst menu? Sounds like the V2 stuff loaded, but if you had to copy missing tcpctl/tcputl scripts from 7.2.2, you may need to retry installing SQL*Net V1. Possibly an error occurred during linking of the orasrv binary?
The tnsnames.ora file is a lookup file for known services on the network, rather like /etc/hosts in function. However, the listener.ora file is the one which configures the tnslsnr process and the ports, protocols and db names on which it accepts connections. You will need to copy that too, either into $ORACLE_HOME/network/admin or into /etc. From memory, that is normal -- you have to set up the SQL*Net V2 files again after install.
Also check that the new listener is configured to listen on the same socket as it did under 7.2.2. I believe the IUG says to configure the listener on TCP/1521, but Oracle Corp actually shipped install files configured to port 1525!. As a result, I have seen a confusing mash of numbers being used on various systems. My books aren't handy (I'm at home) so check the numbers first.
What actually happens when you start the listener with "lsnrctl start"? An error? Does tnslsnr remain running? Does "lsnrctl stat" report anything? The works/doesn't-work situation for tnsping is a mystery to me.
Have you any other databases on that host? I once had a 7.1.6 and a 7.2.3 database co-resident on one host. I had a surprising problem in which the
7.2.3 version of the listener could not make SQL*Net connections to the 7.1.6 database although it was configured to service both. However the 7.1.6 version of the listener worked with both 7.1.6 and 7.2.3 databasesusing the same listener.ora file! So I stuck with the 7.1.6 listener on that system. Go figure.
Another possibility could be that if a mistake has inadvertently happened during the upgrade such that the alphabetic case of ORACLE_SID no longer matches the case of the "db_name =" line in the init.ora file, it may cause the listener to fail to connect SQL*Net and DB links.
Multi Threaded Server tends to have more than it's share of bugs throughout Oracle7 versions. If you are using it, you could try turning off the MTS_ parameters in the init.ora file to see if that has any effect on the problem. The problem with turning it off is of course more running processes and higher memory usage if your system has a high user concurrency.
Considering the PCs and Database links, what protocol are they using? If they're using the T:<host>:<SID> form of connect string, then they're attempting SQL*Net V1 connections. And that product sounds like it needs a reinstall to unbreak it. Broken networking could present an opportunity to "wean" users and db links off SQL*Net V1 so you can dump the tcpctl, tcputl and orasrv suite once and for all.
One final beard-scratch and I seem to recall that if "global_names = true" is set in the init.ora file, it will break any database links which have any name other than a service defined in tnsnames.ora or Oracle*Names.
Good luck,
Brian.
-- "Strictly UNIX" To dance is to live. belliot_at_gil.com.auReceived on Wed Jan 07 1998 - 00:00:00 CST
 |
 |