Re: Flashback, Restore Points and Standby databases

From: Tim Gorman <tim_at_evdbt.com>
Date: Fri, 07 Nov 2014 10:13:47 -0700
Message-ID: <545CFDCB.2040402_at_evdbt.com>



Lyall and Venkat,

Provisioning environments that can rewind easily for big one-time tasks like conversions is something that data virtualization solutions do really well.

Virtual data is becoming the new norm, an emerging must-have, just as virtual servers have already become the new norm. It's becoming harder to justify continuing to do things as we have for the past 15-20 years. I'm not saying this thread is a particular example, but it might be...

Since it is so time-consuming and expensive to create perfect clones of production stacks (i.e. database, software binaries, etc), it generally happens that large conversions like this move forward with a lot of unknowns. As a result, all of the uncertainty demands the ability to fallback to multiple points-in-time be available during the final production cutover.

Data virtualization means that cloning complete production stacks can be generated self-service by project teams or individual developers and testers as they need it.

Because the virtual databases and virtual file-systems consume practically no storage, the "spending authority" required to authorize the provisioning of a complete virtual stack of database and application software for testing falls from the VP- or director-level, down to the level of the individual developer or tester.

Oracle EM12c Cloud Control has this capability (called DBaaS) and Delphix has been doing this in production at customers for the past 4 years. There are also thin-cloning solutions from storage vendors (i.e. NetApp, EMC, IBM, etc), but they aren't as focused on Oracle-based applications as the fully orchestrated and automated products such as Oracle EM12c DBaaS and Delphix, and so they require massive amounts of custom-built orchestration, scripting, and automation around the core capability, which are inherent to the Oracle and Delphix solutions. This becomes yet another build-vs-buy decision, either buy the stuff ready to work, or build your own.

Here's how I believe this massive conversion would go in an organization with data virtualization capabilities...

  • The development needed for the massive conversion would have completed in half the time because the developers assigned to the task would have been able to provision as many complete private environments as they needed, when they needed it o Provisioning environments is the single biggest bottleneck in application development
  • Testers would have completed in half the time, because they were able to spend 80% of their time actually testing with only 20% of the time getting set up, instead of the current-day situation where they spend less than 20% of their time actually doing testing, with the other 80% getting set up o As a result of the ability to do extensive and more-productive testing, the possibility of fallback during cutover is reduced
  • Production cutover could proceed with less preparation because an infinite number of virtual databases can be created quickly and easily on demand at each crucial restore-point o Not just a restore point, but an up-and-running environment provisioned at that point-in-time
  • If a fallback becomes necessary during cutover, then there are numerous options... o if the number of changes to fallback are simple enough, they can be copied from a point-in-time using the appropriate virtual database and/or file-system o if it would take too long to fallback that way, then production can immediately resume using an appropriate virtual database, which itself can be instantiated as a non-virtual physical database if preferred

It results in a complete sharp-left-turn shift in thinking about the task, based on the reality of being able to provision an infinite number of copies of environments on a whim.

Automation, orchestration, and disruptive new capabilities result in continuous delivery, rather than infrequent bet-the-farm releases.

Sorry if I seemed to fall into salesy talk here, but this isn't really sales speak. It's real, it's live, and it's in production.

Hope this helps!

Thanks!

-Tim

On 11/6/14 22:57, Venkat srinivasan wrote:
> Hi Lyall,
>
> You can achieve by putting the restore points and convert your standby
> to shapshot standby. You can go through the below blogs will help.
>
> http://shivanandarao-oracle.com/2013/02/04/snapshot-standby-database-convert-physical-standby-database-to-snapshot-standby-database-read-write-mode-and-viceversa/
>
> http://www.pafumi.net/Standby_Snapshot_DB.html
>
> Hope this helps
>
> Regards
> Venkat
>
> On 6 November 2014 19:52, Lyall Barbour <lyallbarbour_at_sanfranmail.com
> <mailto:lyallbarbour_at_sanfranmail.com>> wrote:
>
> Hello everyone,
> Oracle 11.2.0.4, RHEL 5.10, Primary database and two Standby
> databases, one physical, the second Logical.
> This weekend, my company will be doing a massive conversion of
> an Application system from a company that we bought, into our main
> App. Before this happens, the App Team wants a backup of the
> Production database. I'll be doing an RMAN level 0, but i'm also
> blowing up our Flashback area so that i can set some restore
> points along the way this weekend. I'm trying to figure out how,
> in the case of a major issue, if we Flashed back to a certain
> Point, what happens to the Logical Standby? Does any know? Will
> it be Flashback too? Do i have to set a Restore Point on it, in
> line with the Restore on Primary? Is there no way that they'll
> stay in sync after a restore? Do i just have to rebuild it?
> Thanks,
> Lyall Barbour
> -- http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Nov 07 2014 - 18:13:47 CET

Original text of this message