Re: Sizing Locally Managed Tablespace

ronnie_yours_at_yahoo.com (Ronnie) wrote in message news:<ea603f8d.0401061245.74c60517_at_posting.google.com>...
> Hi,
>
> We have a database on which I am planning to create a Locally Managed
> Tablespace. The Tables/objects in this table space will be dropped
> nightly and fresh data imported using the import utility from our
> internal databases.

Do you mean the transportable option?

>
> The reason we are doing this is because we want 2 databases one
> internal and one external. Internal database being the one where our
> employees enter the data and external databaseis the one which our
> clients access.
>
> This particular application in question needs to be available to our
> clients hence this export import.
>
> Now my question?
>
> This is a small application. Around 3 Gigs of data in 3 datafiles. It
> consists of tables of various sizes a lot being small lookup tables
> and some 1 which has over a million rows.
>
> How should I size my LMT on my external database to get the best
> performance and optimal storage.

You might consider dividing the tables up by their function (ie, static lookup tables, volatile transaction tables, big momma data tables), and give each function its own tablespace.

Then, how you are going to access these tables.

Autoallocate will make some varying extent sizes on your big tables, that doesn't seem to matter much operationally, but is easier to administer on an existing system that has tables with varying needs.

Run a google search on this newsgroup for the words LMT extent size.

>
> Thanks
> Ron

jg

--
@home.com is bogus.
http://www.securityfocus.com/archive/1/348692