Bug 526353 - when estimating required tablesize, logging-in as oracle should be suggested
Summary: when estimating required tablesize, logging-in as oracle should be suggested
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Upgrades
Version: 530
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
Depends On:
Blocks: sat540-upgrades
TreeView+ depends on / blocked
Reported: 2009-09-29 23:00 UTC by Jan Hutař
Modified: 2010-08-26 12:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-26 12:08:07 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Jan Hutař 2009-09-29 23:00:21 UTC
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):

How reproducible:

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
# 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

Comment 1 Milan Zázrivec 2010-08-26 12:08:07 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.