Could be any number of things. Take a look at 'ovobjprint -s' and
eyeball it for unexpected stuff. Do 'ovtpofix -a' and see if a lot of
things (hints) get deleted. That will happen if you are using certain
kinds of wildcards in your seedfile. For example if you are excluding
nodes from discovery by using !@oid, Netview will create little stubs
of objects it finds but should not discover, then checks them periodically
to see if they have changed into something it should discover. Doing
ovtopofix -a gets rid of them but they will gradually come back. I have
found that it is best to increase ovwdb cache to accomodate those things,
but otherwise they don't have much impact on performance. To keep
these to a minimum it is best to exclude as much as possible by
address range (!xxx.xxx-xxx.*.xxx-xxx for example). Then exclude by oid.
Or maybe you discovered a new router that has a lot of friends...
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
The environment:
RS6000 43P/240 (dual process) 320 Mbytes RAM
AIX 4.2.1 Netview 5.0
We noticed a huge size increase in our ovwdb; the ovobjprint | head -1
shows 13909 defined objects in the database when we usually have no more
than 8000 objects.
The following file is over 1 Gbyte in size, which is abnormal. Checking
the backups of our DB's this file usually sits around 40 Mbytes.
ls -l /usr/OV/databases/openview/ovwdb/current/value_info.pag
-rwxrwxrwx 1 root bin 1003954176 Jun 24 15:52
When we run some db utilities like ovtopofix -Cv there seems to be a lot of
objects that are not in any topology maps. Below part of the output of this
command:
magicolor (112242) -- not in any maps, updating times.
magicolor:QMS (112241) -- not in any maps, updating times.
Updating magicolor (objid = 112242)
5730/6438 ) WLADEK.eas.ualberta.ca (112244)
WLADEK (112244) -- not in any maps, updating times.
WLADEK:129.128.66.163 (112243) -- not in any maps, updating times.
Updating WLADEK (objid = 112244)
5731/6438 ) TORYGR08.eas.ualberta.ca (112246)
TORYGR08 (112246) -- not in any maps, updating times.
TORYGR08:129.128.66.162 (112245) -- not in any maps, updating times.
Updating TORYGR08 (objid = 112246)
5732/6438 ) admintest.eas.ualberta.ca (112248)
admintest (112248) -- not in any maps, updating times.
admintest:129.128.66.160 (112247) -- not in any maps, updating times.
Updating admintest (objid = 112248)
Making the story short; there seems to be thousands objects in our ovwdb
that don't appear to be present in any topology maps. If this is the case
how can I get rid of them. I already ran the smit option 'resolve database
inconsistencies' with no luck.
Thanks for any help.
.
Jorge A. Jiles
Network Analyst
Computing & Network Services
University of Alberta
Edmonton, Alberta
Canada
|
