태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Annoying _fix_control bug - 5548510

오라클 2008.04.30 15:51
Oracle 10gR2부터 Optimizer를 제어하는 레벨이 점점 세밀해지고 있다. 그 대표적인 것이 SQL 문장 레벨에서 Optimizer 변수를 제어할 수 있는 OPT_PARAM 힌트다.

10.2.0.2에서 추가된 또 하나의 중요한 변화가 "_fix_control" 파라미터의 등장이다. _fix_control 파라미터는 Bug Fix를 Control할 수 있는 기능을 제공한다. Optimizer의 버그를 해결하기 위해 수많은 Bug Fix(Patch)가 제공된다. 문제는 Optimizer가 워낙 복잡한 모듈이나 보니 특정 Bug를 Fix하기 위해 추가된 코드가 또 다른 문제나 Bug를 유발하는 경우가 매우 많다는 것이다.

이런 이유 때문에 Oracle은 _fix_control이라는 파라미터를 이용해 특정 Bug Fix를 적용할지 말지의 여부를 제어할 수 있게 해준다. 즉

ALTER SESSION SET "_fix_control"='3118776:OFF';
-- 또는 (여기서 3118776은 버그 번호이다)
ALTER SESSION SET "_fix_control"='3118776:ON';


과 같이 세션이나 시스템 레벨에서 특정 Bug Fix를 위한 코드를 활성화할지 말지를 결정할 수 있다. 10053 Trace를 보면 다음과 같이 어떤 Bug Fix가 활성화 또는 비활성화되었는지 확인할 수 있다.

Bug Fix Control Environment
    fix  3834770 = 1      
    fix  3746511 = enabled
    fix  4519016 = enabled
    fix  3118776 = disabled

Bug Fix의 적용 여부는 v$session_fix_control 뷰나 v$system_fix_control 뷰를 통해 편리하게 조회할 수도 있다. Optimizer 문제를 Troubleshooting 하기 위한 좋은 도구가 추가된 셈이다.

하지만, 5548510 버그 번호는 참으로 아이러니한 현상을 보여주고 있다. _fix_control을 사용한 경우 특정 상황에서 Memory Leak이 발생한다는 것이다. 아마 이런 경우를 막말로 빼도 박도 못한다고 해야할 것이다.

Oracle에서는 이런 경우, 즉 특정 버그를 해결하기 위한 코드가 다른 버그를 낳우가 간혹 보고된다. 복잡한 소프트웨어에서는 피할 수 없는 현상일 것이다.
또는 Oracle의 버그 보고 및 관리 체계가 경쟁 제품군에 비해 체계적이고 광범위하다는 반증이기도 할 것이다.

PS) 10.2.0.2 이전 버전에서는 다음과 같이 Event를 이용해서 제어가 가능하다.
hpl2000:oracle:/home/oracle:209> oerr ora 38079
38079, 00000, "CBO disable the fix for bug 3118776"

_fix_control을 이용한 제어가 훨씬 직관적이라는 것을 알수 있다.

또한, _fix_control 파라미터는 opt_param 힌트를 통해서는 제어가 안되는 것으로 보인다. 흐음... 이게 된다면 훨씬 편리할 것 같은데... 


신고
Trackbacks 24 : Comment 0

Write a comment

티스토리 툴바