MSAMM
Back to course

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

Patching cadence, and falling behind

Lesson 79 of 184 · 2 min

An estate three years behind is NOT THREE TIMES HARDER TO PATCH, it is A DIFFERENT PROJECT. How that happens and how to stop it. The cost of catching up is not linear, and understanding why is what makes the case for a cadence. A CURRENT ESTATE APPLIES ONE PATCH, ON A KNOWN LEVEL, WITH ONE SET OF PREREQUISITES. A three-year-old estate applies a chain, in order, each with its own prerequisites — and the intermediate levels may need their own testing. The prerequisite chain alone can be weeks. AND THE TESTING IS THE PART THAT BECOMES A PROJECT RATHER THAN A TASK. Three years of changes arrive at once, so the business test is not "did this patch break anything" but "does the whole system still work". That needs the business, at length, and it needs an environment that matches — which is Module 6, and the clone of…

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