Damaged extents after upgrade to 8.1.19 BE AWARE

[uffeg]

We have had such a struggle with damaged extents and asked IBM for the reason.
TODAY I finally got a reply in another case where we asked about move container with defrag=yes. If that is okay in 8.1.21 since we suspected that could be a reason on 8.1.19.

IBM now wrote:

Thank you for the updates. This is Merna with SP support team, I will be working with you in this case.
As I understood that you're trying to enable defrag to solve damaged extents appeared after upgrade !
Auto defrag which is running with defrag=yes should be installed and enabled automatically at your version as it's installed starting version 8.1.16.

As for the damages appearing after upgrade to 8.1.19 and 8.1.20, This happens because the container size was enforced in 8.1.19 and later versions. so the cntr size mismatch created prior to 8.1.19 will be exposed and will be reported as damaged extents.

I suggest to run the fix below to get rid of the damages.

1. Reset the filesize in container records as their actual file size in filesystem. Please run it when server has less stress to avoid resource conflict.

RESET CONTAINERSIZE <pool>
2. Audit the damaged containers

db2 -x "select 'audit container ' || cntrname || ' w=y'from tsmdb1.sd_containers where cntrid in (select ac.cntrid from tsmdb1.sd_all_chunks ac, tsmdb1.sd_dedup_audit da where da.id=ac.chunkid)" > re-audit.macro
Then run the generated re-audit.macro via dsmadmc

Hope this helps. Please let me know if you have any questions.

Thank you,
Merna Nagy
IBM SP support

 

[EricvanLoon]

Hi Merna,

I'm also having issues with multiple damaged extents, can you please sent me your case number, so I can refer to it in my case? Thanks in advance!
By the way, 8.1.22 is available, which contains multiple stgrule replication fixes.

Kind regards,
Eric

 

[uffeg]

Hi Merna,

I'm also having issues with multiple damaged extents, can you please sent me your case number, so I can refer to it in my case? Thanks in advance!
By the way, 8.1.22 is available, which contains multiple stgrule replication fixes.

Kind regards,
Eric

Hi, Im Ulf. Merna is from IBM.

But anyhow here is the case nr: TS016020759

I have found out how this has happened.
If you run PROTECT/REPLICATE and go up to 8.1.19 nothing happens.
As soon as you enable stgrule repl instead, BAM. damaged extents.

So we all have latent issue just waiting for it to happen.

And if IBM is correct in this case then it measns as soon as you have an old server that runs prot/repl you have to do this first before using stgrule repl:

1. reset containersize.
2. audit on ALL containers
3. then change to stgrule repl.

How do I know, we have many servers still using prot/repl.
All servers we got problems with was converted to stgrule repl.