PVSS Oracle archiving

1
PVSS Oracle archiving

• Involved people in the latest developments
• Ronald Putz (ETM)
• Chris Lambert (IT-DES)
• Eric Grancher (IT-DES)
• Lothar Flatz (Oracle consultant)
• Luca Canali (IT-PSS)
• Manuel Gonzalez (IT-CO)
• Nilo Segura (IT-DES)
• Piotr Golonka (IT-CO)
• Laura Fernandez Nocelo (IT-CO)
• Svetozár Kapusta (PH-AIT)

2
History

• 2004
• ETM (company developing PVSS) promises to its
  customers to be able to archive to different
  flavors of database systems
• 2005
• First prototype comes to CERN with many
  functionality issues, mainly loosing data and low
  client performance (100 changes/s)
• Q4 2005
• Oracle consultant (paid by CERN) comes to ETM to
  boost client performance
• Q1 2006
• IT-CO puts enormous effort to test the new RDB
  Mgr (Relational DataBase Manager)
• insertion rate of 1500 changes/s for a few
  minutes
• Stability issues, memory leak, slow Event Mgr
  Data Mgr communication, server shows low
  performance
• Huge client memory consumption (up to 1.5GB RAM)

3
History 2

• April 2006
• Tuning session at CERN with Oracle consultant, 23
  clients, 2 node RAC (Real Application Cluster)
  Oracle server
• Many enhancements, new issues discovered
• Archive groups not working partitioning on
  server instead
• 24 000 changes/s inserted continuously
• Bottleneck Network
• May 2006
• Tuning session at CERN with fixed RDB Mgr (also
  Linux version available), 56 clients, 2 (later 4)
  node RAC server
• lower memory consumption (300MB RAM)
• 56 000 (later 100k) changes/s inserted
  continuously
• Bottleneck Server

4
History 3

• End of May 2006
• Tuning session at CERN with ETM employee, 150
  clients, 6 node RAC server
• Schema enhancements, new issues discovered and
  fixed
• 150 000 changes/s inserted continuously
• Last Week weekend
• Tuning session at CERN, 170 clients, 6 node RAC
  server
• 70 000 changes/s inserted continuously over the
  weekend
• Right Now
• The tests with 170 clients still continue until
  end of the month to tune queries

5
Test Configuration

• Client side
• mixture of Windows
• ALICE DCS lab (20 PC) bldg 12
• IT-CO lab (4 PC) bldg 13
• and Linux clients
• LHCb (44 PC) Point 8
• LxBatch (120 PC) Computing Center
• PVSS 3.1, cumulative patch
• patches 167, 203 (available from IT-CO web page)
• framework 2.3.6
• data generated with simulator drivers configured
  to change the values of DPEs (DataPoint Elements)
  at the required rate.
• Server side
• Oracle RAC server with 1, 2, 4 and 6 nodes (PCs)
  respectively
• 3 GHZ Dual Processor Xeon, 2GB RAM, Oracle Real
  Application Cluster 10.2.0.2 on Linux Red Hat
  Enterprise
• Fiber channel RAID10, 32 SATA disks (20 write, 32
  read)

6
Performance Improvements
7
Disable job to analyze tables and indexes

• PVSS server job running every 3 hours
• gathers statistics on objects in the DB to
  improve performance
• degrades performance considerably (one order of
  magnitude) if ran at inappropriate times
• this is a typical task for the DB administrator

8
Disable indexes on TS and element_ID

• Indexes are used to boost queries which filter on
  the timestamp and/or element_ID (unique number
  for each DP element)
• Slowed the server considerably
• Consumed a lot of disk space (2/3 of data volume
  was in the indexes (extra data in the redo
  logs))
• Useless for ALICE
• Got disabled, let only the primary key (composite
  index on columns TS and element_ID)
• Once the data are inserted, if required the
  disabled indexes could be enabled
• More efficient in CPU and storage usage

9
Use direct path for data insertion instead of
merge

