Delphix Products

Hi all,

in reference to the article http://docs.delphix.com/display/DOCS31/Use+Case%3A+Testing+Oracle+Upgrades+and+Application+Patching I'd like to have a hand to understand how Delphix can simplify the Oracle upgrade process.

If I choose the approach relative to the 3rd step, I will patch the existing ORACLE_HOME. But at the 5th step, the simply restore of the VDB does not unpatch the ORACLE_HOME, does it? 
Instead, If I choose the approach relative to the 4th step, the 5th step could be unnecessary because I keep unchanged the original ORACLE_HOME: I have just swinged the VDB. 

What eludes me?
Thank you.
Gianpiero


#DemoEnvironment

Hi Gianpiero,
I'm not sure what you mean by "swing a VDB" however here is more information about upgrading Oracle VDBs and use cases that might help you with your testing:


There are 2 distinct methods for performing an Oracle upgrade on a VDB

1. Upgrade the VDB independently of the Source DB
2. Upgrade the Source DB (dSource basis) and allow changes to propagate to the VDB via Delphix "VDB Refresh"
   
   

The main driver for choosing one over the other is whether you want to maintain changes to the VDB.  Method #1 is more difficult and time consuming, especially for large numbers of VDB's.  But Method #1 will preserve changes.  

Practically, many users choose option #1 because they want to test the DB Upgrade on non-PROD VDB's.  

Ex:  You have a new version of your software in DEV (VDB) which you want to test with the upgraded DB version, but this software isn't in PROD (dSource).  Method #1 allows you to test the software on the new DB version without redeploying it.

Ex:  You have 25 VDB's to upgrade. Use method #2 wherever possible.

Background: Elements of an Oracle Upgrade

There are two elements of an Oracle Upgrade:  binary changes and data dictionary changes.  

Binary changes are accomplished by installing a new Oracle Home and mounting the database with the new binaries.  Binary installation is performed on source and target environments through the standard Oracle tools.  Delphix must be made aware of the new binaries by refreshing the environment, and by clicking on the Upgrade icon.

Data Dictionary changes are accomplished by running Oracle scripts.  DD changes can be propagated from source to VDB via VDB Refresh or by running the appropriate scripts on the VDB.

Method #1:  Upgrade the VDB independently of the Source DB

Because a VDB is just like a regular database, DBA's can use standard techniques to perform the upgrade, with one small twist.  Delphix must be made aware of the location of the new binaries.

Upgrading the VDB independently allows you to preserve the changes made to that VDB, and get to the new Oracle version.

1. Install new binaries onto the target environment
2. Upgrade the VDB through a standard Oracle method, treating the VDB exactly like a physical DB
3. In Delphix, refresh the target environment to discover the new binaries
4. In Delphix, select the VDB and click the Upgrade button.  This updates the Delphix metadata, so that Delphix knows the VDB is a newer version.

Method #2:  Upgrade the VDB after upgrading the Source DB

Logically, this is identical to removing the VDB and recreating it with the new version of Oracle binaries, except that the VDB name and other attributes will be preserved.

Changes made to the VDB will be lost.

1. First, upgrade the Source DB following the latest docs.  Upgrading dSources and VDBs .  Do not stop LogSync.  Now you have an upgraded dSource.
2. Install new binaries on the target environment
3. In Delphix, refresh the target environment to discover the new binaries
4. In Delphix, select the VDB and click the Upgrade button.  This updates the Delphix metadata, so that Delphix knows the VDB is a newer version.
5. In Delphix, refresh the VDB from a time after the dSource upgrade.

 

Saying just "Many thanks" is not enough to show you my appreciation of your elaborate reply. It was very clear and makes me more experienced on Delphix.

But it seems to me that Delphix cannot simplify the work of the DB admin for the upgrade process. Using or not using Delphix, the DBA has to do the same amount of work for upgrading the DB.

I want to find a strong point of Delphix to help the DBA man during the upgrade process. I'd like to tell him: "If you use Delphix, you could easily reiterate your tries before applying the process in the production environment". So I found interesting the http://docs.delphix.com/display/DOCS31/Use+Case%3A+Testing+Oracle+Upgrades+and+Application+Patching article. But I don't understand how the fifth step can reset the binaries upgrade.

Sorry for my possible english mistakes.
And thank you again for your help.
Gianpiero

Ciao Giampiero, I can add my 2 cents from my personal experience.

The great advantage that Delphix provides it's in the capability to strengthen and speed up the upgrade process.
In real life scenarios, many time a DB upgrade is not executed because of the many different impacts this task can have on a prod environment, where on top of the DB there are one or many applications using the DB to consume and/or persist data.
In fact, an application is made of processes, functions, events that can be heavily affected by the upgrade version of the DB.
For example, in best case, since you're upgrading you DB, you would expect to improve the application efficiency by exploiting new capabilities provided by the upgrade.
In worse case, you could experience difficulties and stops during the upgrade process, post upgrade performance issues, lack of functionalities, etc.

All these cases suggest to plan properly an upgrade task in order to minimise risk and production outages.
This means to test and reiterate an upgrade process until it's fine tuned and proven. Imagine it as a Software Development Project and its life cycle. It is actually.
Hence, the more you can test it, the better and faster you achieve your goal.

Delphix provides exactly these benefits: it allows more tests in less elapsed time.
In some enterprise application projects I've worked on, a DB upgrade project required weeks or months. With Delphix the same result can be achieved in days.

Back to your comments, yes the upgrade process isn't changing really. You can save a lot of work of a DBA and the Application team, because you de-risk the upgrade, reducing to zero the unprevented, unexpected issues and the related firefightings that happen in prod.

Hope this helps
Ugo

Thank you very much for having brought us your actual experiences. Thanks to Jaclyn and you, now I have a clearer overview of the benefits of Delphix in the Oracle upgrade case.
Gianpiero