I had/have a similar problem where SA was months out of date.
PASUP had me run "bin\update_foxray foxray.db login" from the SA command prompt.
The point at which things were blowing up was visible there ("DBD::mysql::db do
failed: Data too long for column 'TAGTYPE' at row 1 at UPDATE_foxray.pl line
2285, <STAR_DEF> line 1135.").
I had to go to the problematic (the node throwing the above error) node's
'SYSTEMX' folder temporarily move all the .ready and .configx files out of the
folder so that the import wouldn't crash on the problem files.
It took several days for it to update all the backlogged .configx and .ready
files.
It still stops occassionally (is four days behind as I type this).
PASUPPORT still hasn't provided a root cause on this.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> On Behalf Of
Duc M Do
Sent: Wednesday, December 9, 2020 10:57 AM
To: foxboro@xxxxxxxxxxxxx
Cc: QUEIROLO, IGNACIO ESTEBAN <ignacio.queirolo@xxxxxxx>
Subject: Re: [foxboro] System Auditor missing block
Ignacio,
Great! Now you have information to say that the problem is isolated to just one
database/network.
You mentioned that you see files in the SYSTEMX directory, but no mention of
any in the companion HLBLX/PLBX directories. Unless you have
*no* sequence blocks or PLB blocks in your system, the absence of these files
can be indicative of some problems. What those problems are, I cannot say from
here without seeing the system. But this could be where you concentrate on
digging into why there are files in SYSTEMX and not HLBLX/PLBX.
If, however, you really do not have sequence/PLB blocks in this system, then
the absence of files in these directories is correct. I'd start looking closely
at the files in SYSTEMX, particularly their timedate stamps, which could clue
you in when your problem started.
Duc
On 2020-12-09 07:28 AM, QUEIROLO, IGNACIO ESTEBAN wrote:
Duc, I checked today and 2 of 3 DB worked fine, one of them still have
the files in SYSTEMX folder at SA server. The transfer of the files
from the DCS to SA server is functioning properly for all 3 DCS. The
issue now is with just one DB which is the last DB listed in foxray.db
file. One point to mention is that the slow_import task it is
scheduled every 1 hour, not 8. This was done by the service engineer
when we installed Foxray almost 5 years ago.
Regards,
Ignacio
-----Mensaje original-----
De: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> En
nombre de Duc M Do Enviado el: martes, 8 de diciembre de 2020 17:35
Para: foxboro@xxxxxxxxxxxxx
Asunto: Re: [foxboro] System Auditor missing block
Ignacio,
Yes, the racing condition that sometimes happens between Checkpoint
Spy and the IA system itself can cause problems, and that's why
Ricardo introduced the wait.dat file to slow down Checkpoint Spy. Hope
you have pinpointed the source of your problem.
Regards,
Duc
On 2020-12-08 03:25 PM, QUEIROLO, IGNACIO ESTEBAN wrote:
Thanks Duc! I think that now is working fine. I am testing it doing
some checkpoints from System Manager and I see the files you
mentioned. At the first try, the file .configx had only 4 lines for
one CP. So, I added a delay of 60 seconds to the file wait.dat in
D:\opt\foxray\login folder and I checkpointed again the same CP, and
this time the file contains much more information.
Regards,
Ignacio
-----Mensaje original-----
De: Duc M Do <duc@xxxxxxxxxx>
Enviado el: martes, 8 de diciembre de 2020 17:04
Para: foxboro@xxxxxxxxxxxxx
CC: foxboro-bounce@xxxxxxxxxxxxx; QUEIROLO, IGNACIO ESTEBAN
<ignacio.queirolo@xxxxxxx>
Asunto: Re: [foxboro] System Auditor missing block
Ignacio,
The source(s) of your problem can be one (or more) of several:
1. Like Philip Pulas mentioned, the Checkpoint Spy on your CP host
may not be running, or running but not functioning properly. If
you're running Solaris, then Checkpoint Spy is started as a daemon.
Run 'ps -eaf' to see if it's running. If you're on Windows,
Checkpoint Spy is a service and is started automatically upon the AW
booting up; check the list of services to see if it's running.
2. A week ago, Matt Gunter had a somewhat similar problem with his
Foxray/SA installation, and it turns out the data transfer between
the data collector (AW) and the SA server failed. You can try
manually running an ftp session between your AW and the SA server to
make sure ftp is still functioning correctly.
3. Check the directories where the collected data are kept on the AW
(/opt/foxray/login/SYSTEMX, HLBLX, and PLBX), these files are
aggregated here before being transferred to the SA server, then
deleted. If you see a large collection of files here, that's a
telltale sign that the data transfer is not happening properly.
4. Likewise, check the directory on the SA server where it keeps the
data sent by the AWs. This should be below your installed SA
directory, something like $FOXRAY\<network>\SYSTEMX, HLBLX, and PLBX.
There can be multiple files with the extension .configx and .ready,
but these should not be older than the interval that slow_import.bat
is scheduled to run (ie. if slow_import.bat is run three times a day
at equal intervals, these files normally should not be older than 8
hours). If there are a collection of files here, then your import
batch file is not functioning properly, or the database updating
component, Update_Foxray.exe, is not working properly.
Hopefully this simple troubleshooting guide helps you.
Duc
Two months ago, I have added a new block to a DCS with System
Auditor
(SA) and the new block does not appear in SA database. Any thoughts?
Thanks in advance.
Ignacio