• Used to move data from the client temporary
  tables to the history table
• Has a big impact on performance
• Changes completely the current approach
• Previously check is done before inserting a new
  value to see if it is a correction value or a new
  value
• Currently insert everything in the history table
  and treat the errors afterwards
• More efficient since new values will occur much
  more frequently in comparison to correction
  values
• This way of treating errors can only be used
  since Oracle 10.2.

10
Index Organized Tables

• Data and index data are kept together
• Fits the design (many inserts, few deletes)
• Transparent for client
• Not as performant as INSERT /APPEND/

11
INSERT /APPEND/

• Oracle hint
• Dont search for an empty place, just append it
  at the end of the table
• Boosts performance in high insert rate
  environments (more than IOT)
• But only 1 client can write into 1 table in time

12
Partition of the history table per client

• Comes as an implication of the previous point
• The history table has to be partitioned
• Each client accesses only one partition and
  doesn't interfere with other clients
• Due to the way insert append works
• To allow for scalability in a RAC server
• Special feature that doesn't come in the standard
  Oracle version

13
Initial size and extend of tablespaces

• It is important to preallocate enough space
• Space allocations and extensions were happening
  very often and penalizing performance
• We used the PVSS data driven mechanism to tune
  the parameters for allocations and extensions

14
Requests Open Issues

• Password has to be introduced in config file in
  plain text
• It is just a workaround to be able to easily
  start the RDB for the first time
• one should rely on the internal DP
• Negative system ids
• system numbers bigger than 127 appear negative in
  the database
• Problem fixed (new version of patch 203).
• Archive groups
• We spent a lot of time trying to understand what
  the clients do when groups are used
• We have not been able to make the Archive groups
  work
• Remains an open issue

15
Requests Open Issues 2

• Queries separated per DPE
• One SQL statement, let the DB do the processing
• Dont issue several separated SQL statements with
  processing in client
• ETM needs to modify the dpGetPeriod function
  (also used by the IT-CO trending tool)
• use dpQuery in your code, so PVSS will not split
  the SQL queries
• Memory allocation at OCCI level
• OCCI 10.1 has a bug that makes the RDB Mgr crash
  if the first block sent over OCCI is big
• Current workaround The RDB Mgr starts with a
  small block size, increased afterwards
• Solutions
• Put a logic in the RDB limiting the size of the
  first block sent through OCCI
• Use OCCI 10.2
• ETM claims it has a bug when running queries
• requires newer version of compilers that the ones
  ETM is using)

16
Requests Open Issues 3

• Number of blocks retained in overload/DB not
  reachable condition
• A parameter limits the number of blocks in memory
  of the RDB Mgr when it is not able to send all
  data
• However the RDB Mgr buffers blocks without any
  limit
• Dangerous since it could make the PVSS project
  crash
• Happens because the thread that writes to the DB
  is the same that manages the blocks in memory
• Solution would be to do the management of the
  blocks in the same thread that receives data from
  the DM and writes data to the blocks

17
Requests Open Issues 4

• Very slow start up of clients
• RDB Mgr does several queries at start up
• Query to get maximum Time Stamp in the history
  table
• Query to get all elements for events
• Query to get all elements for alerts
• The bigger the history table, the longer it takes
  run an initial query
• The more clients were connected the slower the
  start of each client was
• Last 2 queries a client is iterating over all the
  elements but keeps only his ones (this filtering
  is much better done by the server and was fixed)
• First query still an issue
• Used to decide which values stored in the local
  lastval archive have to be sent to the DB
• ETM claims it is faster than to send all the
  values and see if there are duplicates
• Query the whole history table gtmore than 1
  client, it will not be coherent (client should
  ask for the latest timestamp of a value inserted
  by him and not any client)
• History tables will be big gt more efficient to
  insert all the local lastval values and the
  correct duplicates afterwards
• Not clear how this will work in 3.5 (local
  lastval archive has been disabled)

18
Requests Open Issues 5

