1. The Case of the Limitless DBA
The Patching Epiphany
The Case of the Limitless DBA

2. Epiphany e·piph·a·ny əˈpifənē/ noun
a (1) : a usually sudden manifestation or perception of the essential nature or meaning of something (2) : an intuitive grasp of reality through something (as an event) usually simple and striking (3) : an illuminating discovery, realization, or disclosure
b : a revealing scene or moment

3. A Single Use Case
The goal here is to use one use case to help drive the epiphany of virtualization.

4. Patching and Upgrading….
I’d simplified patching using Enterprise Manager 12c and patch plans.
They were simple to create, but still required work each month to test and build.
Also expensive management tasks.
Sometimes I still had to intervene.
It was a never-ending task.

5. Standard Database Environment
Time?
Finance
Weeks? HR
Months?
CRM
DBA has to commandeer a database for patch testing.
This has to be performed for EACH environment, 100’s or 1000’s of databases!
Most are not synchronized with production, different outcomes when released to production.
Bugs occurring in one, not another!

6. Now You Have To
Maintain All Of It

7. Patching and Upgrading Databases
Each patch, (PSU) would need to be applied to a development database, requiring outage to development teams and then tested before applying to test, QA and then onto production.
This has to be performed to EACH environment, every database, each quarter.
Quarterly PSU Patching is
Finance
A Major Undertaking HR
CRM

8. Risks/Challenges Of This Approach
Downtime for valuable resources.
DBAs working afterhours
Each database must have it done and…
The tedious task must be performed over and over again.
Little opportunity for advanced learning.
Each database may experience different bugs.

9. Virtualization Eliminates 90%+ Common, Repeated Data
Spin a VIRTUAL database up a patch test, without having to remove a current development or test one.
PRODUCTION
Database/App Tier
1 TB
Storage Pool for Delphix
DEV
PATCH TEST QA
TEST
▶ ▶ ▶
Virtualize and Deployed▶ ▶ ▶
Read From Production
0.6 TB

10. I’m a Command Line Person, Whatcha Got?
The name of the VDB you want to create
The group in which to create the VDB
The Oracle database name
The Oracle database unique name
The Oracle database instance number
The Oracle database instance name
The source dSource or VDB from which you wish to provision
The SCN or timestamp of the point you want to provision from, (commands can be run to get the list of snapshots or timeflow ranges.)
The CLI, (Command Line Interface) is very robust for Delphix and Creating VDB is easy!

11. Choose Source Snapshot: >snapshot list database=<dbname>
timeflow ”<dbname>" timeflowRanges;
commit;
Create A Virtual Database:
>database provision;
delphix database provision > defaults
delphix database provision defaults > set container=<Vdbname>
delphix database provision defaults > commit;

12. What a CLI Scripted Refresh Looks Like
> database
> select <VDB name>
> refresh
> set timeflowPointParameters.type= (one of TimeflowPointBookmark, TimeflowPointBookmarkTag, TimeflowPointLocation, TimeflowPointSemantic, TimeflowPointTimestamp as appropriate)
> set timeflowPointParameters.location= (the location, timestamp, or bookmark you wish to refresh to)
> set timeflowPointParameters.timeflow= (the timeflow associated with location)
> commit
Still, very simple vs. what we write every day to support a simple create table or create database…

13. When Do I USE the CLI or Graphical UI?
Monstrous deployments, (20+) benefit from a scripted, CLI option.
Single or several VDB deployment.
When investigating deep level issues, using the CLI can make details easier to search through.
When looking for “just the facts”, then a graphical UI is beneficial for high level error messages.
Self-service has great benefits and make it simple for those without deep level skills to take advantage of virtualized environments for development and testing.

14. Cost Vs. Benefit…
No Management Packs outside of database feature licensing.
Heterogeneous Opportunities
Update)/Oracle upgrade:
A) Apply to existing ORACLE_HOME. (best if on Delphix v4.1.x or higher.)
B) Create new ORACLE_HOME (could clone existing one) and then apply the PSU to the new ORACLE_HOME.
For a dSource using option A:
1) Follow Oracle documentation, patch the ORALCE_HOME and the database.
2) Refresh the Environment in the GUI.
For a dSource using option B:
1) Refresh the Environment from the Delphix GUI and verify that the new ORACLE_HOME is picked up and in the databases tab as an ORACLE Installation.
2) Follow all Oracle documentation, patch the production database etc.
3) Go to the Delphix GUI flip the dSource card over and use the Upgrade Icon on the bottom to switch the ORACLE_INSTALLATION to the new (verified in step 1).

15. Environment Virtualization, DB Style
Spin up a new VDB and apply patch there- no need to commandeer existing! V D V V V V V

16. After Testing, Apply to Production
No need to keep the extra VDBs post patch to prod. V D V V V V V

17. Environment Virtualization, DB Style
The Compressed Copies in the Delphix Engine are Upgraded!
Testing upgrades and patches can be greatly simplified using the portability and ease-of-use of Delphix Virtual Databases (VDBs). Here are two approaches that can be used, depending on the upgrade or patch.
Link the production database with the Delphix Server.
Provision a VDB at the existing patch level.
Patch the existing $Oracle_Home against the live VDB.
or 
Create the new $Oracle_Home and swing the VDB.
Rollback VDB or Refresh from production.
Repeat 3 or 4 until confident.
Once the process has been tested and confirmed, it can be rolled out with confidence into production.

18. Environment Virtualization, DB Style
In minutes, refresh and complete! D V V V

20. Patching and Upgrading with Virtualization
Not only did I save on 80% or more on storage usage overall.
I didn’t have to take away a valuable resource’s database environment to test the patch/upgrade.
I didn’t have to apply the patch/upgrade to each environment, as they are virtualized copies of the source.
I save significant time that commonly has to be allocated to quarterly and annual maintenance for patching and upgrading.
I apply the patch twice- once to test, once to production. I only need to refresh my environments after I’m done.
This works for the database AND application tier.

21. The quickest way to complete a task is not having to do it.
And there’s the epiphany…
The quickest way to complete a task is not having to do it.

22. Now its your turn to see how easy it is!
AWS Trial Version: <insert URL>

23. References and Tips
Delphix Oracle Upgrade Workflow: us/articles/ Oracle-Upgrades-Workflow-and-Troubleshooting Upgrading the Dsource after an Oracle Upgrade: How to Upgrade an Oracle VDB: KB089-How-to-Upgrade-an-Oracle-VDB Tip: Don’t Suspend:LogSync When Upgrading the Source!

24. https://www.delphix.com/products/ <insert URL>