From markl@hep.ucl.ac.uk Fri Mar 16 23:56:56 2001 Date: Tue, 12 Dec 2000 11:46:51 +0000 ( ) From: Mark Lancaster To: Jim Amundson , ksmcf@fnal.gov, lmark@cdfsga.fnal.gov, Marjorie Shapiro , r.stdenis@physics.gla.ac.uk, rharris@fnal.gov, Rob Snihur , sexton@fnal.gov, stefano.belforte@ts.infn.it, Terry Watts , wolbers@fnal.gov Subject: Random access #s and some clarifications Some clarifications & answer to one of Bill's # questions : Readback times for 1000*1 row: Done this morning on fcdfsgi2 : msql : readback in order : 1000*1 row = 19.5 sec readback randomly : 1000*1 row = 19.6 sec oracle : readback in order : 1000*1 row = 509 sec readback randomly : 1000*1 row = 524 sec - so randomising the access has no significant effect. Oracle however remains a dog on fcdfgsi2. * The remote user will always have the "socket based" fallback. To implement this is a one line change in the database manager talk-to. One simply points to the database at oracle@fnal and it connects via I/P. So you always have this provided your network is OK. But e.g. from the UK readbacks that take 4 secs at FNAL take 40 secs over the atlantic. For within the US, this fallback may be OK e.g. timings from LBL were no worse (often better !) than from the trailers to FCC. So the remote user CAN work without a local copy of the database but is then at the mercy of the network. N.B. The connection over the network does not store locally any of the constants - it stores some in memory but nothing is made persistent. The adventurous user can even customise their code such that some tables are read remotely whilst some are read locally. Not to be encouraged but possible. * Most users I believe are not so concerned about super fast access times. One can always take the constants and optimise their access e.g. put in c-struct; put in text file on local disk. The latter is what Level-3 does. The point here is that unlike in run-1 it is actually easy for a user to take e.g. beam positions from the DB and write them to a text file and then use this file in an analysis. * msql requires no root access just access to cdfsoft account. This can also be configured to be any named user. One user owns msql. * msql will require less disk space than oracle since it does not keep rollback logs, temporary files for optimising access etc * # servers one would use depends on the network. For msql where overhead is trivial, I imagine each university group would have one machine in their linux cluster as the server and users would connect as clients over local IP. For oracle a more sensible configuration may be regional servers. * for msql solution; export via tape/CD is possible. One could request that the snapshot files - these are only tar gzipped files of a temporary msql DB be written to CD/tape. A simple script could then be run to unpack these snapshots. * ascii file of BPO is easy - as I said Level-3 do exactly this. Cheers Mark