• Slow/Deadlock when starting clients after
  reconfiguration
• concurrent start of the clients was very slow and
  in some cases lead to a deadlock
• solution is that each client takes a lock on all
  the tables it requires (this serializes the
  operations and will not produce any deadlock
  situation)
• Site configuration in RAC servers
• There seems to be a problem when having a RAC as
  DB server. It is not foreseen to easily reflect
  the RAC configuration in the internal table
  arc_site
• This is an issue because there is a check (SQL
  join) between the information in arc_site and a
  system view (vinstance) in the code
• Algorithm to calculate element_id limited to 255
  systems
• The current algorithm to calculates the
  element_id in the DB from the dpe_id, dp_id and
  system_id, is limited to 255 systems
• PVSS 3.5 will not be limited to 255 systems in a
  distributed system
• Querying data from a remote system requires local
  connection to DB
• When querying data from a remote system, the
  local system needs to be connected to the DB even
  though the query is executed by the remote system

19
Requests Open Issues 6

• Error monitoring handling
• monitor the number of blocks in the RDB with an
  internal DPE
• know which periods of time were stored to file
  instead of the DB
• timeout in the threads that interact with the DB.
  If for any reason they get blocked, their
  operation should finish gracefully

20
Future ETM improvements

• PVSS Set up script for Oracle server
• Will be run from a panel in PVSS
• First version available
• Future release will contain advanced
  configuration parameters for CERN that set up the
  database to
• Disable the job gathering statistics
• Disable useless indexes
• Use direct path for data insertion instead of
  merge
• Use INSERT /APPEND/
• Partitioning (it is not a standard feature and
  most of the ETM customers will not have it)
• Default parameters for allocation and extension
  of tablespaces

21
Future ETM improvements 2

• Queries in distributed systems
• Query on data from a remote system goes via the
  remote system
• Degrades performance of the remote system
• Some PVSS systems will be mostly writing to the
  DB, others will be mostly querying (load will be
  on the systems that write data to the DB)
• If remote systems are not available it is not
  possible to query their data, even if all the
  information is in the DB
• We would like to have the following behavior
• Queries go always through the local system, even
  if they require data from a remote system
• Remote system is running, use its DP
  identification to query the DB
