Re: partitioning tables

You're on the right track. You can make copies of the datafiles after the tablespace is made READ ONLY, then skip any READ ONLY tablespaces during your backup (as long as the tape for the READ ONLY tablespaces doesn't disappear or get corrupted).

Another question: Is the history data SELECTed from? If the data is solely there for history purposes and is rarely read from, then you may keep the READ ONLY datafiles on the same mount point as your heavy I/O datafiles if you wish.

You will probably want to dynamicaly script the quarterlies, using a test database.

shaunak wrote in message <3881C51B.3B128055_at_speedlink.com.au>...
>hi
>
>i am implementing an application that has 50 tables of which only 5 grow
>at a good rate 5GB/month the rest grow insignificantly. I have been
>considering partitioning
>the large growing tables to keep the backups smaller and faster. My data
>is all history data (unchangable) and i can make the older partitions
>readonly to avoid backing up.
>
>At present i have a common tablespace called USER_APPS for all the
>tables.
>
>i want your expert opinion on
>
>1. would it be simpler to partition all the tables and create a new
>tablespace for all new table partitions in every quarter. I get a good
>24 hour down time every quarter.
>
> or
>
>2. should i keep all the slow growing tables unpartitioned in a single
>Tablespace called SLOW_GROW. The fast growing tables can be partitioned
>and kept in series
>of tablespaces called FAST_2000_Q1, FAST_2000_Q2.....
>
>
>thanks in advance
>
>
>butun
>
>
Received on Sat Jan 15 2000 - 09:16:03 CST