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
'turned into' something that meets the criteria of your seedfile. So first
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
range that will keep out big chunks of these things. For instance, you
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
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Ray Schafer <schafer AT tkg DOT com>@tkg.com on 06/19/2000 12:34:41 PM
Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
Sent by: owner-nv-l AT tkg DOT com
To: IBM NetView Discussion <nv-l AT tkg DOT com>
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 AT tkg DOT com
The Kernel Group | Distributed Systems Management
NV-L List information and Archives: http://www.tkg.com/nv-l