Choose timezone
Your profile timezone:
Powered by Indico
v3.3.3-pre
We did a quick recap of the To Do lists and CTA Status Update. We are making steady progress. Details are on the individual tickets. Main points for this week:
Summary by Cédric.
Here is a summary of the meeting Steve and I had this morning (18/01/2021) with Sebastien Masson (DB).
1. Preparation for CTA schema 4.0
I have asked how I can run my migration scripts against a database that is a copy of the production one to ensure that there are no major issue with these scripts.
Sebastien proposed to do it by creating an empty database schema and do a data pump over the network. Our database data is around 100 GB so this is easily doable.
In order to do that, we will use the castorint database and a PL/SQL command has to be ran in order to perform this task (Sebastien will give me the instructions to do it).
I have to ask for a new schema for castorint on the CERN resource portal. The question is, by which service account the new schema should be owned?
Update during the meeting: Julien will create the service account and will set up a private area to keep track of service account passwords. In the meantime, Cédric can create the new schema on his own account and transfer it to the service account later.
2. Slowness of the query used to list the content of the tape
The query used to list the files contained in a tape (old_getTapeContent.sql) uses a hint to tell Oracle to use a specific index.
After some discussion about the problem, it appears that we may have to partition the TAPE_FILE table to have, for example, one partition per tape. But, we want to be sure that it works. Steve pointed out that there are two different use cases for listing files:
We have to be sure that this solution works for both of these use cases.
Sebastien said that partitioning an existing table with many rows in it takes time, but this can be done in online mode: the database can continue running while doing this operation. He nevertheless suggested that we do it in offline: we stop the production while the partitioning process runs.
New indexes can be created after we have partitioned the TAPE_FILE table. They can be local to a partition or global to the table.
According to Sebastien, the partitioning concept also exists in PostgreSQL but it might not be implemented or used the same way as Oracle.
To sum things up, the slowness of the query used to list the content of a tape needs more investigation on how to solve it properly.
3. Other business
Sebastien spotted that there are PARALLEL tables set on the CTA production database (I found out that the PARALLEL tables are the TAPE_FILE and the ARCHIVE_FILE ones). We will discuss this during the CTA development meeting this afternoon.
This is an artefact of the migration process. There is a script to clean up after the migration which removes the PARALLEL option, but this script was not executed after the CMS migration as there were several other tapes that had to be migrated immediately afterwards.
The CASTOR disk attached to tape servers is used only for repack. If we have FSTs running on tape server machines, they can be used for repack or for the retrieve space, but should not be used for archive space, to avoid the risk of interrupting data taking if we need to reboot a tape server.
Our current hardware consists of 64 machines, each with 32 TB SSDs = 2 PB total. Bandwidth is 2.5 GB/s × 64 = 160 GB/s total. We do not anticipate needing more than this in the near future. Vlado will therefore order 100 new tape servers without SSDs. We have the option of adding them (NVMe devices) later if we decide it's necessary.