1 of 1 people found this helpful
You are correct... we'd expect the primary archive file to shift once it is full instead of converting to AutoDyn and continue receiving data. So, I'm wondering whether an archive shift was scheduled but failed and could not be recovered such that all incoming data was redirected to the current and full primary archive, causing it to convert to auto-dynamic.
Could you please check the message logs on the PI server using the filter *Fixed-size archive was automatically converted to an auto-dynamic archive* or *[-30405] * and Severity set to Debug? Now that we know when the primary archive was converted to auto-dynamic, do you see any messages in the logs around the time of the conversion about archive shifts?
Also, could you please attach a screenshot of your Archive Tuning Parameters (PI SMT > Operation > Tuning Parameters > Archive)? And finally, which version of the PI Data Archive are you running (PI SMT > Operation > PI Version)? You mentioned PI DA 2012, but I'd like the version number as well.
Thanks for your response Michael. I will get back to you later with the detail in the log file, but I have the tuning parameters and version information for you. I'm not sure why there are minor variations in the file versions 3.4.390.16/ .18 I guess this is probably due to patches having been applied.
Archive Tuning Parameters:
Archives 5-0 match the file-name specification from the Archive_AutoArchiveFileRoot tuning parameters
So, looking at the message log has taken me deeper down the rabbit hole.
There are no entries in the message log matching filters *Fixed-size archive was automatically converted to an auto-dynamic archive* or *[-30405] * in the last 30 days. However, there are entries in the log indicating that backups have not run successfully since, oh, December 2017? Hmm, is the (in)ability to perform a backup linked to the failure to create a new archive file?
I am now looking into reasons why the (standard) backup would fail with the message 'Backup start failed, Status: [-16917] Backup in progress'.
The error suggests that a VSS backup is already in progress, as I know that only one VSS operation can be carried out at any one time. I don't think the -wait switch in the pibackup.bat file will be causing a task-overlap.
The backup is scheduled to run daily, here are the backup tuning parameters.
Executing from command prompt 'VSSADMIN LIST PROVIDERS' lists only the Microsoft VSS provider.
Executing from command prompt 'VSSADMIN LIST WRITERS' lists about a dozen. Against 'OSIsoft PI Server' is noted 'Retryable Error' - the same state is not mentioned for any other VSS writer.
Further investigation: looks like this might be an instance of Request Rejected as the error log for the first of the failed backups shows:
Through strangely there were multiple successful backups between when the server was last rebooted (1/Sep/2017) and these faults (13/Dec/2017)
So, further update; as soon as the piartool.exe -backup abort command was issued, a new archive file was created automatically and a shift took place with data now logged in the new primary archive. Curiously, the log event that the new archive file had been created appears in the message log before the notification that the backup had been aborted, but I am fairly certain that the later event caused the former.
It isn't clear from the logs how this state was entered in the first instance. The server had not been recently rebooted, and backups had occurred multiple times in the intervening period. The pibackup service had not bee restart since the previous successful backup that did complete correctly.
How are others handling execution of the piartool.exe -identify -numarch 1 command on a regular basis; is there any impact in running this before every backup to prevent this situation arising again?