Re: Database upgrade hacking

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
Brent

On May 17, 2013, at 3:21 AM, Laimutis.Nedzinskas_at_seb.lt 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 _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
>
>

--
http://www.freelists.org/webpage/oracle-l