nv-l
[Top] [All Lists]

Re: [nv-l] Huge .pag files in mapdb dir

To: nv-l@lists.tivoli.com
Subject: Re: [nv-l] Huge .pag files in mapdb dir
From: Stephen Hochstetler <shochste@us.ibm.com>
Date: Tue, 11 Mar 2003 11:47:34 -0600
Delivered-to: mailing list nv-l@lists.tivoli.com
Delivery-date: Tue, 11 Mar 2003 19:05:24 +0000
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
List-help: <mailto:nv-l-help@lists.tivoli.com>
List-post: <mailto:nv-l@lists.tivoli.com>
List-subscribe: <mailto:nv-l-subscribe@lists.tivoli.com>
List-unsubscribe: <mailto:nv-l-unsubscribe@lists.tivoli.com>
Mailing-list: contact nv-l-help@lists.tivoli.com; run by ezmlm



I did not see what version of NetView was running in the note.    I have
seen this before and support came back with a great tool to resolve this.
Actually, I have seen this twice.

First time.  A person on the team built a SmartSet definition that was
recursive (included itself).   The person did not realize it and left it
configured and running that way.   The customer called me in when the
performance went horrible.  It was creating objects in the database over
and over and over...over 60,000 objects and still running.  After a short
time it took the object count past the ovwdb cache size and that is when it
impacted the operators using the system.    ovobjprint -S will tell you if
you have a hugh unexpected database.    The fix was to remove that smartset
and then remove all those created objects.   With a little scripting, it
still took about hours to recover and remove the items.
(simptom:  more objects than you should have...suspect SmartSet
configuration)

Second time.  This was back in NetView v5 days.   The NetView server
discovered a new LARGE router with hundreds of interfaces.  It loaded that
data into the database which is sparse...and a 300MB file grew to several
Gig.    But the number of objects did not grow hugh.  The solution was to
run " /usr/OV/service/NVturboDatabase space".    This should work for both
NV V5 and NV V6.   I think it is automatic in V7 now.   To run this you
should have your database backed up.   Also you should have enough free
space that the database can be duplicated in that filesystem when it it
run.

Note, but of these were large .pag file in the ovwdb database.   If you are
seeing large .pag files in mapdb directory....check to see if anyone is
running some sort of "homegrown" NetView application that is adding non-IP
items to the map.   I would still run NVturboDatabase.


Hope this helps.

Kind regards,
Stephen Hochstetler              shochste@us.ibm.com
International Technical Support Organization at IBM
11400 Burnet Road   Austin, TX  78758
Office - 512-838-6198 (t/l 678)       FAX - 512-838-6931
------------------------------------------------------------
http://www.redbooks.ibm.com




                                                                                
                                 
                      James                                                     
                                 
                      Shanks/Raleigh/IB        To:       nv-l@lists.tivoli.com  
                                 
                      M@IBMUS                  cc:                              
                                 
                                               Subject:  Re: [nv-l] Huge .pag 
files in mapdb dir                 
                      03/11/2003 10:36                                          
                                 
                      AM                                                        
                                 
                                                                                
                                 
                                                                                
                                 




You cannot delete anything out of /usr/OV/databases without causing great
harm to the product.  Those files you are complaining about are the
databases themselves.  UNIX databases use a ".dir" as a list of pointers
into the ".pag" which is the data portion of the file.

 Start with ovobjprint -S for a summary of your database.  It will tell
you how many objects you have.  Then make sure that ovwdb is running with
a cache size 20% larger than that.  If he's not then you could see a lot
of thrashing as he tries to obtain enough memory to hold the entire
database in contiguous storage.

 If your ovwdb has grown hugely overnight, doubled in size or some such
thing, then something has gone horribly wrong with discovery and you need
to shut down netmon and run ovobjprint to a file and see what kinds of
things have been added.

If the answer here is not obvious, then I 'd say you need to call Support.


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group




"Pretorius, Vynita" <VPretorius@fnb.co.za>
03/11/2003 10:38 AM


        To:     "Nv-L (E-mail)" <nv-l@lists.tivoli.com>
        cc:
        Subject:        [nv-l] Huge .pag files in mapdb dir



Hi

The .pag files are in the databases directory on netview/aix 5 ..
Can they be deleted and is there a size limitation on these files and
would
they cause the cpu to grow as described below?

Overnight our ovwdb is running at 80% of cpu and after the users have
logged
in we are running 100% cpu from an average of 40%, does anybody have an
idea
of what the problem could be?
As a result the sites are not going red when down etc...

Thanks in advance
Vynita

___________________________________________________________________________________________________



The views expressed in this email are, unless otherwise stated, those of
the author and not those
of the FirstRand Banking Group or its management.  The information in this
e-mail is confidential
and is intended solely for the addressee. Access to this e-mail by anyone
else is unauthorised.
If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or
omitted in reliance on this, is prohibited and may be unlawful.
Whilst all reasonable steps are taken to ensure the accuracy and integrity
of information and data
transmitted electronically and to preserve the confidentiality thereof, no
liability or
responsibility whatsoever is accepted if information or data is, for
whatever reason, corrupted
or does not reach its intended destination.

                               ________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)





---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)





---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web