|
You cannot integrate (out-of-the-box) NetView SNMP performance data with the Tivoli Data Warehouse if you choose to use the new SNMP collector functionality. So for those wanting to move NetView SNMP collected data into the TDW, you need to stick with the orginal snmpCollect function. Please don't mistake the use of a DB2 database by snmpCollect for integration with TDW and the use of a DB2 database for the new SNMP data collection functions. You need a DB2 based RDBMS for both solutions. Let me also add, there is currently a requirement that the DB2 Server hosting the database that the new SNMP collector functionality uses must reside on the same box as the NetView server. In other words, you cannot use a DB2 Server/Client arrangement with the new SNMP data collector (its database must be local to NetView). You do not want to install the DB2 product. If you are not forwarding data to Tivoli Data Warehouse, then you do not need the DB2 product to use the SNMPv1 MIB Collector. <--- snmpCollect only needs a DB2 database if you want to be able to use the NetView "ANM" ETL1 to move SNMP performance data into the TDW The SNMPv1 MIB Collector (snmpCollect) can forward data to Tivoli Data Warehouse. <--- would need a DB2 based database in this case. Would need to use snmpCollect and not the new SNMP data collector if you wanted to forward data into the TDW. Does that help ?
Thanks, Leslie. I reread that section of the Installation Guide (Determining which data collector application to use), and the last bullet makes it sound as if you need the DB if you are going to do the Data Warehouse. That seems to be in conflict with the next-to-last sentence of the previous paragraph. Just so you don’t have to hunt up the doc, here are the two parts I’m referring to: You do not want to install the DB2 product. If you are not forwarding data to Tivoli Data Warehouse, then you do not need the DB2 product to use the SNMPv1 MIB Collector. AND The SNMPv1 MIB Collector (snmpCollect) can forward data to Tivoli Data Warehouse. Peace, Blane Robertson Capgemini / Dallas Enterprise Systems Management/ Capgemini Energy Office: +1 214 879 1666/ www.us.capgemini.com Whether you think you can, or you think you can’t, you’re right! – Henry Ford 
From: nv-l-bounces@lists.ca.ibm.com [mailto:nv-l-bounces@lists.ca.ibm.com] On Behalf Of Leslie Clark Sent: Thursday, May 24, 2007 11:57 AM To: Tivoli NetView Discussions Subject: Re: [NV-L] snmpCollect vs nvcollectord Your v2 devices should respond to a v1 request. The Counter64 would be the main reason for using the new one. If you intend to monitor interface bandwidth utilization, and the interfaces in question are high-speed and actively used, then the data you collect with Counter32 may be inaccurate, but worse, you won't know if it is accurate or not. So for me, if there is an intention to monitor or collect bandwidth using Netview, then I would do the database. I have not implemented this for any customers yet, though I practiced the database install on a linux vmware system and that went ok. Check the archives for other thoughts on the subject. Cordially, Leslie A. Clark IT Services Specialist, Network Mgmt Information Technology Services Americas IBM Global Services (248) 552-4968 Voicemail, Fax, Pager _______________________________________________ NV-L mailing list NV-L@lists.ca.ibm.com Unsubscribe:NV-L-leave@lists.ca.ibm.com http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only) _______________________________________________ NV-L mailing list NV-L@lists.ca.ibm.com Unsubscribe:NV-L-leave@lists.ca.ibm.com http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only) |
