OPTOFC Parameter를 사용한 GBase 8s JDBC 최적화

Source: Dev.to

OPTOFC가 적용되는 경우

다음 모든 조건이 충족될 때 최적화가 적용됩니다:

• 문장이 PreparedStatement 인스턴스일 때.
• 쿼리가 SELECT일 때.
• ResultSet 타입이 TYPE_FORWARD_ONLY일 때.
• 동시성 모드가 CONCUR_READ_ONLY일 때.

수행 내용

• OPEN과 FETCH 메시지 병합 – 일반적으로 두 개의 별도 네트워크 요청이 발생합니다. OPTOFC를 사용하면 두 요청이 하나로 전송되어 왕복 횟수가 줄어듭니다. (가변 길이 컬럼의 경우 드라이버가 이미 병합할 수 있으며, OPTOFC=1을 설정하면 병합을 강제합니다.)
• 커서 자동 종료 – 서버에서 모든 행을 가져오면 서버가 자동으로 커서를 닫습니다. 이후 ResultSet.close() 호출 시 추가 네트워크 요청을 피할 수 있습니다.

활성화 방법

JDBC URL에 OPTOFC=1을 추가합니다:

jdbc:gbasedbt-sqli://192.168.226.180:12888/testdb:OPTOFC=1

성능 벤치마크

테스트는 동일한 SELECT * 쿼리를 루프 안에서 1,000번 실행했습니다. 두 개의 테이블을 사용했습니다:

• t1(name varchar(10)) – 가변 길이 컬럼
• t2(name char(10)) – 고정 길이 컬럼

예시 1 — 고정 길이 컬럼 (char)

예시 2 — 가변 길이 컬럼 (varchar)

예시 3 — 작동하지 않는 경우 (TYPE_SCROLL_INSENSITIVE)

URL에 OPTOFC=1을 포함했지만 ResultSet 타입을 TYPE_SCROLL_INSENSITIVE로 설정하여 조건 3을 위반했습니다. 실행 시간은 2,848 ms로 최적화되지 않은 경로와 동일했습니다.

핵심 요점

OPTOFC=1은 전방향(forward‑only), 읽기 전용(read‑only) SELECT 쿼리, 특히 가변 길이 컬럼이 포함된 경우에 눈에 띄는 속도 향상을 제공합니다. URL만 변경하면 되며 코드 수정이 필요 없으므로 많은 GBase 8s 애플리케이션에 낮은 비용으로 성능을 개선할 수 있는 방법입니다.

GBase 8s를 JDBC 워크로드에서 사용하고 있다면 ResultSet 타입과 연결 문자열을 확인해 보세요—성능을 놓치고 있을 수도 있습니다.