Re: Managing Large tablespaces

Hi Steve,

Your question appears (?) to confuse tablespace sizes with data file sizes.

Note a tablespace can have many datafiles so there is no need to create one "mamma" big data file for the tablespace. In fact even if you could I would question it. Can you imagine having to restore one 40G data file in case of media recovery ? Can you image how much recovery might be required on such a large datafile ? Can you image the lack of flexibility performing hot backups as you must backup the large file in one go. It's much better to create a number of smaller data files (max limit of 2G is quite common, not just from some O/S limitations but from a practicality point of view as well). In your case 25 data files is not a huge number.

You only need really big data files on really really big DBs (in the many T byte range).

In summary, use a smaller number of data files for this tablespace and appreciate the flexibility (especially in backup/recovery situations) when/if they arise.

Good Luck

Richard

"Steve S" <stevens_at_coloradocustomware.com> wrote in message news:bafba412.0207121504.5e46de58_at_posting.google.com...
> We have a customer that will be deploying our application soon with a
> DB size of ~50 GB. The largest we have in production now is ~15 GB.
> We have data and indexes seperated into their respective tablespaces.
>
> What would be a recommendation for a size limit a 9i tablespace on
> Windows 2000? What kind of problems would a single 30 ro 40 GB file
> create?
>
> Thanks for any help!
>
> Steve
Received on Fri Jul 12 2002 - 21:47:43 CDT