• Remote system is not running, use the information
  stored in the DB to query the data. (Given a DP
  element name the query to get the element id for
  the DB is very straight forward and more
  efficient that manipulating the dpe id, dp id and
  system id to calculate the element id

22
Future ETM improvements 3

• Buffer to local disk when not possible to send
  data to DB
• If the buffers in the RDB exceed a given size
  either because of an overload or because the DB
  is not reachable, it writes to files in the local
  disk
• separate file for each block that could not be
  handled
• format of the files is ASCII
• File contains SQL statements that are required to
  insert data into Oracle
• Scheduled to be released in August.
• CERN Comments on the concept
• The insertion from the files is done value by
  value. This is very bad for performance, as we
  already saw in the early versions of the RDB
  manager.
• Bind variables are not used. This is dangerous
  because it could delete the parsed queries in the
  Oracle cache.
• It was suggested to explore other possibilities
• Use Oracle SQL loader to import files with the
  values. This is the fastest way to insert the
  data. Error handling is a bit more complex
  because one has to wait for some report files to
  be generated.
• Use the same method as for the normal insertion
  write to the client temporary table and let the
  PL/SQL code in the DB do the job. This may
  require some changes in the PL/SQL code because
  right now it can only insert in the current
  history table, not in previous ones

23
CERN tests results

• Inserts of 170 clients each at 1000 changes/s
• DB was not able to handle fully the load
• Clients were inserting the data at the same time
  because of their simultaneous start
• Starting clients randomly has increased
  performance
• Long term stability 170 clients each inserting
  at 500 changes/s during 14 hours
• Currently the impact of queries is tested

24
Other News And Reminders

• SPD are configuring their FERO using the Oracle
  DB sitting in the DCS lab
• At CERN
• Use CERN DB service for PVSS configuration DB
• Use CERN DB service for FERO configuration DB or
  ask ACC team
• Ask ACC team or IT for an account
• At home institute
• install your own (Oracle versions to use)

25
Oracle Versions to use

• The latest!
• Server 10.2.0.2
• Standard and Enterprise editions (advanced users)
• http//www.oracle.com/technology/software/products
  /database/oracle10g/index.html
• Express edition 10.2.0.1
• http//www.oracle.com/technology/software/products
  /database/xe/index.html
• Any other development PCs
• Oracle instant client 10.2.0.2
• http//www.oracle.com/technology/software/tech/oci
  /instantclient/index.html

26
Current organization of SPD FERO configuration
data
MBRVersion
MBRVersion Number(9) PK
MBRVect Varchar2(2460)
27
Conclusions

• Huge improvements in performance of the PVSS
  Oracle archiving accomplished
• RDB Manager is getting mature
• Application can and will scale
• No showstopper identified
• Full functionality and tests expected this summer

28

• Thank you for your attention

29
Appendix
30
Organization of the Configuration Database

• The ALICE Running mode (e.g. lead-lead, cosmics,
  p-p, etc.) is defined by the ECS
• The mode is sent to the DCS at every change
• A valid configuration must exist for every
  running mode
• The same configuration might be re-used for
  several modes
• FERO Configuration lookup tables define the
  relationship between the ALICE Running mode and
  the corresponding configuration version for each
  sub-detector

31
Hierarchical organization of DCS FERO
configuration data
A view created from the individual detector
versions
Actual configuration modes (Fixed number of rows,
only updates)
ALIVersion
TypeOfRun PK
SPDMode
Table Name
SPDVersion PK
SPDVersion PK
TypeOfRun PK
SPDversion FK
Column Name
SPD Data
SDDVersion PK
SDDVersion PK
SDD Data
SSDVersion PK
SSDVersion PK
number(4,0)
number(7,0)
Oracle Datatype

SSD Data
ppRunID
xxxxx


CosmicsRunID
xxxxx

PbPbRunID
xxxxx
TRDVersion PK
TRDVersion PK

xxxxx
TRD Data

xxxxx
xxxxx


xxxxx
SPDRemark
SPDversion FK
Remark
number(7,0)
varchar2(1000)
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
xxxxx
32
Organization of the Configuration Database

• Separate schemas (users and their tables) are
  created for each detector
• Data organization is hierarchical and follows the
  intrinsic detector segmentation
• The atomic data records represent a group of
  parameters, which should be loaded together (e.g.
  chip settings, sector settings)
• A new configuration data for any of the detector
  components results in a new configuration set for
  the whole detector
• Hierarchical organization allows for re-using the
  information already stored in the database

33
Configuration DB hierarchical organization
Configuration Version
Group 1 Version
Group 1. Version

Sub-group 1 Version
Sub-group 1 Version
Group n Version

DATA
Sub-group n Version
Sub-group n Version
DATA
Group n Version
Sub-group 1 Version
Sub-group 1 Version

DATA
Sub-group n Version
Sub-group n Version
DATA
34
Configuration DB example SPD
Configuration Version
Side A Version
Side A Version
Side C Version
Sector 0 Version
Sector 0 Version

Half-Stave 0 Version

Sector 9 Version
Half-Stave 0 Version

DATA
Half-Stave 5 Version
Side B Version
Sector 0 Version

Sector 9 Version
Half-Stave 5 Version
DATA
35

• There are two options for writing the data record
  type
• Table containing individual parameters
• Configuration data stored in a BLOB
• It is the responsibility of detector groups to
  define the database schema and implement the
  client code in the FED server(s)
• The DCS team will
• Provide assistance (we can help you to create the
  schema and implement the client code)
• Verify the schema (in collaboration with IT)
• Install, operate and maintain the database

36
General recommendations

• Development of Oracle applications -General
  advices from IT
• https//twiki.cern.ch/twiki/bin/view/PSSGroup/Gene
  ralAdvices
• Reference slideshow
• https//twiki.cern.ch/twiki/bin/view/PSSGroup/Refe
  renceSlideshow
• Database design
• http//agenda.cern.ch/askArchive.php?baseagendac
  atega044825ida044825s0t2/moreinfo

37
Define keys, constraints and indices

• Primary key
• Column or set of columns that uniquely identifies
  table rows
• Every table should have a primary key defined
• Primary key protects from entering duplicated
  rows to a table
• Oracle implicitly creates a unique index on
  primary key columns
• Foreign key
• Relation (e.g. master-detail) between 2 tables
  should be formalized by creating a foreign key
  constraint
• Foreign key helps to keep data integrity and
  facilities cascade operations
• Oracle DOES NOT create implicitly indices on
  foreign key columns so if related tables are
  supposed to be joined one needs to create such
  index by hand.

38
Define keys, constraints and indices (2)

• Primary and foreign keys syntax examples
• ALTER TABLE employees ADD CONSTRAINT employees_pk
  PRIMARY KEY (id)
• ALTER TABLE departaments ADD CONSTRAINT
  employees_pk PRIMARY KEY (dept_id)
• ALTER TABLE employees ADD CONSTRAINT
  departaments_fk FOREIGN KEY (dept_id) REFERENCES
  departaments (dept_id)

39
Define keys, constraints and indices (3)

• Unique keys
• Column or set of columns other then primary key
  that uniquely identifies rows in the table
• Oracle implicitly creates index on unique keys
• In contrary to primary keys, unique keys allow
  NULL values
• ALTER TABLE employees ADD CONSTRAINT
  employees_unq UNIQUE (lname)

40
Define keys, constraints and indices (4)

• Other constraints
• Usually it is better to enforce data integrity
  constraints on database server side than on
  client/middle tier side
• Central management
• Easier maintenance
• Better performance
• Allowed constraints
• NOT NULL
• CHECK
• ALTER TABLE employees ADD CONSTRAINT salary_chk
  CHECK (salary BETWEEN 1000 AND 50000)

41
Define keys, constraints and indices (5)

• Indices
• They are like indices in books -gt they speed up
  lookups
• BUT insert into a table with 3 indices is 10
  times slower than into table without indices
• It is important to find for each table a minimal
  set of indices
• It is usualy better to not create indexed on
  small tables (lt 50 rows)
• CREATE INDEX emp_dept_id_idx ON employees
  (dept_id)

42
Use Bind Variables

• Place-holder variables in SQL statements that are
  substituted with concrete values before statement
  execution e.g
• SELECT "schedulerJobId" FROM CMS_DASHBOARD.JOB
  WHERE "jobId" 2001
• SELECT "schedulerJobId" FROM CMS_DASHBOARD.JOB
  WHERE "jobId job_id
• Bind variables help
• To reduce CPU consumption (less hard parses)
• 5000 executions of query above take either 2.4 or
  18.1 s depending on whether bind variable has
  been used or not.
• To improve application scalability (less Oracle
  internal locking)
• To decrease DBAs anger
• To improve code security
• Bind variables protect from SQL injections.
• To make code more readable and easier to maintain
  
• Concatenated strings with hard-coded values are
  usually less readable then strings with bind
  variables

43
Connection management

• Opening a connection to a database is very
  expensive from Oracle point of view
• New OS process has to be forked
• Session context has to be created inside Oracle
  instance
• User has to be authenticated and authorized
• Client-server applications
• Database session should be created at the
  beginning of the client program execution and
  reused during its lifetime
• EXCEPTION if client is idle for a long period of
  time it is better to close the session and free
  server-side resources

44
Recapitulation of General Recommendations

• Use bind variables
• Use primary keys
• Define foreign keys (and add indices)
• Add indices to columns which are referred to
  often in the WHERE clause of queries
• Use constrains to enforce the data integrity
• Use a normalized schema
• Focus on representing the modularity of the
  detector when creating the tables

45
Application of General Recommendations for FERO

• Implement constrains on table columns
• Use Primary keys PK on columns which contain the
  version number
• Use Foreign keys FK on the columns which
  reference the primary keys.
• Use NOT NULL keywords for columns in order to
  have for every version the corresponding data
• Use constrains with CHECK in order to have the
  configuration data within reasonable values
• Since no deletes and no updates will be run-
• Consider using IOTs (Index Organized Tables)
  (CREATE TABLE ORGANIZATION INDEX) to assure
  for future performance

46
Once the schema is ready

• When populating the tables (e.g. from
  configuration files) you might use the /APPEND/
  hint (example insert /append / into mytable
  values (1, 255))
• You can let the version column increment itself
  by creating a sequence and a trigger
• create or replace sequence myseq increment by 1
  start with 1 nomaxvalue nocycle
• create or replace trigger mytrigger before insert
  on mytable for each row begin select
  myseq.nextval into new.version from dualend/)

