[322] in Athena_Backup_System
Minutes of Oct 3, 1996
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Oct 3 13:56:52 1996
Date: Thu, 3 Oct 1996 13:55:47 -0400 (EDT)
From: Bill Cattey <wdc@MIT.EDU>
To: athena-backup@MIT.EDU
* Status report:
The modifications for the simpler dumpset architecture are done both in
documentation and in code.
Wild carding of of volume names and server names is now permitted.
Diane has successfully done a fair number of dumps with the new code.
Mark needs to make some changes to the test suite to fully run the
regression tests.
* Issues:
Support for Wild Carding
The specifics of supporting wild carding were discussed with an eye to
maximizing the value to the user of ABS while minimizing the impact on
the vldb.
Web interface:
Because the Oracle Web system can only make PL/SQL calls and is unable
to call outside programs, it turns out that we're limited in what kinds
of Web-based user interfaces we can do.
We don't want to rewrite everything in PL/SQL. (We probably wouldn't
have wanted an implementation in PL/SQL anyway.)
But there is still one area where doing a Web based interface has value:
Interfaces to set/show configurations (i.e. tape drives on and dumpset
and schedule specifications) and to display system status.
The amount of programming effort to do really nice looking displays with
easy to use setup screens in a Web interface is probably much less than
to do it in the graphical programming environments we currently have
available. (And over the summer, we did look at a couple.)
So we'll probably do some amount of Web interface GUI's for this sort of thing.
vldb loading
It was decided that doing a little baseline performance measurement of
the vldb would help us understand how to minimize the impact of ABS.
If something went flakey in AFS land after ABS went live, it would be
really good to be able to show in quick time that ABS was not the
culpret.
It would also be good to understand under what conditions it is best for
ABS to query the vldb in individual queries, and when to do so with bulk
queries.
Miki (who was not present at the meeting) was nominated to write any
necessary code and to establish the best baseline metrics to measure.
Bill suggested we write one page that says "the five things we'll measure".
We'll probably measure stuff like:
Does the vldb get big when it's queried a lot?
Does doing queries in parallel help?
What is the impact on the network of the various sorts of queries
we could be making?
What is the load on the vldb for the various sorts of queries we
could be making?
How are other vldb users impacted by running an ABS dump?
Ted then would have the responsibility for running the benchmarks.
The exact implementation of ABS vldb queries would be informed by the
result of the benchmarks.
