I did not see any answers to this question so I thought I would give it a
shot.
1. DBMS systems almost always cost additional capacity.
2. The wide deployment of DBMS systems is a good indication that the
benefits out way the total costs, one such cost is capacity requirements.
That being said we will now focus on the capacity cost.
I also assume you are considering the deployment of a relational DBMS where
no DBMS was before ... This makes a big difference replacing one DBMS with
another has entirely different considerations than adding one.
Memory.
Over the years the first exploiters of architecture changes to allow more
address spaces, more real memory, and more virtual memory have always been
DBMS systems. At this time I would suggest allocating at least 2 gig of
additional real memory to your future DBMS. DBMS system address spaces in
general are intolerant of paging. This is because a page in results in a
wait for the entire address space and to make things worse DBMS address
spaces serve many concurrent users.
CPU.
I assume from your question you have a good grasp on your current capacity
issues and are asking how a DBMS will impact future capacity issues.
Estimate the CPU requirements for today's requests to access methods or
media manager to quadruple. Now an I/O is an I/O so there is no gross
adjustment in cost here, however the following is quite expensive.
Classic I/O CPU requirements
CPU call analysis
CPU for block level or row level locking
CPU for logging / recovery
CPU for data growth due to the relation model (to be discussed
below)
Call analysis and locking each increase CPU by an additional 1x. The
remainder may be somewhat less each.
DASD Storage
Relational objects costs space.
Consider this classic example
Key 10 bytes
Jan Total 10 bytes
Feb Total 10 bytes
...
Dec Total 10 bytes
Total 130 bytes
One standard normalization rule is no repeating groups so relationally we
get
Key1 10 Bytes
Month Key 3 Bytes
Total 10 Bytes
23 bytes per month * 12 276 bytes (Plus 12 observations indexed instead
of one)
I/O increases ....
Consider our original monthly total example again, For the key we might
actually have all of the following potential key values:
Customer Name 50 bytes
Customer Number 10 bytes
Tax ID 10 bytes
For various reasons (one being very high DASD expense) we do not want to
carry all this extra alternate key data with every replicated observation.
So what we do is create reference tables like one containing
Customer Number and Customer Name
Now we can have a query like
Select a.CustNo, b.CustName, a.Total
>From Monthly_Total a,
Name_Ref b
Where a.Month_Key = 'Jan' and
b.CustName = ?inputed value? And
b.CustNo = a.CustNo
This is called a join and it costs I/O and CPU, in the relational model, it
does save some DASD storage.
Hope I have given you a quick introduction to the capacity issues.
Please remember there is a very wide acceptance of DBMS and relational
technology. It does cost capacity but results in huge benefits in other
areas to many businesses.
Avram Friedman
-----Original Message-----
Does anyone have experience in starting a Relational Database and how
much Capacity it took to get started?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
