Yes. The restart does not remove that file because it does not rewrite
that file, only all of the other files. It leaves it behind to trick you,
because
the function pre-dates turbo. Support will not assume the database is turbo
just from the presence of that file. In my experience, if the customer has
that
file, they want to be in turbo and regular compression is desirable so they
should be rerunning nvTurboDatabase as part of their normal housekeeping.
So it is moot, I think.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Oliver
Bruchhaeuser/Germany/Contr To: IBM NetView
Discussion <nv-l@tkg.com>
/IBM@IBMDE cc:
Sent by: Subject: RE: [NV-L]
TurboDB & Converting
owner-nv-l@tkg.com
08/03/01 03:32 AM
Please respond to IBM
NetView Discussion
Leslie,
are you sure that "Retstart automatic map generation" will drop then NDBM
format?
As you already mentioned
/usr/OV/databases/openview/ovwdb/current/value_info.cfg
is left with the same contents.
1 1000 20000000 1 8 1 3 8192
for nvTurboDatabase speed
and
1 1000 20000000 0 0 1 3 8192
for nvTurboDatabase space
This is the way I try to detemine the database state -> maybe up to now ;-)
Of course "Clear object/topology/map databases" will delete all files
under /usr/OV/databases/openview/ovwdb/current/.
James,
can you help to clarify this?
Kind regards
Oliver Bruchhaeuser
Leslie
Clark/Southfield To: IBM NetView Discussion
<nv-l@tkg.com>
/IBM@IBMUS cc:
Sent by: Subject: RE: [NV-L] TurboDB
& Converting
owner-nv-l@tkg.c
om
02.08.2001 23:34
Please respond
to IBM NetView
Discussion
If nvTurboDatabase has been run on that system, then in there will
be a <something>.cfg file in /usr/OV/databases/openview/ovwdb/current.
However, if you rediscover the network, the database is non-turbo
(classic?) but that file is still there. So you cannot be certain without
knowing the history of your system. The instructions for converting to
turbo are in Appendix G in the Inst & Config manual. Take a backup
first (tar up /usr/OV/databases/openview) and make sure you have
extra space in there, as backups of the various files are made.
Yes nvdbformat can be painfully slow on a large database. One
possibility, if much of your size is due to stub objects, is to run it
right after an ovtopofix, when the object count is at its lowest. And
the turbo should help some.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
Dean Sullinger
<DSullinger@dot.st To: "'IBM NetView
Discussion'" <nv-l@tkg.com>
ate.az.us> cc:
Sent by: Subject: RE: [NV-L]
TurboDB & Converting
owner-nv-l@tkg.com
08/02/01 02:36 PM
Please respond to
IBM NetView
Discussion
We are running Nview v601 on Solaris 8. How do I know if we are running
the
turboe version of the database and if we are not, how do I convert it over.
Also, I need to run some nvdbformat scripts against the db, but we have
18,000+ nodes and it takes forever. Is there anyway to speed this process
up?
Thanks
--
DSullinger
_________________________________________________________________________
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
|