DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

Bill Gallagher

DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
We are DB2 z/OS v11 NFM.

We're looking to do some SHRLEVEL(CHANGE) reorgs on our LOB tablespaces. Some of them are defined as NOT LOGGED.

I'm wondering how SHRLEVEL(CHANGE) and NOT LOGGED tablespaces can play nicely together?

And in particular, is there anything unusual that we need to look out for when doing this?

Thanks in advance for any comments or advice that you may be able to offer.

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration
________________________________
This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

TRVDiscDefault::1201

Olle Brostrom

DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Bill Gallagher)
From Knowledge center DB2 11

You can run REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space.
REORG TABLESPACE SHRLEVEL CHANGE processes a LOB table space the same as REORG SHRLEVEL REFERENCE except the mapping table is ignored.
The restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces applies to LOB table spaces.
REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space uses shadow data sets and includes a LOG phase.

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/ugref/src/tpc/db2z_utl_reorgtablespace.html


Best Regards

Olle Broström

From: Gallagher,Bill R [mailto:[login to unmask email]
Sent: den 19 september 2018 16:47
To: [login to unmask email]
Subject: [DB2-L] - DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

We are DB2 z/OS v11 NFM.

We're looking to do some SHRLEVEL(CHANGE) reorgs on our LOB tablespaces. Some of them are defined as NOT LOGGED.

I'm wondering how SHRLEVEL(CHANGE) and NOT LOGGED tablespaces can play nicely together?

And in particular, is there anything unusual that we need to look out for when doing this?

Thanks in advance for any comments or advice that you may be able to offer.

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration
________________________________
This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

TRVDiscDefault::1201
-----End Original Message-----

Bill Gallagher

DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Olle Brostrom)
Ollie,

Yes, thanks. The manual was the first place I looked.

Unfortunately, "the restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces" is not easily found. Can you (or somebody) point me to where that restriction is defined?

Also, I'm trying to understand how the LOG phase of a SHRLEVEL CHANGE reorg works if the tablespace is defined as NOT LOGGED. The LOG phase typically reads the log and applies any updates made to the tablespace since the REORG started to the shadow data sets. But if nothing is being logged (because of NOT LOGGED), then how does the LOG phase work; what does it actually do?

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration

From: Olle Brostrom <[login to unmask email]>
Sent: Thursday, September 20, 2018 6:59 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

From Knowledge center DB2 11

You can run REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space.
REORG TABLESPACE SHRLEVEL CHANGE processes a LOB table space the same as REORG SHRLEVEL REFERENCE except the mapping table is ignored.
The restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces applies to LOB table spaces.
REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space uses shadow data sets and includes a LOG phase.

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/ugref/src/tpc/db2z_utl_reorgtablespace.html


Best Regards

Olle Broström

From: Gallagher,Bill R [mailto:[login to unmask email]
Sent: den 19 september 2018 16:47
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

We are DB2 z/OS v11 NFM.

We're looking to do some SHRLEVEL(CHANGE) reorgs on our LOB tablespaces. Some of them are defined as NOT LOGGED.

I'm wondering how SHRLEVEL(CHANGE) and NOT LOGGED tablespaces can play nicely together?

And in particular, is there anything unusual that we need to look out for when doing this?

Thanks in advance for any comments or advice that you may be able to offer.

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration
________________________________
This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

TRVDiscDefault::1201
-----End Original Message-----

-----End Original Message-----

Michael Hannan

RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Bill Gallagher)

Bill,

Without claiming to actually know a lot in depth, that even if the LOB Tablespace is not Logged, then reference pointers to the LOB objects from the normal Tablespace or Auxiliary Index would be. So updates for those pointers would have to be applied in the Log phase. Just trying to guess, and without even worrying about the exact format of the LOB reference info. I guess Rowid comes into it.

I can don't know if a LOB tablespace can be Reorged without any affect to the referencing normal tablespace, but possibly only affects the Auxiliary Index. Never ran a LOB Reorg myself. I think of it being similar to not being able to reorg a table without updating its indexes.

Anyway the Log apply phase has to do catchup of recent changes that occurred since the original objects were copied. So I think it might be references to the LOB that have to be logged and updated, even if every LOB object is only replaced and never updated in place, hence no logging of first to last changed byte inside a LOB.

Hate to think how much Log would be used if frequent changes to contents of a LOB were logged. I know from bad experience long ago when I had a DBD with too many objects e.g 300 or 400, and did COMMIT after every DDL that changed the DBD, creating the new objects. LOL The before and after images were rather large and logs got cycled very fast indeed. Ha ha. Only make that mistake once. Small DBDs are better!, although we don't all have Auth to create lots of new Databases. Maybe reduce Commits too.
 
In Reply to Bill Gallagher:

Ollie,

