| Hi there,
Well, I'll start with a caveat... I used the EXPORTER/REPORTER 3 years
ago... At the time, we had limited system resources and saw all kinds
of problems... ok, that being said.
I assume, *correctly*? that you're using an OpenVMS platform and this
is not an Ultrix implementation, yes? I don't think Rdb ran on
Ultrix...
That being said, you need to check things like the
MCC_EXPORTER-whatever.LOG file(s). You should check to ensure that
what you think you're exporting is actually being exported... It's been
some time, but I believe you can check the status of your exporting?
You might want to check the obvious stuff... are the rdb database files
being grown to the full extent you think they should be, or are you
running out of diskspace, etc. Do a SHOW ERR, to ensure you're not
seeing hard disk errors...
Check your batch queues, you need to setup a batch queue that has the
Rdb database filename in it, don't you? Make sure you have the proper
quotas, ie: WSQUOTA or whatever for your queues...
I seem to remember that if you try to export too much stuff, you start
losing things... for example, you might want to export line counters
for a routing circuit, as opposed to just blankedly exporting all
attributes of a router...
Sounds like you're sure that the REPORTER is in fact setup properly?
You have your CDD$TOP or whatever pointers setup properly in
SYLOGIN.COM? I've made mistakes like this in the past...
You didn't mention bridges, but you know you can't do much with
bridges? Never implemented...
You state that you're seeing a smaller period of time than you are
requesting, which leads me to believe it's either a typo... I make 'em
too ya know...smile. Or a system resource deal...
You might not want to hear this, but you should upgrade to V1.4, there
were some holes in V1.3 that I believe were fixed... I know there were
memory leaks once upon a time, could be the culprit...
Remember, if you get brave and upgrade, you'll have to change the CMA
libraries if you chose to upgrade VMS as well... See previous notes, I
think with my name in them about CMA$....whatever.
You might want to check in the Rdb notes conference and ensure the
version of Rdb you are using doesn't have any gotchas... You might have
to call Oracle, but they've got all the Rdb gurus...
Try creating a new domain, almost forgot, EXPORTING is domain specific,
isn't it? Create a new domain, try just 1 router or hub, or whatever,
submit a batch job with just that domain and Rdb file in it and see if
you see the same issues...
Of course, you've got the background processes setup properly, yes? Do
a few, DIR/SINC *.LOG's to see if you are seeing failures with your
batch jobs... you might have a SUBMIT/RESTART statement in your batch
job and perhaps, periodically you're losing your batch job and they are
getting resubmitted... remember, EXPORTing is extrememly resource
intensive... There were lots of bugs and don't know that they ever got
identified, let alone fixed...
Now that I've totally confused/perplexed you... good luck! Remember,
we started the REPORTER with datatrieve/CDD and the EXPORTER with Rdb,
we abandoned the REPORTER and there's been no development work done on
it in 2-3 years... how *GOOD* could it possibly be... 8^)
/Mic
|
|
Hi,
I am trying to help Fred solve this mystery. Just to restate the problem, we
are seeing holes in the data as it is stored in the RDB database. For example
if we have collected one sample every hour in a day, we would expect to see 24
samples in the database. Instead we might only get 10 samples for a particular
entitity. So for entity A, on a Monday we might miss data that should be there
from 09:00 to 13:00, while entity B has data for the whole day. Looking at the
same entities for data on the Tuesday, we find that both entities have data for
each hour of the day.
So here are some answers for .1
Yes, we are using OpenVMS platform.
After checking the exporter logs (MCC_EXPORTER_BACKGROUND.LOG;*), found the
3 different errors in some of the logs -
$ ver = f$verify(0)
SGK: Error attempting to close socket 5
Close
: mount device busy
%MCC-E-QREADERR, error reading queue file.
NETMAN job terminated at 4-APR-1996 05:18:07.44
Accounting information:
Buffered I/O count: 1721898 Peak working set size: 10244
Direct I/O count: 997548 Peak page file size: 109233
Page faults: 4303070 Mounted volumes: 0
Charged CPU time: 0 06:38:15.56 Elapsed time: 6 18:18:59.02
$ ver = f$verify(0)
%MCC-E-QREADERR, error reading queue file.
NETMAN job terminated at 28-MAR-1996 02:22:04.82
Accounting information:
Buffered I/O count: 199618 Peak working set size: 10244
Direct I/O count: 128841 Peak page file size: 75213
Page faults: 485115 Mounted volumes: 0
Charged CPU time: 0 00:43:30.16 Elapsed time: 0 19:25:41.81
$ ver = f$verify(0)
SGK: Error attempting to close socket 5
Close
: bad file number
Your guess is as good as mine as to what these mean.
The RDB files are definately growing. We might miss a couple of hours data on
a Monday say, and have a full days data on the Tuesday. This thing is not
stopping totally, just occasionally, and then restarting.
SHOW ERROR gives no clues. Disk space is not a problem. Queues setup ok -
AHY1V1>sh que/bat/all *export* /full
Batch queue EXPORT$BATCH, available, on AHY1V1::
/BASE_PRIORITY=3 /JOB_LIMIT=4 /OWNER=[NETMAN] /PROTECTION=(S:E,O:D,G:RW,W)
Entry Jobname Username Status
----- ------- -------- ------
559 MCC_EXPORTER_BACKGROUND
NETMAN Executing
Submitted 4-APR-1996 18:24 /KEEP
/PARAM=("DISK$MCC:[REPORTS]MCC_DB.RDB","30") /NOPRINT /PRIORITY=100
/RESTART=EXPORT$BATCH /WSEXTENT=10240
File: _AHY1V1$DKA0:[SYSCOMMON.SYSMGR]MCC_EXPORTER_BACKGROUND.COM;9
AHY1V1>sh lo disk$mcc
"DISK$MCC" = "AHY1V1$DKA100:" (LNM$SYSTEM_TABLE)
AHY1V1>sh dev d
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
AHY1V1$DKA0: Mounted 0 VAXVMSRL054 300378 491 1
AHY1V1$DKA100: Mounted 0 MCC 312045 177 1
AHY1V1$DKA200: Mounted 0 DATA 7578 10 1
DAD0: Online 0
Exporting too much stuff, well that might be a possibility as we are exporting
on CISCO interfaces (all attributes by default). Not sure if we can reduce the
scope for this.
We are not exporting on bridges, we are exporting on SNMP devices, spefically
CISCOs ( and also Chipcom Hubs).
V1.4 upgrade, well normally I would have also suggested this, but in this case
we are avoiding any upgrades as this site may well be disappearing after June,
so we don't want to invest the time of upgrading.
Seeing the EXPORTER is teeming with bugs, we may have to look at upgrading.
Would be good to get this going as it is.
Cheers,
Louis
|