FW: Statspack consolidation

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

--
http://www.freelists.org/webpage/oracle-l

Other related posts: