Re: Database upgrade hacking

  • From: Brent Day <coloradodba@xxxxxxxxx>
  • To: "Laimutis.Nedzinskas@xxxxxx" <Laimutis.Nedzinskas@xxxxxx>
  • Date: Fri, 17 May 2013 17:15:06 -0600


I have used an approach that is very similar. In fact for our more critical 
systems I make a clone, then upgrade to 11.2, perform basic validation and then 
flashback. This allows us to script and test everything before go live and then 
give management a very accurate estimate of timings. Then the night of the real 
upgrade we create a restore point before we start the upgrade, usually after 
coalesce of the database.

I use a similar process when we test or perform application code upgrades as 
well and this is now standard procedure for out team. Great feature that can 
save hours of hassle. We have EMC snap clone technology as well but Oracle 
flashback is our preferred tool for these types of scenarios.

Hope that helps

On May 17, 2013, at 3:21 AM, Laimutis.Nedzinskas@xxxxxx wrote:

> 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 @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
> --
> //

Other related posts: