Description of problem: In step 2 in rhn-satellite-5-upgrade-scenario-1b.txt there should be suggested logging-in as oracle when using satellite-temp_tbs-estimate.sql script Version-Release number of selected component (if applicable): rhn-upgrade-5.3.0.24-1.el4sat How reproducible: always Steps to Reproduce: 1. see rhn-satellite-5-upgrade-scenario-1b.txt Actual results: cd /etc/sysconfig/rhn/satellite-upgrade sqlplus -S dbusername/dppassword@dbSID @satellite-temp_tbs-estimate.sql Expected results: su - oracle cd /etc/sysconfig/rhn/satellite-upgrade sqlplus -S dbusername/dppassword@dbSID @satellite-temp_tbs-estimate.sql Additional info: # whoami root # cd /etc/sysconfig/rhn/satellite-upgrade # sqlplus -S rhnsat/rhnsat@rhnsat @satellite-temp_tbs-estimate.sql bash: /opt/oracle/bin/sqlplus: No such file or directory
Logging in as oracle to execute satellite-temp_tbs-estimate.sql should not be needed because: 1. The script only counts rows of one table to determine TEMP_TBS size estimates for which you don't need sysdba privileges 2. Running it under oracle would mean oracle-server-*'s sqlplus would be used, which is what we don't want. We want to user instantclient's sqlplus. 3. The script needs to work with both embedded and external databases, which means we cannot rely on how oracle user is setup. Besides, the fact that bash complains about /opt/oracle/bin/sqlplus leads me to believe that what in fact happened was: 1. you ran sqlplus on the satellite before the upgrade (which used oracle 9.x) 2. you upgraded to satellite 5.3, which has sqlplus in a different location, though bash would still like to execute /opt/oracle/bin/sqlplus (this is how it remembers it).