1. Databases E. Leonardi, P. Valente

2. Conditions DB Conditions=Dynamic parameters non-event time-varying Conditions database (CondDB) General definition: Examples: HV settings, temperatures, thresholds, TDAQ partitions, trigger menus, calibration constants, alignment parameters, etc. In principle, the detector geometry, cabling and hardware connections are static parameters In practise, these parameters do change even in the Monte Carlo, due to different versions, change in hardware configuration, faults and fixes, upgrades, etc. Given the amount and complexity of the Conditions data, a database is needed to handle them What else?

3. Configurations database (ConfDB)Conditions database (CondDB) It may (e.g. ATLAS) or may not be useful, to identify parameters that are needed in order to configure the data-taking such as thresholds, TDAQ partitions, trigger menus, etc. In any case, all or part of those data should be in any case stored in the conditions database, since needed for reconstruction and analysis Variant: Conditions DB

4. DB Clients Clients for a database can be producers (write data to the DB), consumers (read data from the DB), or both Typical clients are – Detector control system – TDAQ system – Reconstruction software – Analysis software – Simulation software – Calibration software – …

5. Time dependence Data stored in the database describe the status of the detector at a given point in time All data must include an interval of validity (IoV) which identifies the set of events for which the data are valid – A set of calibration constants – A set of alignment values

6. Versions Some conditions can be multi-versioned, i.e. more than one version of the same quantity can exist for the same IoV – E.g. calibration constants for a given IoV can be computed/improved several times in the experiment lifetime In general online conditions are NOT multi- versioned – E.g. the readout value of a temperature probe Database consumers must be able to access all versions of each condition

7. Replication Depending on the computing model, part or all of the Conditions DB must be replicated in several places, possibly outside CERN – online data should be written to the DB at the experiment site… – … and then replicated to the main offline DB, in general at the site where the reconstruction is running – GRID-based simulation/reconstruction/analysis models will require the replication of part or all of the Conditions DB at all GRID sites

8. What is available All LHC experiments have their Conditions DB Atlas, CMS, and LHCb are using the LCG persistency framework infrastructure based on – CORAL: C++ based SQL-free abstraction layer to access relational databases Supports Oracle, MySQL, SQLite, … – COOL: set of tools for handling conditions data Supports time-varying and multi-versioned data https://twiki.cern.ch/twiki/bin/view/Persistency e.g. COOL

9. General structure example: ATLAS The main database is in Oracle but can be distributed in smaller “slices” using SQLite (file-based). SQUID web cache Alternative access: FroNTier technology: database queries  url query results  xml documents storage and retrieval of C++ objects access to the database itself for complex queries (Typical examples: monitoring, reconstruction) access to conditions data files (used to store some specific object(s), Typical example: calibration)

10. Replication example: CMS Online Master Database System DCS TDAQ Offline Reconstruction Condition DB ONline subset HLT Offine Reconstruction Condition DB Offline subset Online network at P5 Tier-0 Oracle Streams technology

11. Short term plans Contacts between NA62 DCS team and IT Database support, DCS proposal is: – Set DB accounts on one of the integration/test databases – Start exercising the configuration database and Oracle Archiver for NA62 – Proposed schemas: Configuration Database "NA62DCS_CONF” schema with standard developer privileges; creation of "Reader" and "Writer" accounts PVSS ORACLE archiver, RDB manager, to store DCS data: “NA62DCS_COND” – To be used for functional tests, and development of LKr control application – Not to be used as “production” DB for the 2011 run