성능고도화 7-5. 병렬 처리에 관한 기타 상식

Direct Path Read 

 - 오라클은 그래서 병렬 방식으로 Full Scan 할 때는 버퍼 캐시를 거치지 않고 곧바로 

   PGA 영역으로 읽어들이는 Direct Path Read 방식을 사용한다. 

   병렬도를 2로 주면 쿼리 수행 속도가 2배보다 훨씬 더 향상되는 이유가 바로 여기에 있다. 

 - 자주 사용되고 버퍼 캐시에 충분히 적재도리 만큼의 중소형 테이블을 병렬 쿼리로 읽을 때는 

   오히려 성능이 나빠지는 경우가 있는데, 버퍼 경합이 없는 한 디스크 I/O가 메모리 I/O보다 

   빠를 수 없기 때문이다. 게다가 Direct Path Read를 하려면 메모리와 디스크간 동기화를 

   위한 체크포인트를 먼저 수행해야 한다.  

 - 따라서 병렬 쿼리의 Direct Path Read 효과를 극대화하려면 그만큼 테이블이 아주 커야 한다. 

병렬 DML 

 - 병렬 처리가 가능해지려면 쿼리, DML, DDL을 수행하기 전에 각각 아래와 같은 명령을 

   먼저 수행해 주어야 한다. 

     ● alter session enable parallel query ;

     ● alter session enable parallel dml ;

     ● alter session enable parallel ddl ;

 - 이와 관련해 각 세션의 상태를 v$session을 통해 확인할 수 있다. 

     ● select pq_status, pdml_status, pddl_status from v$session ;

 - 다행히 parallel query와 parallel ddl은 기본적으로 활성화돼 있으므로 사용자가 의도적으로 

   비활성화하지 않는 한 신경 쓸 필요가 없다. 하지만, parallel dml은 사용자가 명시적으로 

   활성화 해주어야 하는데, 이 사실을 몰라 병렬 DML을 효과적으로 활용하지 못하는 개발팀을 

   여러번 보았다고 한다. 

 - 오라클 9iR2부터 병렬 DML이 블록 기반 Granule로 바뀌었다. 

   ( 메뉴얼에는 비파티션에 대한 병렬 DML이 여전히 블가능하다고 돼 있지만, 

     9iR2 New Features를 보면 주요 개선사항 중 하나로 기술돼 있다. ) 

 - 주의할 점은, 병렬 DML을 수행할 때 Exclusive 모드 테이블 Lock이 걸리나는 사실이다. 

   성능은비교할 수 없을 정도로 빨라지겠지만 해당 테입르에 다른 트랜잭션이 DML을 수행하지 

   못하게 되므로 트랜잭션이 빈번한 주간에 이 옵션을 사용하는 것은 절대 금물이다. 

병렬 인덱스 스캔 

 - Index Fast full scan이 아닌 한 인덱스는 기본적으로 병렬로 스캔할 수 없다. 

 - 파티션된 인덱스일 때는 병렬 스캔이 가능하며, 파티션 기반 Granule이므로 당연히 

   병렬도는 파티션 개수 이하로만 지정할 수 있다. 

병렬 NL 조인 

 - 병렬 조인은 항상 Table Full Scan을 이용한 해시 조인 또는 소트 머지 조인으로 처리된다고 

   생각하기 쉽지만 인덱스 스캔을 기반으로 한 병렬 NL 조인도 가능하다. 

 - Parallel Full Scan에는 블록 기반 Granule이 사용되므로 병렬도는 파티션 개수와 무관하다. 

병렬 인덱스 스캔으로 드라이빙하는 경우 

 - 병렬 NL 조인을 수행하려면, 드라이빙 인덱스가 반드시 파티션 인덱스여야 한다. 

   드라이빙 테이블과 두 번째 인덱스 및 테이블의 파티션 여부와는 상관없다. 

 - 인덱스를 드라이빙한 병렬 NL 조인에는 파티션 기반 Granule이 사용되므로 병렬도가 

   파티션 개수를 초과할 수 없다. 

 - 사용되는 파티션 보다 크게 병렬도를 지정해주더라도 실제로는 사용되는 파티션 개수 만큼의 

   프로세스만 사용된다. 만약 더 적게 지정한다면 각각 하나씩 처리하다가 먼저 일을 마친 

   프로세스가 나머지를 처리한다. 

