Hi Nandhita,
----- Original Message -----
> > -----Original Message-----
> > From: Nathan Scott [mailto:nathans@xxxxxxxxxx]
> > [...]
> > just the first 6. This patch applies to the PMDA code you sent through as
> > your first case (i.e. "1.pmdaoracle_mod_item.txt").
> >
>
> Thanks Nathan. Yes, it makes complete sense to use name -> item hash and I
> got it working.
Great!
> > It looks like there is also a problem in handling the instance domain
> > ($sid) in the
> > current pmdaoracle code; I've added a $sysstat_instances which I think will
> > be
> > needed too (we have to hold the instance names and the @values in there - a
> > similar change will be needed for all $sid_instances uses I suspect) into
> > that
>
> my $values =$sysstat_instances{$sid}; this returns undef, so I am getting
> error in @varray (line# 598). What is this statement supposed to do?
Oh it was attempting to setup an array reference associated with the sysstat
indom (similar to what you have returned from the cherrypick() routine) - so
that in the fetch callback, the values are neatly laid out in an array with
an index based on item# -- I musta botched something there, sorry. General
idea is the same as you've done in other places using cherrypick() though.
> I see that you have defined insts query for sysstat as 'SELECT sid FROM
> v$session' (line# 76) - I think this should be 'statistic# from v$sysstat'?
Hmm, well the indom there really is $sid (i.e. the set of database names) -
and not the statistic number - the (internal) statistic number does not need
to be exposed anywhere by PCP, unless we really have to like for some of the
other tables). For v$sysstat though, we setup PCP metric names for each of
the statistic numbers.
The reason behind the indom changes there was to provide data structures like
%sysstat_instance, that can hold all of the values returned from the SQL, for
each of the $sid instances. And in a way that doesn't conflict with any per-
$sid values for other $sid_indom metrics, like v$sesstat (which would need to
handle this same issue I believe).
>
> For system_event, there is a subroutine system_event_insts (line# 203). The
> script doesn't appear to be using it at all, so what is it's purpose?
>
Its used here:
my %tables_by_cluster = (
[...]
'10' => {
name => 'system_event',
setup => \&setup_system_event,
indom => $system_event_indom,
insts => \&system_event_insts,
values => \&system_event_values },
Which is a pointer-to-a-function (accessed by hash key "insts"). See also the
oracle_sid_connection_setup() code for further use of that via $insts_query.
Metric instances can be queried independently to metric values - see pmFetch(3)
vs pmGetInDom(3) man pages - and that drives the need for separate insts/values
functions.
cheers.
--
Nathan
|