Re: Somewhat Perplexed - Very Sheepish - Totally Ignorant:SQPLUS after 10.2.0.4 Upgrade

Thanks folks, i got it. Our Basis folks put the Oracle Instant Client location in the front of my LD_LIBRARY_PATH and LIBPATH. I've modified those paths and now I get the expected results.

Really appreciate the help. Stimulated my brain and got me moving in the right direction.

Sixth Law: A working example is worth a thousand manual pages.

On Tue, Nov 4, 2008 at 12:20 PM, Bobak, Mark <Mark.Bobak_at_proquest.com>wrote:

> David,
>
>
>
> One thing you could try, which may help, if you know how to interpret it,
> is to do a trace on sqlplus.
>
>
>
> <trace_cmd> sqlplus
>
>
>
> Where <trace_cmd> is strace, or truss, or tusc, or something like that….not
> sure what the command is for AIX. It may reveal what's going on, but,
> again, the output may not be very readable, particularly if you've never
> used it before.
>
>
>
> -Mark
>
>
>
> *--
> Mark J. Bobak*
> *Senior Database Administrator, System & Product Technologies*
> ProQuest
> 789 E. Eisenhower, Parkway, P.O. Box 1346
> Ann Arbor MI 48106-1346
> +1.734.997.4059 or +1.800.521.0600 x 4059
> mark.bobak_at_proquest.com <mark.bobak_at_il.proquest.com>
> www.proquest.com
> www.csa.com
>
> *ProQuest...*Start here.
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *David Barbour
> *Sent:* Tuesday, November 04, 2008 12:09 PM
> *To:* nigel.cl.thomas_at_googlemail.com
> *Cc:* ORACLE-L
> *Subject:* Re: Somewhat Perplexed - Very Sheepish - Totally
> Ignorant:SQPLUS after 10.2.0.4 Upgrade
>
>
>
> Rats!
>
> orapr1_at_r3prdci1>which sqlplus
>
> /oracle/PR1/920_64/bin/sqlplus
>
> orapr1_at_r3prdci1>whence sqlplus
>
> /oracle/PR1/102_64/bin/sqlplus
>
> orapr1_at_r3prdci1>sqlplus
>
>
>
> SQL*Plus: Release *10.2.0.4.0* - Production on Tue Nov 4 11:33:50 2008
>
>
>
> And I tried the whole thing on the QA server (which was upgraded at the
> beginning of September and I have the same issue. Ditto with the
> development server that was upgraded in August. Interestingly enough, I do
> not have the issue on our 'new' sandbox.
>
> orasbx_at_sapsand>sqlplus / as sysdba
>
> SQL*Plus: Release 10.2.0.4.0 - Production on Tue Nov 4 12:07:14 2008
>
> Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
>
>
> Connected to:
> Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
> Production
> With the Partitioning, OLAP, Data Mining and Real Application Testing
> options
>
> SQL> !ls
> 102_64 sapbackup
> Mail sapcheck
> SAPupg sapdata1
> brconnect_091708_1458.log sapdata2
> dead.letter sapdata3
> mbox sapdata4
> mirrlogA sapreorg
> mirrlogB saptrace
> oraInventory smit.log
> oraarch smit.script
> origlogA smit.transaction
> origlogB sqlnet.log
> saparch upgrade
>
> SQL>
>
> Now at least I have a known 'good' set of pathing and variables to check
> against.
>
> On Tue, Nov 4, 2008 at 10:21 AM, David Barbour <david.barbour1_at_gmail.com>
> wrote:
>
> Bingo.
>
> orapr1_at_r3prdci1>which sqlplus
> /oracle/PR1/920_64/bin/sqlplus
>
>
> Now the problem is why the heck is that still in the path. I suspect it
> has to do with our AIX Systems Administrators and their invocation of HACMP
> (which was dismantled but all the scripts left in place).
>
> orapr1_at_r3prdci1>echo $PATH
>
> /oracle/PR1/102_64/bin:/usr/sap/PR1/SYS/exe/run:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java14/jre/bin:/usr/java14/bin:/usr/tivoli/tsm/client/ba/bin:/usr/tivoli/tsm/client/oracle/bin64:/usr/local/scripts:/usr/local/scripts/operator:/opt/CA/UnicenterNSM/atech/services/bin
>
>
>
>
> On Tue, Nov 4, 2008 at 3:41 AM, Nigel Thomas <
> nigel.cl.thomas_at_googlemail.com> wrote:
>
> David
>
>
>
> None of your tests so far show you which directory you are actually in. It
> is possible that some kind soul has put a sqlplus shell script earlier in
> the PATH than the Oracle sqlplus executable which does something like:
>
>
>
> cd some-directory
>
> $ORACLE_HOME/rdbms/bin/sqlplus
>
>
>
> So: to check this, you try the following:
>
>
>
> orapr1_at_r3prdci1> *which sqlplus*
>
>
>
> On most unixes *which* should tell you if you have a script in the way
> (and where it is hiding).
>
>
>
> Otherwise, try
>
>
>
> orapr1_at_r3prdci1> *pwd*
>
>
>
> orapr1_at_r3prdci1> *sqlplus user/pass*
>
> SQL>* !pwd*
>
>
>
> Are you in the same directory as before?
>
>
>
> Another way you could end up in a different directory is if your shell (eg
> ksh) runs a login, .profile, or other startup file (like .bashrc) which
> includes a *cd* command. Check *man ksh* for the files that are executed
> when you launch a new shell.
>
>
>
> HTH
>
>
>
> Regards Nigel
>
>
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l