RE: Re: Re: ovwdb: strange objects

["Hasty, Buddie" <buddie.hasty@2ndwaveinc.com>]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

I don't know how I got on this distribution list, but could someone remove
me.  I have no need for the info being displayed, although very good I must
admit.

Thanks
Buddie

 -----Original Message-----
From:   helmut.schroeder.hs@bayer-ag.de
[mailto:helmut.schroeder.hs@bayer-ag.de] 
Sent:   Tuesday, May 08, 2001 10:09 AM
To:     IBM NetView Discussion
Subject:        Re: Re: [NV-L] Re: ovwdb: strange objects



Found the faster solution to get rid of objects that just contain only one
field
Selection Name=Selection Name<nnnnnn>
(ovtopofix does not work, ovwdbdmap -d  ... takes too long to remove
several thousand objects and I don't want to rediscover everything):

Add to every incomplete object a field  IP Hostname=dummy<nnnn>
with nvdbimport and run an ovtopofix  afterwards.
ovtopofix will now remove the incomplete objects.

Cheers - Helmut Schroeder







"Leslie Clark" <lclark@us.ibm.com>@tkg.com on 04.05.2001 04:17:38

Bitte antworten an IBM NetView Discussion <nv-l@tkg.com>

Gesendet von:  owner-nv-l@tkg.com



An:   IBM NetView Discussion <nv-l@tkg.com>
Kopie:
Blindkopie:
Thema:    Re: [NV-L] Re: ovwdb: strange objects

Can I come over and redo your map? It is my favorite thing to do;)
If I were you, I would plan on doing a rediscovery to get the migrated
junk out of there.  Look at the output of 'ovtopodump -l' and compare
the numbers of nodes, interfaces, networks, etc to the number of
objects after an ovtopofix. There were a number of problems with
this sort of object in V3 and early V4. You will be glad you did after
it is done.

Before doing that, though, you can do a lot of planning, so the time to
recreate the map will be as short as possible.

1) You can generate a complete seedfile, in sections, by parsing the
output of ovtopodump -rl, and grouping routers (near to far) and then
separate lists of hubs, servers, etc, and the rules of course.
2) You can practice and test the design of the location.conf file. Using
your existing database, you can put a draft location.conf file in place
and then 'File...New Map'. The new map will use that file. Do it over a
couple of times until you get it right.  This only places networks in
location submaps, and that might make it look worse at first. but don't
worry.
3) Make a smartset of isLocation is True. This makes it easy to find
those little tiny location icons for cutting and pasting.
4) You can use nvdbimport to set fields on routers that indicate which
location submap they go in.  A few simple scripts can generate the
import file.
5) You can use Locate...By Attribute, then View..Highlights..Select
Highlights
to select things too tiny to see, then cut (make sure you use the menu
pick on the correct submap) and paste into the location icon. Use this
on the routers, referencing that field you created.

You cannot leave any users up while rediscovering, since the entire
database is flushed (except smartset and apm definitions). But with
planning, you could redo it in one long evening. Or two, if you want to
take a backup, flush and discover and work on it a while, then back
that up and restore the old one for another day, and repeat. Or get
another box, rediscover from there, and port the database back to
the production machine.


Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit

"Francois Le Hir/Quebec/IBM" <flehir@CA.IBM.COM>@tkg.com on 05/03/2001
01:38:42 PM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com


To:   "NetView List" <nv-l@tkg.com>
cc:
Subject:  [NV-L] Re: ovwdb: strange objects




Hi,

I am running Netview 6.02 on AIX 4.3.3

I also have about 120 entries with strange "FIELD VALUE": "Selection Name"
or "Selection Name+Number" or just a Number.
I also have lots of entries in the same field with "REMOVED:Name" or with
the name of a machine that has been removed from the network for years. Is
this normal ?

I migrated this database from Netview 5.1 to Netview 6 and I know it was
migrated from Netview 4 before and probably even from an earlier version.
I don't know if it's growing : this is the first time I see these entries.

When I did the migration from Netview 5.1, I asked support if it was normal
to have such a big database for the size of our network. I was told that it
was not a problem.
We have about 300 routers, 500 servers and less than 20 000 computers on
the network.
ovobjprint gives me 132816 objects in database and this number is growing.

