• [통계정보]
• - 실행계획 수립 시 옵티마이저가 사용하는 오브젝트에 대한 정보
• - 테이블, 인덱스, 컬럼(히스토그램 포함), 시스템 통계가 있음
• - analyze, dbms_stats 패키지를 이용해 수집 가능

통계정보 수집은 언제나 성능이 향상된다?

오라클을 사용해본 사람이면 통계정보가 무엇인지는 알고 있 다. 대부분 사람들은'통계정보는 오라클의 오브젝트 정보를 수 집하는 것이며, 최신 정보를 가지고 있기 때문에 성능은 더 좋아 진다'고 알고 있다.

그러나 이와 같이 생각하고 있는 것은 통계정 보의 일부분만 알고 있는 것이다. 통계정보 수집 시 최신 오브젝 트 정보를 수집하는 것은 맞다. 하지만 항상 성능이 좋아지는 것 은 아니다.

어느 프로젝트에 투입됐을 때의 일이다. 어느 개발자 가“우리는 통계정보를 매일 갱신해 왔고, 예전부터 이렇게 만들 어져서 매일 통계정보를 수집하며 잘 운영해 오고 있다”고 말했 다. 과연 이와 같은 말이 정말 안정적으로 시스템을 운영하고자 하는 사람에게 맞는 것일까?

하나의 예를 들어보자. A 군은 박스에 구슬을 모은다. 구슬은 총 10가지 색상이 있었고, A 군은 1,000개의 구슬을 모았다. 하 지만 박스 안에는 어떠한 구슬의 색깔들이 있는지 모르기 때문에 A 군은 구슬을 모두 세어보기로 했다.

전체 1,000개의 구슬을 모 두 분류하는 데 1시간이 걸렸다. 구슬은 빨간색이 550개였고, 나 머지 색깔이 각 50개씩이었다. 하지만 구슬을 세는 데 시간이 너 무 많이 걸리고 힘들었다.

시간이 흘러 A 군의 구슬은 100개가 추가됐고, 또 다시 구슬을 세어보기로 했다. 추가된 구슬은 빨간 색이 55개이고, 나머지가 각 5개씩이었다. 하지만 A 군은 1,000 개의 구슬을 세어보는 데 너무 많은 시간을 허비했기에 전체 구 슬의 10%인 110개만 꺼내어 계산하기로 했다.

10개를 다 꺼낸 시점에 색깔은 빨간색이 20개, 나머지가 색깔이 10개씩 나온 것 이다. 추가된 구슬들은 확률적으로 똑같이 증가했다. 하지만 10%만을 꺼낸 구슬의 결과는 너무나도 달랐다.

통계정보 또한 이러한 방식이다. 총 Row의 수량이 1,000만 개 일 때와 1,100만 개일 때의 통계정보는 다르게 수집될 수 있는 것이다. 그렇다고 전체를 수집하기에는 통계정보 수집시간이 너 무 많이 걸린다.

위의 개발자가 말한 것과 같이 불안정한 통계정 보를 계속 수집하는 것이 맞는 것일까? 필자는 프로젝트를 수행 하며, 통계정보 수집을 최소한으로 줄이라고 권고하고 있다.

통 계정보를 수집하지 않아도 될 오브젝트를 수집해, 잘못된 실행계 획 수립과 수집 후 과다한 Hard Parsing은 뜻하지 않은 장애 상 황을 초래할 수 있기 때문이다. 하지만 필자도 처음 데이터베이 스를 접하고 이러한 이야기를 글로 접했을 때는 믿지 않았다. 하 지만 이러한 글들을 증명하듯이 운영 중에 이러한 상황은 빈번하 게 일어났다.

주간에 힘든 일들을 모두 마치고 즐거운 주말에 일어난 일이다. 어떠한 작업도 하지 않았는데, 갑자기 데이터베이스에 업무 지연이 생겼고 이 때문에 많은 개발자와 업무 담당자가 출근하는 사태가 발생했다.

이는 실행계획의 변경으로 인한 업무 장애였다. 그리고 그 장애의 핵심에는 작은 테이블의 통계정보 수집이 있었다.

평일에는 많은 업무로 인해 통계정보를 돌릴 여유가 되 지 않은 시스템이어서, 주말에 한꺼번에 통계정보 수집을 행했다. 그렇게 몇 년 동안 이와 같은 방식으로 돌렸지만 한 번도 발 생하지 않았던 장애가 갑작스럽게 찾아온 것이다. 언제나 장애는 우리가 예측하는 범위 내에서 일어나지 않는다.

오라클의 옵티마이저는 통계정보를 바탕으로 실행계획을 세운다. 그런데 이러한 통계정보가 운영자 의도와 다르게 수집된다면, 옵티마이저도 오판할 수 있다는 것이다.

