Scheduling
Description
Action Scheduling controls how the replication jobs generated by Hvrinit and Hvrrefresh will be run by Hvrscheduler. By default, (if this Scheduling action is not defined) HVR schedules capture and integrate jobs to run continuously. This means after each replication cycle they will keep running and wait for new data to arrive. Other parameters also affect the scheduling of replication jobs, for example Capture /ToggleFrequency.
If this action is defined on a specific table, then it affects the entire job including data from other tables for that location.
A Scheduling action is only effective at the moment that the job is first created, i.e. when HVR Initialize creates capture or integrate jobs or when HVR Refresh creates a refresh job. After this moment, redefining this action has no effect. Instead, the scheduler's job attributes (such as trig_crono) can be manipulated directly by clicking the Attributes tab while inspecting a job in the HVR GUI.
Parameters
This section describes the parameters available for action Scheduling.
| Parameter | Argument | Description |
|---|---|---|
/CaptureStartTimes | times | Trigger the capture jobs at the given times, rather than cycling continuously. For the format of times see section Start Times below. Example, /CaptureStartTimes="0 * * * 1–5" specifies that capture jobs should be triggered at the start of each hour from Monday to Friday. |
/CaptureOnceOnStart | Capture job runs for one cycle after trigger. This means that the job does not run continuously, but is also not triggered automatically at specified times (the behavior of /CaptureStartTimes). Instead, the job stays PENDING until it is started manually with command Hvrstart. | |
/IntegrateStartAfterCapture | Run the integrate job after a capture job routes new data. | |
/IntegrateStartTimes | times | Trigger the integrate jobs at the given times, rather than cycling continuously. For the format of times see section Start Times below. |
/IntegrateOnceOnStart | Integrate job runs for one cycle after trigger. This means that the job does not run continuously, but is also not triggered automatically at specified times (the behavior of /IntegrateAfterCapture or /IntegrateStartTimes). Instead, the job stays PENDING until it is started manually with command Hvrstart. | |
/RefreshStartTimes | times | Trigger the refresh jobs at the given times. For the format of times see section Start Times below. By default they must be triggered manually. This parameter should be defined on the location that is on the 'write/right' side of HVR Refresh. |
/CompareStartTimes | crono | Trigger the compare jobs at the given times. For the format of times see section Start Times below. By default they must be triggered manually. This parameter should be defined on the location that is on the 'write/right' side of HVR Compare. |
/StatsMetricsSince v5.7.0/17Since v5.7.5/11 | Set of metrics that hvrstats job must gather from the router files and HVR log files. Available options are:
For HVR versions prior to 5.7.0/17 and 5.7.5/11, all available metrics are gathered and it is not configurable to select a set of metrics.
| |
/StatsGranularitySince v5.7.0/17Since v5.7.5/11 | min | Time granularity based on which the hvrstats job gathers metrics from the router files and HVR log files. Available options are:
For HVR versions prior to 5.7.0/17 and 5.7.5/11, the granularity is 1 minute and it is not configurable to select a different time granularity.
|
/StatsHistory | size | Size of history maintained by hvrstats job, before it purges its own rows. Available options for size are:
A smaller policy will reduce the amount of disk space needed for the hub database. For example, if a hub has 2 channels with same locations (1 capture and 2 targets) and each has 15 busy tables measured using 10 status measurements, then the following is the approximate number of rows in hvr_stats after 1 year:
Related topic, Statistics |
/StatsCycleDelaySince v5.7.0/17Since v5.7.5/11 | secs | Time delay between metric gather cycle. After each time the hvrstats job gathers metrics from the HVR log files the hvrstats job waits for secs time. The default delay is 60 seconds. For HVR versions prior to 5.7.0/17 and 5.7.5/11, the delay is 5 seconds and it is not configurable to select a different time delay.
|
Start Times
Argument times uses a format that closely resembles the format of Unix's crontab and is also used by scheduler attribute trig_crono. It is composed of five integer patterns separated by spaces. These integer patterns specify:
- minute (0–59)
- hour (0–23)
- day of the month (1–31)
- month of the year (1–12)
- day of the week (0–6 with 0=Sunday)
Each pattern can be either an asterisk (meaning all legal values) or a list of comma–separated elements. An element is either one number or two numbers separated by a hyphen (meaning an inclusive range). All dates and times are interpreted using the local–time. Note that the specification of days can be made by two fields (day of the month and day of the week): if both fields are restricted (i.e. are not *), the job will be started when either field matches the current time. Multiple start times can be defined for the same job.