Internet Standards/CD1.mdf/INET/IETF/RDBMSMIB/94MAR.MIN

Text File | 1994-06-07 | 12.5 KB | 311 lines

CURRENT_MEETING_REPORT_

Reported by Bob Purvy/Oracle and David Brower/INGRES

Minutes of the Relational Database Management Systems MIB Working Group
(RDBMSMIB)

These are the minutes of the open meetings of the RDBMSMIB Working Group
at the 29th IETF meeting in Seattle, Washington on March 29 and 30,
1994.  Please send comments to the working group mailing list,
[e-mail].


Introduction

The working group held three meetings in Seattle, Tuesday afternoon, and
Wednesday morning and afternoon.  Tuesday's meeting was a general review
of the MIB as it existed prior to Seattle.

The Wednesday morning session was devoted to Tony Daniel's/Informix's
configuration parameter proposal, one more pass over existing objects,
and a discussion of conformance groups.  The afternoon was spent
considering Tony's proposal for storage hierarchy discovery and
statistics.


Tuesday Afternoon

A general walk-through of the MIB was done.

Bob Natale suggested that each vendor's private MIB have some sort of
direct tie-in to the public MIB. After some discussion, he decided to
withdraw the request for more study.

The OutofSpace trap:  It was suggested that you could have a way,
through the MIB, of setting a hysteresis threshold, so that the network
does not get flooded with traps once the database runs out of space.
Finally, we decided just to add language to the MIB suggesting that the
implementor just not allow that.

The StateChange trap:  Language will be added to clarify that the
variable returned with the trap is the new state.

A writeable variable was suggested whereby the database could be shut
down.  There was also a proposal to add other settable variables, so the
RDBMS could be controlled as well as monitored.

It was eventually decided to leave this for the second version of the
public MIB.

It was proposed that RMON-like tables be added to the MIB (histograms,
etc.).  It was also proposed that a ``time of highwater sessions''
variable be added, so that you could tell when you almost ran out of
configured sessions.  This was discussed at length, with no one
violently opposed, but finally it was pointed out that there are already
mechanisms, in RMON and the M2M MIB, to accomplish some of what was
wanted.  Also, if you are polling the database even as seldom as every
half hour, you would still have a good idea when it happened.  So this
was not adopted.

The ever-popular topic of associations was brought up.  Many at IBM do
not like the current definition, since it does not distinguish between
``local'' and ``remote'' connections.  Furthermore, they have both SQL
and DRDA connections.  It was observed that many vendors have no way of
telling local and remote apart, since the underlying software hides that
information.  Finally it was decided that language would be added to the
MIB to broaden the definition of association.


Wednesday Morning

I. Parameters

Tony Daniels presented his proposal for configuration parameters.  All
vendors had some sort of parameters, and their visibility through the
standard MIB would be useful for the following purposes:


  1. Collecting data for a trouble ticket
  2. Revealing changes in configurations
  3. Enabling table driven interpretation in network management stations


Those present agreed strongly that (1) and (2) were useful and
important, and we should pursue parameter visibility.  There was weaker
support of (3) on the grounds that it called for more powerful NMS
applications than might be present.

There was considerable discussion about the semantics of the
value-carrying object.  The proposal had a very loose definition that no
one was very happy with.  There seemed to be four possible semantics:


  1. The value at server startup
  2. The current value
  3. The value the administrator would like the current to be
  4. The value the administrator would like at next startup


Those present strongly preferred that the value field here be the
current value.  We then discussed what to do about things for which the
current value might not be obtainable in an RDBMS product, and concluded
it should not make the value visible at all.  This led us to consider
whether we should have two objects, the startup config value and the
current.  This was unclear, and we left with the sense that only current
need exist in this version of the MIB.

Since the value was current, we suggested the names be changed to
reflect a parameter (rather than configuration) table, with a current
value object.  This will admit extension of configuration and desired
value objects at a later time.

We wondered what to do about global parameters, common across all
servers, and decided we should just duplicate the value in all servers.

We then discussed what to do about multi-valued parameters, for instance
an ``IsDBA'' objects that would have a comma separated list of users who
had a DBA privilege.  Some thought there should not be rows in the table
with duplicate names and different values.  There was also a thought
that a display string might not be big enough to hold all enumerated
list values.  This would require multiple rows per object, but this
leads to questions of ordering.  This still seems to be an open
question.

Marc Sinykin, Tony Daniels, and Dave Brower were named to a subcommittee
to try to resolve this, since it seems like a reasonable solution should
be doable.  They will report back to the group when they have a
proposal.

Value objects should have writable max-access, and read-only min-access
in the conformance clauses.

The name objects should continue to be strings instead of OIDs, as they
are more efficient.



