# Oracle EBS Critical Patch Update (CPU) Patching Effort Calculator

> Source: https://netray.co/tools/oracle-ebs-critical-patch-update-annual-effort-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate the annual hours, cost and production downtime of applying Oracle CPU patches to EBS, by cycle frequency and number of environments.

## Category

oracle

## Erp

Oracle E-Business Suite

## Audience

- Apps DBA
- Security manager
- IT operations manager

## Tool

**Kind:** calculator

**Currency:** $

**Inputs:**

#### CPU cycles applied per year

**Key:** cycles

**Type:** select

**Default:** 4

**Options:**

##### Every quarter (4)

**Value:** 4

##### Semi-annual (2)

**Value:** 2

##### Annual (1)

**Value:** 1

#### Environments patched per cycle

**Key:** envs

**Type:** number

**Default:** 4

**Min:** 1

**Step:** 1

#### Analysis hours per cycle (ETCC, readmes, conflict check)

**Key:** analysis

**Type:** number

**Default:** 8

**Min:** 0

**Step:** 1

**Unit:** h

#### DBA apply hours per environment

**Key:** apply

**Type:** number

**Default:** 6

**Min:** 0

**Step:** 0.5

**Unit:** h

#### Regression test hours per cycle

**Key:** test

**Type:** number

**Default:** 40

**Min:** 0

**Step:** 4

**Unit:** h

#### Database tier patch (RU / OJVM) included

**Key:** db_flag

**Type:** select

**Default:** 1

**Options:**

##### Yes

**Value:** 1

##### No

**Value:** 0

#### Database patch hours per environment

**Key:** db_hours

**Type:** number

**Default:** 4

**Min:** 0

**Step:** 0.5

**Unit:** h

#### Production downtime per cycle

**Key:** downtime

**Type:** number

**Default:** 60

**Min:** 0

**Step:** 15

**Unit:** min

#### Blended hourly rate

**Key:** rate

**Type:** number

**Default:** 90

**Min:** 0

**Step:** 5

**Unit:** $/h

#### Staff available for regression testing

**Key:** staff

**Type:** number

**Default:** 1

**Min:** 1

**Step:** 1

**Help:** Informational: used to show elapsed test days per cycle.

**Outputs:**

#### Hours per cycle

**Key:** hours_per_cycle

**Expr:** analysis + envs * (apply + db_flag * db_hours) + test

**Format:** hours

#### Annual patching hours

**Key:** annual_hours

**Expr:** cycles * hours_per_cycle

**Format:** hours

**Primary:** true

#### Annual cost

**Key:** annual_cost

**Expr:** annual_hours * rate

**Format:** currency

#### Annual production downtime

**Key:** annual_downtime_hours

**Expr:** cycles * downtime / 60

**Format:** hours

#### Elapsed regression test days per cycle

**Key:** test_days

**Expr:** test / (staff * 8)

**Format:** days

#### Extra months a fix can wait vs quarterly

**Key:** months_behind

**Expr:** 12 / cycles - 3

**Format:** months

**Description:** How much longer, at most, a released security fix waits compared with applying every quarter.

**Chart:**

#### Annual patching hours vs environments

**Type:** bar

**X:** envs

**From:** 1

**To:** 8

**Steps:** 8

**Series:**

- annual_hours

**Disclaimer:** Hour defaults are planning assumptions. Actual effort depends on the CPU content for each quarter, your database and technology stack versions and your test scope.

## Content

**Intro:** This calculator estimates the yearly hours, cost and production downtime of applying Oracle Critical Patch Updates to Oracle E-Business Suite across all environments. It covers analysis, application tier and optional database tier patching, and regression testing per cycle.

**Sections:**

#### The CPU schedule and what each cycle involves

**Body:** Oracle releases Critical Patch Updates quarterly, on the third Tuesday of January, April, July and October, and publishes the schedule and advisories on its security alerts page. For EBS, each cycle typically means reading the EBS CPU availability document for that quarter, identifying the EBS product patches plus technology stack patches (WebLogic, Fusion Middleware, Forms and Reports, Java) and the database Release Update and OJVM patches, then applying them from non-production through to production. On 12.2 the application patches are applied with adop in an online patching cycle, so most of the work happens while users are working and downtime is limited to the cutover. On 12.1 you apply with adpatch during downtime.

#### How to use it

**Body:** Pick how often you actually apply CPUs, not your policy. Enter the environments you patch each cycle (usually dev, test, UAT and production). Analysis time covers running the EBS Technology Codelevel Checker, reading readmes and checking for conflicts with existing one-off patches. Apply hours are DBA time per environment for the application tier; add database tier hours if you apply the database RU and OJVM patch in the same cycle. Regression test hours are business and IT test time per cycle. The months-behind output shows the extra exposure a slower cadence creates.

**Bullets:**

- Hours per cycle = analysis + environments x (apply + DB flag x DB hours) + test
- Annual hours = cycles x hours per cycle
- Annual downtime = cycles x downtime minutes / 60

#### Checking code levels with ETCC

**Body:** The EBS Technology Codelevel Checker (ETCC), described in My Oracle Support Doc ID 1594274.1, has two scripts. checkDBpatch.sh runs on the database tier and reports missing database bug fixes required for EBS; checkMTpatch.sh runs on the application (middle) tier and reports missing technology stack fixes. Download the latest ETCC each cycle, because its patch list is updated as new fixes are required. Record the ETCC output as part of the change record for audit.

#### Worked example and the cost of skipping cycles

**Body:** With the defaults, one cycle is 8 + 4 x (6 + 4) + 40 = 88 hours, so quarterly patching is 352 hours a year, about 31,700 at 90 per hour, with 4 hours of production downtime. Moving to semi-annual halves the hours but each cycle usually gets bigger, conflicts multiply, and a fix can wait up to 3 months longer. Teams that skip cycles often find the next CPU requires a newer AD/TXK or database RU level first, which turns a routine cycle into a project. Automating regression tests is the biggest lever on the annual total.

**Cta:** If you want an assistant that reads your ETCC output, patch inventory and CPU documents on your own servers and drafts the cycle plan, we can set that up.

**Faq:**

#### When does Oracle release Critical Patch Updates?

**Answer:** Quarterly, on the third Tuesday of January, April, July and October. Oracle publishes the dates of upcoming CPUs and the advisories on its security alerts page. EBS-specific patch lists for each CPU are in the EBS CPU availability document on My Oracle Support.

#### How do I apply EBS CPU patches on 12.2?

**Answer:** Run ETCC and apply any required technology fixes, then apply the EBS CPU patches with adop through a full online patching cycle: prepare, apply, finalize, cutover and cleanup. Users keep working until cutover. Apply database tier patches separately per their readmes, which usually needs database downtime.

#### What is ETCC in Oracle EBS?

**Answer:** The EBS Technology Codelevel Checker, documented in Doc ID 1594274.1. checkDBpatch.sh checks the database tier and checkMTpatch.sh checks the middle tier for bug fixes EBS requires. Download a fresh copy each cycle, as the required patch list changes.

#### Is it acceptable to apply CPUs only once or twice a year?

**Answer:** Oracle recommends applying CPUs as soon as possible. A slower cadence leaves known vulnerabilities open longer and makes each cycle larger and riskier because prerequisites accumulate. If you patch less often, document the risk acceptance and track critical CVEs that may need out-of-cycle action.

## Search terms

oracle ebs cpu patches, oracle ebs critical patch update, oracle ebs security patches, oracle ebs patch management, oracle ebs patching process, etcc checkmtpatch checkdbpatch, ebs cpu patching effort

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json