테라바이트 급 테이블의 인덱스를 만들 때, 대량의 데이터이다 보니 인덱스 하나를 생성하는데도
3~4시간 걸리는 경우가 있다.
이런 인덱스를 심지어 4~5개를 생성해야 될 경우, 인덱스 하나를 생성하는 시간은 전체 이행
소요시간에 절대적인 영향을 미치게 되므로 매우 중요하다고 볼 수 있다.
그런데, 3시간 이상 돌던 인덱스 작업이 에러를 발생시키면서 죽어버린다.
미치고 팔짝 뛸 지경이다. 에러 메시지 확인 결과, 테이블스페이스 부족이란다.
테이블스페이스를 늘려주기만 하면 되겠지만, 막상 넉넉하게 공간을 줄 수 있는 상황도 아니다 보니,
최대한 예측해서 늘려줬지만, 또 불가피하게 부족해서 다시 돌린 경우도 죽는 경우가 발생하게 된다.
이렇게 두번만 죽어도 그 날의 인덱스 생성 작업은 실패라고 볼 수 있겠다..
무려 6시간 이상이 날아가버렸으니…이런 억울한 상황을 당하지 않기 위해 기억해야 할 파라미터가
하나 있다.
“resumable_timeout” 이 바로 그것이다.
v$parameter의 resumable_timeout 파라미터 value에 부여한 시간 만큼 대기하겠다는 의미이다.
이 시간만큼은 테이블스페이스가 부족해서 에러가 나더라도 돌던 작업이 죽지 않고, 그 시간 만큼은
대기해 준다는 것이다. 그 시간 안에 현상을 파악한 후 공간을 추가하게 되면 다시 정상적으로 작업이
돌게 된다. 이렇게 함으로써 우리는 이행할 때 절대적인 시간을 save할 수 있게 될 것이다.
resumable 대상을 확인하는 sql은 아래와 같다.
select COORD_INSTANCE_ID, COORD_SESSION_ID, SESSION_ID, NAME, status,
TIMEOUT, SUSPEND_TIME, START_TIME, ERROR_NUMBER,
substr(SQL_TEXT,1,150) SQL_TEXT
from dba_resumable
where status != 'NORMAL' -- 'SUSPENDED'
order by 1,2,3