RE: Somewhat Perplexed - Very Sheepish - Totally Ignorant:SQPLUS after Upgrade

From: Bobak, Mark <>
Date: Tue, 4 Nov 2008 12:20:36 -0500
Message-ID: <>


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 J. Bobak
Senior Database Administrator, System & Product Technologies
789 E. Eisenhower, Parkway, P.O. Box 1346
Ann Arbor MI 48106-1346
+1.734.997.4059  or +1.800.521.0600 x 4059<><><>

ProQuest...Start here.

From: [] On Behalf Of David Barbour
Sent: Tuesday, November 04, 2008 12:09 PM
Subject: Re: Somewhat Perplexed - Very Sheepish - Totally Ignorant:SQPLUS after Upgrade

orapr1_at_r3prdci1>which sqlplus

orapr1_at_r3prdci1>whence sqlplus
orapr1_at_r3prdci1>sqlplus SQL*Plus: Release - 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 - 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 - 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 <<>> wrote: Bingo. orapr1_at_r3prdci1>which 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
On Tue, Nov 4, 2008 at 3:41 AM, Nigel Thomas <<>> 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 --
Received on Tue Nov 04 2008 - 11:20:36 CST

Original text of this message