Re: [foxboro] Legacy historians stop collecting messages
- From: "Thefs, Stephen" <sthefs@xxxxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 30 May 2011 14:44:57 +1000
Hello Kevin,
Is your Informix database running out of space? As shown in your email, the
"Number of data bytes" for opraction is 37378530. This is a large table.
I have a Foxboro document (HH528 dated July 1993) which shows how to add extra
space to the Informix database while it is online.
Note: This document says the tbcheck command reports size in 2KB blocks.
"tbstat" also reports size in 2K blocks.
You can use 'tbstat -d' to check free space in the Informix database. In the
example below there is 31294*2KB, or about 62 MB free.
Chunks
address chk/dbs offset size free bpages flags pathname
100129e8 1 1 150 36765 31294 PO- /dev/md/rdsk/d3
My guess is that you need about 6.4 MB of free space in your database for the
opraction table to grow as the "Next extent size" = 3204 (3204 * 2KB).
The following is from HH528. I have used it many times to extend the size of
our Informix databases. It creates a file called "cooked" (or whatever you
what to call it) to extend the database, as opposed to the first chunk which is
a raw partition.
Example:
Use "tbspaces" to add a 50Mb chunk to the raw Informix partition.
The example will take space from the /opt partition and add it to the raw
partition.
Note: The space should be taken from the /opt partition because this is the
largest partition.
Make sure the /opt partition has enough space before running "tbspaces" to add
a chunk to the raw partition. (Use df command)
# setenv INFORMIXDIR /opt/informix
# setenv PATH ${PATH}:/opt/informix/bin
# cd /opt/informix/bin
# touch cooked
# chmod 666 cooked
# chgrp informix cooked
# chown informix cooked
# tbspaces -a rootdbs -p /opt/informix/bin/cooked -o 0 -s 50000
Notes:
* -a parameter = add.
* -p parameter = pathname.
* -o parameter = offset.
* -s parameter = size (in Kbytes).
* Type "tbspaces" for more help.
# ls -l /opt/informix/bin/cooked
-rw-rw-rw- 1 informix informix 51200000 May 30 13:17
/opt/informix/bin/cooked
'tbstat -d' will now list two chunks.
You could have a weekly cron job that runs 'tbstat -d' to monitor database free
space.
Regards
Stephen Thefs
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Kevin Fitzgerrell
Sent: Monday, 30 May 2011 9:48 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Legacy historians stop collecting messages
Hi all,
We've mostly transitioned from IMAC collecting messages from COM10s to
Foxray, and so rely on collecting OAJ messages from the legacy historians.
Over the last few days I've had to put together sequence of events for a
couple incidents indifferent plant areas and found that 2 of our 12 legacy
historians had not been collecting messages for a LONG time. One has not
collected messages since 2009. The other started collecting messages again
last month after the historian was "optimized" (initialized and re-loaded
from control station ordered list via cfgpts).
I remember frequent problems with historian message collection stopping back
15+ years ago - if we changed the number of messages in a given group, that
group would grow to fill the partition, but also remembered Foxboro fixing
that at some 4.x version.
I'm really looking for suggestions on 3 things:
1) I'd like to get message collection back working again without
initializing the historian.
2) Ideas on what went wrong and how to keep it from happening again
3) Ideas on how to promptly identify this failure if it occurs again
Initially I'll probably write a script to check the opraction table each
week to make sure there are messages < 1 week old to identify whether the
messages collection is working. If I can't figure any other way to get
messaging back online I'll drop all the message related tables and recreate
them with collect_msg_2.
When I run tbcheck -pe I get no errors.
When I run tbcheck -pc I see (I think) what I expect for the opraction
table:
TBLSpace hist10:root.opraction
Physical Address 100036
Creation date 08/24/10 09:59:46
TBLSpace Flags 2 Row Locking
Maximum row size 135
Number of special columns 0
Number of keys 1
Number of extents 6
Current serial value 1208375
First extent size 6408
Next extent size 3204
Number of pages allocated 21458
Number of pages used 21458
Number of data pages 19777
Number of data bytes 37378530
Number of rows 276878
Extents
Logical Page Physical Page Size
0 101b27 6408
6408 103753 3204
9612 104b33 3204
12816 105f13 3204
16020 107433 3204
19224 1086e3 2234
I do get the normal warnings at the end of the tbcheck -pc:
WARNING:No syscolauth records found.
WARNING:No sysdepend records found.
WARNING:No syssyntable records found.
WARNING:No sysviews records found.
Cheers,
Kevin
The contents of this electronic message and any attachments are intended only
for the addressee and may contain legally privileged, personal, sensitive or
confidential information. If you are not the intended addressee, and have
received this email, any transmission, distribution, downloading, printing or
photocopying of the contents of this message or attachments is strictly
prohibited. Any legal privilege or confidentiality attached to this message and
attachments is not waived, lost or destroyed by reason of delivery to any
person other than intended addressee. If you have received this message and are
not the intended addressee you should notify the sender by return email and
destroy all copies of the message and any attachments. Unless expressly
attributed, the views expressed in this email do not necessarily represent the
views of the company.
_______________________________________________________________________
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:
