Bug 496907

Summary: Schema upgrade script errors out when trying to run
Product: Red Hat Satellite 5 Reporter: Mike Santangelo <msantang>
Component: UpgradesAssignee: Milan Zázrivec <mzazrivec>
Status: CLOSED NOTABUG QA Contact: Brandon Perkins <bperkins>
Severity: medium Docs Contact:
Priority: low    
Version: unspecifiedCC: cgrillo71, claudiol, jpazdziora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-23 22:00:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
SQL script log
none
3.7 -> 4.0 schema upgrade script log
none
rhn_search log
none
Taskomatic daemon log none

Description Mike Santangelo 2009-04-21 15:50:30 UTC 
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 15:51:45 UTC 
Created attachment 340558 [details]
SQL script log
Comment 2 Milan Zázrivec 2009-04-21 16:52:50 UTC 
Did the 3.4 schema import complete successfully (look for errors in
import log)?
Comment 3 Jan Pazdziora 2009-04-22 09:50:55 UTC 
What does the export / import mean here? exp + imp?
Comment 4 Mike Santangelo 2009-04-22 16:33:58 UTC 
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 13:02:36 UTC 
After the DBA's did their refresh the scripts worked perfectly. Closing the ticket.
Comment 6 Mike Santangelo 2009-04-23 15:24:09 UTC 
Created attachment 340955 [details]
3.7 -> 4.0 schema upgrade script log
Comment 7 Mike Santangelo 2009-04-23 15:25:22 UTC 
Created attachment 340956 [details]
rhn_search log
Comment 8 Mike Santangelo 2009-04-23 15:29:08 UTC 
Created attachment 340957 [details]
Taskomatic daemon log
Comment 9 Mike Santangelo 2009-04-23 15:33:18 UTC 
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 22:00:17 UTC 
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.