...
- LCLS side: laci on lcls-daemon2: runLCLSPVcrawlerLx.bash: crawls LCLS PVs and creates lcls-specific tables (bsa_root_names, devices_and_attributes), copies LCLS client config files to dir where CD client crawlers can see them.
- LCLS side: laci on lcls-daemon2: caget4curr_ioc_device.bash: does cagets to populate curr_ioc_devices for the IOC Info APEX app. Run separately from the crawlers because cagets can hang unexpectedly – they are best done in an isolated script!
- CD side: cddev laci on slcs2lcls-prod01: runAllCDCrawlers.csh: runs CD PV crawler and all client crawlers, data validation, and sync to MCCO.
- FACET side: flaci on facet-daemon2: runFACETPVcrawlerLx.bash: crawls FACET PVs, copies FACET client config files to dir where CD client crawlers can see them.
...
time | script | cron owner/host |
|---|---|---|
8 pm | runFACETPVCrawlerLx.bash | flaci/facet-daemon1 |
9 pm | runLCLSPVCrawlerLx.bash | laci/lcls-daemon2 |
1:30 am | runAllCDCrawlers.csh | cddev laci/slcs2 lcls-prod01 |
4 am | caget4curr_ioc_device.bash | laci/lcls-daemon2 |
...
- If the drop is intentional: You will need to update the database manually to enable the crawler to proceed: the count difference is discovered by comparing the row count of the newly populated curr_pvs view with the row count of the materialized view curr_pvs_mv, which was updated on the previous day. If the PV count has dropped > 5000 PVs, the synchronization is cautious - it prevents updating good data in MCCO until the reason for the drop is known.
The step to say "it's ok, the drop was intentional or at least non-destructive - synchronization is now ok" is to go ahead and updated the materialized view with current data. Then the next time the crawler runs, the counts will be closer (barring some other problem) and the synchronization can proceed
So, to enable the crawlers proceed, you need to update the materialized view with data in the current curr_pvs view, like this:
log in as cddev laci on slcs2 lcls-prod01 and run
/afs/slac/g/cd/tools/irmis/cd_script/updateMaterializedViews.csh
The next time the crawler runs (that night), the data validation will be making the comparison with correct current data, and you should be good to go.
- If the drop is intentional: You will need to update the database manually to enable the crawler to proceed: the count difference is discovered by comparing the row count of the newly populated curr_pvs view with the row count of the materialized view curr_pvs_mv, which was updated on the previous day. If the PV count has dropped > 5000 PVs, the synchronization is cautious - it prevents updating good data in MCCO until the reason for the drop is known.
...