Table compression can only help if you are using "direct-path" inserts. The standard STATSPACK package does "conventional" (i.e. not direct-path) inserts, as does the IMP utility, so data loaded from either would not compress. Table compression would only help if one was transferring data using INSERT /*+ APPEND */ selecting from a database link or loading data using SQLLDR DIRECT=TRUE. on 4/29/05 12:06 PM, Vlado Barun at vlado@xxxxxxxxxx wrote: > Also, you using the table compression feature helps if you are low on free > space... > > > On 4/29/05, daniel.hubler@xxxxxxxxxx <daniel.hubler@xxxxxxxxxx> wrote: >> We are contemplating creating a single Statpack database, on one >> server/instance, >> and pushing all of our Statspack data to it. This would probably include >> data from 7-8 instances. >> We are guessing that we are not the first to consider this. >> Does anyone have any guidelines/comments/horror stories/direction to give >> on this idea? >> >> Any thoughts appreciated! > > Approach it like supporting rman catalogs: > > one schema per supported version within the same database, e.g.: > perfstat817 > perfstat920 > perfstat101 > > you're going to have to disable constraints during import if you use exp/imp. > beware of using direct=3Dy with exp on 10.1.0.3 (bug). > > partitioning the larger tables would be an excellent idea. > perhaps you might even want to export the data as a transportable tablespace. > > I looked at this long ago, but then was cured of CTD so I never completed it. > > Paul -- //www.freelists.org/webpage/oracle-l