Db2/z V11-NFM: All TS in UTRW status

Mario Novelli

Db2/z V11-NFM: All TS in UTRW status
non-data sharing.

Not sure if this is a bug or how its supposed to work. Could not find any hits on the issue.

While looking into an issue noticed that every tablespace in a particular database was in UTRW status. There was no utility running at the time, anywhere and no stopped utilities with a hanging util-id.

Only utility I could find running against these DB/ts' was COPY.

The COPY is a FULL SHRLEVEL CHANGE using a LISTDEF list.

Looked at the doc for COPY and came across this.....

* If you are copying a list and you specify the SHRLEVEL CHANGE option, you can specify OPTIONS EVENT(ITEMERROR,SKIP) so that each object in the list is placed in UTRW status and the read claim class is held only while the object is being copied.
* The read claim class is briefly obtained for each object during the UTILINIT phase to determine the object size if LIMIT is specified on the COPYDDN or RECOVERYDDN template. This applies only if OPTIONS EVENT(ITEMERROR,SKIP) is specified.
* If you do not specify OPTIONS EVENT(ITEMERROR,SKIP), all of the objects in the list are placed in UTRW status and the read claim class is held on all objects for the entire duration of the COPY.
Our COPY does not have an OPTIONS statement.

Questions:
-Is there any impact of having all those TS in UTRW status other than preventing another utility?
-It reads like it would be of benefit to add an OPTIONS to reduce the time of the read claim. Anyone have any experience on this?
-Will adding the OPTIONS allow the tablespaces to go back to R/W status?
-Is this behavior a bug? Why would the UTRW status remain after the job successfully ends.

Thank you very much for any insight you can provide.
Mario











http://www.medmutual.com [cid:[login to unmask email]

Visit MedMutual.com http://www.medmutual.com


CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure by law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this message. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature, unless a specific statement to the contrary is included in this message.
Thank you, Medical Mutual.

Attachments

  • image86b44c.JPG (9.7k)

Andy Smith

RE: Db2/z V11-NFM: All TS in UTRW status
(in response to Mario Novelli)

Hi Mario

We've recently encountered an SQLCODE -666 (new to me) during an ALTER INDEX operation, due to the associated tablespace being marked as UTRW as a result of being included in a large LISTDEF for an active COPY utility (note that the associated tablespace was not actually being copied at the time of the -666, the copy took place approx 30 mins later).  It was at this point that I learnt about using OPTIONS EVENT(ITEMERROR,SKIP) with the LISTDEF, so that only the object currently going through the utility processing has the UTRW status, instead of all objects in the LISTDEF.

If you cannot find any outstanding utilities then perhaps you should open a case with IBM.  The only time that I've seen something like this was after a version migration, with an outstanding utility from the previous version not being tidied-up properly before the migration.  Fallback and TERM UTIL was necessary before re-migrating again.

Please update this thread with the outcome.

Thanks
Andy

Mario Novelli

RE: Db2/z V11-NFM: All TS in UTRW status
(in response to Andy Smith)

Hadn’t thought of the migration scenario. We did have a recent V12 migration issue and fallback. Do not know what the status was at the time the upgrade was installed.

PMR w/IBM opened.

Steven Lamb

RE: Db2/z V11-NFM: All TS in UTRW status
(in response to Andy Smith)

Another useful feature of OPTIONS EVENT(ITEMERROR,SKIP) is if you have nultiple LISTDEFs in the same job step.

Without it, if there's an error processing an object in one LISTDEF, any subsequest LISTDEFs in the same job step are flushed. With it, subsequent LISTDEFs do get processed.

 

Ooh, Mr Smith - not checking for outstanding utilities before a migration, what can I say :)

 

Regards,

Steve

Mario Novelli

RE: Db2/z V11-NFM: All TS in UTRW status
(in response to Steven Lamb)

IBM requested running:
DIAGNOSE DISPLAY DBET DATABASE dbname
DIAGNOSE DISPLAY DBET TABLESPACE TSname <-- every TS had an entry in the output

IBM responded:
You have an orphan DBET record.
Either the job was cancelled or a utility was running and someone forced Db2 down.

Ran:
REPAIR SET TABLESPACE TSname RESET <-- on all tablespaces

The DISPLAY then returned nothing.

My guess is OPS forced Db2 down while the backup was running. Closed PMR

Andy Smith

RE: Db2/z V11-NFM: All TS in UTRW status
(in response to Mario Novelli)

Thanks for the update Mario, I'll try to remember that one.