1. Online Access to the ATLAS Conditions Databases Online Access to the ATLAS Conditions Databases L. Lopes, A. Amorim, J. Simões, P. Pereira (Faculty of Sciences of University of Lisbon, Lisbon, Portugal) I. Soloviev (Petersburg Nuclear Physics Institute (PNPI)) S. Kolos (University of California, Irvine (UCI)) M. Caprini (IFIN/HH Bucharest, Magurele, Romania) Lourenço Vaz (FCUL – University of Lisbon, Lisbon, Portugal) – lvaz@cern.ch 15 th IEEE NPSS Real Time Conference 2007 (RT07), Fermilab, Batavia IL, 60510 – Apr 29 - May 5, 2007 – http://computing.fnal.gov/cd/rt07/index.htm A Toroidal LHC ApparatuS (ATLAS/CERN) OKS2COOL is an interface to store Configurations databases (OKS) into COOL each time the TDAQ is booted. Along with OKS2CORAL, they form the interfaces to store TDAQ setups with time of validity and persistency to be browsed back in future. Its main features are: Uses a simple API to load OKS objects into COOL (TIDB2OKSPlugin) It's core module for ONASIC Uses TIDB2 (Temporal Instrumentation Database 2) Handles schema changes by also storing the oks binnary object in COOL OKS2COOL2 context diagram: OKS2COOL Data Mapping: Schema can change at any time, causing no trouble to the storing procedure. Keeps historical evolution easy to track, because data with different schema can be stored on the same folder. Only relevant attributes can be showed, later we can change our mind and show more attributes. OKS2COOL2 can be bidirectional at a low cost. LCG/COOL Conditions Database is used to store TDAQ Monitoring information and supply Configuration setups to High Level Trigger (HLT) algorithms, to ATLAS Subdetectors, and also to Offline event reconstruction jobs. LCG/COOL is a persistent and time managed database, and both the Monitoring and Configurations data may grow to large number of objects per run due to their constant change in time, this poses high reliability standards to the tools interfacing this services with COOL. Configurations setup or Configurations database is managed in the Online framework by Online Kernel System (OKS) an in-memory database, whose content can be dumped to an XML file, and Monitoring data is provided by Information Service (IS). A set of packages has been developed to deal with the transfer of Configuration setups and Monitoring data into COOL: OKS2COOL and ONASIC. On other hand, HLT during event processing and Subdetectors during their configuration, accesses COOL by a very large number of clients, this poses high performance standards to COOL and its backend RDBMS. To evaluate this performance, DBStressor tool was developed and widely used during Large Scale Tests (CERN 07), where a computing farm up to 1000 nodes simulated HLT and SubDetector read accesses to COOL. This set of tools integrate TDAQ s/w as cvs packages since Oct/2006 and presently fully functional. ATLAS T/DAQ Conditions Databases It's a two-tier interface from IS to COOL whose reliability lies in avoiding backpressure from database servers, it does it by using OKS XML files as local and temporary buffer. It includes SetCondition tool which allows the user to configure ONASIC on-the-fly, thus enhacing ONASIC integration with Monitoring WG. It's architecture uses 2 interfaces, ONASIC_IS2OKS (interfaces 2 Online Services) and ONASIC_OKS2COOL (non dependent from TDAQ infrastructure): Main features: Very Flexible Configuration Monitoring data from run integrety preserved. ONASIC: Online Asynchronous Interface to COOL It's a set of tools to test COOL access in a wide networking scale. DBStressor core is an Online Controller wich access the database during TDAQ ConfigureAction. Uses IS both to rapidily configure all controllers and also to collect all individual results. It includes a versatile populate DB tool. Tests during LST07:  Measure Oracle/COOL & LXSHARE Network Bandwidth  Test Capability of Indexing of Oracle/COOL  Measure Times to build Tables in COOL  Test Performance of COOL's queries by ChannelID  Overall results for each scalability step: COOL bandwidth vs scalability: DBStressor / LST07 tests Histogram with the real case: 1000 clients fecthing each a complete COOL Table of 289MB Histogram with simulation of: 100 threads processing with 300s (spread 20%) a total of 1000 clients Real data vs Simulation OKS class as a COOL folder A1,B1 A2,B2,C1,D1 A3,B3,C2,E AB,BB,DB Similar OKS objects Name Attr_name_ 1 Rel_name_ 1 OKS_Class (...) OKS DataCOOL Data Name Attr_name_ 1 Rel_name_ 1 Folder (...) S IS Id Attr_value_ 1 Rel_value_ 1 OKS_Obj (...) Id Attr_value_ 1 Rel_value_ 1 OKS_Obj (...) IS S Id Attr_value_ 1 Rel_value_ 1 Row (...) Since Till Id Attr_value_ 1 Rel_value_ 1 Row (...) Since Till OKS_Data FileSystem OKS2C OOL TIDB2 COOL MySQL Postgre SQL Oracle SQLite OKS data OKS2C OOL2 KTIDBExplorer OKS OKS2COOL2 IS OKS IS2OKS OKS2COOL OKS2COOL2 (OKS2TIDB2) TIDB2 COOL/ COOL2 Oracle MySQL PostgreSQL ONASIC ONASIC2 SetConditions