home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
rdbmsmib
/
rdbmsmib-minutes-94feb.txt
< prev
next >
Wrap
Text File
|
1994-06-07
|
5KB
|
131 lines
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