Jesse, Rich wrote: >I had one such occasion on 9.2.0.5.0 under HP/UX 11.11 just last week on >a dev DB that gets rebuilt from scratch weekly. The sniped process >prevented the release of shared memory even after a SHUTDOWN ABORT >(confirmed by ipcs -a), which prevented the new instance from starting >up. I haven't needed to take time to troubleshoot it, since it's just a >dev DB. I've also seen this on 9206 on hp-ux 11.11. Even ipcrm couldn't remove it, I had to bounce the production box to release the shared memory. Rare, but it can happen. If all you (Queen Roo-Roo) are doing is killing off users for a backup (and you should investigate if that is really necessary for the backup, or just a means of preventing undo problems because people don't log off correctly), you can script OS process kills with something like: Echo "Killing list:" ps -ef|grep oracle${ORACLE_SID}|grep -v grep|grep -v <any other things you don't want to kill>|awk '{print "kill -9 "$2}' >> $$kill_oracle_attaches <then the same line again without the redirect to output what is going to be killed> echo "[End of list]" if [ -f $$kill_oracle_attaches ] then chmod +x $$kill_oracle_attaches ./$$kill_oracle_attaches fi rm $$* This is handled in oracle by PMON, while the alter system is handled by SMON, who may never get around to it. Sessions killed with alter system not releasing locks is pretty common. Joel Garry http://www.garry.to -- //www.freelists.org/webpage/oracle-l