Scheduling

Last updated on Jun 25, 2021

Contents

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.

/StatsMetrics
  Since    v5.7.0/17  
  Since    v5.7.5/11  


Set of metrics that hvrstats job must gather from the router files and HVR log files.

Available options are:

  • FULL: Gather all available metrics from router files and HVR log files.
  • LITE (default): Gather only the basic/important metrics from HVR log files. The basic/important metrics are highlighted using green color in Metrics for Statistics.

    The hvrstats job will still gather metrics from the router files for which the hist_time_gran is 0.

  • LITE_LOGONLY: Gather metrics only from the HVR log files. Metrics from the router files will not be gathered.

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.

This parameter only affects the hvrstats job. So, after defining/changing the value of this parameter, the hvrstats job must be restarted for the change to be effective.

/StatsGranularity
  Since    v5.7.0/17  
  Since    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:

  • MINUTE
  • 10 MINUTES (default)
  • HOUR

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.

This parameter only affects the hvrstats job. So, after defining/changing the value of this parameter, the hvrstats job must be restarted for the change to be effective.

/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.

UNBOUNDEDNever purge history rows. Rows continue to grow in hvr_stats.

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 : 207K rows
  • MEDIUM : 1222K rows
  • LARGE : 7M rows
  • UNBOUNDED : 75M rows

To purge the statistics data immediately (as a one-time purge) from the hvr_stats table, use the command hvrstats (with option -p).

Related topic, Statistics

/StatsCycleDelay
  Since    v5.7.0/17  
  Since    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.

This parameter only affects the hvrstats job. So, after defining/changing the value of this parameter, the hvrstats job must be restarted for the change to be effective.

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.