성능 테스트를 위해 오라클 캐시를 비활성화하는 방법

성능 테스트를 위해 오라클 캐시를 비활성화하는 방법

데이터에 대한 새 요약 표의 유용성을 테스트하려고 합니다.

그래서 저는 두 가지 절차를 만들어 특정 간격의 데이터를 가져옵니다. 각각은 다른 테이블 소스를 사용합니다.그래서 C# 콘솔 애플리케이션에서 저는 하나 또는 다른 하나를 호출합니다.좋은 패턴의 응답 시간을 갖기 위해 이를 여러 번 반복하고 싶을 때 문제가 시작됩니다.

저는 1199,84,81,81,81,81,82,80,80,81,81,80,81,91,80,80,81,80과 같은 것을 얻었습니다.

Oracle 10g이 부적절한 캐싱을 수행하고 있는 것 같습니다.

어떻게 해결해야 하나요?

편집: 이 작업을 수행하는 방법과 수행하지 않는 이유에 대해 설명하는 질문에서 이 스레드를 참조하십시오.

테스트 환경에 있는 경우 테이블스페이스를 오프라인 및 온라인으로 다시 설정할 수 있습니다.

ALTER TABLESPACE <tablespace_name> OFFLINE;
ALTER TABLESPACE <tablespace_name> ONLINE;

아니면 해보셔도 됩니다.

ALTER SYSTEM FLUSH BUFFER_CACHE;

테스트 환경에서만 가능합니다.

"실제" 시스템에서 테스트할 때 캐시된 데이터를 사용하는 첫 번째 통화 후에 받는 시간이 더 흥미로울 수 있습니다.절차를 두 번 호출하고 이후 실행에서 얻을 수 있는 성능 결과만 고려합니다.

Oracle 10g이 부적절한 캐싱을 수행하고 있는 것 같습니다.

실제로 Oracle은 완전히 적절한 캐싱을 수행하고 있는 것으로 보입니다.이러한 테이블을 많이 사용할 경우 대부분의 시간을 캐시에 저장할 수 있습니다.

편집을

피터의 반응에 대한 논평에서 루이스는 말했습니다.

통화 전 플러싱은 다음과 같은 몇 가지 흥미로운 결과를 얻었습니다. 1370, 354, 391, 375, 352, 390, 376, 326, 335, 435, 334, 334, 328, 317, 417, 377, 384, 367, 393.

플러시는 행이 DB 캐시에 있을 때보다 호출이 약간 더 오래 걸리지만 첫 번째 호출만큼 오래 걸리지 않기 때문에 이러한 결과는 "재미있는" 것입니다.이는 서버가 실제 캐시에 실제 레코드를 저장했기 때문입니다.빈 캐시에 대해 실제로 실행되는 것을 방지하는 유일한 방법은 모든 테스트 전에 서버를 재부팅하는 것입니다.

또는 쿼리를 적절하게 조정하는 방법을 배웁니다.데이터베이스의 작동 방식을 이해하는 것은 좋은 시작입니다.그리고 EXPLEX PLAN은 벽시계보다 더 나은 튜닝 보조 장치입니다.자세히 알아보세요.

언급URL : https://stackoverflow.com/questions/2179512/how-to-disable-oracle-cache-for-performance-tests