Yes, thanks. The manual was the first place I looked.

Unfortunately, "the restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces" is not easily found. Can you (or somebody) point me to where that restriction is defined?

Also, I'm trying to understand how the LOG phase of a SHRLEVEL CHANGE reorg works if the tablespace is defined as NOT LOGGED. The LOG phase typically reads the log and applies any updates made to the tablespace since the REORG started to the shadow data sets. But if nothing is being logged (because of NOT LOGGED), then how does the LOG phase work; what does it actually do?

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration


 

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Edited By:
Michael Hannan[Organization Members] @ Sep 21, 2018 - 10:39 AM (Europe/Berlin)
Michael Hannan[Organization Members] @ Sep 21, 2018 - 10:42 AM (Europe/Berlin)
Michael Hannan[Organization Members] @ Sep 21, 2018 - 10:51 AM (Europe/Berlin)
Michael Hannan[Organization Members] @ Sep 21, 2018 - 10:53 AM (Europe/Berlin)
Michael Hannan[Organization Members] @ Sep 21, 2018 - 11:27 AM (Europe/Berlin)
Michael Hannan[Organization Members] @ Sep 21, 2018 - 11:28 AM (Europe/Berlin)
Michael Hannan[Organization Members] @ Sep 21, 2018 - 11:29 AM (Europe/Berlin)
Michael Hannan[Organization Members] @ Sep 21, 2018 - 11:30 AM (Europe/Berlin)

Olle Brostrom

DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Bill Gallagher)
Since the tablespace is NOT LOGGED the logapply phase is dismissed even if you run SHRLEVEL CHANGE.
I assume the object is not available for update during the REORG, that is what I read from the manual!

Best Regards

Olle Broström

