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
_________________________________________________________________________
|