Bug 496907 - Schema upgrade script errors out when trying to run
Schema upgrade script errors out when trying to run
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Upgrades (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Milan Zazrivec
Brandon Perkins
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-21 11:50 EDT by Mike Santangelo
Modified: 2013-03-03 18:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-23 18:00:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SQL script log (2.45 KB, text/plain)
2009-04-21 11:51 EDT, Mike Santangelo
no flags Details
3.7 -> 4.0 schema upgrade script log (224.93 KB, text/plain)
2009-04-23 11:24 EDT, Mike Santangelo
no flags Details
rhn_search log (1.33 MB, text/plain)
2009-04-23 11:25 EDT, Mike Santangelo
no flags Details
Taskomatic daemon log (4.78 MB, text/plain)
2009-04-23 11:29 EDT, Mike Santangelo
no flags Details

  None (edit)
Description Mike Santangelo 2009-04-21 11:50:30 EDT
Description of problem:
We are trying to upgrade a customer from RHN Satellite 3.4 on a RHEL 2.1 instance to RHN Satellite 5.2 on RHEL 4.7. Customer uses external databases with their own DBA's to manage the databases. 

We had the DBA's export the data from the current 9i Oracle database and import it in to the new instance which is a 10g Oracle database. We then connected a test RHN Satellite 5.2 instance to the external 10g Oracle instance using tnsnames.ora (In other words the Satellite instance is not using or connected to the database, it just recognizes the instance so we can connect using sqlplus) and tried to run the schema upgrade scripts. 

We got errors when we tried to run those scripts (log is attached)


Version-Release number of selected component (if applicable):
RHN Satellite 3.4/Oracle 9i
RHN Satellite 5.2/Oracle 10g

How reproducible:
Happens every time we try to run the script on the test machine.

Steps to Reproduce:
1.  
2.
3.

Actual results:


Expected results:


Additional info:
Putting in the bug now, but we are checking with the customer DBA's to be sure that the new Oracle instance was built to the correct specifications (as laid out by Red Hat in the documentation for RHN Satellite) and that the data was imported correctly and successfully. So this may end up being nothing and related strictly to the Database itself.
Comment 1 Mike Santangelo 2009-04-21 11:51:45 EDT
Created attachment 340558 [details]
SQL script log
Comment 2 Milan Zazrivec 2009-04-21 12:52:50 EDT
Did the 3.4 schema import complete successfully (look for errors in
import log)?
Comment 3 Jan Pazdziora 2009-04-22 05:50:55 EDT
What does the export / import mean here? exp + imp?
Comment 4 Mike Santangelo 2009-04-22 12:33:58 EDT
The export/import means that the DBA's did a data/schema export from the external 9i Oracle database and imported the data/schema in to the external 10g Oracle database.

The DBA's discovered that there were some inconsistencies in the schema, so they are refreshing the schema with a new export now. If this turns out to have been the problem then I will close the ticket.
Comment 5 Mike Santangelo 2009-04-23 09:02:36 EDT
After the DBA's did their refresh the scripts worked perfectly. Closing the ticket.
Comment 6 Mike Santangelo 2009-04-23 11:24:09 EDT
Created attachment 340955 [details]
3.7 -> 4.0 schema upgrade script log
Comment 7 Mike Santangelo 2009-04-23 11:25:22 EDT
Created attachment 340956 [details]
rhn_search log
Comment 8 Mike Santangelo 2009-04-23 11:29:08 EDT
Created attachment 340957 [details]
Taskomatic daemon log
Comment 9 Mike Santangelo 2009-04-23 11:33:18 EDT
Apparently I was premature in thinking everything went perfectly. After all 8 schema upgrade scripts ran (from 3.4 -> 5.2) with no errors we thought we were good. However, when we pointed at the new instance and tried to go to the web GUI we were getting 500 server errors. 

Looking in the logs we found errors relating to the RHN_SYNCH_PROBE_STATE identified in Oracle. Looking through the schema update script logs, that identifier is created in the 3.7 -> 4.0 schema upgrade script, and the log file shows that this process was created successfully. 

I have attached the schema update script log file, the rhn_search log, and the rhn_taskomatic log just so you can see the errors. If you notice, there is a block of time we are geting those errors related to the RHN_SYNCH_PROBE_STATE identifier. Then, when we pointed RHN back at the embedded database the errors went away.
Comment 10 Mike Santangelo 2009-04-23 18:00:17 EDT
Closing this bug once more, I promise this will be the last time.

After having the DBA's look in to it, again, they found out that the Oracle user they had assigned for us did not have the proper permissions to access some of the new objects created by the database schema update scripts. Once we used the user with the correct permissions, the RHN Satellite instance connected to the database and all data showed up.

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