FAQ
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...

Babu

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
Raj

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.

Jared

--
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

Previous

Related Discussions

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

People

Translate

site design / logo © 2022 Grokbase