> -----Original Message-----
> From: Nathan Scott [mailto:nathans@xxxxxxxxxx]
> Sent: Monday, January 18, 2016 9:49 PM
> To: Narendra Babu, Nandhita <nandhita.narendra.babu@xxxxxxxxx>
> Cc: pcp@xxxxxxxxxxx; Nelson, Doug <doug.nelson@xxxxxxxxx>
> Subject: Re: [pcp] Oracle PMDA - sysstat values
>
> Hi Nandhita,
>
> ----- Original Message -----
> > [...]
> > I have been working on Oracle PMDA for a while now. I was able to make
> > some changes to the source code and get the values printed out by
> > Pmval (after referring to Postgresql PMDA) for all instances except sysstat.
>
> Aha - it's great to hear that you're working on it and making progress too!
>
> >
> > select statistic# , value from v$sysstat;
> >
> > This SQL returns1178 rows of statistics, out of which 179 are listed
> > as performance metrics in setup_sysstat .
> >
> > [...]
> >
> > I thought one way to extract a specific statictic# and itâs value is
> > by using the $item number in sysstat_values sub.
>
> Yeah, looking at the code, that's not going to work. The problem is the item
> numbers (part of the PCP PMID, assigned at the call to add_metric() in setup()
> routines) has no direct relation to the column (or row) in the SQL result.
>
> We'll need to construct something to handle that. I see your code has
> acquired
> several "map" arrays, like @latch_map and so on, to solve a similar problem.
> In the v$sysstat case, I think we'll need to have a similar but different map.
>
> Complicating the matter a bit is a statement on this page:
> https://docs.oracle.com/cd/B28359_01/server.111/b28320/dynviews_3086.ht
> m#i1420473
> Which states: "Note: Statistics numbers are not guaranteed to remain constant
> from one release to another. Therefore, you should rely on the statistics name
> rather than its number in your applications."
>
> This is a problem we need to deal with, because we were considering mapping
> item number (from PCP PMID) to statistic number (from v$sysstat), or
> vice-versa,
> and that cannot be done directly according to the above.
>
> So, what I think is needed is a name -> item hash (instead of the column
> number
> array, indexed by PMID item number) used when refreshing the other tables, as
> in $latch_map for example. Attached is a patch to show the idea, not tested
> at
> all and obviously would need to be updated for all of the v$sysstat metrics
> not
> 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.
> 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?
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'?
> patch, as well as an online reference to many of the stat names (V$STATNAME is
> the definitive reference for the installed Oracle, AIUI).
>
>
> Hope that all makes sense, and thanks again for starting to revive this code!
>
> cheers.
>
> --
> Nathan
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?
Thanks,
Nandhita
|