should I be concerned about the size of my database ?
I know it would be good for cleaning to rediscover the network, but it's
such a work to put every node back in it's place that I am little bit
afraid to start such a process. It is possible to restart a discovery in a
new map while operator are doing production work on the original map on the
same server ?

Thanks,

Francois Le Hir
Network Projects & Consulting Services
IBM Global Services
Phone: (514) 205 6695

--------------------------------------------
Date:      Wed, 18 Apr 2001 16:11:16 -0400
From:      "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: ovwdb: strange objects

Helmut, I have not seen that happen in years. I keep an eye out for them
because long ago there were some code problems that could cause them.
But I don't see it any more. Have you been migrating the same database
since V4? If I saw that, even if they were not growing, I would schedule
time
for a rediscovery just to get it clean. If it is growing, call Support. If
not,
weigh the pain and either ignore it or clean it up. Or call Support.

And I will say it again, you should always be prepared to rediscover or
restore your database. Stuff happens.  I would take a backup of this, and
restore from an old backup and check to see if they were always there. If
they were, you can just restore your most current one ( if you have the fix
for pax installed).

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit

helmut.schroeder.hs@bayer-ag.de@tkg.com on 04/17/2001 11:47:18 AM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com


To:   nv-l@tkg.com
cc:
Subject:  [NV-L] ovwdb: strange objects





Hi,

This is NV 6.01 in AIX 4.3.3:
Checking our object DB, I found about 9.000 objects with no
fields but Selection Name as follows:

OBJECT: 134765
        FIELD ID        FIELD NAME                      FIELD VALUE
        10              Selection Name                  "Selection
Name134765"

OBJECT: 134766
        FIELD ID        FIELD NAME                      FIELD VALUE
        10              Selection Name                  "Selection
Name134766"
....

I have no idea where they came from  - ovtopofix changes nothing.
 ...  I don't really want to restore from backup because they
seem to be there for quite a while.
Any ideas ? Thanks in advance ....

Helmut Schroeder



_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l


_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l




_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l

I don't know how I got on this distribution list, but could someone remove me.  I have no need for the info being displayed, although very good I must admit.

Thanks
Buddie

 -----Original Message-----
From:   helmut.schroeder.hs@bayer-ag.de [mailto:helmut.schroeder.hs@bayer-ag.de]
Sent:   Tuesday, May 08, 2001 10:09 AM
To:     IBM NetView Discussion
Subject:        Re: Re: [NV-L] Re: ovwdb: strange objects

Found the faster solution to get rid of objects that just contain only one field
Selection Name=Selection Name<nnnnnn>
(ovtopofix does not work, ovwdbdmap -d  ... takes too long to remove
several thousand objects and I don't want to rediscover everything):

Add to every incomplete object a field  IP Hostname=dummy<nnnn>
with nvdbimport and run an ovtopofix  afterwards.
ovtopofix will now remove the incomplete objects.

Cheers - Helmut Schroeder

"Leslie Clark" <lclark@us.ibm.com>@tkg.com on 04.05.2001 04:17:38

Bitte antworten an IBM NetView Discussion <nv-l@tkg.com>

Gesendet von:  owner-nv-l@tkg.com

An:   IBM NetView Discussion <nv-l@tkg.com>
Kopie:
Blindkopie:
Thema:    Re: [NV-L] Re: ovwdb: strange objects

Can I come over and redo your map? It is my favorite thing to do;)
If I were you, I would plan on doing a rediscovery to get the migrated
junk out of there.  Look at the output of 'ovtopodump -l' and compare
the numbers of nodes, interfaces, networks, etc to the number of
objects after an ovtopofix. There were a number of problems with
this sort of object in V3 and early V4. You will be glad you did after
it is done.

Before doing that, though, you can do a lot of planning, so the time to
recreate the map will be as short as possible.

