SysStatusSFDataPending after upgrade

Hi, after upgrade from 2023 P03 to 2023 R2 our tier-1 and tier-2 historian has the system tag "SysStatusSFDataPending" set to true. Both of them are running on windows server 2022 with the latest verified patches, and SQL server 2022.

The tier-1 is receiving data from several platforms/engines in system platform (still running version 2023 P01). Non of them are, or have been in store & forward mode for days (good and stable gigabit connection) . Tier-2 is receiving data from tier-1 only.

How can I find the HCAL client (or other sources) causing the bit set to true?

Parents
  • This tag is independent for the "tier 1" and "tier 2" (e.g. the "tier 2" will not set this simply because it was set in the "tier 1"; it will only be set if it applies to sources directly sending to the "tier 2"), so treat them as separate issues.

    There aren't any system tags which would help isolate the specific source still reporting store-forward data. You might query for "full" retrieval on "SysStatusSFDataPending" to see if it has changed at all since it first became "true"--if it has, manually comparing those timestamps with OCMC Logger messages reporting connections could help you isolate the specific source. 

    Not very convenient, but you can also check the contents of each store-forward folder on the source system looking for the one(s) with "original.dat" (and potentially, "original-N.dat") files--these will be in the subfolder "A000000_001". Some may also have an "Events" subfolder with it's own "A000000_001" subfolder. 

    I did compare with one 2023 R2 (RTM) test system and I see "SysStatusSFDataPending" working as expected (e.g. sometimes NULL when first starting up, goes to "0" quickly, goes to "1" quickly, then returns to "0" not long after that and stays that way for a long time). One potential difference compared to your system is that all of the sources in my scenario are also on 2023 R2 and are using the new "HCAL" (gRPC-based) and not the "HCAL (classic)" (the older WCF-based one). Of course, this isn't supposed to make any difference, but it is an area of related code changes between 2023 and 2023 R2. 

    If none of that proves helpful, suggest following up with Tech Support. 

  • Hi Elliott, thank you pointing in the right direction. After spending some time inspecting store-forward folders, I could see that both the T1 and T2 Historian had a "original.dat" file in the "/StoreForward/LocalAutoSummaryReplication" folder. To resolve the problem I had to do the following:

    1. Stop & disable Historian.

    2. Delete the "LocalAutoSummaryReplication" folder.

    3. Start & enable Historian.

    4. Verify that the "LocalAutoSummaryReplication" is recreated and check logs.

Reply
  • Hi Elliott, thank you pointing in the right direction. After spending some time inspecting store-forward folders, I could see that both the T1 and T2 Historian had a "original.dat" file in the "/StoreForward/LocalAutoSummaryReplication" folder. To resolve the problem I had to do the following:

    1. Stop & disable Historian.

    2. Delete the "LocalAutoSummaryReplication" folder.

    3. Start & enable Historian.

    4. Verify that the "LocalAutoSummaryReplication" is recreated and check logs.

Children
No Data