특정 조건을 기반으로 수백만 개의 레코드가있는 테이블을 업데이트해야하는 문제가 있습니다. 긴 셸 스크립트와 SQL 문을 작성하여 성능을 확인했습니다. 계획을 설명하여이 "실행 계획은 다음과 같은 이유로 다를 수 있습니다"고 기록 여기 http://docs.oracle.com/cd/B10500_01/server.920/a96533/ex_plan.htm#19259실행 계획 비용 추정
에서 공부 다른 Costs-> 데이터 볼륨 및 통계 초기화 매개 변수를 변수 유형을 바인딩 - 전 세계적으로 또는 설정 세션 수준
여기 내가 어떻게 이해할 수 없다. 초기화 매개 변수 - 전역 또는 세션 수준에서 설정은 실행 계획에 영향을줍니다. 아무도 이것을 설명 할 수있는 ? 또한 계획이나 자동 추적 설명 이외의 성능을 위해 SQL 문을 검사 할 수있는 다른 방법이 있습니다.
GLOBAL 또는 SESSION 매개 변수 오라클 초기화 파라미터 세트와 설정입니다. 그것들을 무시하기 위해 아무 것도 지정되어 있지 않으면 기본적으로 사용됩니다. ALTER SESSION (단일 사용자에게 영향을 미침) 또는 ALTER SYSTEM (Oracle이 재시작 될 때까지 모든 사용자에게 영향을 미침) 명령을 사용하여 세션 또는 시스템 레벨에서 작업을 변경하거나 코드에서 옵티 마이저 힌트를 사용하여 오버라이드 할 수 있습니다. 이것들은 당신이 보는 계획에 영향을 줄 수 있습니다.
설명 플랜과 관련하여 다른 Oracle 데이터베이스는 다른 초기화 매개 변수를 갖거나 SAME 코드가 다르게 동작 할 수있는 세션/시스템 매개 변수 세트를 가질 수 있습니다 (다른 Oracle과 비교하여 하나의 Oracle 데이터베이스에서 다른 실행 계획을 얻음) 데이터 베이스).
또한 실행 계획이 선택한 데이터의 영향을 받기 때문에 TEST에서 정상적으로 실행되는 쿼리 또는 패키지는 데이터 볼륨이 훨씬 큰 PRODUCTION에서 끝나지 않을 수 있습니다. 이는 코드가 정확한 데이터 볼륨 (또는 테스트가 데이터와 같은 대량의 프로덕션을 보유 할 수없는 경우 프로덕션 데이터베이스에서 가져온 테이블 통계와 적어도 테스트 한 경우)에서 공통적으로 발생하는 문제입니다. 제안 사항을 추적
지금까지 방법에 문제가있는 문을 알고 가정 개인 성명을 추적하는 방법을 알려하지만 당신은 여러 SQL 문에 쉘 스크립트가 언급.
당신은
#!/bin/ksh
sqlplus -S user/pass <<EOF
set heading off
BEGIN
-- DO YOUR FIRST SQL HERE
-- DO YOUR SECOND SQL HERE
END;
/
EOF
#!/bin/ksh
sqlplus -S user/pass <<EOF
set heading off
BEGIN
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'
-- DO YOUR FIRST SQL HERE
-- DO YOUR SECOND SQL HERE
END;
/
EOF
지금이 당신의 추적 파일이 SQL에서 생성되는 위치 확인 PLUS 디렉토리에
SQL> show parameter user_dump_dest
/app/oracle/admin/rms/udump
이동을 사용하여 다음, 하나의 실행을 수행하는 쉘 스크립트를 실행하고 스크립트에서 SQL의 전체 실행 추적을 포함하는 .trc 파일이됩니다.
당신은 이제 당신의 홈 디렉토리로 변경하고 그 순서에 나와있는 SQL 문으로 .prf 파일이있을 것이다이
unix> tkprof your.trc ~/your.prf sys=no sort=fchela,exeela
처럼 유닉스 TKPROF 명령으로 읽을 수있는 형식이 변환 할 필요가 가장 많은 실행 시간을 가지거나 설명 계획과 함께 실행 시간을 가져옵니다. tkprof에 대한이 매개 변수 세트를 사용하면 가장 오래 걸리는 명령문을 수정하는 데 집중할 수 있으므로 튜닝에 대한 가장 큰 수익을 얻을 수 있습니다.
셸 스크립트가 여러 sqlplus 명령을 실행하는 경우 각각 별도의 세션을 생성하므로 각각에 ALTER SESSION 문을 추가하면 별도의 추적 파일이 작성됩니다.
또한 세부 사항에서 길을 잃기 쉽다는 것을 잊지 마십시오. 때로는 튜닝은 몇 초 만에 얻을 수있는 단일 SQL로 작업하는 것보다 전체적인 그림을보고 다른 방법으로 수행하는 것입니다. 전반적인 계획에서 전체 실행 시간을 줄이는 데 도움이되지 않습니다.
큰 테이블 하나를 가지고있는 것처럼 업데이트 명령문의 수를 최소화하려면 테이블의 한 번에 업데이트를 수행하고 업데이트를 지원하는 인덱스가 있으면 더 효율적입니다. 작은 업데이트를 많이하는 것보다
더 많은 도움이 필요하면 스크립트의 관련 부분, 실행에 소요되는 전체 시간 및 설명 계획을 게시 할 수 있습니다.
개인적으로 나는 실행 된 정확한 계획을 제공하기 때문에 행 소스 작업 만 신뢰합니다. 계획이 어떻게 구성되는지에 영향을 미치는 몇 가지 매개 변수가 존재합니다. 대부분의 매개 변수는 인스턴스 수준에서 설정되지만 세션 수준에서 벗어날 수 있습니다. 이것은 모든 세션이 자신의 유효한 매개 변수 집합을 가질 수 있음을 의미합니다.
문제점 스크립트를 실행할 세션의 정확한 설정을 알아야한다는 점에 문제가 있습니다. 세션 수준 설정을 변경하는 몇 가지 방법이 있습니다. 설정은 로그온 트리거, 저장 프로 시저 또는 스크립트에서 변경할 수 있습니다.
스크립트가 로그온 트리거의 영향을받지 않고 alter session 문을 발행하는 코드를 호출하지 않으면 인스턴스에있는 설정을 사용하게됩니다.
문에 대한 실행 계획에 영향을 줄 수있는 몇 가지 (초기화) 매개 변수가 있습니다. 즉시 떠오르는 것은 OPTIMIZER_MODE
입니다. 그 밖의 명백한 세션은 인덱스의 유용성에 영향을 줄 수있는 NLS 설정과 같은 것들입니다.
세션을 추적하고 tkprof를 사용하는 것 외에는 실제 실행 계획을 얻는 다른 방법은 /*+ gather_plan_statistics */ 힌트와 함께 'dbms_xplan.display_cursor()'를 사용하는 것입니다.
이
실제로 먼저 위의 힌트를 사용하여 문을 실행하면됩니다 (그래서이 "보통"이상 걸립니까 설명) : 그 진술이 완료된 후 가select /*+ gather_plan_statistics */ *
from some_table
join ...
where ...
그런 다음, 당신이 사용하는 검색 할 수 있습니다 계획에 사용 dbms_xplan :
SELECT *
FROM table(dbms_xplan.display_cursor(format => 'ALLSTATS LAST');