MSAMM
Back to course

Oracle Apps DBA: Keeping E-Business Suite Alive · Module 7 · Patching

Why you are patching at all

Lesson 68 of 184 · 3 min

Security, a bug you have hit, a prerequisite for something else, or a support requirement. THE REASON DETERMINES THE URGENCY AND THE RISK YOU SHOULD ACCEPT. Patching is the largest single cause of self-inflicted outages, so the first question is always whether this patch is worth its risk — and the answer comes from why you are applying it. A SECURITY PATCH HAS A DEADLINE SET BY SOMEBODY ELSE. The vulnerability is published, the exposure is real, and deferring it is a decision with a growing cost. This is the category where you accept more risk and a shorter test cycle, because the alternative is not "no change", it is "a known hole". A BUG YOU HAVE ACTUALLY HIT IS THE EASIEST CASE TO JUSTIFY AND THE EASIEST TO TEST. You know the symptom, so you can verify the fix — reproduce it before, confirm it is gone after. That…

The full lesson is part of the course

The video, the complete written lesson and the module quiz are included in Oracle Apps DBA: Keeping E-Business Suite Alive, with a certificate on completion and a fourteen-day refund window.

See the course and enrol9 free lessons

Get the free lessons by email

We will email you a link to every free lesson in this course. No account needed, and one message only.

In this module: Module 7 · Patching

  1. 1Why you are patching at all
  2. 2Kinds of patch, and what each touches
  3. 3Reading a readme properly
  4. 4Online patching: the model
  5. 5The adop cycle, phase by phaseFree preview
  6. 6When a phase fails
  7. 7Abandoning and cleaning up
  8. 8Rollback: what is actually reversible
  9. 9Patching the database tier
  10. 10Testing a patch before production
  11. 11The outage plan
  12. 12Patching cadence, and falling behind
  13. 13What breaks: five patching failures
  14. 14Lab briefing · Apply, fail, abandon, apply again