병렬 NL 조인의 효용성 

 - NL 조인을 병렬로 수행하는 것도 가능하지만 실무적으로 활용할 기회가 많지는 않다. 

 - 유용하게 사용할 수 있는 상황 가정 

    1. Outer 테이블과 Inner 테이블의 둘 다 초대용량 테이블이다. 

       ( 어느 한쪽이 작은 테이블이면 병렬 해시 조인으로 해결 가능하다. ) 

    2. Outer 테이블에 사용된 특정 조건의 선택도가 매우 낮은데 그 컬럼에 대한 인덱스가 없다. 

    3. Inner 쪽 조인 컬럼에는 인덱스가 있다. 

    4. 수행 빈도가 낮다. 

        ( 수행 빈도가 높다면 Outer 쪽에도 인덱스를 만드는 편이 낫다. ) 

병렬 쿼리와 스칼라 서브 쿼리 

 - 병렬 쿼리에 트레이스를 걸면 QC의 트레이스 파일은 user_dump_dest 디렉토리 밑에 

   생기지만 병렬 서버의 트레이스 파일은 background_dump_dest 디렉토리 밑에 생긴다. 

 - 병렬 쿼리는 대부분 Full Table Scan으로 처리되는데, 도중에 이처럼 인덱스를 경유한 

   Random 엑세스 위주의 스칼라 서브쿼리까지 수행해야 한다면 수행 속도를 크게 저하시킨다. 

   따라서 병렬 쿼리에서는 스칼라 서브쿼리를 가급적 일반 조인문장으로 변환하고 

   [Full Scan + Parallel] 방식으로 처리되도록 하는 것이 매우 중요한 튜닝 기법 중 하나이다. 

 - 만약 병렬 쿼리 결과집합 전체를 Fetch 하지 않고 중간에 멈추는 상황, 즉 부분범위처리가 

   가능한 상황이라면 불필요한 스칼라 서브쿼리 수행을 최소화하는 것만으로도 쿼리 응답 속도를

   크게 향상시킬 수 있다. 

 - 스칼라 서브쿼리를 기술하는 위치에 따라 QC가 수행하기도 하고 병렬 서버가 수행하기도 하며, 

   이는 병렬 쿼리 수행 속도에 지대한 영향을 미친다. 병렬 처리 효과를 높이려면 부분범위 처리, 

   전체범위처리 여부에 따라 스칼라 서브쿼리 위치를 옮기거나 아예 일반 조인문으로 바꾸는 

   등의 튜닝을 실시함으로써 큰 효과를 얻을 수 있다. 

병렬 쿼리와 사용자 정의 함수 

 - 사용자 정의 함수를 생성할 때 아래와 같이 Parallel_enable 키워드를 선언해 주어야 

   병렬 실행이 가능하다고 흔히 생각하는데, 그렇지 않다. 

 - 세션 변수를 참조하지 않는다면 이 키워드를 지정하든 안 한든 병렬 수행이 가능하며, 

   세션 변수를 참조하는 함수일 때는 parallel_enable을 선언하느냐에 따라 함수의 병렬 수행 

   여부가 결정된다. 

Parallel_enable 키워드 역활 

 - SQL 수행 결과는 병렬로 수행했는지 여부와 상관없이 항상 일관된 상태여야 한다. 

   그런데 함수가 패키지 변수 같은 세션 변수를 참조한다면 병렬 수행 여부에 따라 결과가 

   달라질 수 있다. 원인은, 병렬 쿼리 시 각 병렬 서버가 개별적인 세션ID를 부여받고 

   실행된다는 데에 있다. 

 - 패키지 변수는 세션 레벨에서만 유효하다는 특징을 갖는다. 즉, 세션이 수립될 때 초기화 되어 

   같은 세션 내에서는 지속적으로 참조할 수 있지만 다른 세션과는 값을 공유하지 못한다. 

 - SQL 수행겨로가는 병렬로 수행하지는 여부와 상관없이 항상 일관된 결과를 반환해야 한다. 

   그런데 패키지 변수를 참조하는 함수는 병렬로 실행했을 때 일관성이 보장되지 않이 때문에 

   오라클은 기본적으로 병렬 수해을 거부한다. 

 - parallel_enable의 역할은 직렬로 수행할 때와 비교해 함수 수행 결과가 달라질 수 있음에도, 

   사용자가 parallel_enable 키워드를 선언하면 오라클은 사용자 지시에 따라 함수를 병렬로 

   실행할 수 있도록 허용한다. 하지만 겨로가에 대한 책임은 사용자의 몫이다. 

 - 굳이 이 키워드를 사용하지 않더라도 병렬 수행이 가능하다. 

