| Running utlu102i.sql for upgrade(8.1.7 to 10g2) [message #223987] |
Mon, 12 March 2007 09:51  |
preet_kumar
Messages: 204
Registered: March 2007
|
Senior Member |
|
|
Is it possible to run utlu102i.sql on a standby database.I tried to run and it gives the following error
ORA-00604: error occurred at recursive SQL level 1
ORA-00372: file 1 cannot be modified at this time
ORA-01110: data file 1: '/oracle/data/sid/system.dbf'
|
|
|
|
|
|
|
|
|
|
| Re: Running utlu102i.sql for upgrade(8.1.7 to 10g2) [message #224010 is a reply to message #223987] |
Mon, 12 March 2007 11:08  |
preet_kumar
Messages: 204
Registered: March 2007
|
Senior Member |
|
|
I dont need to upgrade the standby database.I want to upgrade from 8.1.7 to 10g and for which i need to run the utlu102i.sql which comes with 10g.Already i installed a new server with 10g and later would import data from old server.
I need to run this script on the old database to analyze it before upgrading as it shows the compatibility status.I dont want to take a risk of running this on primary so i wanted to run it on standby where the database is readonly.
|
|
|
|
|
|
|
|
 Re: Running utlu102i.sql for upgrade(8.1.7 to 10g2) [message #228991 is a reply to message #223987] |
Wed, 04 April 2007 19:48 |
d0hboy
Messages: 5
Registered: December 2006
|
Junior Member |
|
|
We recently ran through a similar process with upgrading a 9.2.0.6 primary/physical standby to 10.2.0.3. I believe the utlu102i.sql is harmless and shouldn't update anything, but simply does an assessment. It probably needs to touch some system tables in the process but nothing that would appear to cause irreparable damage.
Assuming you have a direct upgrade path (should read the manual first to see if its legit), What we did was:
install 10.2.0.3 on new Oracle_home on primary/standby
0)
1) make sure standby is caught up
2) switch log, shutdown primary
3) make sure log applied on standby, shutdown standby
4) startup primary using new 10g oracle_home using STARTUP UPGRADE
5) create sysaux
6) run catupgrade script
7) startup standby using new 10goracle_home
8.) start managed recovery on standby, picking up the primary's logs
There were a few times we had to bounce and change the log_archive_format to the 10g compliant way, and change the compatible setting, so those are gotcha's that have to be managed.
some of the steps may not be exactly the same order as what the manual said, but i'm going by memory here. Out of curiosity, what kind of downtime were you guys expecting to have?
[Updated on: Wed, 04 April 2007 19:49] Report message to a moderator |
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
