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.
Created attachment 340558 [details] SQL script log
Did the 3.4 schema import complete successfully (look for errors in import log)?
What does the export / import mean here? exp + imp?
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.
After the DBA's did their refresh the scripts worked perfectly. Closing the ticket.
Created attachment 340955 [details] 3.7 -> 4.0 schema upgrade script log
Created attachment 340956 [details] rhn_search log
Created attachment 340957 [details] Taskomatic daemon log
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.
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.