Two points.
(1) The first option is fine as long as you are careful. It is not supported
because if you are not careful, no one can help you fix the database. The deal
is that the daemons keep the database they are updating in memory and do not
write it out often, if at all, until they close. And you will want to have not
only the latest information but also the last closed time in the database as
well in order to get this to work successfully. So we have said for a long
time, that you must at least close the GUIs and ovstop netmon and snmpCollect
when you take the backup you will later export. But recently I have heard on
this forum that some people are not even doing that. OK, but then things had
better be real quiet, because if the databases are copied without all the
information being present in them, it could become corrupted, and then you have
no choice but to make a new copy and do it cleanly this time. Since we have no
way of knowing whether a user actually follows the procedure correctly and no
way to fix it if he doesn't, we don't support it. You are on your own.
(2) When you talk about exporting the database into an RDBMs, remember that
there are two flavors of this. One is that you just do it after the fact, and
update it periodically, but you just use the RDBMs to generate reports. NetView
itself has no contact with it except for the one-way export. This is what most
people do. The other flavor is that you set the flag on ovtopmd and try to run
NetView using data that has been uploaded into the RDBMs for run-time map
updates. This is the area where people see performance problems and so is not
often done. I have never even heard of someone trying to export from one
NetView and use the resulting RDBMs to run a second NetView. That I think would
be a first, so you would definitely be out on the leading edge.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Frederic Mottiat <frederic_mottiat@BE.IBM.COM> on 12/06/99 10:58:26 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Flat file DB --> RDBMS
Alain,
Regarding your options :
1) Not supported by the lab - from what I've heard or read -, although this is
generaly working quite good - from the point that both NetView servers are in
the same subnet, that you don't forget to use reset_ci and mapadmin commands
2) I never tried this personnaly, nor read references to that kind of config
anywhere. Anybody tried this ? Although, the question is : the topology DB is in
your RDBMS or exported from server A to the RDBMS, to be used by server B - how
do you maintain adequacy with the object databases on both NetView server. Even
if this could work, I guess it will be more difficult to handle than solution 1.
3) forget it.
Where do you see reporting facilities in TIPN ? The only one I know about are
for generating HTML reports about your Tivoli Managed Nodes, etc
Frederic Mottiat - IBM Global Services (PSS-SMNS)
Tivoli Implementation & Services
Email : frederic_mottiat@be.ibm.com
Tel : 02/225 34 08 Gsm : +32 (0)75 388 773
"MENEZES, ALAIN" <alain.menezes@FORTISBANK.COM> on 06/12/99 16:49:25
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: Frederic Mottiat/Belgium/IBM)
Subject: Re: Flat file DB --> RDBMS
This is what we would like to do :
NetView Server A : used with flat files and local (secondary) DNS for
Network management and third-party applications
NetView Server B : used as an interface that enables Tivoli to have a view
on network elements. Server B will have all Tivoli components like TIPN,
TFNC, TMNH, .... + its DB. Now regarding the DB there are several options :
1) Regularly copy database from Server A to Server B
2) export Server A DB to Server B's RDBMS DB (assuming this is possible)
3) Define a NFS read-only exported file system from Server A
(/usr/OV/database) that can be connected to by Server B
What do you think ? Personally I solution 3 sounds interesting but solution
2 offers interesting reporting advantages through RDBMS tools ... (although
TIPN offers reporting facilities too)
> -----Original Message-----
> From: Frederic Mottiat [SMTP:frederic_mottiat@BE.IBM.COM]
> Sent: lundi 6 d
écembre 1999 16:17
> To: NV-L@UCSBVM.ucsb.edu
> Subject: Re: Flat file DB --> RDBMS
>
> Alain,
>
> seems you are doing a lot of NetView activities, these days :-)
> Which is the DB you want to put in a RDBMS ?
>
> Globally, if we talk about NetView and RDBMS, you can :
> - regularly upload your trapd.log in a RDBMS : usefull if you want to know
> a
> little bit more about your event traffic patterns as you'll be able to
> query
> this RDBMS with SQL (and some NetView commands as well)
> - regularly upload the snmp collected data (from snmpCollect) into a RDBMS
> :
> usefull for queries, again
> - store the topology database in a RDBMS : usefull if you want to compare,
> for
> instance, the "evolution" of your network topology. But I would advise you
> not
> to do this, unless you have a very good reason, because the performance
> are up
> to 20 times slower than when using the flat file topology DB.
>
> In any case, I urge you to read the NetView Database Guide. You might have
> not
> received it in hardcopy with your NetView software, so go to
> www.support.tivoli.com : you can download the guide (PDF) from there
> (you'll
> need a userid and password to access some part of this web site, again
> check
> with your Tivoli team)
>
> Regards,
>
> Frederic
>
> Frederic Mottiat - IBM Global Services (PSS-SMNS)
> Tivoli Implementation & Services
> Email : frederic_mottiat@be.ibm.com
> Tel : 02/225 34 08 Gsm : +32 (0)75 388 773
|