하나의 SQL 문장(쿼리)에서 하나의 DOP로 PE를 수행하며 한 쿼리에 여러 개의 Parallel Hint가 있거나, Parallel Hint가 있는 동시에 Parallel Option을 가진 테이블을 쿼리에 포함하는 경우 그 중 가장 큰 DOP를 그 쿼리의 DOP로 결정한다. 명시된 DOP가 0보다 작거나 같은 경우에는 디폴트 값 4로 DOP를 결정한다. DOP는 Parallel Hint에 명시할 수 있으며, 사용 방법은 "Tibero SQL 참조 안내서"를 참고한다.

DOP를 결정할 때 참고해야 할 요소는 다음과 같다.

보통 한 사용자만 PE를 수행한다고 하면 정렬과 같은 CPU bound 작업은 CPU 개수의 1~2배로 DOP를 설정하는 것이 적당하고, 테이블 스캔과 같은 I/O bound 작업은 디스크 드라이브 개수의 1~2배로 DOP를 설정하는 것이 적당하다. 이처럼 쿼리의 종류와 시스템 환경을 고려하여 DOP를 설정하면 PE를 통해 더 나은 성능을 기대할 수 있다.

Tibero에서는 쿼리를 수행하는 과정에서 Parallel 연산을 수행할 차례가 되면 QC가 계산된 DOP 만큼의 WTHR를 요청하고, 이에 가용한 만큼의 WTHR를 PE_SLAVE로 얻어오게 된다.

다음과 같이 연산 하나로 수행하는 쿼리는 DOP 개수만큼 WTHR를 가져와서 하나의 연산을 담당할 하나의 PE_SLAVE set을 구성한다. 그 이외는 2*DOP 개수만큼 WTHR를 얻어오고 두 개의 PE_SLAVE set을 구성한다. 이때 WTHR의 개수가 사용자가 명시한 DOP로 수행하기에 부족하면 사용할 수 있는 WTHR만 가지고서 DOP를 재정의하여 수행하게 된다.

SELECT * FROM table1;

예를 들어 DOP를 4로 결정하여 힌트에 명시한 경우 2*DOP만큼의 WTHR가 필요한 상황이고 WTHR가 5개뿐이라면 DOP를 2로 재정의하고 4개의 WTHR를 얻어와 PE를 수행한다. 또는 사용 가능한 WTHR가 1개뿐이라면 Parallel Plan을 만들었더라도 차례로 수행한다. 즉, PE를 수행하지 않는다. 그리고 QC가 얻어온 PE_SLAVE는 쿼리 수행이 끝나면 다시 활용이 가능한 WTHR로 반환되며 다음 쿼리 수행을 위해 리소스를 점유하지 않는다.

PE는 QC가 생성한 실행 계획을 모든 PE_SLAVE가 공유하도록 구성되어 있으며 각 PE_SLAVE는 실행 계획의 특정 부분만을 실행하도록 QC가 메시지로 제어한다.

TPS는 TCS에 연산의 결과물을 공급하여 TCS가 다음 연산을 처리할 수 있도록 한다. TPS가 결과물을 분배하는데 Tibero는 hash, range, broadcast, round-robin, send idxm 5가지 방식을 지원하고 있다. 주로 hash, range, broadcast가 자주 사용된다.

DOP가 4로 결정된 PE 실행 계획에서 inter-operation parallelism으로 TPS와 TCS 2개의 set가 상호 연동하는 방식을 선택하면 총 PE_SLAVE 8개가 전체 PE 수행에 참여하게 된다.

PE_SLAVE set 하나가 TPS가 되어 테이블 스캔을 하고 TCS로 설정된 다른 set가 order by를 수행할 수 있도록 로우를 공급해 준다. 이때 4개의 PE_SLAVE는 각각 A~G, H~M, N~S 그리고 T~Z로 정렬 키에 대한 범위를 정하여 정렬하게 되며, 이에 맞게 TPS는 range 방식으로 해당 로우가 담당하는 PE_SLAVE에 전달될 수 있도록 한다.

TCS가 정렬 작업을 완료하고 나면 TPS로 역할이 전환되면서 PE_SLAVE가 설정된 range의 순서대로 정렬 결과를 QC에게 전달함으로써 전체 데이터에 대한 결과가 얻어진다.

Parallel Hint가 사용되었거나 Parallel Option이 있는 테이블에 쿼리를 수행하면 Tibero는 Parallel Plan을 만들어 낸다. 단, Parallel로 수행하기 충분한 WTHR가 있을 때만 Parallel Plan대로 PE를 수행한다.

SQL> select /*+ parallel (3) */ * from t1;
SQL> create table t1 (a number, b number) parallel 3;
SQL> select * from t1;

다음의 연산은 Parallel로 수행하지 않는다.

Tibero는 'create table ... as select, create index, rebuild index'를 Parallel로 수행할 수 있다.

'create table ... as select'는 의사 결정 지원 애플리케이션(decision support application)에서 요약 테이블을 만들 때 유용하게 사용할 수 있으며 select 부분과 insert 부분을 Parallel로 처리하여 보다 빠른 DDL의 수행을 기대할 수 있다.

DDL 문에 Parallel Option을 명시하는 방법으로 사용할 수 있으며 DDL과 관련된 문법은 "Tibero SQL 참조 안내서"를 참고한다.

Tibero는 insert, update, delete 문에 대해 Parallel DML을 지원하지만 'insert into ... values ...' 문의 Parallel DML은 지원하지 않는다. Parallel DML은 주로 큰 데이터를 insert, update, delete 처리하는 배치 작업에 유용하게 사용한다. 다시 말해 트랜잭션이 적은 작업에는 효과적이지 않다.

Parallel DML을 'alter session enable parallel dml'로 설정한 후 insert, update, delete 문 뒤에 Parallel Hint를 사용해야 DML을 Parallel로 수행한다. 'enable parallel dml'을 하지 않으면 DML 문에 힌트를 명시해도 Parallel로 수행하지 않는다. 즉, 'disable parallel dml'로 Parallel DML을 못하도록 설정할 수 있다.

Parallel DML은 DOP + 1 개의 트랜잭션으로 동작하며 커밋은 Two-phase commit으로 이루어진다. 롤백 또한 DML이 여러 개의 트랜잭션으로 이루어졌기 때문에 Parallel로 진행된다.

Parallel DML은 여러 개의 트랜잭션으로 진행되기 때문에 Parallel DML 후 커밋 이전까지는 같은 세션에서 select 문으로 해당 테이블을 조회할 수 없으며 Parallel DML로 수정된 테이블에 대한 조회는 커밋 후에 가능하다.

SQL> alter session enable parallel dml;
SQL> insert /*+ parallel (3) */ into PE_test3 select * from PE_test3;
10001 rows created.
 
SQL> select * from PE_test3;
TBR-12066: Unable to read or modify an object after modifying it with PDML.
 
SQL> insert /*+ parallel (3) */ into PE_test3 select * from PE_test3;
TBR-12067: Unable to modify an object with PDML after modifying it.

select 서브 쿼리에 Parallel Hint를 주어 insert뿐만 아니라 insert할 로우를 추출하는 select도 Parallel로 수행하여 더 빠르게 DML을 수행할 수 있다.

SQL> insert /*+ parallel (3) */ into PE_test3
      select /*+ parallel (3) */ * from PE_test3;

10001 rows created.

다음의 경우는 Parallel DML로 수행하지 않는다.