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

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

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

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.

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!

Now You Have To Maintain All Of It

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

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.

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

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!

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; https://docs.delphix.com/display/DOCS43/CLI+Cookbook%3A+Provisioning+a+VDB+from+a+TimeFlow+Bookmark

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…

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.

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).

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

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

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.

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

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.

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.

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

References and Tips Delphix Oracle Upgrade Workflow: https://support.delphix.com/hc/en- us/articles/221248628-Oracle-Upgrades-Workflow-and-Troubleshooting Upgrading the Dsource after an Oracle Upgrade: https://docs.delphix.com/display/DOCS/Upgrading+dSources+after+an+Oracle+Upgrade How to Upgrade an Oracle VDB: https://support.delphix.com/hc/en-us/articles/204929258- KB089-How-to-Upgrade-an-Oracle-VDB Tip: Don’t Suspend:LogSync When Upgrading the Source! https://community.delphix.com/delphix/topics/tip-of-the-day-upgrading-an-oracle-vdb

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