1) You can generate a complete seedfile, in sections, by parsing the
output of ovtopodump -rl, and grouping routers (near to far) and then
separate lists of hubs, servers, etc, and the rules of course.
2) You can practice and test the design of the location.conf file. Using
your existing database, you can put a draft location.conf file in place
and then 'File...New Map'. The new map will use that file. Do it over a
couple of times until you get it right.  This only places networks in
location submaps, and that might make it look worse at first. but don't
worry.
3) Make a smartset of isLocation is True. This makes it easy to find
those little tiny location icons for cutting and pasting.
4) You can use nvdbimport to set fields on routers that indicate which
location submap they go in.  A few simple scripts can generate the
import file.
5) You can use Locate...By Attribute, then View..Highlights..Select
Highlights
to select things too tiny to see, then cut (make sure you use the menu
pick on the correct submap) and paste into the location icon. Use this
on the routers, referencing that field you created.

You cannot leave any users up while rediscovering, since the entire
database is flushed (except smartset and apm definitions). But with
planning, you could redo it in one long evening. Or two, if you want to
take a backup, flush and discover and work on it a while, then back
that up and restore the old one for another day, and repeat. Or get
another box, rediscover from there, and port the database back to
the production machine.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit

"Francois Le Hir/Quebec/IBM" <flehir@CA.IBM.COM>@tkg.com on 05/03/2001
01:38:42 PM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com

To:   "NetView List" <nv-l@tkg.com>
cc:
Subject:  [NV-L] Re: ovwdb: strange objects

Hi,

I am running Netview 6.02 on AIX 4.3.3

I also have about 120 entries with strange "FIELD VALUE": "Selection Name"
or "Selection Name+Number" or just a Number.
I also have lots of entries in the same field with "REMOVED:Name" or with
the name of a machine that has been removed from the network for years. Is
this normal ?

I migrated this database from Netview 5.1 to Netview 6 and I know it was
migrated from Netview 4 before and probably even from an earlier version.
I don't know if it's growing : this is the first time I see these entries.

When I did the migration from Netview 5.1, I asked support if it was normal
to have such a big database for the size of our network. I was told that it
was not a problem.
We have about 300 routers, 500 servers and less than 20 000 computers on
the network.
ovobjprint gives me 132816 objects in database and this number is growing.

should I be concerned about the size of my database ?
I know it would be good for cleaning to rediscover the network, but it's
such a work to put every node back in it's place that I am little bit
afraid to start such a process. It is possible to restart a discovery in a
new map while operator are doing production work on the original map on the
same server ?

Thanks,

Francois Le Hir
Network Projects & Consulting Services
IBM Global Services
Phone: (514) 205 6695

--------------------------------------------
Date:      Wed, 18 Apr 2001 16:11:16 -0400
From:      "Leslie Clark" <lclark@us.ibm.com>
Subject: Re: ovwdb: strange objects

Helmut, I have not seen that happen in years. I keep an eye out for them
because long ago there were some code problems that could cause them.
But I don't see it any more. Have you been migrating the same database
since V4? If I saw that, even if they were not growing, I would schedule
time
for a rediscovery just to get it clean. If it is growing, call Support. If
not,
weigh the pain and either ignore it or clean it up. Or call Support.

And I will say it again, you should always be prepared to rediscover or
restore your database. Stuff happens.  I would take a backup of this, and
restore from an old backup and check to see if they were always there. If
they were, you can just restore your most current one ( if you have the fix
for pax installed).

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit

helmut.schroeder.hs@bayer-ag.de@tkg.com on 04/17/2001 11:47:18 AM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com

To:   nv-l@tkg.com
cc:
Subject:  [NV-L] ovwdb: strange objects

Hi,

This is NV 6.01 in AIX 4.3.3:
Checking our object DB, I found about 9.000 objects with no
fields but Selection Name as follows:

OBJECT: 134765
        FIELD ID        FIELD NAME                      FIELD VALUE
        10              Selection Name                  "Selection
Name134765"

OBJECT: 134766
        FIELD ID        FIELD NAME                      FIELD VALUE
        10              Selection Name                  "Selection
Name134766"
....

I have no idea where they came from  - ovtopofix changes nothing.
 ...  I don't really want to restore from backup because they
seem to be there for quite a while.
Any ideas ? Thanks in advance ....

Helmut Schroeder

_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l

_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l

_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l