At least some of the symptoms you mention are probably attributable to the
(potentially large) number of stub objects in your database. Those stubs do
actually get polled during the daily config poll. This is to see if they
have
'turned into' something that meets the criteria of your seedfile. So first
off,
make sure the ovwdb cache setting is high enough to accomodate that large
number of ojbects. Use the number you get from 'ovobjprint -S' a day or so
after the last ovtopofix. Then think of a way to limit your seedfile by
address
range that will keep out big chunks of these things. For instance, you
might
exclude the DHCP ranges for some of your largest subnets. Taking a look
at the nodes on the list from netmon -a 4 will give you an idea of what you
are discoverying as stubs.
To get a known good comparison, you might do database maintenance on
both machines at the same time: ovtopofix and nvTurboDatabase (your new
compression tool). Check file sizes, and check ovobjprint -S and check
ovtopdump -l.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Ray Schafer <schafer@tkg.com>@tkg.com on 06/19/2000 12:34:41 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: IBM NetView Discussion <nv-l@tkg.com>
cc:
Subject: Re: [NV-L] Netview Database Problem.
"Jewan, P. (Pritesh)" wrote:
> After the conversion we tar'ed the database directory and restored on
> our production machine, ran the reset_ci and restarted the daemons and
Did you use tar to restore it? If so, that *might* be the start of the
problem. The value_info file is a sparse file. Backing it up with tar
is OK, but tar doesn't handle sparse files during a restore. You should
use "pax -rpe" to restore. But that may or may not have any bearing on
the problem at hand.
> Q1) Can anyone tell me what the above file is for and why the one is
> larger that the other, when box machines are configured exactly
>
> the same ?
Probably all the "stubs" account for that space.
> Q2) Are there any implication on copying the new format database from
> one machine and restoring on another machine or should I have
>
> run the nvTurboDatabase command separately on both of my
> machines ?
You should have run nvTurboDatabase on both machines, probably. Do they
both see the network the same way (same segment, SNMP community names
the same)? If the answer to that is no, copying the database from one
to the other is probably OK. If they see the network much differently,
it is not wise to do this copy.
--
Ray Schafer | schafer@tkg.com
The Kernel Group | Distributed Systems Management
http://www.tkg.com
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|