Monthly Archives: December, 2016

DB2 LUW: Create (vs) Declared Global Temporary table

The main difference between declared and create global temporary tables is the SCOPE.

Declared Global Temporary table: Current session

Create Global Temporary table: At current server level. So, it exists for all users who connect.

DB2 LUW Express Server edition discontinued

As per IBM, IBM DB2 LUW Express server edition (DB2 Express) is discontinued from DB2 LUW 11.1.

***

IBM DB2 Express Server Edition (DB2 Express) will no longer be available for purchase starting on September 23, 2016. This offering will not be part of the introduction for DB2 11.1 for Linux, UNIX and Windows family. Existing DB2 Express license holders can replace those licenses and continue support with DB2 Workgroup Server Edition.

Ref: http://www-03.ibm.com/software/products/en/db2-express-server-edition

***

db2 luw: Standard steps to drop a database

Below are steps to drop TESTDB database:

db2 “CONNECT TO TESTDB”
db2 “UNQUIESCE DATABASE”
db2 “QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS”
db2 “UNQUIESCE DATABASE”
db2 “CONNECT RESET”
db2 “DROP DATABASE TESTDB”

QUIESCE: This will ensure that no other users are currently connected to the database.

LDAP Authentication in IBM Netezza

Three authentication methods:

  • Local
  • LDAP
  • Kerberos

LDAP authentication differs from local authentication method in that Netezza system uses the username and password stored on LDAP server.

Please note that: same LDAP user account must also exist in Netezza system catalogs.

Keep in mind the following characteristics of LDAP authentication:

  • After the LDAP authentication process completes successfully, the Netezza system looks up the user in the system catalog. The system displays an error message if it does not find the user, and it terminates the session.
  • If authentication fails, you see the message LDAP authentication failed. The system notes the reason for the failure in the /nz/kit/log/postgres/pg.log file.
  • Netezza users should not notice any difference between LDAP and local authentication.
  • When you CREATE or ALTER a user account, a password is not required if you use LDAP authentication. (Local authentication continues to require a password for user accounts.)

Finding out active netezza host

[root@nzhost1 ~]# crm_resource -r nps -W

crm_resource[5377]: 2009/06/07_10:13:12 info: Invoked: crm_resource 
-r nps -W
resource nps is running on: nzhost1

Runaway query event

You can use the RunAwayQuery event type to monitor queries that exceed configured query timeout limits.

Outdated rows in IBM Netezza

Outdated is another name for deleted rows.

nzdumpschema in IBM Netezza

Use the nzdumpschema command to generate a shell script with SQL statements that duplicate a database by extracting its object definitions and statistics. nzdumpschema generates Table definitions, view definitions, database statistical information, and us
er-defined extensions registered within the database

Note: Because no actual data is dumped, you cannot use this command to back up a database.
Example: To dump table and view definitions to the file named testdb3.sh, enter:
$ nzdumpschema -R testdb3 testdb3.sh

Callhome service in IBM Netezza

The callhome service is an automated notification process that detects problem conditions on the IBM Netezza appliances and reports them to IBM Netezza Support.

This is an optional feature and, if enabled, opens a PMR with IBM automatically. When enabled, callhome automatically collects information and attaches all required log files in the automatically opened PMR.

The callhome service is supported on the following appliance models:

  • IBM PureData System for Analytics N1001 (including the IBM Netezza TwinFin and IBM Netezza 1000 models)
  • IBM PureData System for Analytics N200x
  • IBM PureData System for Analytics N3001

Few example scenarios of automatically opening PMR:

  • SPU/S-Blade/Disk failures
  • Host failovers
  • Unexpected system state changes
  • SPU Core files

 

Query history database in Netezza

The below note will explain on how to build history database:

http://www-01.ibm.com/support/docview.wss?uid=swg21688917

We have two types of History Databases

query history – A query database collects and stores the data that is most commonly needed to monitor and report on the query activity of a system.

audit history – An audit database collects the same data as a query database, but stores the data in row-secured tables and digitally signs the data to prevent it from being changed.

Note: If an audit database is used and the history data staging area exceeds its STORAGELIMIT value, the system stops, and the administrator must free up space and restart the system before users can resume activity.