Scheduling

From HVR
Jump to: navigation, search
Actions
Previous: LocationProperties
Next: None
Action Reference

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

Parameter Argument Description
/CaptureStartTimes times Defines that the capture jobs should be triggered at the given times, rather than cycling continuously.

For the format of times see START TIMES below.

/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 Defines that the integrate job should run after a capture job routes new data.
/IntegrateStartTimes times Defines that the integrate jobs should be triggered at the given times, rather than cycling continuously.

For the format of times see 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 Defines that the refresh jobs should be triggered at the given times. By default they must be triggered manually. This parameter should be defined on the location on the 'write' side of refresh.

For the format of times see START TIMES below.

/CompareStartTimes crono Defines that the compare jobs should be triggered at the given times. By default they must be triggered manually. This parameter should be defined on the location on the 'right' side of compare.

For the format of times see START TIMES below.

/StatsHistory size Size of history maintained by hvrstats job, before it purges its own rows. Available options for size are:
NONE History is not maintained by hvrstats job. Does not add history rows to hvr_stats.
SMALL History rows for per-table measurements at 1min/10min/1hour/1day granularity are purged after 1hour/4hours/1day/7days respectively.
History rows for all tables (table=*) at 1min/10 min/1hour/1 day granularity are purged after 4hours/1day/7days/30days respectively.
MEDIUM (default) History rows for per-table measurements at 1min/10min/1hour/1day granularity are purged after 4hours/1day/7days/30days respectively.
History rows for all tables (table=*) at 1min/10min/1hour/1day granularity are purged after 1day/7days/30days/never respectively.
LARGE History rows for per-table measurements at 1min/10min/1hour/1day granularity are purged after 1day/7days/30days/never respectively.
Rows for all tables (table=*) at 1min/10min/1hour/1day granularity are purged after 7days/30days/never/never respectively.
UNBOUNDED Never purge history rows. Rows continue to grow in hvr_stats.

If /StatsHistory is not defined then the default is MEDIUM.

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;

SMALL 207 K rows
MEDIUM 1222 K rows
LARGE 7 M rows
UNBOUNDED 75 M rows

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.

Example

/CaptureStartTimes="0 * * * 1–5" specifies that capture jobs should be triggered at the start of each hour from Monday to Friday.