1. Scaling up from local DB to distributed DB Cristiano Bozza European Emulsion Group Nagoya, Jan 2004 Presented by Giuseppe Grella

2. Report on DB development activities The development of the European Scanning DB continues steadily, involving several groups and resources Salerno 2 dual-CPU servers, 3 rd coming OS: Windows 2003 Server Oracle 9iDS 32-bit version Lyon 1 server OS: Solaris Oracle 9iDS 64-bit version Bari (NEW!) 1 PC, 1 dual-CPU server coming OS: Windows XP, to become Windows 2003 Server Oracle 9iDS 32-bit version DB Server: Oracle 9iDS

3. Report on DB development activities All the groups share the same DB schema.NET access library is part of the SySal development (already works and is being upgraded / debugged) Java and C++ libraries for OPERA needs are under development (at some point in space-time, people working on the official SW should meet people working on this DB to check possible interplay) Stable design: just 1 field added in 8 months over more than 30 tables Largest development effort underway now: Replication tests + performance estimation

4. Replication tests Lyon Salerno #1 Salerno #2 Bari Current replication topology Replication policy: MultiMaster Replication (will switch to Materialized Views when more sites come up)

5. Replication tests Replication has been set up and verified in 2-site subconfiguration (only pairs of DB servers were connected at each time) Everything OK! Next test: check with fully interconnected network, all 4 sites together Lyon Salerno #1 Salerno #2 Bari

6. Performance estimation Most difficult situation: large bunches of INSERTs Optimize indices Optimize data formatting Optimize network communication Optimize access library Optimize SQL OperaDb library v.2 is 8 times faster than v.1 (in certain operations)... but the code is becoming increasingly complicated Data retrieval tests (SELECT) are easy to perform Almost no parameters to optimize Foreword

7. Performance estimation INSERT bunch (server and client on the same machine)

8. Performance estimation An interesting test: load 57 aligned scanning zones from the 57 plates of the spring-packed brick (Frascati, Oct 2003) Test details: Data sample: 356467 Base tracks, 712934 Microtracks Query: parameterized bunch of INSERTs wrapped in a single transaction DB Server: Salerno #1 server (Win2003) 2 Pentium-IV Xeon CPUs at 2.4 GHz 1 GB RAM 3×65 GB SCSI HDD (RAID-5 by HW RAID controller) 1 Gbps Ethernet card, switches to 100 Mbps on external LAN DB Client: Salerno file server (Win2000) 2 Pentium-III CPUs at 933 MHz 512 MB RAM 3×72 GB SCSI HDD (RAID-5 by Windows SW) 100 Mbps Ethernet card Network traffic: almost zero (tested on Sundays) Benchmarking tool: Windows Performance Counter DB Access SW: OperaDb v.2  (ODP.NET) PRELIMINARY tests to estimate Oracle performance for OPERA

9. Start!!! Client machine Start!!! DB server machine Performance estimation Snapshots of the start

10. Performance estimation During the query The network load is low “Bursts” of INSERTs DB Server

11. Performance estimation During the query When caches are full, disks are a bottleneck DB Server machine

12. Performance estimation Results of the test: Available bandwidth: 100 Mbps Data sample: 356467 Base tracks, 712934 Microtracks Data size on disk (SySal files): 41 MB in TLG files Data size on disk (Oracle data file): 122 MB Total duration: 0:25:50 (0:25:16 excluding client program code)

13. Performance estimation Replication performance: the insertion of these data naturally forced a replication onto the Bari DB server Results of the replication Available bandwidth: Unknown, < 2 Mbps Data sample: 356467 Base tracks, 712934 Microtracks Total duration: The sample was checked after 1 hours and was found already completely replicated on the Bari DB Server Further tests are needed to improve the precision However, the replication speed is expected to be not lower than the SQL INSERT speed

14. Performance estimation Final considerations after preliminary performance tests Processor occupancy and disk activity are relatively low The network performance could be improved Find the best access method (DB access performance has been found to depend dramatically on the library used) Improve TCP packet usage by access library INSERT server (only if really needed) Oracle confirms again to fit OPERA needs

15. Conclusions No big difficulty met up to now in developing the European Emulsion Scanning DB for OPERA Oracle confirms to be a good multi-platform DB server Easy development – people can concentrate on creating tools instead than on solving problems Performances are already fair but there are hints that can be improved with a little more work