RE: Statspack consolidation
- From: "Vlado Barun" <vlado@xxxxxxxxxx>
- To: <bdbafh@xxxxxxxxx>, <daniel.hubler@xxxxxxxxxx>
- Date: Fri, 29 Apr 2005 14:06:43 -0400
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@xxxxxxxxxx
AIM: vbarun2
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Paul Drake
Sent: Friday, April 29, 2005 12:55 PM
To: daniel.hubler@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Statspack consolidation
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.
>=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.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
