Re: Usual meaning of "size" of a database

Rick Denoire wrote:
>
> When you say that your DB is 100 GB in size, do you mean the sum of
> the sizes of all files (including perhaps the ones in the TEMP
> tablespace)?
>
> The way I calculate the size of a DB is to do a sum(bytes) over all
> segments of all tablespaces.
>
> But of course, one could do a fresh gathering of statistics and
> multiply the average size of rows times the number of rows and add for
> all indexes and tables. But this will ignore size of other kind of
> objects.
>
> So what is the usual method to report the size of a database,
> according to your experience?
>

What are you trying to accomplish?

I've found that it depends entirely on who your are talking to, or what you are trying to do. Frequently I've seen it this way:

When dealing with management (esp. trying to emphasize that you need a purchase req. for more disk space signed now!) use the actual space allocated to the tablespaces + the log files + software + anythng else even remotely related (but stick to numbers easily verified as related and used). The fact that tablespaces are only 35% full is irrelevant.;  

When talking to other DBAs, use the size of the allocated data extents but ignore system, undo/rollback, temp and index;

When talking to the press or someone else who you want to impress, use the sum of the unformatted disk capacities that contain any database & instance related information (don't forget swap is needed, so count that as well);

When trying to project what is actually happening so you can do appropriate space management, use the sum(bytes) as you indicated.