Oracle 10g, Linux 386, Cooked files

I need to calculate/estimate how much disk space a database will use.
What would be best: Create the database add data, check size, add data
and check size and use the difference to estimate how much the database
will increase over time OR calculate how much space each row in each
table will use and then use this data to estimate the size?

If the first, about how much data do I need to load to get numbers that
are more or less reliable? If the latter, eh, how exactly is that done?

I assume that I need to sum the bytes each column uses for a row, and
it seems that the characterset matters for chars and varchars. That
would be the easy part. Then there is probably some overhead. And for
the indexes I really don't have a clue. Oracle leaves space empty to
let rows grow. What more to consider?

There doesn't seem to exist documentation on how to proceed with this.

Thanks for your time,
ph

"PHernandez" <phph109@yahoo.es> wrote in message
news:1117567148.413604.234540@g47g2000cwa.googlegr oups.com...
> Oracle 10g, Linux 386, Cooked files
>
> I need to calculate/estimate how much disk space a database will use.
> What would be best: Create the database add data, check size, add data
> and check size and use the difference to estimate how much the database
> will increase over time OR calculate how much space each row in each
> table will use and then use this data to estimate the size?
>
> If the first, about how much data do I need to load to get numbers that
> are more or less reliable? If the latter, eh, how exactly is that done?
>
> I assume that I need to sum the bytes each column uses for a row, and
> it seems that the characterset matters for chars and varchars. That
> would be the easy part. Then there is probably some overhead. And for
> the indexes I really don't have a clue. Oracle leaves space empty to
> let rows grow. What more to consider?
>
> There doesn't seem to exist documentation on how to proceed with this.
>
> Thanks for your time,
> ph
>

I would do it the first way, use volumetrics from the analysis phase to help
you populate the db, build your indexes, analyze and then test, When it is
acceptable in terms of performance scale the sizes upwards.

The size estimate for a complete database has to include more than just
the data; it must include the overhead necessary to support SYSTEM,
SYSAUX, TEMP, and UNDO. The TEMP and UNDO tablespaces can require a
lot of space depending on how the application works, activity levels,
and how far back in time it is desired to be able to flashback a query.

The size estimate for the database then has to be then more than
doubled to support Oracle's recommendation for a flashback database
area (10g), if you plan to use this feature.

You can make the estimates without building a database if you have a
decent idea of the amount of data, number of tables, and number of
indexes. There have been numerous posts in the past on how to estimate
the size of a table. The big problem is that development often has no
idea how big the application is going to be!

Note that the total space consumed by indexes has a tendency in the
OLTP world to just about equal the total space consumed by tables as
applications grow in number of tables. In another environment I have
the data is 3/4 the size of the indexes (part OLTP and part SPC
system).

HTH -- Mark D Powell --