Alexander,
Here is trick that I learned from a customer:
If you have a node(s) in the object database that does not exist in any map.
1. Create a SmartSet for that selection name (use Object List).
2. Open the SmartSet, select and Delete from all submaps.
3. It is now deleted from the object database.
You already have half the work done. Just select those offending nodes in
the SmartSet and delete them.
This method was developed to be able to delete just what you are describing.
In a production environment they could not stop netmon to run ovtopofix.
I would AVOID routinely using any incantation of "ovwdbdmap" (I don't think
"-d", delete is supported).
I consider it a last resort, use only if all else fails!
Don Davis
-----Original Message-----
From: Scott Barr [mailto:scott_barr@csgsystems.com]
Sent: Tuesday, July 03, 2001 10:09 AM
To: IBM NetView Discussion
Subject: RE: [NV-L] NV Database [ND.Cerberus checked]
This is still a problem under v6.02
Paul Stroud and I have run into this problems a number of times. What I know
will work is this:
ovtopofix -A
ovmapcount -a
(neither of these will fix it, but you should always try first)
then use ovobjprint -s | grep objectname
When you get the display back you will have the object number
ovwdbdmap -d objectnumber
Also, I have found that if you use CTRL-N (search by selection name) you can
sometimes find the object is an interface with a similar object name. I
believe this is because discovery picks up the interface AGAIN after you
have deleted it from the map(s). I then cut that object from all submaps and
that has worked sometimes.
-----Original Message-----
From: owner-nv-l@tkg.com [mailto:owner-nv-l@tkg.com]On Behalf Of Leslie
Clark
Sent: Tuesday, July 03, 2001 6:55 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] NV Database [ND.Cerberus checked]
Perhaps you have more than one map? Check with 'File...Open Map' and see
if it lists more than just the default map. Or, at the commandline, do
'ovobjprint -s <selection name>' where selection name is the name listed
when
you do the nvUtil. In the object info, there will be 'Maps Exist' and 'Maps
Managed'
counts. Those fields would indicate that Netview thinks it is still in use
somewhere.
These counts can be wrong sometimes. Try 'ovmapcount -a' to get them set
correctly, then do the ovtopofix again. By the way, this is less of a
problem at
6.0.2, so if you are current, you should get the update.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Alexander.Korn@allianz.at@tkg.com on 07/03/2001 07:33:46 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] NV Database [ND.Cerberus checked]
Hi All,
does anyone know, how to solve this? I have there some nodes which won't
exist any longer. After they where shut down (to take away) they turned red
on my map's and also on the collections - all right, I started to delete
this objects (from all maps) - they are no longer as objects visible -
still all right.
But if I start a "nvUtil l" they are still in the nodelist of this
collections, and also in the nv db to find with an ovtopodump. I think
thats not right, even I run some shellscripts on objects, depending if they
are in this collection or not.
The summary what I've done:, deleted the Objects, as they where no longer
in the net, an ovtopofix out of the smit with the default parameters there.
my problem is how to threw this objects out of the system?
any tips are welcome,
cheers
Alexander Korn
Allianz Insurance
Vienna / Austria
_________________________________________________________________________
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
------------------------------------------------------------------------------
This electronic mail and any files transmitted with it are confidential and are
intended solely for the use of individual or entity to whom they are addressed.
If you are not the intended recipient or the person responsible for delivering
the electronic mail to the intended recipient, be advised that you have
received this electronic mail in error and that any use, dissemination,
forwarding, printing, or copying of this electronic mail is strictly
prohibited. If you have received this electronic mail in error, please
immediately notify the sender by return mail.
|