Share This:

This time we’ll discuss two recent changes in NGT Unload, the addition of a “less dirty”, which I’ll explain shortly, and the ability to set the default concurrency, or SHRLEVEL.

NGT Unload has always defaulted to “online unload” creating a point of consistency unload while keeping the object read-write.  After all, this only requires a single drain of the writer claims.  This is rarely a bother because transactions that update are pretty good at committing right away.  This table shows the NGT Unload concurrency options.  NGT’s default has always been SHRLEVEL CHANGE CONSISTENT YES, you don’t have to specify any SHRLEVEL to get an online consistent unload. This BLOG will primarily discuss the change shown below in bold.

 

Syntax

Concurrency

SHRLEVEL REFERENCE

 

 

RW POC

SHRLEVEL CHANGE

 

 

RW POC

SHRLEVEL CHANGE

CONSISTENT YES

 

RW POC

SHRLEVEL CHANGE

CONSISTENT NO

 

RW DIRTY

SHRLEVEL CHANGE

CONSISTENT NO

QUIESCE YES

Less Dirty

SHRLEVEL CHANGE

CONSISTENT NO

QUIESCE NO

RW DIRTY

 

SHRLEVEL CHANGE CONSISTENT NO QUIESCE YES

Prior to BQU2750 in February 2020, NGT would make a clean point of consistency unload if you requested CONSISTENT NO QUIESCE YES, just like it does with CONSISTENT YES.  Now NGT makes a “less dirty” unload which means it will drain the write claimers to flush any changes for the table space out of the Db2 buffer pool.  This makes the Unload less dirty because only changes that occur during the unload can be missed, any changes Db2 had buffered before the unload are externalized and unloaded. 

 

I know what you’re thinking, this is crazy.  It’s disruptive to get the drain but not disruptive to track the changes and make a consistent unload, so why have the same pain for less gain? 

 

If you haven’t read my previous BLOG about simultaneous unloads of the same table, please check it out.  There you will see that two Point-Of-Consistency (POC) unloads cannot run at the same time unless they share the POC.  If you are ultra-sensitive to the timeliness of your unloads and you have many unloads that may try to unload the same table at the same time, then you might want to opt for a less dirty and inconsistent unload rather than the chance of unload failure, especially in a test environment; this is why the “less dirty” option was added.

 

Default Unload concurrency

This leads us to the default unload SHRLEVEL keywords.  As I mentioned the default has always been SHRLEVEL CHANGE CONSISTENT YES and it still is. However, with BQU2907 in May of 2020 you now can configure the default you want using these Unload parameters (+parms).

 

  • +CONSISTENT(YES/NO)
  • +QUIESCE(YES/NO)

 

Now if you want no disruption to applications, no drain, and you’re OK with inconsistent data, you can configure +CONSISTENT(NO) and +QUIESCE(NO) for your shop default. That’s not a recommendation, but just one option.