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_at_cadre5.com wrote:

> Also, you using the table compression feature helps if you are low on free
> space...
>
>
> On 4/29/05, daniel.hubler_at_aurora.org <daniel.hubler_at_aurora.org> 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