G0 Database - 14 August 2003 Teleconference Notes

The Bad Detector Problem

• How do we deal with runs where beam quality is good but specific detectors are "bad"?
  • Examples: dead phototubes, pulser left on, electronics problems, etc.
  • Currently throw out the entire run if one or more detectors are bad. Not an acceptable solution.
• Add a column bad_flag to the measurement table.
  • Column type of BOOL:
    • NULL when detector is "good"
    • NOT NULL when detector is "bad"
  • Allows specification of individual detectors as good or bad on a run-by-run basis.
  • This SQL fragment will select only "good" detectors:
    SELECT ... FROM measurement AS m, ... WHERE m.bad_flag IS NOT NULL AND ...
• Proposal for use during the run
  • Analysis crew and/or g0analysis updates measurement.bad_flag after first replay of data.
• To Do
  • Make a GUI or script for setting/unsetting bad_flag for individual detectors and runs/run ranges. 90% complete (png).
  • Automate determination of bad detectors during replay and update via g0analysis?
  • Update scripts to make use of new flag.
  • If desired, update results database from engineering run.

Selecting Data Sets

• How do we deal with different sets of data within the results database?
  • Database will contain results from IA scans, PZT scans, Wells plot runs, and other non-standard runs mixed in with normal asymmetry runs.
  • Currently implement individual good_for_? tables containing run_ids for the desired data set.
    • Join good_for_? into query to select only desired runs.
    • Difficult to maintain.
    • Difficult to include in generic scripts.
    • Additional join on already long queries.
• Add a column good_for to run table.
  • Column type of SET:
    • Allowed values set at database creation; e.g. asymmetry, pzt_scan, ia_scan, junk, etc.
    • Column can contain more than one allowed value; e.g. run.good_for = "asymmetry, junk".
  • Allows specification of multiple data set memberships on a run-by-run basis.
  • This SQL fragment will select only PZT scan runs:
    SELECT ... FROM run AS r, ... WHERE r.good_for LIKE '%pzt_scan%' AND ...
• Proposal for use during the run
  • run_control automatically enters preliminary information into run table of database; e.g. run number and start time.
  • Shift crew uses a GUI (separate from run_control) to update good_for column of run table anytime after the start of the run.
  • As new data sets are defined (e.g. high quality asymmetry data) the GUI can be used by the analysis crew to update run.good_for.
• To Do
  • Create a GUI for updating run.good_for.
  • Update scripts to make use of new flag.
  • If desired, update results database from engineering run.

Database Backup

• Current Situation
  • One database server (wmg0)
  • Periodically dump database to SQL and jput to silo
  • Not automated
  • Database must be taken off line to perform backup
• Database Replication
  • Two or more database servers: master and slave(s)
  • Updates performed on master server (g0analysis, GUIs, scripts, etc.)
  • Slaves periodically pull changes off of master
  • A slave can be taken offline to backup the database to tape without affecting the master.
  • Slaves can be on or off site (a good way to get up-to-date databases to collaborating institutions)
• Status: Testing with a pair of local servers.
• Future Needs: One or more additional servers (at least one on-site) with large hard drive capacity.

Classified Ads

Help Wanted

Seeking programmers to write graphical user interfaces for database backends. Experience with Perl, Perl/Tk, and SQL desired but not necessary. Positions available starting immediately. Please contact D. Spayde at 757-269-5192 or spayde@jlab.org.

• GUIs Needed
  • measurement.bad_flag (90% complete)
  • run.good_for
  • cuts manager
  • calibrations manager
  • Analysis frontend (Fraser GUI)

Goods Wanted

Seeking database servers for hosting database mirrors. Large hard drive capacity required but other technical specs are modest. Please contact D. Spayde at 757-269-5192 or spayde@jlab.org.