[foxboro] Rebuilding CSA database

  • From: Kevin Fitzgerrell <fitzgerrell@xxxxxxxxx>
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Thu, 8 Oct 2009 16:16:36 +0900

Hi all,
Just in case anyone else runs in to this problem, my work this afternoon may
save someone else some time.

We noticed a massive problem with our CSA database this morning.  An
engineer was trying to copy a block while creating a new one and ICC was
saying "Find Object" Failed.  I ran a CSA_Save and checked the files
generated, many of our control station CSA files from the save were empty.
Others are not completely empty, but don't have all their blocks.  I
confirmed in /opt/fox/csa that the idx files were effectively empty too.  I
suspect that somewhere during our move to the Mesh, or during a workstation
change-over, some engineer (could even be me) messed up a CSA_Merge.

After a conversation with TAC, we were advised that if
saveall/initialize/loadall is impractical (yes) to do a CSA_Save and then
manually edit in the missing or corrupted information in the same format.
An effective middle ground would be to build the CSA database up off-line on
a testbed by doing a loadall of each of the control stations.  Well, we have
around a hundred control stations, about half of which are affected, I
really didn't feel like manually entering 20,000 lines of CSA, and don't see
the need to build the database up off-line, so I wrote a little script to
create a CSA save for me based on iccprt output from the control stations.
We rarely use our work volumes, so I'm not recovering those, but they don't
appear corrupted or bad either, so I'm collecting them from the real CSA
save.

My script, build_csa_from_prt.sh is as follows:

#!/bin/sh
HOME="/opt/ts_group"
cd $HOME
mkdir save
PRT_FILES=`ls *.prt`
for FILE in $PRT_FILES
do
  OUT_FILE=`echo $FILE | sed 's/.prt//'`
  egrep '(^NAME|^  TYPE)' $FILE | sed -f merge_name_type.sed | sort -u | awk
'$3 ~/COMPND/{printf ("%-12s\n", $1)} $3 !~ /COMPND/{printf
("%-12s\t%-12s\t%-6s\n", $1, $2, $3)}' > $HOME/save/$OUT_FILE
done
echo "now copy volumes in from last CSA save on CSA server"
The "egrep" line is long and will probably wrap - starts with "egrep" and
finishes with "$OUT_FILE".  I have a current iccprt output from all of my
control stations in the directory I'm running this in, named STATIONLBUG.prt

There is a sed script used in there to take multi-line NAME and TYPE and
turn that in to a single line and edit appropriately.  The script
merge_name_type.sed looks like:
/^NAME/{
N
s/NAME   = //
s/:/ /
s/\n  TYPE   = / /
s/ COMPND/ # COMPND/
}
Additionally, you should check to see if there are any block name mismatches
between the control stations and the station work files.  There are a good
set of tools for checking mismatches as part of the OLUG toolkit, but I
wrote the following check_mm.sh script to compare the same STATIONLBUG.prt
files on a host to the checkpoint files on that same host for block
mismatches:
#!/bin/sh
HOST=`uname -n`
HOME="/opt/ts_group"
STATIONS=`grep $HOST /usr/fox/sp/sldb | egrep '(^CP|^GW|^AB)' | awk '{print
$1}'`
cd /usr/fox/sp/files
for STATION in $STATIONS
do
  /opt/fox/bin/tools/dbvu -p -CDB${STATION}.UC | egrep '(^ 200|:)' | egrep
-v '(200  CMP|^CHECKPOINT|^BPC)' | awk '{print $2}' > $HOME/mm_1.tmp
  grep "^NAME" $HOME/${STATION}.prt | awk '{print $3}' > $HOME/mm_2.tmp
  diff $HOME/mm_1.tmp $HOME/mm_2.tmp > $HOME/MM_${STATION}.out
done
cd $HOME
more $HOME/MM_*.out > $HOME/mismatch_report.$HOST

The "dbvu" line is long and will probably wrap.  It starts with
"/opt/fox/bin/tools/dbvu" and ends with "mm_1.tmp"

I do appreciate the reason for the separate databases, but given the
frequency that people have problems with them not being in-synch, I think
that we should have tools as part of the main distribution to rebuild and/or
re-synchronize.

Regards,

Kevin FitzGerrell


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts:

  • » [foxboro] Rebuilding CSA database - Kevin Fitzgerrell