Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ActionsDescriptionSchedule
Bulk delete recordsThe action deletes records in a bulk operation where the retention has expired or a matching deletion policy is configured. The data management policy which is executing the deletion only marks the records in the database for deletion and the bulk delete job deletes the records ultimately from the database tables.Daily
Move data from temporary tables to the final tables

The action moves data from temporary tables which store data for 15 minutes only to the final tables where the data resides for the long term. The move job runs on the following tables:

  • section1 -> section2
  • section_meta1 -> section_meta2
  • marker1 -> marker2
  • section_participant1 -> section_participant2
  • section_cdr_media1 -> section_cdr_media2
  • section_file1 -> section_file2
  • section_centera1 -> section_centera2
  • storage_executed_action1 -> storage_executed_action2
  • call_export_log1 -> call_export_log2
  • section_message1 -> section_message2
Every 15 minutes
Rebuild indexes

The action rebuilds indexes where the fragmentation is greater than 30% on all tables

Daily
Reorganize indexes

The action reorganizes indexes where the fragmentation is greater than 5% on all tables

Daily
Extend partitions

The action creates new partitions for the next 5 months and merges partitions with a small amount of data for the following tables:

  • section2
  • section_archived
  • section_message2
  • section_meta2
Daily

...

The Verba Maintenance SQL Agent Jobs are automatically created in the Primary Replica during the installation. The jobs must be created on the Secondary Replicas manually with the provided update-programs-maintenance-job.sql script. This script must be executed in the Secondary Replicas after an upgrade of the system too because new jobs may be added to the product.

The Jobs will be started on the Secondary Replicas too based on the schedule but will do nothing because the job checks the state of the replica and will immediately stop the execution on the Secondary Replicas. This way the jobs will be running on the new Primary Replica after a failover.

...