WOW! What a wealth of information.
1. We did re-install and re-discovered the network. We went with Solaris 8,
Tivoli 3.6.3 and Netview 6.0.2. It's up and running right now and doing
pretty good. We still have a few problems that we are working out with Paul
Stroud in support.
2. Paul recommended the weekly maintenance, but thank you for the additional
two bottom lines, I wouldn't have thought of that. I will add it to the
script. I noticed you said to "watch" for messages... do you run this
manually? I was planning a at command once a week to take care of it.
3. We have been backing up our database since we installed the servers, but
only in a 30 day rotation. After this ordeal, I will start also running a
once a month on the database so we will also have a 12 months a year on
tape.
4. We experienced a strange problem yesterday that lasted all day yesterday
and half of today. Whenever we pinged something, it was taking far to much
time to resolve the name. We shut down Netview to make sure it wasn't
involved, then we thought it might be DNS, but the Netview machine is the
only UNIX box effected. Were still not real sure what happened, but we will
have to take a look at it again if it ever shows back up.
5. We are not currently using the Turbo database... should we and why?
Thanks for the help.
-----Original Message-----
From: Kevin Smith [mailto:c-kevin.smith1@wcom.com]
Sent: Wednesday, May 30, 2001 10:32 AM
To: 'IBM NetView Discussion'
Subject: RE: [NV-L] Netview Maint. Issues and Problems
You wouldnt want to backup the conf with the backup and restore procedure?
Sincerely,
Kevin Smith
-----Original Message-----
From: owner-nv-l@tkg.com [mailto:owner-nv-l@tkg.com]On Behalf Of Leslie
Clark
Sent: Friday, May 18, 2001 9:46 PM
To: IBM NetView Discussion
Subject: RE: [NV-L] Netview Maint. Issues and Problems
Dean, I would suggest that this might be a good time to plan an upgrade,
and a new discovery and a clean database. But in the meantime, this is
what I recommend to all customers I visit. You can check the man pages
for explanations of these commands. The functions are outlined in the
Diagnostics manual.
Reorganizing the Databases
From time to time it is advisable to re-synchronize the various netview
databases. I recommend that you do it weekly. It is not necessary to
take the map down while you do this, but it is recommended.
1.) ovmapcount -a
2.) ovstop netmon
3.) ovtopofix -a (watch the output for any instructions)
4.) ovstart
5.) ovobjprint -S (note number of objects in database)
6.) ovtopodump -l (note real numbers of nodes, interfaces)
Backing up and restoring the Netview database(s)
All of the databases for the maps are under /usr/OV/databases/openview.
They can be backed up to disk at some point where the map is just the
way you want it, and restored to that point in case of a problem. Even
if it is a little out of date, it will quickly synchronized and become
current, saving you from redoing all of your cutting and pasting.
Do this weekly, or after major changes, or before software updates.
If you DO restore it, be sure to save it again after it synchs up!
Your backup directory is /_______/backups
To save the netview databases:
cd /_________/backups
tar -cvf nvdb.baknn.tar /usr/OV/databases/openview
where nn is some unique number or date indication.
To restore:
cd /_________/backups
pax -rp e -f nvdb.bknn
(Use pax for the restore because Netview databases are sparse filesystems.
Using tar to restore them would result in very large, mostly empty, files.
The pax command understands sparse files and restores them using only the
necessary space.)
It is best to do the backup when everything is shut down, but not
essential.
To do the restore, you must close all maps and do an ovstop.
When restoring, you may find it necessary to do an ovw -fields, ovw
-verify,
ovw -config. If you restore a backup made on another system, or before the
ip address was changed, you will also need to do a
/usr/OV/service/reset_ci ( the chicken soup of Netview...)
mapadmin -u <hostname>
Compressing the databases
Classic database format: (Initially, on rediscovery, this is the format)
Further compression is necessary somewhat less frequently.
Check monthly this way
1) cd to /usr/OV/databases/openview/ovwdb/current
2) ls -l value_info.pag (note size is in bytes)
3) du -a value_info.pag (note size is in 512 byte blocks)
4) multiply output result of the 'du -a' command by 512 to get bytes
5) If the 'ls -l' output gets to 50% larger than converted 'du -a'
output, it is time to compress.
After a backup, and making sure you have 20% free space in the
/usr/OV/filesystem, compress the databases with:
ovwdbdmap -c
and then take a new backup. Note that if the value_info.pag does not
compress, then it did not need compression. If you are using a seedfile
with oids rather than address ranges for restriction, then you may have
a large number of 'stub' objects in the database which will cause the
'ls' value to be many times larger than the 'du' value, but still not be
compressable. If this is the case, it is recommended that you switch
to the turbo form of the database.
-- OR --
Turbo database format:
Further compression is necessary somewhat less frequently.
Do it monthly this way:
1) Take a backup (see above)
2) Make sure you have space in /usr/OV
a) cd to /usr/OV/databases/openview/ovwdb
b) du -rs (note size is in 512 byte blocks)
c) Double this. This is how much space you need free in /usr/OV (est
50MB)
d) Check space in /usr/OV with df -ks /usr/OV
3) Close all guis
4) Stop daemons (ovstop)
5) /usr/OV/service/nvTurboDatabase speed
6) Take a new backup.
Remember that you are using the Turbo form of the database as opposed to
the regular or classic format, in case you are asked.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Dean Sullinger <DSullinger@dot.state.az.us>@tkg.com on 05/17/2001 05:18:47
PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc:
Subject: RE: [NV-L] Netview Maint. Issues and Problems
> We are running Netview on a Sun E3500 with 2GB RAM, 60GB HD,
> Solaris 2.6 and Netview 5.1.1 with Framework 3.6 with about
> 19,000 items in our database
Along the same lines as the before asked question, is there something I
should be doing daily, weekly, monthly? to maintain or maintenance the
database?
Any ideas?
-----Original Message-----
From: Dean Sullinger [mailto:DSullinger@DOT.STATE.AZ.US]
Sent: Thursday, May 17, 2001 2:05 PM
To: 'IBM NetView Discussion'
Subject: [NV-L] Netview Maint. Issues and Problems
Sorry, I don't mean to change off the subject I was talking about, but we
are experiencing a problem this week with our Netview and it shows it's
ugly
head occasionally and I am looking for recommendations of keeping this from
happening or how we can recover somewhat soothly.
Here's the scoop, on Tuesday some idiot in the computer room pluged an
electrical appliance they weren't supposed to on our dedicated circuit for
Netview, which in turn blew the breaker and we lost power to Netview. We
are
running Netview on a Sun E3500 with 2GB RAM, 60GB HD, Solaris 2.6 and
Netview 5.1.1 with Framework 3.6 with about 19,000 items in our database
with only about 300 of them being managed. When it came back up, Netview
would not demand poll. We waited about 20min and it still would not demand
poll. I then did a ovstop and ovstart and waited to see if it would come
back and it did not. I then stopped netmon and ran ovmapcount-a and
ovtopofix -a just to try and clean any problems up. I then restarted
netmon
and Netview and waited about 20min and it sitll would not demand poll. At
this point we rebooted and waited... about 3+ hours later it began demand
polling.
Please excuse my stupidity on the subject, but my job is to support the
Network... I got stuck with the job of supporting the Sun equipment because
I know UNIX and Solaris... it's something I do when I can get time to mess
with it.
Right now we are in the same spot... something went wrong and we had to
restart the services and it is not demand polling.
Anyone have any ideas before I call support?
--
Dean Sullinger
Arizona Deptartment of Transportation
Information System Group Phone: (602)712-8673
Wide Area Network Group
Email : dean@dot.state.az.us
SMail : 206 S. 17th Ave #119A Phx Az 85007-3212
Internet: http://www.dot.state.az.us
_________________________________________________________________________
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
|