Create Database with Size forecasted for 3 Months or 3 Years?

News
Services
Products
Whitepapers

Create Database with Size forecasted for 3 Months or3 Years?

Create database with Size forecasted for 3 Months or 3 Years?

- A discussion of several aspects

This topic is relevant for for databases which start with initially small size but grow within 1 to 3 years to hundreds of Gigabytes or Terra bytes.

This graphic illustrates a typical scenario: During the first years the customer base is growing fast, and as archiving of transaction history starts after 12 months, the disk space allocation growth x-square duing first year.

Afer 12 months, when transaction archiving is in place and all transactions older than 12 months are archived, the grows significantly reduces.

The 2 green lines indicate database size after 3 and 6 months.

It is obvious, that the size is magnitudes smaller than the size estimated after 1 year and 3 years.

As managing (cloning, backup, restore-tests) a small database is easier and faster than managing the fully-sized database, the idea to install the database with initially small size is obvious.

The following table provides pro- and contra arguments.

Utilizing “autoextend” feature allowing database files to grow on demand, is only an alternative

if this feature and the associated constraints are fully understood,

space-monitoring is configured to support this feature,

and escalation plans / on-call hours of the potential different teams managing file systems and database files have been adjusted for this feature.

Argument

Topic

Description

Pro 3 Years

Maturity

Allocating only space for 3 Months bears – dependent on culture within an organization – the risk, that the remaining space on the shared storage (SAN), purchased by the project but not used, is assigned to another project - and not available any more when the disk space is required to extend the database.

Pro 3 Years

Maturity

If you are application vendor and you had to size the system for 3 years, the decision depends on the maturity of your customers organization: For sure you want to avoid getting blamed by your customer for “wrong installation” because the customer's monitoring system did not monitor used / free database space, or the DBA ignored the space warnings and did not add data files.

Pro 3 / 6 Months

Initializing DR-Protection

The file transfer volume to remote data centre is much smaller.

Pro 3 / 6 Months

Database cloning

For the case that you (more likely in early project phases / short after going live) want an additional (cold) backup or clone before applying an urgent hot-fix, the backup or cloning duration will be much shorter if the data files are small, compared to 3-year volume.

Pro 3 / 6 Months

Backup Duration

Dependent on database system, database version, backup method

either a) only the used space within data files (up to a “High Water Mark”) is backed up,
or b) the complete data file, even if 95% empty.

In case b)

backup volume will be much smaller,
backup duration will be much shorter and
slow down of disks / io-system will be reduced to this shorter time.

Pro 3 / 6 Months

Backup Costs

In case of b) you will shorten your backup duration and backup costs for the first year(s), until database reached it's full size and archiving has been initiated such that that size will remain constant. If your department / cost centre benefits from that, depends on the company internal charging model, which might not exist. (ISO 20000 Part I requires mandatory costing, but leaves company internal charging as optional in Part II)

Pro 3 / 6 Months

Faster Restore and Recovery Tests

Restore and Recovery tests – an absolute necessity before going live! – will be much shorter.

The disk space required for those tests will be much smaller.