Re: Storage Parameters defined on tablespaces

For small tables it's not the big problem with using default storage parameters. But if you have small and big tables you can have 2 wrong situation. You have to big storage paramaters for small tables, and many empty space in database, or to small storage parameters for big tables. This second situation have strong impact on performace eg. default 10K extent for table with size 100MB means that this table can has 10000 (depends on PCTFREE, PCTUSED) extents (very very bad and slow). The best idea is to have always storage definitions with table definition. Lets talk with your developers. Depends on project they shoul know correct storage parameters for all tables. I'm always using table definition with storage definition.

Regards

Rafal Czekala (czekala_at_real.pl)
Oracle DBA

In article <37A61AB4.E5A077FC_at_yahoo.com>,   sh <sh_at_yahoo.com> wrote:
> A quick question in regards to tablesapce storage parameters.
> Is it not "best practice" to define storage parameters at the
tablespace
> level, particularly when a developer does not do so at the table
level?
> We have a new database going into production soon, and I am
identifying
> the storage parameters based upon table sizes seen on the development
> machine.
>
> I know that some smaller tables could take up the same storage
parameter
> of a larger table because of this, but it seems better than leaving
the
> storage parms at
> the default.
>
> thanks.
>
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Tue Aug 03 1999 - 07:22:32 CDT