Built-in tasks and sensors

The Scheduler contains built-in tasks and sensors that run automatically.

The following table shows the built-in Scheduler tasks and sensors. Sensors have results tables to store the information they collect, and retention periods to determine how long that information is stored. You can change task and sensor properties, for example, the frequency, by updating the ph_task table. Some tasks are triggered by thresholds. You can change thresholds by updating the ph_threshold table. You can disable a task or sensor by changing the value of the tk_enable column in the ph_task table to f.

You can determine how long tasks take by querying the run_duration column in the ph_task table.

Table 1. Built-in tasks and sensors
Task or sensor Description Results table Frequency Retention
add_storage This task add more storage space automatically when automatic space management is configured.   As needed  
Alert Cleanup This task removes all alert entries from the ph_alert table that are older than the threshold of 15 days. The threshold is named ALERT HISTORY RETENTION in the ph_threshold table.   Once a day  
auto_compress This task compresses tables that are configured for automatic compression.      
auto_crsd This task compresses, shrinks, repacks, and defragments tables and fragments.

By default, this task is disabled. You must enable it by updating the ph_task table.

Each of the operations has 2 rows in the ph_threshold table: one to control whether it is enabled and one to control its threshold.

For more information, see Scheduling data optimization.

  Once a week  
autoreg exe This task registers database extensions when they are first used.   As necessary  
autoreg migrate-console Internal. This task checks every database with a logging option of log or buffered log, and, if necessary, migrates all built-in database extensions to the correct version for the database server. This task creates sub-tasks for individual databases, as necessary.   At server startup  
autoreg vp This task creates a specialized virtual processor for a database extension as necessary.   As necessary  
auto_tune_cpu_vps This task automatically adds CPU virtual processors if the number of allocated VPs is less than half the number of CPU processors on the computer.   At server startup  
Auto Update Statistics Evaluation This task analyzes all the tables in all logged databases, identifies the tables whose distributions must be updated, and generates UPDATE STATISTICS statements for those tables, based on the current automatic update statistics (AUS) policies. The AUS policies are set by thresholds in the ph_threshold table:
  • AUS_AGE: statistics are updated after 30 days.
  • AUS_CHANGE: statistics are updated after 10 percent of the data is changed.
  • AUS_AUTO_RULES: guidelines are followed for updating statistics.
  • AUS_SMALL_TABLES: tables containing fewer than 100 rows always have their statistics updated.

For more information, see Automatic statistics updating.

  Once a day  
Auto Update Statistics Refresh This task runs the UPDATE STATISTICS statements generated by the Auto Update Statistics Evaluation task. The PDQ priority for updating statistics is set to 10 by the threshold named AUS_PDQ in the ph_threshold table.   Saturday and Sunday between 1:00 AM and 5:00 AM  
bad_index_alert This task checks for corrupted indexes. If any corrupted indexes are found, a warning alert is added to the ph_alert table.

For more information, see Validate indexes.

  Once a day  
bar_act_log_rotate This task rotates the ON-Bar activity log file that is specified in the BAR_ACT_LOG configuration parameter.

When the ON-Bar activity log rotates, the server switches to a new online message log file and increments the ID numbers for the previous log files by one. When the maximum number of log files is reached, the log file with the highest ID is deleted.

The threshold for the maximum logs to rotate is specified in the ph_threshold table.

  3 A.M. every 30 days (with a maximum of 12 log files)  
bar_debug_log_rotate This task rotates the ON-Bar debug log file that is specified in the BAR_DEBUG_LOG configuration parameter.

When the ON-Bar debug log rotates, the server switches to a new online message log file and increments the ID numbers for the previous log files by one. When the maximum number of log files is reached, the log file with the highest ID is deleted.

The threshold for the maximum logs to rotate is specified in the ph_threshold table.

  3 A.M. every 30 days (with a maximum of 12 log files)  
check_backup This task checks to ensure that backups have run since the time specified by thresholds in the ph_threshold table:
  • REQUIRED LEVEL BACKUP: maximum of 2 days between backups of any level
  • REQUIRED LEVEL 0 BACKUP: maximum of 2 days between level-0 backups