그렇다면 우리는 통 계정보를 수집해서는 안 되는가? 통계정보를 수집하지 않는다면 CBO의 장점을 이끌어낼 수 없다. 통계정보를 수집하되, 꼭 필요 한 시점에서만 수집해 옵티마이저가 최적의 실행계획을 수립할 수 있도록 해야 한다.

통계정보가 필요 없는 RBO

옵티마이저는 크게 두 가지 방식으로 나뉜다. RBO(Rule Base Optimizer)와 CBO(Cost Base Optimizer)가 존재하며 이 두 가지 방식은 차이점을 가지고 있다.

• [표 1] RBO와 CBO의 비교

• 	RBO	CBO
  동작방식	정해진 규칙에 따른 방식	비용 계산 방식
  통계정보	사용 ×	사용 ○
  사용버전	~ 현재	오라클 7 ~ 현재
  인덱스 사용	인덱스가 존재한다면 항상 사용	Cost에 의한 결정

RBO는 예전부터 오라클이 추구해왔던 옵티마이저 동작방식 이다. ‘Rule’이란 단어의 의미 그대로 규칙이 존재하며, 통계정 보 및 비용 계산 방식이 아니라는 것이다. RBO가 11g까지는 존 재하지만 기술적 발전은 없었다.

또한 오라클은 공식적으로 11g 에서 RBO의 사용으로 인한 문제 발생 시 기술지원을 하지 않는 다고 발표했다. 오라클은 CBO를 중심으로 발전하고 있지만 RBO에 대한 폐지는 아직 언급하지 않고 있다.

오라클 하위 버전 의 호환성이 이유일 것이다. CBO는 오라클 7 버전부터 소개된 옵티마이저 동작방식이며, RBO와는 다르게 통계정보를 이용한 비용 계산 방식이다.

현재도 오라클은 지속적으로 CBO 옵티마 이저를 개선하고 있으며, 스마트한 옵티마이저 개발을 위해 많은 기술들이 나오고 있다. RBO가 여전히 발전하지 못하는 것은 규 칙 때문에 너무 비현실적이라는 것 때문이다.

데이터의 90%를 읽어서 처리하는 데도 Index를 사용한다. 왜 사용하는지를 물으면 RBO는“규칙이 정해져 있어서 어쩔 수 없 다”라고 대답할 것이다. 단순 무식하기 때문에 때때로는 장점도 존재한다. 오브젝트의 변경이 없으면 플랜이 고정되고, CBO처 럼 통계정보도 수집할 필요가 없기 때문이다.

하지만 융통성 없 는 사람을 보는 것처럼 답답한 것은 사실이다. 뭐든지 규칙대로 처리해 버리기 때문이다. 이러한 단점을 극복하고자 나온 것이 CBO이며, RBO보다는 현실적인 실행계획을 수립한다.

다음으로는 옵티마이저를 컨트롤하기 위한 파라미터에 어떤 것들이 있는지 알아보자.

실행계획 관련 파라미터

실행계획의 수립에 많은 영향을 주는 것이 통계정보이지만, 초 기화 파라미터 또한 많은 영향을 준다. 가장 대표적인 오라클 초 기화 파라미터로는 [OPTIMIZER_MODE]가 있다.

• [OPTIMIZER_MODE]
• - 옵티마이저의 모드를 조정하는 파라미터
• - RULE : RBO(Rule Base Optimizer)로 운영, 일정한 규칙으로 실행계 획 수립
• - FIRST_ROWS[_n], All_rows : CBO(Cost Base Optimizer)로 운영, 비용 기반으로 실행계획 수립

OPTIMIZER_MODE 파라미터는 오라클의 옵티마이저를 어 떤 형식으로 사용할지에 대해 정하는 부분이며, 전체 시스템 적 용과 힌트를 이용한 부분 적용이 가능하다. 시스템 전체 적용은 Init 초기화 파일을 변경하는 것과 Alter System 구문을 활용하 는 것이 있으며, 부분 적용은 SQL 문 안에 힌트를 삽입해 쓰일 수 있다.

• - OPTIMIZER_INDEX_CACHING
• - OPTIMIZER_INDEX_COST_ADJ
• - OPTIMIZER_DYNAMIC_SAMPLING
• - _OPTIM_PEEK_USER_BINDS

위에 명시한 파라미터들이 옵티마이저와 관련된 대표적인 파 라미터다. 또한 데이터베이스의 운영 환경은 사이트마다 다르기 때문에 정확한 파라미터 권고 값은 존재하지 않는다.

지금까지 실행계획에 영향을 받는 통계정보와 파라미터 관련 내용을 살펴봤으며, 다음 기회를 통해 갑작스런 플랜 변화에 대 한 분석과 임시 조치 방안을 다뤄보기로 한다.