RE: Statspack consolidation

From: Herring Dave - dherri <Dave.Herring_at_acxiom.com>
Date: Sat, 30 Apr 2005 15:56:09 -0500
Message-ID: <7ED53A68952D3B4C9540B4EFA5C76E366218BF@CWYMSX04.Corp.Acxiom.net>

I'm considering this as well, as I've got 10-12 databases to monitor. Reasons? I'd like all the storage impact on one server instead of across 8 different ones. Not a huge amount, but with all data centralized I can account for it on its own (I plan on using the OEM repository). I also like the idea of running all from one database. Sure, I can log into the others to check info, but it seems to be an unnecessary step. Also, at times I've found that the snapshot job has either died or had other problems not caught, for various reasons, and instead of coming up with another job to monitor statspack snapshot jobs I could do that indirectly by the consolidation job via OEM.

Also, I'm not sold on the multiple schema idea. Almost all tables include DBID, which is unique, so I don't see why all but a handful of tables can't be inserted into off each database. Granted I haven't tested this out yet, but hope to do so soon.

Any flaws with that?

Dave
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Post, Ethan
> Sent: Friday, April 29, 2005 3:18 PM
> To: tim_at_evdbt.com; Oracle-L
> Subject: RE: Statspack consolidation
>
> OK, maybe I missed this but why are they doing this? What expected
> gains/reporting ability/monitoring ability etc...do they need to achieve
> by doing this? Or is this another way we DBA's find to waste time (I am
> guilty of this also), let's face it we love to tinker.
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman
> Sent: Friday, April 29, 2005 3:09 PM
> To: Oracle-L
> Subject: 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=3DTRUE.
>
> --
> http://www.freelists.org/webpage/oracle-l

The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. Thank You.

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

Received on Sat Apr 30 2005 - 17:00:42 CDT