If a backup has not occurred, a warning alert is added to the ph_alert table.

  Once a day  
check_for_ipa This task adds an entry in the ph_alert table for each table that has one or more outstanding in-place alter operations.   Once a week  
idle_user_timeout This task terminates user sessions that have been idle for longer than 60 minutes.

By default, this task is disabled. You must enable it by updating the ph_task table.

For more information, see Automatically terminating idle connections.

  Every 2 hours  
ifx_ha_monitor_log_replay_task This task monitors the high-availability cluster replay position.   Not set  
ifx_TrickleFeed_load_ID This task continuously refreshed the data in a data mart. The name of the data mart and accelerator are listed in the task description. This task appears in the Scheduler after trickle feed is enabled for a data mart. Each data mart for which trickle feed is enabled has a separate task. The ID in the task name is unique.

For more information, see ifx_setupTrickleFeed() function.

  Every number of seconds that are specified when trickle feed is enabled  
mon_checkpoint This sensor saves information about checkpoints. mon_checkpoint Every hour 7 days
mon_chunk This sensor saves general information about chunk usage and I/O chunk performance. mon_chunk Every hour 30 days
mon_command_history This task deletes rows from the command_history table that are older than the threshold of 30 days. The threshold is named COMMAND HISTORY RETENTION in the ph_threshold table.   Once a day  
mon_compression_estimates This sensor saves information about how much space might be saved if the data is compressed. mon_compression_ estimates Once a week 30 days
mon_config This sensor saves the most recent value for each configuration parameter in the onconfig file. mon_config Once a day  
mon_config_startup This sensor saves the value for each configuration parameter in the onconfig file when the server starts. mon_config At server startup 99 days
mon_iohistory This sensor saves performance information about chunk I/O. You can change the IO_SAMPLES_PER_HOUR parameter in the ph_threshold table to collect information more frequently.   Every hour 30 days
mon_low_storage This task scans the list of dbspaces to find spaces that fall below the threshold specified by the SP_THRESHOLD configuration parameter. Then, the task expands the spaces by extending chunks or adding chunks using entries in the storage pool.

For more information, see Automatic space management.

mon_low_storage Every hour 7 days
mon_memory_system This sensor collects information about the amount of memory the server uses. mon_memory_system Every hour 7 days
mon_page_usage This sensor saves information about the pages that are used and free in storage spaces. mon_page_usage Once a day 7 days
mon_profile This sensor saves server profile information. mon_prof Every 4 hours 30 days
mon_sysenv This startup sensor saves information about the environment when the database server starts. mon_sysenv At server startup 60 days
mon_table_names This sensor saves table names along with their creation time. mon_table_names Once a day 30 days
mon_table_profile This sensor saves table profile information, including the total number of update, insert, and delete operations that occurred on this table. mon_table_profile Once a day 7 days
mon_users This sensor saves profile information about each user. mon_users Every 4 hours 7 days
mon_vps This sensor collects virtual processor information. mon_vps Every 4 hours 15 days
online_log_rotate This task rotates the online message log file that is specified in the MSGPATH configuration parameter.

When the online message log rotates, the server switches to a new online message log file and increments the ID numbers for the previous log files by one. When the maximum number of log files is reached, the log file with the highest ID is deleted.

The threshold for the maximum logs to rotate is specified in the ph_threshold table.

  3 A.M. every 30 days (with a maximum of 12 log files)  
post_alarm_message This task posts alerts.   Every hour  
purge_tables This task identifies rolling window tables whose purge policies have been exceeded. It discards or detaches qualifying fragments, according to each purge policy, until that policy is satisfied, or until no more fragments can be removed.   Daily at 00:45  
SET tk_enable This task enables the tasks that rotate message log files.   3 A.M. every 30 days  
sync_registry This task automatically converts the connection information between the sqlhosts file format and the Windows registry format.   Every 15 minutes  

Copyright© 2019 HCL Technologies Limited