Could the moderator please put this in the dbasupport.com's technical docs/tools utilities part of the site. That way we all can download it when we want and we could be sparred from being spammed with all the exposed e-mail addresses.
There was no magic sheet on capacity planning as you believed. It is an estimation.
Capacity planning will only work for approximately 60%. Each table in the database requires different type of storage clause. Last week I was testing a table's storage space by changing different value for INITRAN parameter. I was surprised by the outcome. The rest of storage clause parameters are not changed. Number of rows inserted is 10000. Data block size 8K.
Number of blocks used for 10000 rows - 155
Number of blocks used for 10000 rows - 165
Number of blocks used for 10000 rows - 175
In every case the same data was inserted in the table. But I got different results just by changing only one parameter.
Then you can imagine by changing PCTFREE, PCTUSED etc values, how the storage space is going to be.
Today, hardware price is cheap. I can buy 60 GB disk for the price of 6 GB Disk what I paid 3 years ago.
DO NOT WASTE MUCH TIME ON CAPACITY PLANNING.
Shouldn't your findings be of concern to those who deal in 10**6 records ?
I think this directly affects segment growth rates which in turn determines the backup and recovery and segment management (like index rebuilds etc...) techniques implemented by the DBA.
So any space management techniques that can be exploited in the physical d/b design should be thoroughly researched, and your findings are a perfect example of that.
It would be interesting for someone with the tools and detemination (may be it already exists) to generate excel graphs that would display the relation ship of the # of rows,block size, pctfree, pctused, initran, etc.. (other segment size parameters) on segment growth.
Am I thinking correct here ? I am new to d/b management so this kind of information goes a long way.
Always use Average Row Size obtained from DBA_TABLES or used blocks to figure out the table size.
In a transaction environment, each row size in a transaction table differs from other. As I said earlier there is no way you can calculate the exact space requirement for a table. It is only approximation.
My point is simple. Hard disk's price is cheaper. Only you need to ensure that your box has more room for adding more disks.