II. Object Review

 (A) We noted that the RFC 1565 Application MIB wording seemed to
     suggest that it not be used to support things that were not network
     services (i.e., services local to a host and not visible on the
     network).  Marshall Rose said that was not the intent of that
     document, that the wording would need to be revised, that he would
     take care of it, and we should not be further concerned.

 (B) Uncommitted transactions had been noted as controversial, and we
     discussed what it meant.  Was the value meaningful?  Was it painful
     to determine?  We concluded that it was useful to sample for
     trends, but probably not meaningful as an instantaneous value.  We
     then wondered why we did not have the first order statistics from
     which this could be determined:

      -  update transactions started
      -  update transactions completed

     David Meldrum volunteered to float a proposal on the list for these
     values.

 (C) People were confused by the distinction between requests
     handled/made and sends/receives.  We considered the example of a
     `select' statement that returned one row (1 receive, 1 request
     handled, 1 send) and one that returned a million rows (1 receive, 1
     handled, 1,000,000 sends).  This made sense, and will be included
     in the MIB documentation.

 (D) Outbound associations seemed so product specific that it was
     useless.  It had been included for symmetry with Inbound
     associations in the ApplMib.  We will remove it, though this causes
     some conformance problems (see below).

 (E) The out of space trap should pass the out of space value, rather
     than just the server.  This will also pass the server as its index
     value, and is more useful.

 (F) Requests made seemed as product-specific as outbound associations.
     Related objects will be removed.



III. Conformance Groups

 (A) We need to split the MIB into (at least) two groups, one containing
     most objects, and another containing the optional trap related
     things.  We were not clear whether the out of spaces count should
     be in the trap group or the base group.

 (B) There was discussion whether we should split the main objects into
     a ``base'' group and the statistics in the Info tables into an
     optional ``info'' group.  The vendors present wondered if this
     would allow separate packaging and pricing.  The users booed and
     hissed, and insisted that such a consideration had never been
     raised at an IETF before, harrumph!
     Several management tools vendors asked that we not have any more
     conformance groups than absolutely necessary, since it complicates
     their lives enormously and is one of the reasons for OSI's lack of
     success.  Bob Purvey feels that the group is not going to do this.

 (C) The removal of our Outbound association objects creates problems
     with conformance to the RFC 1565 Application MIB. It insists we
     keep track of outbound associations, and if we do not have any,
     what should we do?  Marshall Rose effectively said again, ``don't
     worry, I'll take care of it.''


Wednesday Afternoon


I. Storage Hierarchy and Related Statistics


Tony Daniels presented his storage hierarchy and statistics proposal,
which prompted much discussion.  The essence of his scheme is to provide
meta-data allowing description of many different storage relationships,
and then allow arbitrary statistics gathering as in the Parameter table.

This was interesting to those present, but there was very little support
for including it in the current MIB for a number of reasons.  First, it
looked like it would take a long time to get it into acceptable shape,
and no one wanted to push out the completion dates for this scheme.
Second, it seemed counter to the ``known object'' philosophy of SNMP. It
would place a tremendous burden on the NMS to decipher the meta-data and
do the right thing, and this did not seem like a good thing to require.

There was head-nodding that we should consider more objects than had
currently been proposed, but without dragging in the meta-data approach.
So, we decided that the ``last call for new objects'' made before the
meeting would be considered a ``next to last call,'' and that we would
actively seek to discuss critical things that seemed missing.



II. Brainstorm Session for Grossly Missing Objects


A list of items were brainstormed that seemed important, but which were
currently missing.  Discussion of these are encouraged on the list.  It
is unclear what some of these mean in the broad sense, and concrete
proposals are needed.


   o Cache hits/misses/attempts
   o Table overflows
   o Table size
   o Lock waits
   o Buffer overflow
   o Log space use
   o Error message log
   o Index ``readaheads''
   o Time of last full/partial backup
   o I/O errors
   o xact force aborts
   o Lock overflows
   o Security violations
   o Pages per disk I/O
   o Schema change
   o SQL statements (distinct from requests handled?)
   o SQL connects (distinct from inbound association count?)


Some of these will have scoping problems.  We now only admit to having
servers and databases, and some statistics might belong to larger or
smaller entities.  We do not know if we should create new tables for
these other entities, or shoe-horn objects into the database or server
info tables.


Attendees

David Arneson            [e-mail]
Bashir Ashrafi           [e-mail]
Robert Austein           [e-mail]
Virinder Batra           [e-mail]
Gerard Berthet           [e-mail]
David Brower             [e-mail]
Jeff Case                [e-mail]
Bobby Clay               [e-mail]
Anthony Daniel           [e-mail]
Louis Fernandez          [e-mail]
Shawn Gillam             [e-mail]
Christine Gressley       [e-mail]
Walter Guilarte          [e-mail]
Mike Holloway            [e-mail]
Mark Kepke               [e-mail]
Cheryl Krupczak          [e-mail]
Damien Lindauer          [e-mail]
Dwayne McIntosh          [e-mail]
David Meldrum            [e-mail]
Scott Mordock            [e-mail]
Robert Natale            [e-mail]
Brian O'Keefe            [e-mail]
Andrew Pearson           [e-mail]
Peter Phillips           [e-mail]
Randy Presuhn            [e-mail]
Robert Purvy             [e-mail]
Dan Romascanu            [e-mail]
Marshall T. Rose         [e-mail]
Blair Sanders            [e-mail]
Jon Saperia              [e-mail]
Michael Scanlon          [e-mail]
Marc Sinykin             [e-mail]
Jay Smith                [e-mail]
Suzanne Smith            [e-mail]
Michael Sorsen           [e-mail]
Dick Wallace             [e-mail]
David Walters            [e-mail]
Bert Wijnen              [e-mail]
Stan Wong                [e-mail]