This content has been marked as final. Show 1 reply
rjzamora wrote:Pl post OS details.
I have read quite a bit of the upgrade documentation that I could find. I have run two test upgrades, one from 10.2.0.3 to 22.214.171.124 and another from 126.96.36.199 to 188.8.131.52. I have also successfully upgraded one database to 184.108.40.206 with no issues or questions.
Last night I attempted to upgrade one of my instances from 10.2.0.3 to 220.127.116.11. A number of questions came up:Pl post the complete error message from the database alert log and the upgrade log files. You should not have to drop this table in general. Have you asked Support why they think this is the solution to the issue ?
1) I got an ORA-3113. When I created an SR it recommended dropping the xdb.migr9202status table. I will be trying that tonight when my maintenance window opens up. The general question that I have is: Should I drop this table, proactively, before each upgrade, or do I need to wait for the upgrade to fail before I drop the table?
2) When I run the pre-upgrade script, there is a note that the timezone needs to be upgraded and to run the correct DBMS script. There is an option in the upgrade assistant to upgrade the timezone. What is the best practice, to let the script perform the time zone or should I upgrade the timezone manually?You should manually upgrade timezone related settings after the database upgrade. I do not believe DBUA takes care of this. Pl see this MOS Doc
Actions For DST Updates When Upgrading To Or Applying The 18.104.22.168 Patchset [ID 1358166.1]
3) There is also a note about configuring the network ACLs for several users. I foulnd a web page:Yes - this needs to be done as one of the post-upgrade steps.
Is this the correct way, and should it be performed after the upgrade?
Thanks in advance for the help, RJZHTH