Netezza: nzbackup and concurrent database use

PROBLEM: 

ETL process takes too long when running concurrently with nzbackup.   Why ?

SOLUTION:

Refrain from DDL statements below in ETL design to eliminate nzbackup dependency : 

• TRUNCATE TABLE
• DROP TABLE 
• ALTER TABLE
• GROOM

Above DDL statements will be on hold as "waiting" until nzbackup completes.  Eventually, these statements will succeed, but with delay, upon backup completion. Note, GROOM TABLE VERSIONS will succeed too, however, it will fail nzbackup.

No issues running these statements concurrently with nzbackup : 

• CREATE/DROP TEMP TABLE
• CREATE/DROP any object except table 
• INSERT/UPDATE/DELETE on TABLE
• GENERATE STATISTICS

EXPLANATION: 

Netezza NPS 7.2 documentation about concurrent user during backup operation: 

While a backup is running on a database, users cannot drop or truncate a table in that database until the backup completes. The DROP TABLE and TRUNCATE TABLE commands wait (and appear to hang) until the backup finishes. Operations such as an insert or load, or creating or dropping other object types such as view, run without waiting while the backup is in progress. If a GROOM TABLE VERSIONS command runs on a table that is being backed up, the backup process exits with an error and you must restart the backup process.

Refer  The nzbackup command

See related post: Netezza: nzbackup & nzrestore on NPS 7.2.

Related documentation:  Database backup and restore