Netezza forces serialization.  Only one session can update a table at a time and it must commit before another session can update any data.  INSERT however can be performed by multiple sessions at the same time.  Put in simple terms Netezza does not have row level locking, only table level locking.  Two attempts to update the same table will be serialized automatically (the 2nd pauses until the first completes).

Data loads/updates on Netezza should be done by inserting data into a staging table using one or many parallel insert processes and then using a single SQL insert in a single transaction to merge that data into the target table.  I attached a script that I wrote a few years back that makes the basic process of loading data into a staging table and then into the target table pretty simple.  It requires that the target table must have a primary key defined.  The script does not do updates to the target table, it will replace any records in the target table that have the same PK value as records in the staging table.

The process is basically this:

Something like:

begin transaction;

delete from targettable where (a,b,c) in (select a,b,c from stagingtable where data_load_id=$LOADID);

insert into targettable (a,b,c,d,e,f,g) select a,b,c,d,e,f,g from stagingtable where data_load_id=$LOADID;

commit;

or maybe you want to update / increment data, you can write a custom script something like this:

/* create temp table to merge data between target and staging table */

create temp table temptable as

select

     t.a,

     t.b,

     t.c,

     t.d + s.d,

     t.e - s.e

from

     targettable t, stagingtable s

where

     t.a = s.a and

     t.b = s.b and

     t.c = s.b and

     s.data_load_id = $LOADID;

/* insert new records into temp table which do not exist in target table */

insert into temptable

select a,b,c,d,e from stagingtable

where data_load_id = $LOADID and (a,b,c) not in (select a,b,c from temptable);

/* now load final resultset into target table */

begin transaction;

delete from targettable where (a,b,c) in (select a,b,c from temptable);

insert into targettable (a,b,c,d,e,f,g) select a,b,c,d,e,f,g from temptable;

commit;

I think you may be trying to misuse Netezza.  If you have multiple sessions which need to update the same record then the table should reside on a standard database like Oracle, SQL Server, MySQL, PostgreSQL, etc.  Netezza is for large scale data loading / analysis, it is not designed to be the backend for an application which does a lot of single row updates/inserts/deletes.

So data flow should look something like:

Application -> OLTP database -> ETL processes -> staging table(s) -> target Netezza table

The ETL processes to push data into Netezza could run on a regular basis, every few minutes, once per day, etc.

When I was referring to multiple sessions loading data into a staging table, I'm talking about standard ETL type processing where you have massive amounts of data to process.  The data gets split between multiple ETL processes to enable scaling across multiple systems/CPUs (generally using a HASH based algorithm).  All of those parallel ETL processes dump data into a staging table in Netezza and then once the ETL processing of the data is completed you run a SQL script to push that data into the target table.

Attempting to have Netezza act as the backend database for a normal application will at best cause you a lot of difficultly and at worst end in complete failure.

The first question to understand is if you can even benefit from zone maps on the particular table in question, then the 2nd question is do the updates 'disrupt' the zone maps.  Many scenarios make an 'insert only' strategy for your data warehouse impossible so there is no other solution to that problem.  While David makes a great point that it is a nice thing to strive for, in many  industry verticals it just isn't going to be practical.

Zone maps are only effective if the data has been physically sorted in the table (by a time column for example, or maybe a phone number, customer id, or whatever).  The only way to guarantee that a table is sorted is to either know exactly how the data is loaded (for example, the table is only inserted into and is thus inherently ordered by time or some other id type column) or to regularly reorder the entire table (create newtable as select * from oldtable order by a,b,c and swap the new table with the old table).  Another alternative is to create materialized views and use the views to sort the table (assuming you have enough extra storage).  In general most of my data is automatically loaded in a fairly sorted order (by time) so mostly we rely on that.  We also have some materialized views which we use to only select a subset of the columns in the table which are most commonly used and to also guarantee sorting based on the MVIEW definition.

Prior to NPS version 4.0 when a record was deleted it would totally destroy the zone maps altogether but fortunatly that problem was fixed.  The only problem with delete/update now is that you have to come back and reclaim the space and you may end up with unsorted data (when you update a record it is going to move to the end of the table, leaving a deleted record in the middle until nzreclaim cleans it up).  The only way to fix that problem is as I mentioned above if  you cannot design a loading method which avoids updates.

I've attached a script which will show  you how effective your zone maps are on a given table.  Must be ran as a user that already has the NZ_USER and NZ_PASSWORD variables set (or has used nzpassword to cache the encrypted password).