Last week, we had some issues with our secondary server and IBM
technical support suggests us to run 'oncheck -cI' on the secondary.
The results shows we need to drop and recreate on a lot of indexes.
Because secondary is read-only, we were told we had to drop and
recreate the indexes on primary. Of course he failed to mention, once
you dropped the indexes, it's almost impossible to recreate the indexes
unless you can get exclusive lock on the table. For a busy server, this
means downtime and that is out of question especially when primary's
indexes are clean. So we went with the second route: did a full restore
on secondary.

But oncheck still comes back with exact same result, suggest to drop
and recreate all the indexes. We were puzzled. I opened another case to
get a second opinion. This time, I was told to make secondary standard
and fix indexes as standard (onmode -d standard) . And of course it did
not work because one can only make secondary into standard if DR is
off. The secondary is fine and the DR is on so we are stuck. The case
was escalated and the following is the answer coming from advanced
support,

"The indexes coming back as being corrupt is normal. The secondary of
an HDR pair is always being updated so it is always in an inconsistent
state. As a result, the indexes will always look corrupt to an oncheck
and the chunks usually appear to be in a PI status.

Oncheck does not know how to interpret this behavior, so it shows them
as being corrupted. Unfortunately, this is not documented so it
confuses users."

In other words, you don't really need to fix it. The indexes will look
corrupted to oncheck....
Anyone has similar experience? would you care to share?

-Vivien Kobayashi