There are open transactions on table that repair tries to repair.
Because of these open transactions, post process places lock on table's rows, indexes, etc. Since repair is using post process to apply the discrepancy messages, post has to be running while table is repairing. As the result, post will have lock on table's rows, blocked, indexes, etc, and it causes repair in second stage (repair stage) to not able to lock the table.
To confirm open transactions are the cause of repair hung, the following steps can be used:
1. query oracle
select * from dba_dml_locks where name='<target_repair_table_name>'
or
select
c.owner,
c.object_name,
c.object_type,
b.sid,
b.serial#,
b.status,
b.osuser,
b.machine
from
v$locked_object a ,
v$session b,
dba_objects c
where
b.sid = a.session_id
and
a.object_id = c.object_id;
2. Check qstatus and qview.
a. qstatus - should have old timestamp
b. qview's output - check for commit and non commit subque.
egrep / grep -i "commit|rollback" qview.out | awk -F "," ' {print $1} ' | sort -u
cat qview.out | awk -F "," '{print $1}' | sort -u
compare output from grep commit and cat to identify which subques do not have commit or rollback.
discard or read release messages from subques that do not have commit or rollback.
run repair again after discard or read release old messages from open transactions.
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center