바인드 변수

기본적으로 오라클은 하드파싱과 소프트파싱을 통해 library cache에 실행계획을 저장한다.

 

하지만 실행 계획의 저장이 되는 기준은 SQL문이므로 바인드 변수가 아닌 상수를 통해 매번 변경이 되면 그때마다 하드파싱과 소프트 파싱을 병행해 시스템의 성능에 지장을 주게 된다.

 

그러므로 :custNo같은 바인드 변수명을 동일한 SQL문을 library cache에 저장해 이 cursor을 통해 해당 SQL문이 여러 프로세스에 의해 재사용될수 있게 하는것이다.

 

하지만 이런 바인드 변수에게도 부작용이 존재한다.

1. 바인드 변수를 바인딩하는 시점은 최적화 시점보다 나중인 실행시점이라는 사실이다. 이는 곧 히스토그램 정보를 사용하지 못해 정확한 카디널리티 파악이 어려워져 비효율적인 실행계획으로 시작될수 있다는 말이다.

 

이에 대한 보완으로 11g에서는 적응적 커서 기능이 도입되었다. 실행전 컬럼 히스토그램을 살펴보아 각각에 맞는(FUll일지, Index일지) 실행계획을 만들어 실행하는 것이다.

 

또한 다른 방법으로는 입력값에 따라서 다르게 Hint를 사용해 Union all을 통한 방법이 있다.

하지만 이 방법은 union all을 통한 SQL결합이 늘어날수록, 실행시 옵티마이저는 10개의 SQL을 최적화하여 그만큼 Shared pool에서 많은 공간을 차지하게 된다.

또한 긴 텍스트를 파싱하면서 Syntax를 체크하고 파싱트리를 만들어 체크 과정을 반복하여 CPU의 과도한 사용량을 유발할수 있다.

 

그러니 Unjon all을 통해 SQL을 길게 작성하는것에 있어서 주의를 요해야 한다.