Problem Statement

Users might encounter an error like this when searching for tag history:



Error reading historical repeat area: Disk history read error -1021 at line 1

This message can be seen in the Aspen SQLplus Query Writer and might also be seen elsewhere, like in Aspen Process Explorer.  Some history may be returned, but not all of the requested history.  What can be done to fix the problem?

Troubleshooting Suggestions

The problem ultimately can be fixed by doing a repair on the history filesets in the appropriate history repository.

Because repairing file sets can be very time-consuming, it's preferable to narrow down the range of filesets which need to be repaired.

Try these steps:

1.  Tags typically write to a single history repository but they could write to more.  IP_AnalogDef records have three historical repeat areas and each could be set differently.  The first thing to be done is to make sure of the appropriate history repository.  If a user wanted the usual value, quality, and timestamps from an IP_AnalogDef record then the history repository designated by the IP_REPOSITORY field would contain the filesets for us to check (yellow highlight in screenshot below).  If, for some reason, the Best Fit values were being requested then the IP_BF_REPOSITORY field would specify the corresponding repository (green highlight below).  Finally, if alarm-related values were being requested then the IP_ALARM_REPOSITORY would need to be consulted (orange highlight below). 




Note that different types of records, like PMCAnalogDef for instance, might designate the history repository using different field names.


2.  Now that the repository is known we next need to discern which file sets to repair.  If you don't want to do the process below then you could repair all the file sets for a specific repository, but that could take quite a bit of time (perhaps hours).  A query like the one below could be used to begin narrowing down which file sets need to be repaired.  The tag in this example is called "Feed":
 
The query above would go back from the present to the first of January, 2022, at midnight and return the history values it finds.

The query will either produce the error or it won't.

If it produces the error, then some amount of file sets in that date range need to be repaired.

If it does NOT produce the error then the query could be done on another different (older) date range.

Let's say it DID produce the error.  You could narrow it down by doing a query like this (let's pretend today is December 16, 2022 and it is noon) to get values from now back to July 01:
 


At this point it will require a judgment call on your part.  If the date range where the problem is happening covers  a small amount of filesets it would probably be best to go ahead and repair them.  But if there are many filesets then it might be worthwhile to use the SQLplus queries to narrow down the time range some more.

Generally speaking the smaller the fileset size (in terms of MB) the quicker the repair will be.

3.  You might need to run queries again and repeat the process for *older* time periods (for example from January to December 2021) to see if the problem appears for other date ranges.

In at least one instance a request for all data was made (back to the oldest data available) and then time subdivided from there going back toward the present to help narrow down the problem locations.

4.  To perform the history repairs, open the Aspen InfoPlus.21 Manager and select 'Actions' | 'Repair Archive'.

After the repairs complete try to access the data again.