Database upgrade hacking

From: <Laimutis.Nedzinskas_at_seb.lt>
Date: Fri, 17 May 2013 12:21:12 +0300
Message-ID: <OF61643E39.5845E33F-ONC2257B6E.0032230F-C2257B6E.00336194_at_seb.lt>



Hi

I've tested with success a rollback of upgrade from 10.2 to 11.2. Is such a rollback is supported or not ?

The steps were:

  • leave parameter compatible.2.0
  • do all documented pre-migrations steps
  • startup upgrade
  • create guaranteed flashbak point
  • run _at_catupgrd.sql
  • open database
  • now suppose a problem is detected and rollback decision is taken:
  • flashbacked database to the restore point
  • opened database with 10.2 binaries
  • startup: startup mounted the database but open requested "ORA-01589: must use RESETLOGS or NORESETLOGS option for database open"
  • alter database open resetlogs: Database altered. That's it. The database opened and running.

The idea is that until database does not upgrade datafile headers in uncompatible manner all the rest does not really matter. Parameter files and control files can be delt with.
Changes to the dictionary are delt with by flashback. Redo logs should not be important after flaashback to the point right after "startup upgrade" (it should be possible to create a restore point after mount and only then open the database with migrate option but I haven't tested that yet)
Anything else I am missing ?

The database is opened for read-write. If in doubt you have a time to replicate it to a supported instance. Looks like in some cases it is a better alternative than to restore from backup ?

Brgds, Laimis N


Please consider the environment before printing this e-mail

--
http://www.freelists.org/webpage/oracle-l
Received on Fri May 17 2013 - 11:21:12 CEST

Original text of this message