From: Laurenz Albe on 27 Dec 2006 04:29 DA Morgan <damorgan(a)psoug.org> wrote: >>> Two other suggestions if what has been recommended, so far, doesn't work. >>> >>> 1a. ps -ef | grep libora >>> 1b. kill -9 >>> >>> 2. reboot >> >> Reboot on a unix ( aix ) system? Why in the heck would you recommend >> something like that for a problem based on oracle software >> installations? > > Because sometimes, with AIX, it works. Sure, just like buying a new lamp will fix a broken lightbulb :^) If it is a shared library that is still loaded in memory, all you have to do on AIX is to say 'slibclean' as user root. Yours, Laurenz Albe
From: hpuxrac on 27 Dec 2006 08:43 DA Morgan wrote: > hpuxrac wrote: > > DA Morgan wrote: > > >> Two other suggestions if what has been recommended, so far, doesn't work. > >> > >> 1a. ps -ef | grep libora > >> 1b. kill -9 > >> > >> 2. reboot > > > > Reboot on a unix ( aix ) system? Why in the heck would you recommend > > something like that for a problem based on oracle software > > installations? > > Because sometimes, with AIX, it works. Bad advice is just bad advice. If you want to describe a specific situation on an aix box where re-booting was the only solution and give the details then let's hear it. Otherwise it's probably better to give advice to find and talk to a knowledgeable aix system administrator rather than throw in the "reboot" recommendation. It shows someone without ( apparently ) a lot of unix experience trying to cause other oracle professionals to pick up bad habits.
From: EdStevens on 27 Dec 2006 08:55 DA Morgan wrote: > EdStevens wrote: > > DA Morgan wrote: > >> EdStevens wrote: > >>> Platform: AIX Version 5.3 patch/maintenance level 05 > >>> > >>> Installed Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - > >>> 64bit. Runing fine. > >>> > >>> Installed agent in it's own oracle home: > >>> Oracle Enterprise Manager 10g Release 10.2.0.1.0. > >>> Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved. > >>> --------------------------------------------------------------- > >>> Agent Version : 10.2.0.1.0 > >>> OMS Version : 10.2.0.2.0 > >>> Protocol Version : 10.2.0.0.0 > >>> > >>> > >>> Trying to apply patchset 3731593 to bring agent up to 10.2.0.2.0. > >>> Logon as 'oracle', set ORACLE_HOME to the agent's home, manually > >>> stopped the agent, navigated to <patchset>/Disk1 and fired up > >>> runInstaller. OUI came up, ran some checks and asked some questions, > >>> all as expected, confirmed the components to install, but then > >>> reported: > >>> > >>> Error writing to file > >>> '/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so' > >>> [/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so > >>> (Cannot open or remove a file containing a running program.)] > >>> > >>> Ideas? > >> What did you do that you think stopped the agent? > >> > >> My guess is you stopped some other agent in some other directory based > >> on your path. > >> > >> cd $OMA_HOME/bin -- go to the home directory > >> pwd -- verify you are really there > >> ./emctl stop agent > >> ./emctl status agent > >> > >> On my list of egregious Oracle design errors has been that they put > >> emctl into every home directory they could spell. ;-) > >> -- > >> Daniel A. Morgan > >> University of Washington > >> damorgan(a)x.washington.edu > >> (replace x with u to respond) > >> Puget Sound Oracle Users Group > >> www.psoug.org > > > > Good point about the 'extra' emctl files laying around. But even when > > insureing against that problem as you detailed, the results were the > > same. > > What's the same? 1) Just set ORACLE_HOME and issue 'emctl stop agent' results in "Error writing to file '/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so ..." 2) set home, cd to home, issue "./emctl stop agent" results in "Error writing to file '/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so ..." > > Two other suggestions if what has been recommended, so far, doesn't work. > > 1a. ps -ef | grep libora > 1b. kill -9 > "ps -ef | grep libora" returns nothing but the grep process itself. Tried this both before firing up runInstaller and in a separate session while the OUI was waiting on me to respond to the error message. While driving to the office this morning I had a "DOH!" moment when I realized that I could very well have been picking up a previously installed version. So after setting ORACLE_HOME appropriately and navigating to the Disk1 directory of the patchset, I issued 'which runInstaller'. It reported the one in the current directory. Just for grins, I tried specifying it explicitly anyway, with '$> ../runInstaller'. Same result as all previous efforts. I'll try to get the SA to issue an 'slibclean'. Also, will add 'set -x' to the runInstaller script and examine exactly what's getting set in the environment and what decisions are being made. > 2. reboot > -- > Daniel A. Morgan > University of Washington > damorgan(a)x.washington.edu > (replace x with u to respond) > Puget Sound Oracle Users Group > www.psoug.org
From: DA Morgan on 27 Dec 2006 11:45
EdStevens wrote: >> What's the same? > > 1) Just set ORACLE_HOME and issue 'emctl stop agent' results in "Error > writing to file > '/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so ..." That may well be part of the problem. The emctl in ORACLE_HOME is not the correct emctl to stop the EM agent. It is the emctl that stops the dbconsole agent. As I stated earlier ... Oracle has put the emctl executable in every home they can find. It is often the problem not the solution. HTH -- Daniel A. Morgan University of Washington damorgan(a)x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org |