병렬 쿼리와 Rownum 

 - SQL에 rownum을 포함하면 쿼리문을 병렬로 실행하는 데에 제약을 받게 되므로 주의해야 한다. 

 - sort order by를 QC가 담당한다. 

병렬 처리 시 주의사항 

 - 언제 병렬 처리 기법을 사용하는 것이 바람직한가 

    ● 동시 사용자 수가 적은 애플리케이션 환경에서 직렬로 처리할 때보다 성능 개선 효과가 

        확실할 때 

    ● OLTP성 시스템 환경이더라도 작업을 빨리 완료함으로써 직렬로 처리할 때보다 오히려 

        전체적인 시스템 리로스 사용률을 감소시킬 수 있을 때

 - 야간 배치 프로그램에서는 병렬 처리가 자주 사용되기 마련인데, 야간 배치 프로그램은 

   전체 목표 시가을 달성하는 것을 목표로 해야지 개별 프로그램의 수행속도를 단축하려고 

   필요 이상의 병렬도를 지정해선 안된다. 

   ( 업무적으로 10분 이내 수행이 목표인 프로그램을 5분으로 단축하려고 병렬 처리 기법을 

     남용해서는 안된다. ) 

 - 시스템 리소르를 최대한 사용해야 할 때도 있는데, 데이터 이행이 대표적이다.  이 때는 모든 

   애플리케이션을 중시시키고 이행 프로그램이 시스템을 독점적으로 사용하기 때문에 가능한 

   모든 리소스를 활용해 이행 시간을 최대한 단축하는 것을 목표로 삼는 것이 당연하다. 

 - 병렬 쿼리와 관련해 기타 주의사항 

   ● workarea_size_policy를 manual로 설정한다면, 사용자가 지정한 sort_area_size가 모든 

       병렬 서버에게 적용된다. 따라서 sort_area_size를 크게 설정한 상태에서 지나치게 큰 

       병렬도를 지정하면, OS 레벨에서 페이징이 발생하고 심할 경우 시스템을 마비시킬 수 있음 

   ● 병렬도를 지정하지 않으면 cpu_count x parallel_threads_per_cpu 만큼의 병렬 프로레스가 

       할다 된다. adaptive multiuser 기능을 사용하려는 경우가 아니라면 반드시 병렬도를 지정

   ● 실행계획에서 P ->P가 나타날 때면 지저안 병렬도의 2배수만큼 병렬 프로세그가 필요 

   ● 쿼리 블록마다 병렬도를 다르게 지정한 경우, 여러 가지 우선 순위와 규칙에 따라 

       최종 병렬도가 결정됨, 하지만 이런 규칙을 외우려는 노력보다는 쿼리 작성 시 병렬도를 

       모두 같게 지정하는 것이 바람직 

   ● parallel_index 힌트를 사용할 때는 반드시 index 또는 index_ffs 힌트를 사용하는 습관이 

       필요, 옵티마이저에 의해 Full table Scan이 선택될 경우 parallel_index 힌트가 무시 

   ● 병렬 DML 수행시 Exculsive 모드 테이블 Lock이 걸리므로 업무 트랜잭션이 발생하는 

       주간에는 삼가해야 함 

   ● 테이블이나 인덱스를 빠르게 생성하려고 parallel 옵셥을 사용했다면 작업을 완료하자마자 

       noparallel로 돌려 놓는 것을 잊지 말아야 함 

   ● 부분범위처리 방식으로 조회하면서 병렬 쿼리르 사용한 때에는 필요한 만큼 데이터를 

       Fetch  하고 나서 곧바로 커서를 닫아 주어야 함 

 - Toad나 Orange 처럼 부분범위처리를 지원하는 쿼리 툴에서는 EOF에 도달하기 전까지 

   커서를 오픈한 채로 유지하기 때문에 오라클은 병렬 서버들을 해제하지 못하고 대기 상태에 

   머물도록 한다. 이는 불필요한 리소스를 낭비하는 결과를 초래하므로 조회가 끝나자마자 

   select * from dual  같은 문장을 수행해 병렬 쿼리의 커서를 닫아 주어야 한다.