What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)

  • 1 Pass_index ( I have to copy some simulation condition). Zoltan. Done

  • 2 Fill the processing_pass table (new productions).Script to be provided to add new productions to the book-Keeping, Zoltan. Done. Populate the processing pass table. Joel. Ongoing

  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan. Done

  • 4 Materialized view creation ( automatic or agent?). Zoltan thinks we do not need a view. After the migration, he will test how it works without using a view. The agent is done Zoltan. Miguel fixed the code, we decide we are not using agent for update Done

  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator). I can't remove because the active production BKK registration will fail. Ongoing

  • 6 We have to reimplement a materialized view. Zoltan. Done

  • 7 We have to change the BKK API, because I removed the DaqPeriod. Zoltan. Done

  • 8 Set the Simcondid as primary key in the simulationConditions table (Elisa). Done

  • 9 Find out which is the increase rate of jobs and file. Can we foresee how many new files and jobs will be inserted into the database per year? (Philippe)
1 grid-job = 6*BK-jobs where 1 grid-job has 500 events. So, if we set the total number of events to be simulated in 1 year equal to 2*10^9 it gives the total number: 2.4*10^7 BK-jobs per year + the real data. To be safe, let's say 4*10^7 new jobs in the BK per year. ok

  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade. Done

  • 11 Establish if the data, once inserted into the bk database, are read-only or can be removed. This is very important for Miguel, because it determines the type of backup he has to set for the DB. If they are read-only, he can make a much simpler and less expansive backup. The point is: in principle we are not going to remove entries from the BK, but we will want to update them! (got-replica flag and data quality) so I don't know if a read-only backup works in this case. Ask to Miguel

  • 12 Provide the list of objects which have to be migrated to the production system:

Tables

JOBS
FILES
INPUTFILES
CONFIGURATIONS
FILETYPES
EVENTTYPES
DATA_TAKING_CONDITIONS
SIMULATIONCONDITIONS
PROCESSING_PASS
PASS_INDEX
PASS_GROUP

Packages

BKK_ORACLE
BKK_MONITORING

Sequences

pass_index_seq
groupid_seq
PRODUCTION_SEQ
jobId_seq
fileId_seq
configurationId_seq
simulationCondID_seq

Triggers

jobs_before_delete

What to check before provide the new Bookkeeping system to the users:

After we migrated to production system we have to decide when retired the old system. we have same point what we have to solve.
We have 2 important point before we retried the old bkk:

* 1 genCatalog functionality

*2 We have to query the new bkk to gets the ancestors. (DIRAC3 has to use the new BKK.)

They are inportant points, but they are not very urgent:

* 3 testing the new GUI I recevied feedbacks from users. Ongoing

* 4 BKK instalation on local machine. Zoltan ( I will test the development system(volhcb04))

* 5 Bkk user documentation. Zoltan Ongoing

-- ElisaLanciotti - 17 Oct 2008

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2008-11-21 - ZoltanMathe
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback