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.
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!
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).
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.
Delphix Patching Epiphany
The Patching Epiphany
The Case of the Limitless DBA
Kellyn Pot’Vin-Gorman | Technical Intelligence Manager