We have SAP live system with some custom tables running on RHEL6 DB2 10.1 FP2.System was setup on DB2 9.7 FP5 and then upgraded. Custom tables were created with classic row compression.
One custom table has grown to 350 GB and then we decided to clean it by removing oldest entries. Table had over 1,3 billion rows and we cut it to 300 million records. Daily grow during workday is about 10 million rows. We haven't done reorg after that. So we decided to recompress it to adaptive compression using online admin move table and then free tablespace space by reducing HWM. Copy phase took about 10 hours during night then replay begin. Unfortunately staging tablespace has grown to 20 million records and it is growing daily till 30 million records then replay is able to reduce staging table to 20 million. Next day situation reoccurs. I've been observing db2top and looks like replay is able to process no more than 200 rows per second on source,staging and target table. Normal inserts/deletes are able to process 5000 -10000 per/sec in source and staging table simultanously.
I've aborted this operation on wednesday but looks like we must wait to clean staging table which takes ages.
Fortunately we have weekend in few hours so during 48 hours there will be no operation on this table but i'm not sure if it will end till monday morning.
Is it possible to speed up REPLAY phase now (tuning some parameters) or just terminate AMT now ?
I know i should stop any table activity but for some reasons it is not an option.
Any ideas ?