RE: Centralized StatsPack RepositoryRaj

I did this sometime back but later on somehow this went on to the backburner.. (I also had half-developed XL based interface to the central statspack data)

In the central repository create the set of tables that statspack uses to store data under user "central". Create individual schema's with different instance names (that you want monitored). Under each of the schemas

create a db link with a dba user to the database that this schema monitors
create private synonyms for all of the v$, dba* views that statspack queries using db links created above (create synonym v$session for sys.v$session_at_target_db)
create private synonyms for all of the statspack tables to point to the "central" schema

Now when you schedule statspack.snap it will read from the target db and insert data into the "central" user...


Original Message -----
From: Jamadagni, Rajendra
To: Multiple recipients of list ORACLE-L
Sent: Friday, January 03, 2003 10:08 AM
Subject: RE: Centralized StatsPack Repository

Hmmm... FAGC ??

Jared, I am stumped ... I can't put these 2 & 2 together. I was planning on a new instance called "dbmon". One schema for each production database instance. Statspack will be installed for each schema and other monitoring scripts that we use internally.

I am thinking of best ways to propogate datasets from individual databases to this central db.

Could you explain more about (your idea on) how FAGC would be useful??

Thanks in advance

Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is an art!

-----Original Message-----
From: Jared.Still_at_radisys.com
Sent: Thursday, January 02, 2003 8:03 PM
To: ORACLE-L_at_fatcity.com
Cc: Jamadagni, Rajendra
Subject: RE: Centralized StatsPack Repository
Importance: High

Have you considered FGAC? ( fine grained access control )

I haven't tried it, but it seems like a good candidate for
centralizing stats pack data with as little code as possible.


Please see the official ORACLE-L FAQ: http://www.orafaq.net
Author: Babu Nagarajan
INET: orclbabu_at_hotmail.com

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services

To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 10 | next ›
Discussion Overview
grouporacle-l @
postedJan 2, '03 at 6:14p
activeJan 3, '03 at 6:28p



site design / logo © 2022 Grokbase