From: Gallagher,Bill R [mailto:[login to unmask email]
Sent: den 20 september 2018 14:28
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

Ollie,

Yes, thanks. The manual was the first place I looked.

Unfortunately, "the restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces" is not easily found. Can you (or somebody) point me to where that restriction is defined?

Also, I'm trying to understand how the LOG phase of a SHRLEVEL CHANGE reorg works if the tablespace is defined as NOT LOGGED. The LOG phase typically reads the log and applies any updates made to the tablespace since the REORG started to the shadow data sets. But if nothing is being logged (because of NOT LOGGED), then how does the LOG phase work; what does it actually do?

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration

From: Olle Brostrom <[login to unmask email]>
Sent: Thursday, September 20, 2018 6:59 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

From Knowledge center DB2 11

You can run REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space.
REORG TABLESPACE SHRLEVEL CHANGE processes a LOB table space the same as REORG SHRLEVEL REFERENCE except the mapping table is ignored.
The restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces applies to LOB table spaces.
REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space uses shadow data sets and includes a LOG phase.

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/ugref/src/tpc/db2z_utl_reorgtablespace.html


Best Regards

Olle Broström

From: Gallagher,Bill R [mailto:[login to unmask email]
Sent: den 19 september 2018 16:47
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

We are DB2 z/OS v11 NFM.

We're looking to do some SHRLEVEL(CHANGE) reorgs on our LOB tablespaces. Some of them are defined as NOT LOGGED.

I'm wondering how SHRLEVEL(CHANGE) and NOT LOGGED tablespaces can play nicely together?

And in particular, is there anything unusual that we need to look out for when doing this?

Thanks in advance for any comments or advice that you may be able to offer.

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration
________________________________
This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

TRVDiscDefault::1201
-----End Original Message-----

-----End Original Message-----

-----End Original Message-----

Neil Price

DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Olle Brostrom)
I believe that page of the Knowledge Center / manual is out of date and no
such restriction applies.

For Db2 11 and above, the REORG TABLESPACE syntax page (
https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/ugref/src/tpc/db2z_reorgtablespacesyntax.html)
states "You cannot specify SHRLEVEL CHANGE if the table space has the NOT
LOGGED attribute, *unless the table space is a LOB table space*."

Regards
Neil Price

On 25 September 2018 at 09:08, Olle Brostrom <[login to unmask email]> wrote:

> Since the tablespace is NOT LOGGED the logapply phase is dismissed even if
> you run SHRLEVEL CHANGE.
>
> I assume the object is not available for update during the REORG, that is
> what I read from the manual!
>
>
>
> Best Regards
>
>
>
> *Olle Broström*
>
>
>
> *From:* Gallagher,Bill R [mailto:[login to unmask email]
> *Sent:* den 20 september 2018 14:28
>
> *To:* [login to unmask email]
> *Subject:* [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
>
>
>
> Ollie,
>
>
>
> Yes, thanks. The manual was the first place I looked.
>
>
>
> Unfortunately, “the restriction for REORG TABLESPACE SHRLEVEL CHANGE on
> NOT LOGGED table spaces” is not easily found. Can you (or somebody) point
> me to where that restriction is defined?
>
>
>
> Also, I’m trying to understand how the LOG phase of a SHRLEVEL CHANGE
> reorg works if the tablespace is defined as NOT LOGGED. The LOG phase
> typically reads the log and applies any updates made to the tablespace
> since the REORG started to the shadow data sets. But if nothing is being
> logged (because of NOT LOGGED), then how does the LOG phase work; what does
> it actually do?
>
>
>
> *Bill Gallagher *|* Senior Systems Engineer, DBA *|* Data Administration *
>
>
>
> *From:* Olle Brostrom <[login to unmask email]>
> *Sent:* Thursday, September 20, 2018 6:59 AM
> *To:* [login to unmask email]
> *Subject:* [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
>
>
>
> From Knowledge center DB2 11
>
>
>
> You can run REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space.
>
> REORG TABLESPACE SHRLEVEL CHANGE processes a LOB table space the same as
> REORG SHRLEVEL REFERENCE except the mapping table is ignored.
>
> The restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table
> spaces applies to LOB table spaces.
>
> REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space uses shadow data
> sets and includes a LOG phase.
>
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.
> 0.0/ugref/src/tpc/db2z_utl_reorgtablespace.html
>
>
>
>
>
> Best Regards
>
>
>
> *Olle Broström*
>
>
>
> *From:* Gallagher,Bill R [mailto:[login to unmask email]
> <[login to unmask email]>]
> *Sent:* den 19 september 2018 16:47
> *To:* [login to unmask email]
> *Subject:* [DB2-L] - DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
>
>
>
> We are DB2 z/OS v11 NFM.
>
>
>
> We’re looking to do some SHRLEVEL(CHANGE) reorgs on our LOB tablespaces.
> Some of them are defined as NOT LOGGED.
>
>
>
> I’m wondering how SHRLEVEL(CHANGE) and NOT LOGGED tablespaces can play
> nicely together?
>
>
>
> And in particular, is there anything unusual that we need to look out for
> when doing this?
>
>
>
> Thanks in advance for any comments or advice that you may be able to offer.
>
>
>
> *Bill Gallagher *|* Senior Systems Engineer, DBA *|* Data Administration *
> ------------------------------
>
> This message (including any attachments) may contain confidential,
> proprietary, privileged and/or private information. The information is
> intended to be for the use of the individual or entity designated above. If
> you are not the intended recipient of this message, please notify the
> sender immediately, and delete the message and any attachments. Any
> disclosure, reproduction, distribution or other use of this message or any
> attachments by an individual or entity other than the intended recipient is
> prohibited.
>
> TRVDiscDefault::1201
>
> -----End Original Message-----
>
>
>
> -----End Original Message-----
>
>
> -----End Original Message-----
>
> -----End Original Message-----
>

Bill Gallagher

DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Neil Price)
That brings me back to my original question:

If the LOB tablespace is defined as NOT LOGGED, how does a SHRLEVEL CHANGE reorg work?

Any updates prior to the “log apply” phase of the reorg will be made to the live tablespace. The “log apply” phase then reads the log and applies any updates made to the live tablespace since the start of the reorg utility to the shadow copy. But if there was no logging (because of NOT LOGGED), then how do those updates make it over to the shadow copy of the LOB tablespace?

I would assume that it works somehow . . . otherwise, IBM would not allow SHRLEVEL CHANGE reorgs to LOB tablespaces. I’m just trying to understand the mechanism in which it does so, so that we can understand any risks involved and where the risks may be.

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration

From: Neil Price <[login to unmask email]>
Sent: Tuesday, September 25, 2018 11:23 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

I believe that page of the Knowledge Center / manual is out of date and no such restriction applies.

For Db2 11 and above, the REORG TABLESPACE syntax page (https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/ugref/src/tpc/db2z_reorgtablespacesyntax.html) states "You cannot specify SHRLEVEL CHANGE if the table space has the NOT LOGGED attribute, unless the table space is a LOB table space."

Regards
Neil Price

On 25 September 2018 at 09:08, Olle Brostrom <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Since the tablespace is NOT LOGGED the logapply phase is dismissed even if you run SHRLEVEL CHANGE.
I assume the object is not available for update during the REORG, that is what I read from the manual!

Best Regards

Olle Broström

From: Gallagher,Bill R [mailto:[login to unmask email]<mailto:[login to unmask email]>]
Sent: den 20 september 2018 14:28

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

Ollie,

Yes, thanks. The manual was the first place I looked.

Unfortunately, “the restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces” is not easily found. Can you (or somebody) point me to where that restriction is defined?

Also, I’m trying to understand how the LOG phase of a SHRLEVEL CHANGE reorg works if the tablespace is defined as NOT LOGGED. The LOG phase typically reads the log and applies any updates made to the tablespace since the REORG started to the shadow data sets. But if nothing is being logged (because of NOT LOGGED), then how does the LOG phase work; what does it actually do?

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration

From: Olle Brostrom <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Thursday, September 20, 2018 6:59 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

From Knowledge center DB2 11

You can run REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space.
REORG TABLESPACE SHRLEVEL CHANGE processes a LOB table space the same as REORG SHRLEVEL REFERENCE except the mapping table is ignored.
The restriction for REORG TABLESPACE SHRLEVEL CHANGE on NOT LOGGED table spaces applies to LOB table spaces.
REORG TABLESPACE SHRLEVEL CHANGE on a LOB table space uses shadow data sets and includes a LOG phase.

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/ugref/src/tpc/db2z_utl_reorgtablespace.html


Best Regards

Olle Broström

From: Gallagher,Bill R [mailto:[login to unmask email]
Sent: den 19 september 2018 16:47
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)

We are DB2 z/OS v11 NFM.

We’re looking to do some SHRLEVEL(CHANGE) reorgs on our LOB tablespaces. Some of them are defined as NOT LOGGED.

I’m wondering how SHRLEVEL(CHANGE) and NOT LOGGED tablespaces can play nicely together?

And in particular, is there anything unusual that we need to look out for when doing this?

Thanks in advance for any comments or advice that you may be able to offer.

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration
________________________________
This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

TRVDiscDefault::1201
-----End Original Message-----

-----End Original Message-----

-----End Original Message-----

-----End Original Message-----

Michael Hannan

RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Bill Gallagher)

In Reply to Bill Gallagher:

That brings me back to my original question:

If the LOB tablespace is defined as NOT LOGGED, how does a SHRLEVEL CHANGE reorg work?

Any updates prior to the “log apply” phase of the reorg will be made to the live tablespace. The “log apply” phase then reads the log and applies any updates made to the live tablespace since the start of the reorg utility to the shadow copy. But if there was no logging (because of NOT LOGGED), then how do those updates make it over to the shadow copy of the LOB tablespace?

Bill,

I am not going to investigate this in great depth, to be sure of workings. I don't know which shadow objects are created.

However I can point out a couple of things that can allow it work. Let us assume that a LOB is not updated but a new copy is made, and the pointers (index entries) to it are updated.

During Reorg if any LOB is changed you have the entire old LOB value sitting somewhere and the entire new LOB value somewhere. DB2 can copy that if it wants to, without having the normal LOG entries but with Log entries for the index pointers to those old and new object values. Hope this makes sense.

With more time spent, I am sure more aspects of the method could be deduced.

I am sure they are smart enough to make it work. Just don't know the exact implementation details, as I don't need it for my work. This knowledge however could give you insight into how the utility performs though.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Edited By:
Michael Hannan[Organization Members] @ Sep 26, 2018 - 01:38 PM (Europe/Berlin)

Bill Gallagher

DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)
(in response to Michael Hannan)
An update:

I opened a ticket with IBM to ask them about this. They responded by pointing me to the “DB2 10 for z/OS Technical Overview” Redbook (SG24-7892), section 11.4.1.

Basically, when doing a SHRLEVEL CHANGE reorg for a LOB tablespace that is defined as “NOT LOGGED”, DB2 will automatically turn on logging for the tablespace for the duration of the REORG utility.

Bill Gallagher | Senior Systems Engineer, DBA | Data Administration

From: Michael Hannan <[login to unmask email]>
Sent: Wednesday, September 26, 2018 7:36 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS - REORG LOB Tablespace SHRLEVEL(CHANGE)


In Reply to Bill Gallagher:
That brings me back to my original question:

If the LOB tablespace is defined as NOT LOGGED, how does a SHRLEVEL CHANGE reorg work?

Any updates prior to the “log apply” phase of the reorg will be made to the live tablespace. The “log apply” phase then reads the log and applies any updates made to the live tablespace since the start of the reorg utility to the shadow copy. But if there was no logging (because of NOT LOGGED), then how do those updates make it over to the shadow copy of the LOB tablespace?

Bill,

I am not going to investigate this in great depth, be sure of workings. I don't know which shadow objects are created.

However can point out a couple of things that can allow it work. Let us assume that a LOB is not updated but a new copy is made, and the pointers to it are updated.

During Reorg if any LOB is changed you have the entire old LOB value sitting somewhere and the entire new LOB value somewhere. DB2 can copy that if it wants to, without having the normal LOG entries but with Log entries for the pointers to those old and new object values.

With more time spent, I am sure more aspects of the method could be deduced.

I am sure they are smart enough to make it work. Just don't know the exact implementation details, as I don't need it for my work. This knowledge however could give you insight into how the utility performs though.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

-----End Original Message-----
________________________________
This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

TRVDiscDefault::1201