Author : Igor Gaponenko Creation Date : July 2, 2004 Version : $Id: HOWTO-Setting-Up-BetaMiniAnalysis-CDB,v 1.3 2004/07/02 23:16:38 gapon Exp $ ______________ 1 INTRODUCTION This note describes how to set up an Objectivity/DB federation with a subset of conditions and configuration databases, which (the federation) would be sufficient to run the "BetaMini" analysis. This database will be similar to COND14BOOT CDB (except it will have a subset of conditions). The main benefit of installing a federation in this way it's its small size. At a time when the current document was being written the amount of data in the subset was about 1.6 GB (compared with 31 GB) of the full size CDB. _________________________________________________________________ IMPORTANT: The recipe described in the document is relevant to releases 15.x.x, Analysis-21 and later. Only beginning from these releases the BetaMiniApp is tuned up to use a subset of CDB. _________________________________________________________________ 2 HOW TO CREATE AND LOAD A FEDERATION (STEP-BY-STEP INSTRUCTIONS) Please, follow step-by-step instructions as explained below. If something will go wrong then read further instructions in section 4 to learn where and how you may get the help. ______________________________________ 2.1 ESTABLISH (OR HAVE) A TEST RELEASE The corresponding procedure is described elsewhere. Note, this release is not be necessarily the same one which you'll be using to run BetaMiniApp. But it's always wise to use the most recent release to create and initialize a federation. _______________________ 2.2 CREATE A FEDERATION Make sure that you're in the above created or chosen test release directory. Now, the next step is to create a proper .bbobjy file with the following contents: FD_NUMBER = NNNN FDB_LOCAL_NAME = master-core A value of the first parameter ('NNNN') represents a unique identifier of the new federation. Each user in BaBar has (typically) 5 identifiers allocated to him/her. They can be obtained by: % GetFDID Pick the one which you're going to use. ________________________________________________________________ NOTE: In those cases when you're installing a public federation to be used by other users of your site you may choose to use one of those numbers specifically allocated to your site. Ask your local database administrator which one to use. If the federation already exists (ATTENTION: you have to be sure that you're not going to destroy any useful information!) then you should delete it by: % gmake database.delete CONFIRM_DELETE=yes Then create the new federation by: % gmake database.import At this stage you'll have an empty (no data) federation initialized with the current persistent schema (that's actually the main reason why a most recent software release should be chosen when creating your test release). The catalog of the federation will be empty. You may check its contents by: % setboot % oodumpcatalog The output will have just one special entry describing the federation (FD). ____________________________________________________ 2.3 FIND A SNAPSHOT TO BE LOADED INTO THE FEDERATION If you're installing the federation at SLAC then the snapshot can be found in the following directory: /nfs/objyserv03/objy/databases/snapshots/master/betamini-subset/current Remote (off SLAC) users may find it useful to transfer the snapshot as a single file in the compressed ("gzip") and packed ("tar") form. The file is found in the following directory at SLAC: /nfs/objyserv03/objy/databases/snapshots/master/betamini-subset/currentTar/betamini-subset_cond.tar.gz The size of the file is nearly 4 times less then the size of the uncompressed snapshot. Simply copy the file into a dedicated snapshot directory at your site. Then decompress and unpack it using: % cd % gunzip betamini-subset_cond.tar.gz % tar xvzf betamini-subset_cond.tar % ls -l Now you're ready to load the snapshot. Proceed to the next step. _________________________________________ 2.4 LOAD THE SNAPSHOT INTO THE FEDERATION The following command will load the snapshot into your federation: % gmake database.load SNAPSHOT_DIR= Where is a directory with the snapshot as explained in the previous section. The procedure should be relatively quick, taking about 10 minutes before completion (unless your machine and/or a database server (AMS) are under heavy load, or something is wrong with a file system on which the snapshot is located). In addition, this loading command will establish a core infrastructure of the BDB and CDB layers. Now you may check the contents of the federation's catalog by: % setboot % oodumpcatalog The catalog should not be empty. There will be about 20 (or more) database entries in it. You may also get a list of database images in the federation by: % setboot % oodumpcatalog | grep "DB Name" | awk '{print $4}' _______________________ 3 HOW TO VERIFY RESULTS This is an optional step. You may choose to follow recommendations found in section 4.3 below if you suspect that something went wrong with the above described procedure. First of all, you may check that the federation has been created with proper parameters. This can be done by: % setboot % BdbCondDataDistr dbidrange NAME This command should not complain and should report: master-core That's actually the value of the 'FDB_LOCAL_NAME' parameter which you were supposed to put into the .bbobjy file _before_ creating and initializing the federation. If you see something else (most probably it will be "default") then you didn't have the right .bbobjy file when creating the federation. In this case repeat the whole procedure explained in the section 2. The next step is to check the integrity of the CDB database: % setboot % CdbManager status -origin MASTER % CdbManager status -origin IR2 These commands will verify the CDB meta data only! There shouldn't be any complains during these commands' execution. Proceed to the section 4.3 in case of problems. Another useful outcome of the commands will be two timestamps indicating the actual modification times of OFFLINE ("... -origin MASTER") and ON-LINE ("... -origin IR2") conditions. This information can be used to understand the validity of the snapshot loaded into your federation. If for some reason you suspect that the contents of your federation is too old then you may recreate the federation as it's explained earlier, or update it as it's explained in the section 4.2 below. You may also print a list of conditions available in your federation. This list can be used in case of complains about missing conditions seen when running the BetaMiniApp: % setboot % CdbBrowser conditions / The optional "-long" switch can also be specified to obtain more information on each condition and folder: % setboot % CdbBrowser conditions / -long ___________________________ 4 WHAT ELSE YOU SHOULD KNOW _____________________________________________________________ 4.1 HOW OFTEN THE "BETA-MINI" SNAPSHOT GETS UPDATED AND WHEN? There is an automated procedure for refreshing this snapshot on a weekly basis. You may check the time stamp of the snapshot by looking at the time stamp of files in the snapshot directory. Get in touch with BaBar/SLAC Database Operations Group if you see that the snapshot is too old (older than 1 week). ___________________________________________ 4.2 HOW TO UPDATE AN EXISTING INSTALLATION? If you already have a "BetaMini" CDB federation installed exactly as it's described in the section 2 above then you may refresh its contents by picking up a new snapshot and running the following command: % gmake database.load SNAPSHOT_DIR= -force The optional "-force" flag will tell the loader to replace existing database images with their newer versions. ________________________________________________________________ IMPORTANT: The command must be run from a test release directory where an original (or its copy) .bbobjy file is located. After that you may check results of the step by using the previously mentioned verification procedures explained in section 3 above. _______________________________________ 4.3 WHO TO TALK TO IN CASE OF PROBLEMS? The first step is to talk to your local database administrator or a database expert. If the issue still can't be resolved locally then report a problem directly through the following Hyper News Group: BdbSOS or by sending a message through a e-mail gateway to the following recipient: BdbSOS-hn@slac.stanford.edu One of the members of BaBar/SLAC Database Operations Group will investigate the problem and provide you with an assistance. In case if you'll have questions on the contents of the current document then you may send them directly to the author(s) of the document using the e-mail address(s) specified on the top of the document. ____________________________________________________ 4.4 WHERE TO GET MORE INFORMATION ON BABAR DATABASES First of all it makes a sense to familiarize yourself with a basic procedure for installing a private test federation. The procedure is described in another file of the current package: HOWTO/HOWTO-database-importing It's important to understand differences between the current recipe in those ones described in that file to avoid possible confusions in the future. More information on the Objectivity/DB based databases can be found from a dedicated page called "BaBar Database Environment" from the BDB Web site: http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/users/environment.shtml Conditions Database (CDB) specific questions are covered by a number of documents available from here: http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/experts/designDocs.shtml