Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Database Sizing

Status
Not open for further replies.

totti24

Programmer
Aug 2, 2002
32
MY
hi guys,
this is the first time i'm posting a question regarding Oracle9i. i need help about database sizing?

can i know how am i suppose to estimate the size of my so-called "future database"?? i don know what my table are yet therefore i can calculate any data blocks. all i have is the number of records. issit possible to calculate the size based on the number of records?

please advice... thanks in advance
 
Possible, but in your case rather pointless.

There will be overhead for the number of tables / indexes etc that you create and if you don't know the details yet there is no way you are going to get a sensible estimate.

Alex

 
Totti, I totally agree with Alex: Until you have more details, it's rather like asking a building contractor to estimate the square footage of a house if you know the number of bedrooms there will be. Ken Behring's 4 bedroom home is 30,000 square feet; my 6-bedroom home is only about 2,200 square feet. So it obviously depends.

Given the "it-depends" disclaimer, we can suggest some sort of estimates once we obtain answers to some preliminary questions:
1) who is asking for the estimate?
2) why do they want to know? (Is it for preliminary hardware-cost estimate, et cetera?)
3) how close to "actual" do they expect your "estimate" to be?
4) what are the business risks (including your job) if your estimate is off by +/- 10%? 50%? 100%? 1000%?
5) what applications, current and future, will reside on the database?
6) what growth factors do you expect for the applications?
7) what is the size of the database(s) that house those applications currently? (Either in-house or comparable figures from industrial publications, users' groups, competitors, et cetera might help.)

Armed with answers to those preliminary questions, you can start modelling some size estimates.

I would avoid the "estimating game" if the ones wanting the estimates are unable to provide details. Whenever I find myself in that position, I respond, "Without additional details, I estimate the database will be 100GB, +/- 80GB." Usually they get the idea.

You mentioned you know the number of rows (one dimension) with which you will be dealing. If you don't yet know the second dimension, the attributes (columns), and their average sizes, then it would be like asking the area of a trapezoid, given the length of one side.

Once you know the attributes (with their average sizes), we can then contribute more to your solution.

Cheers,

Dave
 
one thing to keep in mind, it is far more important to have enought bandwidth to your data that to have just enough room for your data.

fastest Oracle database I ever had was 120 1 gig drives, much faster than 6 36 gig drives

120 * 10 meg/second = 1200 meg/second

6 * 40 meg/second = 240 meg second

I tried to remain child-like, all I acheived was childish.
 

i also totally agree with u guys. actually we are in the process of bidding for a project. the reason y they are asking me to do the database size estimation is to know what kind of hardware setup is required for the database server, such as HD, RAM and no of processors. another word for it is hardware costing..... they said they don want to oversize or undersize it. what the hell, by only knowing the number of existing records, i also don know how to do the estimation. and the estimation proposed should be 5 years in advance.

i've gone thru some websites to seek some info. the sample estimation are done when the tables and indexes are already exist. since it's estimated till the field n table level. but for my case it's from the no of record. i also c it is pointless t odo such an estimation coz it wouldn't bring me to anywhere. since the size might differs alot. anyway, thanks for the advice guys.
 
Totti, You CAN do an effective, reliable estimate on database size IF you possess a management-reviewed and management-approved database design. (The main deliverable in an industrial-strength database design is an Entity-Relationship Diagram (ERD).) At that point, you do not need one table or index actually created, yet with the ERD and your "row estimates", you can derive a reliable database size estimate. Until you have an approved database design, don't become responsible for a database sizing estimate.

If I am an astute customer, I would reject any bid for a project if the bidders do not have at least a preliminary database design. Since the database design is the blueprint for a relational-database application, trying to produce a reliable database-size estimate is, again, like expecting a building contractor to produce a reliable cost estimate to build a home without any blueprints. Such an estimate results in GUARANTEED cost overruns.

Potential clients that have become wise through (bad) experience universally accept "Phased Estimates". This means they entertain bids for Phase I: Database/Application Design, award the bid for that phase, and conduct/produce the Database/Application Design. Once the Design is complete, they put out the rest of the project for bid, allowing potential bidders to produce estimates/bids based upon known facts instead of blue sky estimates that eventually cause project budget failure for either the contractor or the customer.

The best service that you and/or competitors can do for your potential customer is to help them first locate professional design assistance to produce (for time and materials) a reliable Design, then bid the rest of the project.

Cheers,

Dave
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top