Presentation Transcript

1. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
2. Oracle Database Patching Best Practices Eleanor MerittVice President, Sustaining Engineering
3. Oracle Database Patching Best Practices Provide you with the knowledge and tools to develop turnkey patching solutions to use at your company
4. Program Agenda What happens at Oracle before you get your patch? How should you test a patch? How can you best plan for and manage patching? How do you minimize downtimes? What is new with Database 12c?
5. Nomenclature Patch Types Patch Set a maintenance release containing all bugs fixed for a given production version during a time period. May contain limited new functionality 1 patch set for every .1 major release 3 patch sets for every .2 major release patch sets are released 12 months after the latest major release or patch set exception is the 3rd patch set for the .2 major release which comes 18-24 months after
6. Nomenclature Patch Types Patch Set Update (PSU) a quarterly collection of fixes for proven high impact bugs encountered in the field includes security content guaranteed not to contain any changes to the optimizer or fixes which change application behaviour may span multiple stack components, for example: Grid Infrastructure and database
7. Nomenclature Patch Types Bundle Patch (BP) a collection of fixes to address bugs in a given feature, product, or configuration. For example: Windows BP, Exadata BP BP’s are super sets of PSU’s. They may contain content as yet unproven in the field may span multiple stack components. For example: Exadata Quarterly Full Stack Download patches
8. Nomenclature Patch Types Security Patch Update (SPU) a collection of patches released quarterly, to fix security bugs. Also known as a CPU (Critical Patch Update) the SPU is being phased out starting with database release 12.1.0.1 Interim Patch a single standalone patch also called a “one-off” or PSE
9. Product Maintenance Process Overview
10. What Happens at Oracle before I get my patch? Maintenance Cycle Overview Bug Reported Bug Fixed Patch Created Bug report opened Problem diagnosed Fix coded against current development release Peer code reviewed Tests run Fix merged in current development release (tested) Fix merged to open patch set releases (tested) Fix coded against customer reported release (tested) Patch generated against customer reported release
11. The Patch Creation Flow Test Environments MOS Automated Patch Framework Report issue and file SR Release patch Run tests Customer RAC Createfix and requestpatch Enterprise Manager Oracle Development Applypatch Exalogic AutomatedPatch Framework Build patch Downloadpatch Exadata Provision test environment Invoketesting Single Instance
12. Oracle Testing Overview
13. Oracle Testing Overview Test Types Functional tests intended to regression test all database functionality entire suite run nightly on latest version of the code base Stress tests test resiliency of the database when pushed to its limit in resource utilization and in configuration settings heavy destructive tests under high load Performance tests workloads, feature testing, atomics
14. Oracle Testing Overview Other Testing Customer beta testing Certification testing Installation, upgrade & downgrade testing Internal deployments
15. Testing Summary by Patch Type
16. Oracle's Maintenance Strategy Recommendations for Customers
17. Establish a Maintenance Strategy Be Proactive Being proactive is the best strategy plan ahead know your options Consider the relative importance of each of these to your business: new features certifications stability supportability
18. Establish a Maintenance Strategy Decide on a Database Release 10.2 is now out of extended support. If you haven’t already upgraded, now is an excellent time to do so! 11.2.0.4 is freshly released. Promises to be the most stable version of 11g with quality levels at least as high as 10.2.0.5 11.2.0.3 is currently the most active release in the field today. Uptake levels are surpassing even 10.2.0.4 12.1.0.1 – excellent prospect for early roll-outof DB 12.1 new features. First PSU due October 2013
19. Establish a Maintenance Strategy What to Avoid Older releases lack of access to current interim patches, PSU’s, SPU’s ,etc. Custom combinations avoid proliferation of interim patches. These create unique environments and make problem diagnosis more difficult. Can also lead to the need for yet more unique patch merges
20. Establish a Maintenance Strategy Insider Information ~70% of bugs hit by Exadata customers are fixed in existing BP’s and patch sets keep current with PSU’s, BP’s at least try to apply them every six months Stay up to date with patch sets: latest patch sets are of proven better quality. They allow access to new PSU’s, BP’s, and interim patches
21. Software Maintenance Testing Recommendations by Patch Type
22. Patching for High Availability
23. Patch the Standby FirstMinimal Downtime Application tier Production up after switchover Run any patch SQL Patch original primary home Patch the standby Test changes!!!! Switchover Post switchover Data Guard
24. Out-of-Place Patching Minimal Downtime DB Instance Clone Home Patches Applied Apply Patches Database Home Cloned Database Home
25. Rolling RACZero Downtime Zero downtime rolling patch orchestration across RACs Patch support for GI (or Clusterware) to both GI and RAC OH in a node in a rolling fashion
26. Online Patching aka Hot PatchingZero Downtime Patched Shared Library Apply shared library Map into text area Use new patched functions Increases memory footprint Patch offline on next downtime P1 or diagnostic patches
27. High Availability by Patch Type *Only available from 11.2.0.2 onward
28. What's new with Database 12c?
29. Queryable Patch Inventory SQL Interface Provides access to the OPatch inventory information from within the database PLSQL/SQL interface to view list of patches applied conflicting patches for a given file prerequisite patches for a given patch patch inventory across RAC nodes SQL patch status
30. Queryable Patch Inventory Display Patch Inventory DBMS_QOPATCH.GET_OPATCH_LSINVENTORY SQL> SELECT xmltransform(dbms_qopatch.get_opatch_lsinventory(), dbms_qopatch.get_opatch_xslt()) FROM dual; Patch 12345678 : applied on Fri Sep 13 05:52:28 PDT 2013 Unique Patch ID: 16709411 Created on 29 Aug 2013, 08:39:18 hrs PST8PDT Bugs fixed: 17330580 Files Touched: /kxes.o --> ORACLE_HOME/lib/libserver12.a /kzp.o --> ORACLE_HOME/lib/libserver12.a ins_rdbms.mk --> ORACLE_HOME/rdbms/lib/ioracle
31. Queryable Patch Inventory Determine if a Patch is Installed DBMS_QOPATCH.IS_PATCH_INSTALLED SQL> SELECT nvl2(dbms_qopatch.is_patch_installed(‘12345678').getStringval(), 'Installed', ‘Not Installed') patch_details FROM dual; PATCH_DETAILS ------------------------ Installed
32. Queryable Patch Inventory Get RAC Node Specific Patch Details DBMS_QOPATCH.SET_CURRENT_OPINST SQL> exec DBMS_QOPATCH.SET_CURRENT_OPINST (‘node2’,’inst2’); SQL> SELECT xmltransform(dbms_qopatch.get_opatch_lsinventory(), dbms_qopatch.get_opatch_xslt()) FROM dual; Patch 12345678 : applied on Fri Sep 13 05:52:28 PDT 2013 Unique Patch ID: 16709411 Created on 29 Aug 2013, 08:39:18 hrs PST8PDT Bugs fixed: 17330580 Files Touched: ...
33. Queryable Patch InventoryDetailed Examples Get detailed examples of how to: compare patch levels on different RAC nodes in a clustered database compare patch levels of one database with another (leverage notion of a “Gold Image”) see My Oracle Support Note: Database 12c Post Patch SQL Automation (Doc ID 1585822.1) See My Oracle Support Note: SQL Interface to compare, validate database patches(Doc ID 1585814.1)
34. Deployment Automation Pre and Post 12c Patches with both Binary and SQL Changes Apply software bits using standard OPatch Restart DB and call datapatch to complete post install actions (EM/ OPatchAuto does it automatically) Restart DB and manually complete post install actions datapatch automatically detects and completes post install actions SQL datapatch SQL
35. Deployment Automation – Patches with SQL Datapatch is the new tool that enables this automation for database patches Determines the requisite apply/rollback actions based on the SQL and OPatch registries Ensures that the binary portion of a patch has been completely installed on all RAC nodes before initiating any post patch actions on the database EM and OPatchAuto call datapatch automatically during every patching session For 11.2 databases, EM and OPatchAuto will also automatically apply post SQL steps, but without datapatch For a multitenant database environment, datapatch will patch the root, seed, and any pluggable databases that are open
36. Multitenant for Simplified Patching Oracle Multitenant provides a new paradigm for rapid patching Simplifies and speeds up patching process by eliminating the need to apply patches to each individual database patching one multitenant container database results in patching all of its many pluggable databases Provides the flexibility to perform selective patching among all pluggable databases in a container patch only single pluggable database in any container, simply unplug/plug to a multitenant container database at a different Oracle database patch level
37. Multitenant for Simplified Patching Patching the Container Database Results in Patching all of its Pluggable Databases 12.X Shutdown Startup Patch Container Database 12.X 12.X 12.X 12.1 12.1 12.1 CRM CRM CRM 12.1 CRM CRM CRM ERP ERP ERP ERP ERP ERP ERP ERP ERP Multitenant Container Database Multitenant Container Database Multitenant Container Database
38. Multitenant for Flexible Patching Selective Patching among all Pluggable Databases in a Container Patch Container Database 12.X 12.1 12.X 12.1 DW DW CRM CRM 12.1 ERP Patched Container Database (12.1.0.1 + Patches) Original Container Database (12.1.0.1)
39. Multitenant for Simplified Patching Oracle Multitenant leverages the Queryable Patch Inventory for checking patch level compatibility when plugging in a pluggable database into a container database SQL patches have to be run against individual plugged in databases, but no separate steps are needed for binary patches datapatch takes care of this step automatically The first patch set release of DB 12.1 will be upgradable in a similar manner
40. What's your turnkey patching solution?
41. Summary Highlights Standardize on set of tests to run based on patch type leverage your knowledge of Oracle maintenance processes Be proactive regularly apply PSU’s, BP’s to avoid known problems choose your database releases according to supportability and business needs Familiarize yourself with options for patching in a highly available manner Database 12c offers many improvements in simplifying patching. Explore them now!
42. References Lifetime Support Policy http://www.oracle.com/us/support/lifetime-support/index.html Error Correction Database, FMW, EM Grid Control, and OCS Software Error Correction Support Policy (Doc ID 209768.1) Patch Set Updates and Bundle Patches Patch Set Updates for Oracle Products (Doc ID 854428.1) Database Machine and Exadata Storage Server 11g Release 2 (11.2) Supported Versions (Doc ID 888828.1) Composite Patches for Oracle Products (Doc ID 1376691.1) Queryable Patch Inventory Oracle Database PL/SQL Packages and Types Reference Deployment Automation for Patches with SQL changes Database 12c Post Patch SQL Automation (Doc ID 1585822.1)