[오경렬]진정한 지식에 대한 단상

좋은 글을 가슴속에 품고 살아가는 일은 험난한 일생의 한줄기 등불과도 같은 존재가 아닐까 생각한다.

 

엔지니어가 가져야 할 마음가짐과 생각을 표현한 글 중에 지식의 여신은 쉽게 옷을 벗지 않는다는 말이 있다.

 

고객 사에서 발생한 문제의 원인을 찾아 분석하는 일을 할 때에 그 문제의 원인이 무엇인지 뒷받침 해주는 지식들의 깊이를 어디까지 가져가야 할까?

 

문제 해결을 위해 네이버 지식인에 물어보면 나오는 경우도 있고 구글 검색을 통해서는 더 무수한 자료가 쏟아져 나오는 경우가 대다수이고 그것을 해결하는 경우가 대부분 일 것이다.  

 

그렇게 하나하나 알아가는 과정에서도 적지 않은 기쁨과 일에 대한 보람을 느끼기도 한다.

 

하지만 이런 일은 누구나 할 수 있는 일이다.

              문제 발생 -> 검색 -> 문제해결

이렇게 생각하니 뭔가 허전한 것이 허탈하기도 하다.

단순한 원리가 아닌 인터넷에 올라와 있는 글이 아닌 논리적으로 조금의 흔들림이 없는 쉽게 논란의 대상으로 공격받지 않는 그런 확고한 지식이 필요한 것이다.

 

인터넷에 올라와 있거나 책에 있는 내용은 내 것이 아니다.

물론 그것을 이해하는 일도 많은 노력이 필요하겠지만 그것을 내 것으로 만들기 위해서는 눈으로 직접 확인하고 경험하는 절차가 있어야 한다.

 

얼마 전 고객 사에서 10분 안에 끝나던 배치 작업이 24시간이 돌아도 끝나지 않는다며 분석을 요청한 적이 있다.

 

발생한 이벤트는 db file sequential reads 이벤트..

 

그렇다. 그 이벤트만 보고 당황했었다.

하지만 차분하게 생각해보니 undo 관련해서 문제가 있을 거라고 생각하고 이벤트 정보를 통해 sequential 한 read가 일어나는 데이터 파일을 확인해보니 역시 undo 데이터 파일을 sequential 하게 읽고 있는 것이었다.

 

이 순간에도 기쁨을 느꼈었다. 아주 단순하고 어찌 보면 당연히 알아야 하고 한 타에 딱! 집어내야 하는 일일지도 모르겠지만 그때는 DBA_UNDO_EXTENTS 뷰를 통해서 그 결과를 도출했을 때 기쁘고 재미있었다.

 

하지만 10분에 끝나던 일이 24시간 걸린다니..

그것도 왜 sequential 하게 읽을까.. 쉽사리 원인을 찾기도 어려웠지만 스스로 해결하기에는 많은 시간이 필요할 것 같아 팀장님께 문제해결에 대한 도움을 요청하고

그 결과 다른 과장님이 전에 같은 현상에 대해서 겪은 적이 있으셨다고 하여 자료를 받아 해당 사이트에 전달해 주는 것으로 문제를 해결해야 했다.

 

배치 장애에 대한 대략적인 이유
 

한마디로 정의하면 read consistency 에 의한 결과였다. 

 

 

read consistency는 commit 이전이나 block cleanout이 일어나지 않는 경우 (Delayed Block Cleanout)에 발생하게 된다.

기간에 무수히 많은 commit 이 발생할 경우 SCN: 700 에서 Query 가 시작되고 undo segment header의 low SCN은 800 이었다고 가정을 하자 읽으려는 데이터 블록이 Active 상태임을 확인하고
undo segment header 의 transaction 정보를 읽으려 했는데 이미 다른 transaction에 의해 overwrite 된 경우  이때 블록에 데이터를 그대로 읽어도 되는지 확인이 필요하게 된다.

즉 CR 이미지를 생성하여 transaction commit 시점을 나타내는 SCN 을 확인하여 SCN이 700보다 낮으면 transaction이전에 변경된 것이므로 그대로 읽어도 되는 것이고 700 보다 크다면 undo header에 CR에 CR이미지를 만들어 확인하는 작업이 필요하게 된다.

이때 Undo Retention 시간 안에 원하는 CR이미지를 찾지 못한다면 ora-01555 에러를 발생하게 된다.

이런 현상이 발생할 경우 문제의 query를 중지하고 단기간에 무수히 발생하는 commit이 끝난 이후에
다시 시작하게 되면 SCN 정보고 Undo segment의 low SCN 정보보다 큰 값을 가지게 되므로 문제를 해결할 수 있게 된다.

 

 

이에 우리가 제공한 해결책은 위와 같이 AP수행 순서를(배치 순서) 조절하는 부분과 order by 1 과 같이 의미 없는 정렬을 유도하여 transaction에 필요한 데이터를 메모리에 모두 로드 한 뒤에 수행하는 방법을 제시했었다.

두 방법 모두 이미 다른 과장님이 직접 경험하신 검증이 된 방법이었지만 내게 문제 분석을 원했던 사이트 담당자는 사이트 담당자가 요구하는 바는 명확한 알고리즘 이었다.

지금까지도 적지 않은 교훈을 주며 오라클사와 문제해결을 위해 노력하고 있다.

대충 이렇게 돌아가니까 이렇게 하시면 돼요 가 아닌 이렇게 돌아가니까 라는 부분에서 이해가 가지 않는 부분에 대해서 각종 덤프를 이용해 확인하고 오라클사에서 제공한 수행 방식에 오점을 찾아내 그들과 토론하고 있다.

그 결과 이미 not a bug로 판명된 사항이 다시 중요도 3에서 2로 수정되어 오라클 본사에 다시 문제 분석을 요하는 단계까지 이르게 되었다.

사이트 담당자가 이 문제를 해결하면서 얻게 될 많은 지식과 기존에 알고 있던 오라클에 대한 지식이 결합하게 되면 분명 그 담당자는 한 단계 더 성장할 것은 자명한 사실이다. 

이처럼 한 단계 더 도약하려고 한발 더 나아가려 할 때 지식의 여신은 쉽사리 그 길을 열어주지 않는다.

오라클 덤프를 뜨며 알듯 말듯한 약어로 표시된 그리고 그 옆에 있는 숫자나 문자를 분석하는 작업을 수행하며 지식의 여신에게 애인이 되기를 요구하다 보면 지식의 여신은 마음의 문을 열고 자신이 가진 모든 것을 퍼주며 기쁘게 해줄 것이다.

머릿속에 무질서하게 쌓인 지식들이 어느 순간에 갑자기 정립되어 길을 만드는 순간이 오게 되면 어떤 기분일까?

그 희열을 생각하면 가슴이 뛰고 힘이 난다는 것이 엔지니어인 내게는 정말 행복한 일이라 생각한다.