StarSQL을 통한 DB2 액세스 - 효율성. 출력 매개 변수 또는 선택 쿼리

Question

좋은 오래된 MainFrame에서 실행되는 오래된 DB2 데이터베이스를 쿼리하는 코드를 작성하고 있습니다. 쿼리는 StarSQL에 작성되어야합니다.이 목표는 Command.Text를 통해 전달되는 현재 쿼리의 MIP 사용을 크게 줄이는 것입니다.

모르는 사람들에게 메인 프레임의 CPU 사용량 (MIP)에 따라 요금이 부과되므로 최대한 효과적으로 효율적으로 실행하고 싶습니다. "Select * From TableA"라고 말하고 그것을 CommandType.Text로 데이터베이스에 전달하고 싶지는 않습니다. 왜냐하면이 명령문을 컴파일 한 다음 결과를 반환해야하기 때문입니다. 프로 시저 (이미 컴파일 된)로 저장하고 원하는 정확한 열을 * 표시해야합니다.

내 질문에. 우리 MainFrame 전문가가 방학 중이기 때문에 나는 스스로에게 대답 할 수 없다 ...

~ 30 개의 열을 반환하는 절차가 있습니다. Select 쿼리를 통해이를 반환하거나 출력 매개 변수로 반환하는 것이 더 효율적입니까? 이것은 저장 프로 시저를 통한 것입니다.

나는 C# 코드의 길이는 걱정하지 않지만, 그 엄청난 메인 프레임에서의 효율성은 걱정 스럽다.

내가 좋아하는 계정 일에 걸릴해야합니다

SELECT PHNS.CLNT_INTERNL_KY as CLNT_INTRNL_KY 

그 열이 열 이름을 적용 할 여분의 CPU 사용량을 사용하지만 커서를 사용하여 출력 매개 변수로 그 내용을 저장하는 것이 더 효율적 것입니까?

다른 정보가 필요하면 알려주십시오.

건배,

(이 내가없는 1500 점이야 아아 태그에 STARSQL 태그,하지만 "수하는"...)

Answer 1

많은 쿼리 API를 저장 프로 시저의 사용을 허용하지 않습니다 이 옵션을 사용하면 저장 프로 시저를 사용하면 모든 실행 중에가 아니라 컴파일 타임에 한 번 쿼리를 구문 분석하고 최적화하여 CPU 시간을 절약 할 수 있습니다. 그렇지 않은 경우에도 동적 SQL 문에 대해 수행되는 캐싱의 이점이 있습니다. 동적 명령문에 대한 액세스 플랜은 패키지 캐시에 임시로 저장되므로, 곧바로 동일한 바이트 단위의 동일한 명령문 (매개 변수 마커 및 리터럴 값 포함)이 발생하면 DB2는 액세스 계획을 패키지 캐시에서 재사용합니다 처음부터 다시 최적화 할 수 있습니다.

저장 프로 시저를 사용하면 다른 리터럴 값으로 매우 자주 실행되는 명령문의 컴파일 시간을 크게 절약 할 수 있습니다. 입력 매개 변수가 선택적이거나 상당히 가변적 인 경우 (예 : 유연한 검색) 스토어드 프로 시저는 런타임에 채워지는 매개 변수를 알지 못하므로 컴파일시 원하지 않는 액세스 플랜을 생성 할 수 있습니다. 이러한 상황에서는 저장 프로 시저가 REOPT 정책을 통해 런타임에 쿼리를 다시 최적화해야 할 수도 있지만이 방법을 사용하면 사전 컴파일이 줄어 듭니다.

DB2의 EXPLAIN 기능을 사용하여 쿼리 작업량에 실제 비용이 어디에 있는지 (컴파일 대 스캔 대 정렬) 결정하는 것이 좋습니다. 쿼리가 많은 행을 스캔하면 각 행을 평가하는 CPU 비용이 동적 쿼리를 최적화하는 비용을 빠르게 초과 할 수 있습니다. SELECT *를 발행하는 쿼리는 종종 옵티마이 저가 적은 I/O 작업으로 동일한 쿼리를 충족시킬 수있는 인덱스를 악용하지 못하게합니다. WHERE 절의 필터 및 조인 술어 (또는 이들의 부족)는 옵티마이 저가 인덱스를 선택할 수 없게 할 수도 있습니다.