INTERIM_MEETING_REPORT_

Reported by Bob Purvy/Oracle and David Brower/INGRES

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

The RDBMSMIB Working Group met on Tuesday, 8 February 1994 at
Independence Technologies in Fremont, California.


Agenda

   o Review Dave's latest MIB, and Marshall's suggested revisions (all
     copied at the end of this message).

   o There are some large architectural issues here (also related to the
     first outstanding issue below), so this may not be a short topic.


Outstanding Issues

   o Server states and database states:  A technical contribution via
     e-mail from Marc Sinykin and Jay Smith of Oracle is expected.

   o Network (or ``interprocess'') activity, now in the MIB as ``RPCs'':
     Technical contributions are solicited on how to measure and
     characterize this.

   o SQL compliance, other than ANSI SQL: A contribution via e-mail from
     Mike Hartstein of Oracle is expected.

   o Size used/size allocated metrics for the database:  Is Dave's
     `dbSize' definition acceptable for everyone?  Should we have ``size
     used'' as well?

   o The meaning of ``sessions.''

   o Trap usage:  Given that traps are out of favor in the SNMP
     community, should we keep the ones we have, in the form that we
     have them now?


Discussion

The meeting proceeded more or less according to plan, with excellent
progress made:


   o The prefix `rdbms' instead of `db' for all MIB objects was
     accepted.  There was no consensus for broadening the goals of the
     MIB to include non-relational databases, as was proposed in an
     e-mail message.

   o States and the tabular organization of the MIB occupied about an
     hour of discussion.  Stephen Campbell's proposal via e-mail to
     delete the dbRelTable was discussed but did not receive support,
     since describing the relationship between servers and databases is
     considered valuable.  Particular decisions will be described
     completely in the editor's new draft, but included:

      -  rdbmsRelState will consist of 5 values:  other, active,
         available, unavailable, and restricted.  `restricted' is to
         mean ``there may, but need not be a problem with the
         database-server combination'' and `other' means ``the
         presumption is that this does correspond to a problem state, to
         be further defined by the vendor.''

      -  The state variable for databases is deleted.

     (The above two are to be considered `tentative' rather than
     `consensus,' since they represent people agreeing that this is the
     best we can do for now, and we need a chance to go off and think
     about it.)

   o Marshall's proposal to move ``active'' variables to separate
     tables, to be called rdbmsDbInfoTable and rdbmdSrvInfoTable) was
     accepted.  The rule is that, for databases which are ``active,''
     all variables must be present.  For ``inactive'' databases, there
     is no such conformance statement.

   o SQL compliance level:  After some discussion, it was observed that
     this does not help with fault, configuration, performance,
     security, or accounting management, so why have it at all?  So it
     was deleted.

   o Network traffic:  Dave Brower's proposal was accepted, but only for
     the first four variables (i.e., the ``bytes sent'' and ``bytes
     received'' were deleted).  Exact wording was kicked around a bit,
     with the editor's draft to have the final word.

   o Size:  `Size used' was added as a new attribute in
     rdbmsDbInfoTable.  It was noted that, for some vendors, `size used'
     may always be the same as `size allocated'.  Units are to be the
     same as `size allocated', and the `units' variable was changed to
     an enumeration.

   o Sessions:  The chair brought it up, but no one could remember why
     this was considered controversial.  If someone has an issue with
     it, can they please state it?  The editor defined it to be a ``SQL
     CONNECT'' statement that has not been ``disconnected.''

   o Traps:  Marshall explained the SNMP philosophy of traps.  We
     removed the `security violation' trap.  The rdbmsStateChange trap
     received a lot of discussion, with the end result being that we
     decided that it will mean ``the database's state has changed to one
     of less availability'' with no presumption that this represents an
     unusual condition.  In other words, an implementation is free to
     send a trap after the administrator deliberately shuts down the
     database.


Attendees

Janice Befu
Gerard Berthet           gerard@indetech.com
David Brower             daveb@ingres.com
Barry Bruins             barryb@ngc.com
Anthony Daniel           anthony@informix.com
Craig De Noce            craigd@sybase.co
Howard Dernehl           howard@ingres.com
Mike Hartstein           mhartste@us.oracle.com
David Morandi            davidm@redbrick.com
Robert Purvy             bpurvy@us.oracle.com
Roger Reinsh
Marshall T. Rose         mrose.iesg@dbc.mtview.ca.us
Marc Sinykin             msinykin@us.oracle.com
Jay Smith                jaysmith@us.oracle.com