47
SPD
48
SPD
49
SPD
50
Hierarchical organization of DCS SPD FERO
configuration data version 2
1
2
20
120
SIDAVersion
SIDVersion PK
SECA0Version
SECA1Version
SEC0Ver FK
Halfstave 0
SECA2Version
Halfstave 0
SEC1Ver FK
Halfstave 1

HASA90Version
Halfstave 0
Halfstave 1
SEC2Ver FK
Halfstave 2
SPDVersion

Halfstave 0
Halfstave 1
Halfstave 2
HASVersion PK


SPDVersion PK
SECA9Version
Halfstave 0
Halfstave 1
Halfstave 2



MCMVer FK
SIDAVer FK
SECVersion PK
Halfstave 1
Halfstave 2


SEC9Ver FK
Halfstave 5
DACVer FK
SIDCVer FK
HAS0Ver FK
Halfstave 2


Halfstave 5
MASVer FK
SIDCVersion
HAS1Ver FK


Halfstave 5
SIDVersion PK


Halfstave 5
SEC0Ver FK

Halfstave 5
SEC1Ver FK
HAS5Ver FK
SEC2Ver FK


SEC9Ver FK
51
Hierarchical organization of DCS SPD FERO
configuration data version 2 continued
1
1
MBRVersion
MBRVersion Number(9) PK
Version 1 508 Tables 507 Primary Keys 3862
Foreign Keys
Version 2 147 Tables 146 Primary Keys 502
Foreign Keys
MBR Varchar(1640)
Redesign
52
Hierarchical organization of DCS SPD FERO
configuration data version 3
Version 3 4 Tables 4 Primary Keys 3 Foreign Keys
1
1
1
MBRVersion
MBRVersion Number(9) PK
MBRVect Varchar2(2460)
53
Connecting and disconnecting from a Oracle
database server using OCCI 10.2.0.1 and MSVC
.NET 2003 7.1.3088

