| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Statspack consolidation
Also, you using the table compression feature helps if you are low on free
space...
Vlado Barun, M.Sc.
Senior Data Architect, Cadre5
www.cadre5.com
Office: 865 690 4442 Mobile: 865 335 7652 e-mail: vlado_at_cadre5.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Paul Drake
Sent: Friday, April 29, 2005 12:55 PM
To: daniel.hubler_at_aurora.org
Cc: oracle-l_at_freelists.org
Subject: Re: Statspack consolidation
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.
>=20
> Does anyone have any guidelines/comments/horror stories/direction to giv=
e
> on this idea?
>=20
> 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/im=
p.
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 tablespac= e.
I looked at this long ago, but then was cured of CTD so I never completed i= t.
Paul
--=20
#/etc/init.d/init.cssd stop
-- f=3Dma, divide by 1, convert to moles.
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Fri Apr 29 2005 - 14:11:30 CDT
 |
 |