시간이 오래 걸리는 것은 건수가 많아서 그런거라 어쩔 수 없어 보이네요.

혹시 High availability ( HADR )이 설정되어 있으신가요? HADR이 설정되어 있고, sync mode가 SYNC로 되어 있으면 log shipping으로 인한 지연이 발생할 수 있습니다. 이런 경우 ASYNC로 바꿔 주시면 확실히 좋아 집니다. ( mode는 님의 환경에 따라 다시 원복하셔도 되고 놔두셔도 되구요.)

rollback이 다 되지 않은 상태에서 죽여 버리는 것은 좀 위험해 보이네요. ( 그래서  backup - restore 를 하시려는 것 같구요. ) 하지만 그래도 상황이 그래도 상관이 없다고 하면, 저의 제안은 이렇습니다.

1. backup or export

만약 table이 몇 개 안 되면 ( 하나면 더 좋구요 ) db2move 등으로  data를 export 받아 놓으시고,

export로 내리기에는 좀 무리가 있다으면, 이 table이 속해있는 table space만 따로 backup을 받으셔도 되겠습니다.

* 만약의 경우를 대비해서 db2look으로  schema definition 받아 놓으시구요. ( 혹 권한 문제가 엮여 있다면 -x 옵션으로 grant에 대한 정보도 같이 받으세요. )

2. not logged initially

update 작업을 하기 전에 log를 기록하지 않도록 설정해 놓으시면 log를 기록하지 않고 작업을 합니다. 문제는 log가 없기 때문에 rollback이 의미가 없고, 혹시라도 강제로 작업을 죽여야 하거나/죽게 되는 경우 table이 깨져 버립니다. 그러면 table을 drop 하고 다시 생성해야 합니다.

* alter table 부분을 살펴 보시기 바랍니다.

3. restore / import

update를 마쳤는데 이전 상태로 돌려야하는 상황이 되었으면,  restore를 통해 해당 table space만 다시 복원을 할 수 있고, export로 받아 놓은 상태라면 db2move의 load를 사용하여 다시 table들의 데이타를 복원할 수 있습니다. 만약 db2move를 사용하셨다면 table load후에 table이 check pending 상태로 들어 가 있을 확률이 높으니, check pending을 풀어 주는 작업을 해 주셔야 합니다.

이 방법의 장점은 log에 상관없이 작업을 할 수 있기 때문에 상대적 속도가 빠르다는 것이나, 단점으로는 rollback이 의미가 없어지기 때문에 문제가 발생할 경우 rollback을 이용한 복구가 안 된다는 것과 중간에 문제가 발생할 경우, 복원이 좀 귀찮아진다는 점입니다.

자세한 관련 문법은  db2 backup, alter table, db2move, db2look, set integrity 등을 살펴 보시기 바랍니다.

짧은 지식이라 도움이 될런지 모르겠네요.. 수고하세요.