OracleFree calculatorPDF, Excel, Word exportOracle E-Business Suite

Oracle EBS Database Growth Forecast Calculator

Storage requests for an EBS database need a number, not a feeling. This calculator turns your current size, growth rate and planned purge into a size forecast and a months-until-full estimate.

Your numbers

GB

Allocated or used size, be consistent with the capacity figure below.

% per month

Compound monthly growth, measured from at least six months of history.

% of size

Space you expect to reclaim from purges such as Purge Concurrent Request and/or Manager Data.

GB

Usable capacity of the volume or ASM disk group.

36 months

Your results

Size at horizon (GB)
1,751.43
Months until capacity is reached
41.4 months
Shows 0 when growth is zero or capacity is already exceeded.
Size after purge
720
Headroom at horizon (GB)
248.57
Negative means you run out of space before the horizon.

Compound growth is a simplification. Month-end close, upgrades and new modules change the slope. Re-fit the growth rate from recent history every quarter.

Save results:

Projected database size (GB) over time

Sweeps Forecast horizon from 1 to 60, holding your other inputs fixed.

Growth driver review

Optionally share table size summaries and we will help identify which modules and logs drive your growth.

Optional. The tool and every export work without this. No spam.

How to use it

Enter current size and capacity in the same unit and basis, either allocated or used. Estimate monthly growth from history, for example size at the start of the year and now, then solve the monthly rate as (end / start) to the power of 1/months, minus 1. Add the percentage you expect to reclaim from a purge program, then slide the horizon. The chart shows the projected size over the full 60 months so you can see when it crosses your storage line.

  • Use at least six months of history to include a month-end and quarter-end cycle.
  • Run the tool with and without the purge to quantify its value.
  • Use growth of the database, not of backups, unless you size both together.

The formula

Size after n months is S times (1 + g) to the power of n, where S is the post-purge size and g the monthly growth rate. Months until capacity C is reached is ln(C / S) divided by ln(1 + g). A purge reduces S once and moves the whole curve down, but it does not change the slope, so the effect is a fixed delay of ln(1 / (1 - p)) / ln(1 + g) months. At 2.5% monthly growth a 10% reclaim buys about 4 months.

Where EBS data grows and what to purge

In most EBS systems the large consumers are FND_CONCURRENT_REQUESTS and its logs and output files, workflow tables such as WF_ITEM_ACTIVITY_STATUSES, GL and subledger accounting tables, and attachments in FND_LOBS. Standard purge programs include Purge Concurrent Request and/or Manager Data and Purge Obsolete Workflow Runtime Data. Check Oracle Support guidance for your release before running purges in production, and take a backup first.

  • Output and log files on the file system do not count toward database size.
  • Archiving subledger data needs functional sign-off, not just a DBA decision.
  • Add growth for planned acquisitions or new modules as a step, not a slope.

Frequently Asked Questions

Is compound growth right for EBS?

It fits most transactional systems over a one to three year view, but real growth is lumpy around closes and upgrades. Use the result as a planning range and refit the monthly rate from the latest quarter of data.

Should I include archive logs and backups?

Only if the capacity you enter covers them. Size the database and the backup or archive destination separately, with their own growth and retention assumptions, for a clean answer.

How do I calculate monthly growth from history?

Divide the latest size by the size n months ago, raise to the power of 1 divided by n, and subtract 1. For example, 650 GB growing to 800 GB over 8 months gives about 2.6% per month.

Does a purge fix the growth problem?

A purge reclaims space once and delays the date you run out by a fixed number of months. It does not slow growth. Lasting control needs retention policies, archiving and scheduled purges.

If you want growth by tablespace and schema trended automatically from your own database and explained to your finance and infrastructure teams, we can build that on-prem.