• On a dual Xeon HT 2.8GHz, 3GB RAM, 2GB RAM for
  Oracle 10gR2, Win2003
• 0.184625s (1000 loops)
• 0.1836 s (100 loops)
• 0.186 s (10 loops)
• 0.266 s (0 loops)
• P4 HT 3.4GHz, 3GB RAM, 2GB RAM for Oracle 10gR2,
  WinXP
• 0.158344s (1000 loops)
• 0.15422 s (100 loops)
• 0.164 s (10 loops)
• 0.25 s (0 loops)
• P4 HT 3.0GHz, 1GB RAM, 0.7GB RAM for Oracle
  10gR1, WinXP
• 0.325016s (1000 loops)
• 0.32735 s (100 loops)
• 0.3531 s (10 loops)
• 0.391 s (0 loops)

54
Results of Oracle server tests

• Configuration Data download
• Blobs
• Big
• Small

55
Data Download from Oracle Server (BLOBs)

• Large BLOBS were stored on the DB server
  connected to private DCS network (1Gbit/s server
  connection, 100Mbit/s client connection)
• Retrieval rate of 150MB configuration BLOBs by 3
  concurrent clients was measured to be
• 3-11 MB/s/client
• Upper limit of 11MB/s corresponds to client
  network connection
• results depend on Oracle cache status, first
  retrieval is slower, succeeding access is faster
