Skip to main content
Click here if you are having trouble viewing this site
Older versions of Internet Explorer will not support certain site features. Chrome, Safari, Firefox, and Edge will provide the best experience.
Resources
Spok

Data Retention

  1. Last updated
  2. Save as PDF

Explanation of the data storage process for the Smart Suite systems.


Data is stored in various tables throughout the database -- messages, page logs, on call assignments, and so on.  This data is stored in the "live" schema owned by the ATMS user.  In very old versions, this data was moved off of the database and stored as files on the operating system on a daily basis (for data older than 7 days).  Since recovering this data (such as requiring a month's worth of on-call schedules) was time consuming and tedious, it was decided to create a new schema to hold the data away from the live data, but still remain the database.  Since the size of the datafiles and disk space is finite, however, constraints had to be put on this archived data for storage.

Archive Process

After "x" days (as defined in /home/amcom/bin/archive.crn) the data is moved from the live (ATMS) schema to the archive (ATMS_ARCHIVE) schema, provided that the criteria for the move are met (messages have to have a date_archived assigned, that sort of thing).

The data is stored in the archive schema for "y" months (as defined in /home/amcom/bin/purge.crn).  The file that "is" the archive schema can become very large whether a customer has a lot of paging activity or not.  A smaller site (one with fewer listing records) may still create a large amount of archive data if there is a lot of paging and oncall assignment transactions and data changes going on.  A large site (with 30000 listing records) may generate very little data on a day-to-day basis.

Purge Process

Every month (on the 1st of the month), the purge script checks the data in the archive tables for "y" months ago.  This value by default is set to "13".  When the purge process takes place, data is selected from the archive tables where that data's month equals the current month minus 13; it does not mean "all data 13 months or more".  The purge process copies that data into the "PURGE" user's table and then removed from the archive tables.  Setting the "months" value to larger than this is not recommended.  Setting it to much larger means more data stored in the archive tables which means slowed response times when querying for data in the archive tables.  The archive tables themselves are also limited by the size of the datafile that "is" the archive schema and the size of the disk on the server where this file is kept.  Therefore, it might be possible to hold 14 or even 15 months' worth, but 24 / 36 / 48 / 60 + months worth wouldn't be possible with the standard configuration.  Typically, if this is changed, the value is moved down (6 months in the archive schema) and the exported purge files (below) dealt with afterwards.

Exported Data Files

The data from the purge tables is exported to files stored on the operating system (dump files, .dmp extension) and can be accessed at a later date for recovery (to run reports) via the Admin Menu utility.  These files are copied in to the larger backup file as part of the nightly backup process.  The purge process only happens from the server that is in PRIMARY mode, so it is normal to see exported files for some months on one server and exported files for other months on another server, depending which was PRIMARY and which was PHYSICAL STANDBY at the beginning of the month.  There is not currently a synchronization script for these files as there is for vru prompts.  These files are generally copied from old servers to newer servers during upgrades so that this data is not lost, and will stay on a server for as long as the customer wants (at the time of this writing, one customer has purge files seventeen years old -- from 1999 and through four upgrades -- on their server).

 

KB28508