4 Replies Latest reply on Apr 25, 2018 3:26 PM by C-V-S

    Primary Archive Changed to AutoDyn instead of Shifting to New Archive


      I am relatively new to Historian administration and the system I am looking at now doesn't seem to be behaving as I would expect after reading the manuals.


      This server has 7 archive files, ranging in age from 2015 to current, with the Primary archive having a start-time of 9/18/2017. This is not a big system, < 600 tags logged. The existing archive files are all Fixed size, 1024MB, with the exception of the Primary archive, which is (now) nearly 1500MB. It is also no longer Fixed, but AutoDyn.


      As I understand it, with PI 2012 if no empty archive is available to shift into, the latest archive will be converted to AutoDyn and logging will continue until the disk is full. However, all archives are reported as shiftable, and the next shift is expected 27-Apr-2018, supposedly overwriting the oldest archive file. I am not sure if this will happen or not - My my reckoning this shift, if it were going to happen, should have happened when the current archive reached capacity, not after it had converted to AutoDyn.


      The other thing that has me scratching my head, is that Auto Archive File Creation is enabled - a path is specified in the Archive_AutoArchiveFileRoot tuning parameter, along with Format and Extension parameters. There is more than sufficient free disk space (~100GB) for new archive files to be created before the existing archives are overwritten.


      Could anyone shed some light on why the system is behaving in this way? I expect that the solution will involve manually creating a new archive and forcing a shift, but I would like some plausible explanation on how this scenario came to be.

        • Re: Primary Archive Changed to AutoDyn instead of Shifting to New Archive

          Hey, Christopher.


          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.



          1 of 1 people found this helpful
            • Re: Primary Archive Changed to AutoDyn instead of Shifting to New Archive

              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:


              Version Information:


              Archive properties:

              Archives 5-0 match the file-name specification from the Archive_AutoArchiveFileRoot tuning parameters


                • Re: Primary Archive Changed to AutoDyn instead of Shifting to New Archive

                  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)

                    • Re: Primary Archive Changed to AutoDyn instead of Shifting to New Archive

                      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?