• Depending on detector access patterns, the
  performance can be optimized by tuning the
  servers cache

56
Test With Small BLOBs

• Test records consists of 10 Blobs with size 10kB
  each
• 260 configuration records were retrieved per test
• Allocation of BLOBs between configuration records
  altered
• From random
• To shared (certain BLOBs were re-used between
  configuration records) -gt to test the ORACLE
  caching mechanism

57
BLOB Retrieval Tests
58
Data Insertion Rate to the DB Server

• Data was inserted to 2 column table (number(38),
  varchar2(128), no index)
• Following results were obtained (inserting 107
  rows into DB)
• OCCI autocommit 500 values/s
• PL/SQL (bind variables) 10000 values/s
• PL/SQL (vararrays)
• gt73000 rows/s (1 client)
• gt42000 rows/s/client (2 concurrent clients)
• gt25000 rows/s/client (3 concurrent clients)

59
Data Download From Tables

• The FERO data of one SPD readout chip consists of
• 44 DAC settings/chip
• There are in total 1200 chips used in the SPD
• Mask matrix for 8192 pixels/chip
• 15x120 front-end registers
• The full SPD configuration can be loaded within
  3sec

60
Results of Oracle server tests (Data download)

• 150MB of configuration data, 3 concurrent
  clients, DCS Private 100Mbit/s network, 1Gbit
  switch
• Bfile 10.59 MB/s
• Blob 10.40 MB/s
• Blob, stream 10.93 MB/s
• Blob, ADO.NET 10.10 MB/s
• 150MB of configuration data, 1 concurrent client,
  CERN 10Mbit/s network
• Bfile 0.81 MB/s
• Blob 0.78 MB/s
• Blob, stream 0.81 MB/s
• Blob, ADO.NET 0.77 MB/s

61
AMANDA

• AMANDA is a PVSS-II manager which uses the PVSS
  API to access the PVSS archives
• Developed in collaboration with the offline team
• AMANDA is the only interface to the DCS archive
• Archive architecture (files/RDB) is transparent
  to AMANDA
• AMANDA can be used as an interface between the
  PVSS archive and non-PVSS clients
• AMANDA returns data for requested time period

62
AMANDA status

• AMANDA version 4.0 released
• Tests look promising (stable and smooth
  operation)
• Still being tested by offline
• Tool is ready for pre-installation

63
Operation of AMANDA
64
AMANDA in distributed system

• The PVSS can directly access only file-based data
  archives stored by its own data manager
• In a distributed system also data produced by
  other PVSS can be accessed, if the connection via
  DIST manager exists
• In case of the file-based archival DM of the
  remote system is always involved in the data
  transfer
• In case of RDB archival, the DM can retrieve any
  data provided by other PVSS within the same
  distributed system without bothering other DMs
• It is foreseen, that each PVSS system will run
  its own AMANDA
• There will be at least one AMANDA per detector
• Using more AMANDA servers overcomes some API
  limitations some requests can be parallelized
  (clients need to know which sever has direct
  access to the requested data)

65
AMANDA
User Interface Manager
User Interface Manager
User Interface Manager
AMANDA Client
API Manager
Control Manager
Archive Manager(s)
Archive Manager(s)
Archive Manager
Event Manager
AMANDA Server
Database Manager
Driver
Driver
Driver
PVSS-II
Archive(s)
66
AMANDA in the distributed environment (archiving
to files)
DIS
DIS
DIS
67
AMANDA in the distributed environment (archiving
to ORACLE)
DIS
ORACLE
DIS
DIS