에너쓰오라클

얼마전에  "smon recovery 중인 작업이 언제쯤 끝날까요? <undo_rollback_info.sql>"라는 포스팅을 했었죠. 오늘은 "transaction recovery를 조금 더 빨리 진행하게 하는 방법"에 대해 이야기 해보겠습니다. 

smon(pmon)이 recovery를 하고 있다는 것은 이미 user process가 해당 recovery를 cancel (kill -9 <process id>) 시키거나, database를 강제로 shutdown 시킨 이후의 상황이죠. 이 상황에서 recovery를 빠르게 하려면 두가지 방법이 있습니다.


여러개의 프로세서로 동시에 transaction recovery 하는 방법은 oracle 8i에서 소개된 fast start parallel recovery 기능이 있습니다. 이 기능은 fast_start_parallel_recovery parameter의 설정으로 가능합니다.

이 parameter는 (LOW/HIGH/FALSE)의 값을 지정할 수 있으며 LOW 지정시에는 CPU * 2개의 parallel slave process까지 기동할 수 있으며, HIGH의 경우 CPU * 4개의 parallel slave process가 기동 됩니다. parallel recovery는 v$fast_start_servers와 v$fast_start_transactions view로 확인이 가능합니다. 가끔 parallel recovery가 smon과의 통신으로 인해 성능 저하가 발생할 경우가 있다는데, 이럴 경우 FALSE로 설정하여 serial하게 recovery를 진행할 수 있습니다.



두번째 한번 수행시 많은 양의 recovery를 하게끔 유도하는 방법은 cleanup_rollback_entries parameter로 조정가능합니다. 기본적으로 smon은 한번에 20개의 undo entriy를 정리하고 잠깐 sleep 하게 됩니다. 따라서 많은 양의 transaction recovery가 필요한 경우 이 값을 많이 늘려 한번에 수행되는 양을 많게 설정합니다. 유의할 점은 smon에게 한번에 많은 양의 recovery를 지정하였으므로 CPU를 과도하게 소모할 수 있으므로 recovery시 수행되는 다른 작업에 영향을 끼칠 수 도 있습니다.

참고:
fast-start parallel rollback 기능에 대한 추가 설명

얼마전에 지금 "smon recovery 중인 작업이 언제쯤 끝날까요? <undo_rollback_info.sql>"라는 내용으로 SMON에서 recovery하는 내용을 모니터링하는 방법을 포스팅하긴 했지만..

이 방법은 수행중인 transaction을 무시하고 oracle을 내려버려서 smon이 transaction을 가지고 있는 rollback segment 별로 얼마나 rollback을 해야하는지 시간을 대충 산정할 수 있는 방법이죠.

현재 수행중인 transaction이 얼마나 작업을 했을까, 또 요거 끊으면 얼마나 rollback하는데 시간이 소모도리까? 이걸 알 수 있는 방법은 없을까요?




뭐 대략적인 방법이긴 하지만,  v$transaction의 used_ublk, used_urec column으로 대충 산정할 수 있습니다.

다음의 SQL은 transaction을 모니터링 할 수 있는 SQL 입니다. 뭐 v$session과 v$transaction을 join 한 단순한 script 입니다.

그럼, 우선 테스트를 할 table을 만들어 보고요..

이제 transaction을 만들어 보겠습니다. 시간이 좀 걸려야 하므로 1000만건 정도 만들겠습니다.

(음.. 제 PC내의 vmware에 설치한 oracle로 테스트를 하니 난리군요..
log buffer switch, log file switch completion,  .. disk IO가 안따라 줍니다..--;)

암튼 이 transaction이 수행되는 과정에서 used_urec는 10초당 12000 ~ 13000 씩, 빠를 때는 15000 개씩 쌓이는 군요..

총 insert 되는 데 걸린 시간은 약 3분 55초 09 이며, USED_UREC는 150593, USED_UBLK는 3772 개 입니다.  (used_urec와 실제 처리도니 row 수의 차이가 많군요.. 요건 나중에 함 알아보죠 ^^;)


rollback시 used_urec는 10초당 대충 3000 ~ 5000개 정도 씩 정리하네요..
이 수치만 보면 rollback 작업이 실제 transaction 보다 약 3배 정도 이상 느리게 나오는 걸로 보이네요..  (실제 used_urec를 모니터링 해보면 특정 시간당 정리하는 갯수의 편차가 좀 있습니다. )

실제 rollback에 걸린 시간은 11분 09초 94 입니다. transaction 보다 약 3배 이상 걸렸군요..
그리고 transaction 생성시엔 used_urec가 10초당 15000 정도인데 반해서 rollback시는 10초당 5000 정도.. (음 생각보단 performance가 많이 안좋게 나왔네요..)

위의 테스트는 제 PC에서 수행된 거라 운영시스템에서의 환경과는 많이 다를 수 있겠지만,
일반적으로 rollback이 transaction보다 시간은 많이 소모됩니다. 이러한 테스트를 관리하는 장비에서 미리 한번씩 해본다면 실제 이러한 문제 발생시 좀더 확실하게 대처 할 수 있겠죠..



물론 위에서 한 테스트는 rollback 의 시간에 영향을 많이 끼치는 cleanup_rollback_entries 의 기본 설정환경에서 진행 되었죠.
다음 번에는 cleanup_rollback_entries parameter의 값 조정과
user process에서의 recovery와 smon에서의 recovery의 시간 비교를 한번 해보겠습니다...
언제? 글쎄요.. ^^;