I am trying to understand Netezza connectivity, and type of access between Datastage to Netezza, and hoping someone can help. Some of these questions may be basic but would surely help my undrestanding on the topic.
I know Netezza native connectivity is available since 8.1 version and 8.7 makes it that much better but have following questions:
1) When I look at the Netezza driver used in DS, its located at following path and has ODBC reference in the naming. If it is a native driver, why does it use ODBC naming for ".so" file?
Location of the driver and its name: /netezza/lib/libnzsqlodbc3_64bit.so
2) How do we ensure we have Native connectivity to Netezza via Datastage?
3) Does use of Netezza Connector OR Netezza Enterprise sage mean native connectivity? (or dumb quesiton can these stages also be connected via ODBC)?
4) What kind of access rights does Datastage batch id/user id suppose to have in Netezza database, as I understand even with Netezza Connector, User ID could still create Work tables etc.
Netezza native connectivity and DS ID access type
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The "native" connectivity to Netezza uses ODBC 3.x protocol.
(The "native" connectivity to DB2 uses protocols closely based on ODBC. The "native" connectivity to UniVerse uses ODBC protocols. So the Netezza story is nothing particularly new. After all, all that's happening is than an environment is set up, SQL is sent, the results of SQL are retrieved, and the environment is freed.)
(The "native" connectivity to DB2 uses protocols closely based on ODBC. The "native" connectivity to UniVerse uses ODBC protocols. So the Netezza story is nothing particularly new. After all, all that's happening is than an environment is set up, SQL is sent, the results of SQL are retrieved, and the environment is freed.)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I found the answer for #4 in IBM's White paper for Netezza. PDF "ID_628_Public_Whitepaper_IBM_InformationServer_Netezza" can be found online and please read the section "7.2 How to Manage Temporary Work Tables (TWTs)".
Here is the summary:
1) Well DataStage Application ID really should not have Create/Drop table access to Database. Netezza Admin can create TWT tables before implementation but it will be required for each Target table and has to match input schema in connector stage.
2) IBM recommends creating separate work table database and allow DataStage Application ID DROP/CREATE access to that Database.
If you do then you can use Option in Properties tab in the Netezza Connector "User separate connection for TWT= Yes" and that will require separate User ID and password for TWT Database. TWT will be created/and dropped automatically by Netezza Connector.
Here is the summary:
1) Well DataStage Application ID really should not have Create/Drop table access to Database. Netezza Admin can create TWT tables before implementation but it will be required for each Target table and has to match input schema in connector stage.
2) IBM recommends creating separate work table database and allow DataStage Application ID DROP/CREATE access to that Database.
If you do then you can use Option in Properties tab in the Netezza Connector "User separate connection for TWT= Yes" and that will require separate User ID and password for TWT Database. TWT will be created/and dropped automatically by Netezza Connector.