James,
(2) you wrote about one-way export of NV data to an RDBMS : Is there a
tool/script for this ? Has anyone tried this out ?
Al
> -----Original Message-----
> From: James Shanks [SMTP:James_Shanks@TIVOLI.COM]
> Sent: lundi 6 décembre 1999 17:36
> To: NV-L@UCSBVM.ucsb.edu
> Subject: Re: Flat file DB --> RDBMS
>
>
>
> 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 << File: ATT10365.txt >>
|