Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/sci/libraries/SPIE2008/7016-47poster.pdf Дата изменения: Thu Jul 3 14:02:50 2008 Дата индексирования: Sat Sep 6 07:25:58 2008 Кодировка: Поисковые слова: star trail

E S O sc a l a b l e a r c h i t e c t u r e f o r o p e r a t i o n a l d a t a b a ses
I. Vera A. Dobrzycki, A. M. Chavan, P. Nass, J. S. Lockhart European Southern Observatory, Karl-Schwarzschild-Str 2, D-85748 Garching, Germany
1. MOTIVATION
!Operations at observing sites should have quick and reliable access to the data, therefore observing sites are provided with their own local database server.

3. SERVICE MODE OPERATIONS
Standard service mode operations: !OBs produced by investigators are submitted to Garching. !OBs are reviewed, accepted and scheduled from Garching.

4. VISITOR MODE OPERATIONS
Standard visitor mode operations: !OBs produced by investigators are directly executed in the observing sites. !OBs are stored in the local repository for archiving purposes. !OBs are replicated to the headquarters.

5. OB RECOVERY STRATEGY
!It is possible that already archived OBs will have to be executed again by means of the OB recovery strategy. !OBs moved to the operational database at Garching are replicated to the operational database at the observing sites by the same mechanism used for standard service mode Obs.

!Synchronization of the database servers is done through replication.

!OBs are replicated to the observing sites and executed by ESO staff.

!After several years of operations, databases at the observing sites has grown considerably. There was no standard procedure for removing data kept only for archiving purpose.

Standard procedures build into the ESO repositories for archiving data no longer necessary for operations.

2. MOVING TO A SCALABLE ARCHITECTURE
OBs are executed in two modes: !Service mode: OBs controlled from headquarters and replicated to Observing sites for execution. !Visitor mode: OBs directly executed in the mountain. Two main issues: !Visitor mode OBs only at the observing sites. !No distinction between current operational OBs and historical OBs Archiving procedure for Service Mode !Run every six months Y F5BZ2 standard observing period. !It removes OBs from Service Mode observing runs that are one and a half years old. !The process is initiated in Garching by executing a stored procedure. !The stored procedure invocation is replicated and a stored procedure is executed in the observing sites. Archiving procedure for Visitor Mode !Run every month at the observing sites. !It removes OBs from Service mode observing runs that are 30 days old. !The process is initiated in the observing sites by running a stored procedure.

6. CONTENT MANAGEMENT
Data consistency check is performed following two rules: ! All data in the operational repository at Garching must be returned from the SM views at the observing sites ! All data returned by the VM views at the observatory must exist in the historical repository at Garching.

7. CONCLUSIONS
!Operational databases contains only data that might be necessary for operations at the observing sites. !Operational databases are kept in a more or less constant size. !Archived data are only kept in the headquarters.

LEGEND
A stored procedure is a set of Structured Query Language (SQL) statements with an assigned name. It is stored in the database and the major bene fit of this technology are the substantial performance gains from precompiled execution.

!Database content management is easy to perform in small databases.

REFERENCES
sp_
[1] Chavan" $. &." ' $()*+,-." &. $." /$ 012.*1)3.+4 562.+7 89* /:-;2+ II= :*9>92;( :*+>;*;.19?=" $5: @9?8. 5+*. Vol, 125, Astronomical Data Analysis Software and Systems VI, 367-370 (1997). [2] Chavan, A. M. , Giannone, G., Silva, D., Krueger, T., & Miller, G. E., "Support tools for the VLT operations: the NTT prototyping experience",Proc. SPIE 3349, 97 (1998).

view

A database view is a virtual table composed of the result of a query. The main advantage used for ESO approach is the possibility of subset t he data contained in a table.

[3] Chavan" $.&." +. ;(." /$ A*9?.-End System for the VLT's Data Flow System', in B)2+*C;.9*6 B>+*;.19?2 .9 B>.171D+ 5,1+?.181, E+.3*?=" :*9,. 5:IF GHIH JKHHHL
the Phase 2 Proposal Preparation (P2PP) system [1,3] allows astronomers to prepare their observations at their home or insti tutions, while maintaining a central repository for all observation data.
The new architecture solves the issues by means of: !Replication of Visitor Mode OBs from the observing sites to the headquarters. Database replication is the process of sharing information between databases . In ESO architecture is done in two ways:

[4] GrosbЬl" :. ' :+*9?" &." /M-+ NOM 0;.; A(9P @9?,+>.=" 1? $5: @9?8. 5+*." N9(. 125, Astronomical Data Analysis Software and Systems VI, ed. G. Hunt & H. E. Payne (San Francisco: ASP) (1997) QRS T31??" :.U." +. ;(." /NOM 0;.; A(9P 562.+7V A*97 @9?,+>.2 .9 B>+*;.19?2=" 1? Observatory Operations to Optimize Scientific Return, Proc. SPIE 3349 (1998) QWS T31??" :.U." +. ;(." /M-+ F5B 0;.; A(9P 562.+7 1? B>+*;.19?2V @(921?X .-+ 0;.; O99>=" in Observatory Operations to Optimize Scientific Return, Proc. SPIE 4010 (2000)

!Creation of a historical repository at the headquarters to hold all the OBs for archiving.

!Replicating data-changing operations. !Replicating stored procedure invocations.