오라클 10gr2에서 성능을 비교하고있는 몇 가지 sql 쿼리가 있지만 처음 실행 한 후 v $ sql 테이블에 캐싱을 위해 저장된 실행 계획이 있으므로 쿼리 중 첫 번째 실행시 28 초가됩니다. .5 초 후. 내가벤치마킹을 위해 oracle 실행 계획 캐시를 어떻게 정리합니까?
을 시도했습니다
ALTER 시스템 FLUSH BUFFER_CACHE; - 이걸 실행 한 후, 쿼리는 5 초에 일관되게 실행됩니다. 정확하지 않다고 생각됩니다.
생각은 어쩌면 캐시에서 개별 항목 자체를 삭제 : 같은 SQL_TEXT이 '에서 .... * 선택하지만보기에서 삭제 할 수 없다는 대한 오류가 발생하는 경우 는 브이 $ SQL에서 삭제합니다.
오라클과 작업 한 지 오래되었지만 실행 계획이 공유 풀에 캐시되어 있다고 생각합니다. 이 시도 : 오라클 저장 최근 디스크 IO를 최소화하기 위해 데이터를 사용하는 경우
alter system flush shared_pool;
버퍼 캐시입니다.
내 28 초 쿼리가 해당 명령을 실행 한 후 1.5 초 걸립니다 –
죄송합니다. 캐시 된 실행 계획을 지우는 방법입니다. :) – Peter
피터는 당신이 물어 본 질문에 대한 답을 주셨습니다.
alter system flush shared_pool;
"캐시에서 준비된 문을 삭제하는 데 사용하는 문"입니다.
가 (준비된 문이 공유 풀에서 플러시 유일한 목적없는, 문은 그것보다 더 많은 기능을 수행한다.)
내 이전 의견에서 지적한 바와 같이 (귀하의 질문에), v$sql 테이블이 아닙니다. 오라클의 내부 메모리 구조를 표로 표현한 편리한 동적 뷰입니다. 동적 성능 뷰에 대해서만 SELECT 권한이 있습니다.이 뷰에서 행을 삭제할 수 없습니다.
공유 풀 및 버퍼 캐시를 삭제 하시겠습니까?
다음은 질문에 직접 답변하지 않습니다. 그 대신 기본적으로 다른 질문에 답합니다.
일반적으로 쿼리 성능을 측정하기 위해 공유 풀 및/또는 버퍼 캐시를 플러시해야합니까?
간단히 말해서 대답은 '아니오'입니다.
톰 카이트 꽤 잘이를 해결 생각 :
http://www.oracle.com/technology/oramag/oracle/03-jul/o43asktom.html
http://www.oracle.com/technetwork/issue-archive/o43asktom-094944.html
< 발췌 한 사실 >
, 튜닝 도구는 그렇게하지 않는 것이 중요하다. 테스트를 실행하고 결과를 무시한 다음 2 ~ 3 회 실행하고 평균을내는 것이 중요합니다. 실제 환경에서는 버퍼 캐시에 결과가 전혀 없습니다. 못.조정할 때 논리 I/O (LIO)를 줄이는 것이 목표입니다. 물리적 I/O (PIO)가 자체적으로 처리하므로 논리 I/O (LIO)를 줄이는 것이 목표입니다.
고려 : 공유 풀 및 버퍼 캐시를 플러시하는 것은 플러시하지 않는 것보다 훨씬 더 인위적입니다. 대부분의 사람들은 평범한 지혜에 직면하기 때문에 이것에 회의적으로 보입니다. 이 방법을 알려 드리지만 테스트에는 사용할 수 없습니다. 오히려, 나는 그것이 무의미하고 완전히 인공적인 운동 인 이유를 설명하기 위해 그것을 사용할 것이다. 그러므로 잘못된 가정에 이르게한다. 방금 PC를 시작했고 큰 테이블에 대해이 쿼리를 실행했습니다. I 버퍼 캐시를 "플러시"하고 다시 실행 :
</발췌 >
을 나는 톰 카이트 정확히 권리라고 생각합니다. 성능 문제를 해결하는 측면에서 "Oracle 실행 계획 캐시 지우기"는 일반적으로 신뢰할 수있는 벤치마킹을위한 단계라고 생각하지 않습니다.
성능에 대한 우려를 해결해 보겠습니다.
플러싱 (모든 인덱스 및 데이터 블록의 시작과 종료)이 실행될 때조차도 첫 번째 쿼리 실행이 후속 실행 (~ 5 초)에 비해 상당히 오래 걸린다는 사실을 알았습니다. 버퍼 캐쉬.
내게는 하드 파문이 다소 힘든 일을하고 있다고 제안합니다. 그것은 많은 일이나 많은 기다림과 마주 치고 있습니다. 이를 조사하고 조정할 수 있습니다.
아마도 통계가 존재하지 않는지 궁금합니다. 옵티마이 저는 쿼리 계획을 준비하기 전에 통계를 수집하는 데 많은 시간을 소비하고 있습니다. 이것이 제가 확인한 첫 번째 것 중 하나입니다. 통계는 참조 된 모든 테이블, 인덱스 및 인덱싱 된 열에서 수집됩니다.
쿼리가 많은 수의 테이블을 조인하는 경우 CBO는 조인 순서에 대한 많은 수의 순열을 고려할 수 있습니다.
오라클 추적에 대한 설명은이 답변의 범위를 벗어나지 만 다음 단계입니다.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318
:나는 당신이 아마 10053와 여기
10046. 당신이 유용하게 사용할 수있는 톰 카이트하여 "이벤트 10053"토론에 대한 링크의 이벤트를 추적 할거야 생각하고
접선 방향으로 관련 일화 이야기 재 : 하드 구문 분석 성능
몇 년 전, 첫 번째 실행에 대한 MINUTES의 관점에서 경과 된 시간을 갖는 쿼리가 1 초 만에 연속 실행되었습니다. 우리가 발견 한 것은 첫 번째 실행 시간을위한 대부분의 시간이 어려운 구문 분석에 소비되었다는 것입니다.
이 문제점 쿼리는 CrystalReports 개발자가 작성했습니다. CrystalReports 개발자는 무심코 (순진한) 두 가지의 거대한보고보기에 합류했습니다.
보기 중 하나는 62 개의 테이블을 조인했고 다른 뷰는 42 개의 테이블을 조인했습니다.
쿼리에서 비용 기반 최적화 도구를 사용했습니다.추적 결과 대기 시간이 아니라는 것이 밝혀졌으며 가능한 모든 조인 경로를 평가하는 데 소요 된 모든 CPU 시간이었습니다.
공급 업체가 제공하는 각 "보고"보기는 그다지 나쁘지 않았지만 그 중 두 대가 합류 한 경우 고뇌스럽게 느려졌습니다. 나는 그 문제가 옵티마이 저가 고려한 조인 치환의 방대한 수라고 생각한다. 옵티마이 저가 고려한 순열의 수를 제한하는 인스턴스 매개 변수가 있지만, 우리의 수정은 쿼리를 다시 작성하는 것이 었습니다. 향상된 쿼리는 실제로 쿼리에 필요한 12 개의 테이블 만 조인했습니다.
(초기 즉각적인 "band aid"초기 수정은 보고서 생성 작업이 실행되기 전에 아침 일찍 쿼리 실행을 예약하는 것이 었습니다. 이로 인해 보고서 생성 실행 속도가 빨라 졌으므로 보고서 생성 속도가 빨라졌습니다. 하드 풀을 피하면서 공유 풀에서 이미 준비된 문을 사용하십시오.
긴급 실행 시간이 없었던 경우 문제를 예비 실행으로 옮겼습니다.
다음 단계는 안정적인 쿼리 계획을 얻으려는 쿼리의 "저장된 개요"를 구현하는 것이었을 것입니다.
물론 Oracle에서는 명령문 재사용 (바인드 변수를 사용하여 하드 구문 분석을 피함)이 규범적인 패턴입니다. 그것은 성능, 확장 성, yada, yada, yada를 향상시킵니다.
이 일화적인 사건은 현재보고있는 문제와 완전히 다를 수 있습니다.
우리는 성능 튜닝 쿼리 최근에 많은 일을하고 있었고, 일치하지 않는 쿼리 성능에 대한 하나의 원인이 오라클에 앉아 파일 시스템 캐시입니다
_ "실제 환경에서 버퍼 캐시는 결코 결과가 없습니다."_ 인용구는 [http://www.oracle.com/technetwork/issuearchive/o43asktom-094944]입니다. .html] –
@ mm1978 : Tom Kyte (이전 됨) 문서를 업데이트 해 주셔서 감사합니다. – spencer7593
HTH.
오라클 캐시를 플러시하는 동안 파일 시스템에 여전히 쿼리가 요청하는 데이터가 있으므로 쿼리가 여전히 빠르게 반환 될 수 있습니다.
불행히도 파일 시스템 캐시를 지우는 방법을 모르겠습니다. 저는 매우 유용한 시스템 관리자의 유용한 스크립트를 사용합니다.
v $ sql은 실제로 테이블이 아니며 동적 성능 뷰이며 아니요, 행을 삭제할 수 없습니다. – spencer7593