쿼리는 다른 Oracle 계획을 사용합니다. Oracle SQL Developer에서 Execute explain Plan의 결과를 이해합니다. 실행 계획 개요
답변 5개
EXPLAIN PLAN 출력은 Oracle Query Optimizer의 디버깅 출력입니다. COST는 다음 중 어느 것을 선택하는 것을 목표로 하는 비용 최적화 프로그램(CBO)의 최종 결과입니다. 가능한 계획요청을 시작하는 데 사용해야 합니다. CBO는 각 계획의 상대적 비용을 계산한 다음 비용이 가장 낮은 계획을 선택합니다.
(참고: CBO가 가능한 모든 계획을 평가할 시간이 부족한 경우도 있습니다. 이러한 경우 지금까지 발견된 비용이 가장 낮은 계획을 선택하기만 하면 됩니다.)
전반적으로, 가장 큰 기여 중 하나는 느린 요청요청을 처리하기 위해 읽은 행 수(보다 정확하게는 블록)이므로 비용은 부분적으로 최적화 프로그램에서 읽어야 할 행 수를 추정하여 결정됩니다.
예를 들어 다음과 같은 쿼리가 있다고 가정해 보겠습니다.
SELECT emp_id FROM 직원 WHERE Month_of_service = 6;
(month_of_service 열에는 NOT NULL 제약 조건과 일반 인덱스가 있습니다.)
여기에서 옵티마이저가 선택할 수 있는 두 가지 주요 계획이 있습니다.
- 계획 1: "employees" 테이블의 모든 행을 읽고 조건자가 true인지 확인합니다(months_of_service=6).
- 계획 2: Month_of_service=6(ROWID 집합이 됨)인 인덱스를 읽은 다음 반환된 ROWID를 기반으로 테이블에 액세스합니다.
"employees" 테이블에 1,000,000(백만)개의 행이 포함되어 있다고 가정해 보겠습니다. Month_of_service의 값이 1에서 12 사이이고 어떤 이유로 상당히 균등하게 분포되어 있다고 가정해 보겠습니다.
가격 계획 1 FULL SCAN이 포함된 의 경우 직원 테이블의 모든 행을 읽는 데 드는 비용은 약 1,000,000입니다. 그러나 Oracle은 다중 블록 읽기를 사용하여 블록을 읽을 수 있는 경우가 많기 때문에 실제 비용은 더 낮습니다(데이터베이스 구성 방법에 따라 다름). 예를 들어 다중 블록이 포함된 샘플 수가 10이라고 가정해 보겠습니다. 스캔은 1,000,000/10 입니다. 총 비용 = 100,000.
가격 계획 2 INDEX RANGE SCAN과 ROWID에 의한 테이블 조회를 포함하는 ROWID를 사용하여 테이블에 액세스하는 비용은 물론 인덱스 스캔 비용도 발생합니다. 범위 인덱스 스캔 비용이 어떻게 되는지는 다루지 않겠지만, 범위 인덱스 스캔 비용이 행당 1이라고 가정해 보겠습니다. 우리는 12번 중 1번 일치하는 항목을 찾을 것으로 예상하므로 인덱스 스캔 비용은 1,000,000/12 = 83,333입니다. 테이블 액세스 비용 추가(액세스당 1개의 블록 읽기를 가정하고 여기서는 다중 블록 읽기를 사용할 수 없음) = 83.333; 총 비용 = 166,666.
보시다시피 플랜 비용은 1( 전체 검사)은 계획 2(인덱스 확인 + rowid 액세스) 비용보다 적습니다. 이는 CBO가 전체 스캔을 선택한다는 의미입니다.
여기서 최적화 프로그램의 가정이 정확하다면 실제로 계획 1이 계획 2보다 더 바람직하고 훨씬 더 효율적일 것입니다. 이는 전체 스캔이 "항상 나쁘다"는 통념을 반박하는 것입니다.
최적화 프로그램의 대상이 ALL_ROWS 대신 FIRST_ROWS(n)인 경우 결과는 상당히 다를 수 있습니다. 이 경우 최적화 프로그램은 전체 쿼리에 대해 효율성이 떨어지는 대신 처음 몇 행을 더 빠르게 반환하는 경우가 많기 때문에 계획 2를 선호합니다. .
CBO는 의사결정 트리를 구축하여 각 비용을 추정합니다. 가능한 방법각 요청에 대해 실행이 가능합니다. 비용은 인스턴스에 설정된 CPU_cost 또는 I/O_cost 매개변수에 의해 설정됩니다. 그리고 CBO는 쿼리에 사용될 테이블과 인덱스의 기존 통계를 바탕으로 최대한 비용을 추정합니다. 비용만을 기준으로 요청을 맞춤설정해서는 안 됩니다. 비용을 통해 옵티마이저가 수행하는 작업을 수행하는 이유를 이해할 수 있습니다. 비용이 없으면 최적화 프로그램이 왜 그런 계획을 선택했는지 이해할 수 있습니다. 더 저렴한 비용더 빠른 요청을 의미하지는 않습니다. 이것이 사실일 때도 있고, 틀릴 때도 있을 것입니다. 비용은 통계표를 기준으로 하며, 값이 틀리면 비용도 부정확해집니다.
쿼리를 설정할 때 각 단계의 카디널리티와 행 수를 확인해야 합니다. 말이 되나요? 최적화 프로그램이 올바른 것으로 간주됩니까? 문자열이 올바르게 반환되었나요? 정보가 올바르게 제공되지 않으면 최적화 프로그램이 결정을 내리는 데 필요한 적절한 정보를 갖고 있지 않을 가능성이 높습니다. 올바른 결정. 이는 테이블과 인덱스뿐만 아니라 CPU 통계의 오래되었거나 누락된 통계 때문일 수 있습니다. 최적화 프로그램을 최대한 활용하려면 쿼리를 구성할 때 통계를 업데이트하는 것이 가장 좋습니다. 회로를 아는 것도 설정에 많은 도움이 됩니다. 옵티마이저가 실제로 선택한 시기를 아는 것 나쁜 결정그리고 그것을 가리켰다. 옳은 길약간의 힌트만 있으면 시간을 절약할 수 있습니다.
"FULL"에 대한 언급은 쿼리가 데이터를 찾기 위해 전체 화면 검색을 수행하고 있음을 나타냅니다. 어떤 경우에는 괜찮지만 그렇지 않으면 잘못된 인덱싱/쿼리 항목을 나타냅니다.
일반적으로 Oracle이 최소한의 행에 액세스하여 필요한 데이터를 찾을 수 있도록 쿼리에서 키를 사용하는 것이 좋습니다. 궁극적으로 언젠가는 테이블의 아키텍처에 액세스할 수 있게 될 것입니다. 비용이 너무 높으면 더 나은 성능을 위해 회로 설계를 조정하는 방법을 고려해야 할 수도 있습니다.
최근 오라클 버전 COST는 옵티마이저가 쿼리를 기다리는 시간을 나타내며, 한 블록을 읽는 데 걸리는 시간 단위로 표시됩니다.
따라서 한 블록을 읽는 데 2ms가 걸리고 비용이 "250"으로 표시되면 요청을 완료하는 데 500ms가 걸릴 수 있습니다.
옵티마이저는 예상되는 단일 블록 및 다중 블록 읽기 수와 계획의 CPU 소비를 기반으로 비용을 계산합니다. 후자는 높은 CPU 비용을 피하기 위해 특정 작업을 다른 작업보다 먼저 수행하여 비용을 최소화하는 데 매우 유용할 수 있습니다.
이는 작업을 완료하는 데 걸리는 시간을 최적화 프로그램이 어떻게 알 수 있는지에 대한 의문을 제기합니다. 최신 버전 Oracle을 사용하면 "시스템 통계" 모음을 생성할 수 있는데, 이는 테이블이나 인덱스 통계와 혼동되어서는 안 됩니다. 시스템 통계는 성능 측정입니다. 하드웨어, 주로 중요:
- 한 블록을 읽는 데 걸리는 시간입니다.
- 멀티태스킹 독서에는 얼마나 걸리나요?
- 다중 블록 읽기의 크기(테이블 크기가 최대값보다 작거나 기타 이유로 인해 가능한 최대값과 다른 경우가 많음)
- CPU 성능
이러한 수치는 시스템 운영 환경에 따라 크게 달라질 수 있으며, 원하는 경우 "주간 OLTP" 작업과 "야간 정기 보고" 작업 및 "월말 보고"에 대해 서로 다른 통계를 저장할 수 있습니다.
이러한 통계 세트를 고려할 때, 이 계획요청을 완료하는 데 드는 비용은 다양할 수 있습니다. 운영 환경, 이는 여러 경우에 전체 테이블 스캔을 사용하거나 다른 경우에는 인덱스 스캔을 사용하도록 권장할 수 있습니다.
비용은 완벽하지는 않지만 옵티마이저는 각 릴리스마다 자체 모니터링이 향상되고 실제 비용과 예상 비용에 대응하여 향후 더 나은 결정을 내릴 수 있습니다. 또한 예측을 어렵게 만듭니다.
병렬 쿼리 작업은 여러 스레드에서 총 시간을 소비하므로 비용이 반드시 실제 시간일 필요는 없습니다.
이전 버전의 Oracle에서는 CPU 작업 비용이 무시되었으며 단일 및 다중 블록 읽기의 상대적 비용이 초기화 매개변수에 따라 효과적으로 수정되었습니다.
또한 v $sql 및 v $session을 쿼리하여 SQL 문에 대한 통계를 얻을 수 있으며 여기에는 모든 종류의 리소스, 타이밍 및 실행에 대한 자세한 메트릭이 포함됩니다.
무료 유틸리티 OraDeveloper Studio를 사용하는 예를 사용하여 설명할 것임을 즉시 명확히 하겠습니다. 왜? 일반적인 쿼리로는 이 작업을 수행할 수 없었고, 더 쉬운 방법이 있기 때문에 이를 알아낼 시간이나 욕구가 없었기 때문입니다. 😉
그렇다면 이것은 무엇을 위한 것일까요? 내가 설명해 줄게 구체적인 예, 이로 인해 최적화를 수행해야 했습니다.
작업은 수만 행의 데이터를 데이터베이스에 로드하는 것입니다. 각 행에 대해 먼저 다소 번거로운 쿼리(조인을 통한 4개 테이블)를 사용하여 데이터베이스에서 추가 데이터를 찾아야 합니다.
문제는 15,000개의 행을 로드하는 데 8~9시간이 걸린다는 것입니다. 작업 조건에 따라 5년에 한 번이 아니라 자주 로드해야 하기 때문에... 일반적으로 시간을 허용 가능한 수준으로 가져와야 합니다.
내가 한 것?
1. 속도가 느려지는 것이 선택이라는 것을 알았습니다. (행이 많이 있고 일부 테이블에는 인덱스도 키도 없는 테이블에 데이터가 삽입되고 업데이트되므로 선택의 결함에 대한 의심이 듭니다.) .
2. 요청에 사용된 필드에 인덱스가 있는지 확인했습니다. 누락된 내용을 추가했습니다.
3. 아시는 분들께 도움을 요청했습니다. 🙂
아는 사람들은 쿼리 실행 계획을 분석하라고 조언했고 OraDev에서 이를 수행하는 방법을 설명했습니다.
새 쿼리 창을 만듭니다(Ctrl+N). 요청을 여기에 복사합니다. Alt+G를 누릅니다. 기존 항목을 선택하거나 새로 만듭니다. 새 테이블계획.
실행 후 실행 계획 트리가 나타납니다. 반 리터 없이는 스스로 알아내는 것이 그렇게 쉽지 않습니다. 😉
이 나무에 대한 우리의 관심은 무엇입니까? 우리는 단계의 비용이 큰 노드(단계)에 관심이 있습니다. 단계 속성에서 단계 가격을 볼 수 있습니다. (속성 창이 항상 열려 있으므로 선택만 하면 됩니다. 올바른 단계; 단계를 마우스 오른쪽 버튼으로 클릭하여 속성을 선택해야 할 수도 있습니다. 우리는 느린 단계를 찾습니다(계획 트리의 루트인 최상위 노드를 고려하지 않습니다. 요청의 총 가격이 여기에 표시되며 이 요청에 문제가 있다는 것을 이미 알고 있습니다). 그것을 발견? 이제 단계가 작동하는 테이블, 필드 및 행 수를 살펴봅니다. 이는 단계의 속성과 이름에 있습니다. 우리는 여기가 왜 이렇게 느린 걸까?
예를 들어, 단계 중 하나는 1~3개의 레코드(천 개가 아님) 대신 4,000개의 레코드로 작업했습니다. 원칙적으로 이런 일이 발생해서는 안 됩니다. 불필요한 정크 더미가 아닌 필요한 범위에서 선택하기 위해 샘플을 정확하게 제한합니다. 조인 조건을 주의 깊게 살펴본 결과 필드 중 하나가 누락되었음을 발견했습니다. 요청에 필드를 추가했더니 모든 것이 제대로 처리되었습니다. 요청 가격(전체)이 531에서 6으로 감소했습니다. :)
동지들의 도움 덕분에 둥지를 틀고 감지합니다.
추신 스크린샷을 포함하지 못해 죄송합니다. 그들에게는 훨씬 더 명확하겠지만... 일부 정보의 기밀성으로 인해 80%는 얼버무려야 하고 다시 불분명해질 것입니다.
추신 총 시간다운로드가 크게 감소했습니다. 17.5,000개 행의 데이터를 데이터베이스에 로드하는 데 12분이 걸렸습니다. 8~9시간에 비해... 글쎄, 당신은 이미 모든 것을 스스로 이해했습니다. 😉
Oracle Database 11g 성능 튜닝.
쿼리 계획을 읽는 방법
실행 계획이란 무엇입니까?
실행 계획은 실행 엔진의 언어로 해석된 최적화 프로그램의 출력입니다. 표현식에서 요청한 데이터를 최대한 빠르고 효율적으로 얻기 위해 수행해야 하는 작업에 대해 실행 엔진에 지시합니다.
EXPLAIN PLAN 표현식은 SELECT, UPDATE, DELETE 및 INSERT와 같은 표현식을 실행하기 위해 최적화 프로그램에서 선택한 실행 계획을 캡처합니다. 실행 계획 단계는 계획에 지정된 순서대로 실행되지 않습니다. 단계 사이에는 상위-하위 관계가 있습니다. 소스 문자열 트리는 실행 계획의 기초입니다. 여기에는 다음 정보가 포함됩니다.
- 명령문에서 참조하는 테이블 정렬
- 명령문에 지정된 각 테이블에 대한 액세스 방법
- 표현식의 조인 연산자에 사용되는 테이블의 조인 방법
- 필터, 정렬, 집계 등의 데이터 작업
- 각 작업의 비용, 카디널리티 등의 최적화 데이터
- 액세스된 파티션 세트와 같은 파티션 데이터
- 조인 연산 배포 방법 등 동시 데이터
실행 계획은 어디서 찾을 수 있나요?
데이터베이스의 표현식에 대한 실행 계획을 얻는 방법에는 여러 가지가 있으며 가장 널리 사용되는 방법은 다음과 같습니다.
- EXPLAIN PLAN 명령을 사용하면 최적화 프로그램이 표현식을 실행하는 데 사용할 수 있는 실행 계획을 볼 수 있습니다. 이 명령은 SQL 문을 저장하지 않고 실행 계획을 작성하고 이를 PLAN_TABLE이라는 테이블에 쓰기 때문에 매우 유용합니다.
- V$SQL_PLAN은 최근 실행된 커서에 대한 실행 계획을 볼 수 있는 기능을 제공합니다. V$SQL_LAN에 저장된 정보는 EXPLAIN PLAN 명령으로 생성된 정보와 매우 유사합니다. 그러나 계획 설명은 잠재적인 실행 계획을 보여주고, V$SQL_PLAN은 이미 실행된 쿼리의 계획을 저장합니다.
- V$SQL_PLAN_MONITOR에는 V$SQL_MONITOR에 있는 각 SQL 문에 대한 계획 수준 모니터링 통계가 포함되어 있습니다. V$SQL_PLAN_MONITOR에 포함된 각 줄은 특정 실행 계획 작업에 해당합니다.
- AWR 프레임워크와 Statspack은 가장 자주 호출되는 SQL에 대한 실행 계획을 저장합니다. 계획은 dBA_HIST_SQL_PLAN 또는 STATS$SQL_PLAN 뷰에 배치됩니다.
- 실행 계획과 행 소스도 DBMS_MONITOR에 의해 생성된 추적 파일에 기록됩니다.
- SQL Management Base는 SYSAUX 테이블스페이스에 저장된 데이터 사전의 일부입니다. 작업에 대한 로그 정보, 실행 계획 내역, 참조 라인은 물론 SQL 문의 프로필도 여기에 저장됩니다.
- 비용 최적화 계산을 기록하는 데 사용되는 진단 이벤트 10053은 쿼리 실행 계획을 생성할 수도 있습니다.
- 버전 10.2부터 프로세스 상태를 덤프하면 생성된 추적 파일에 실행 계획도 포함됩니다.
실행 계획 보기
SQL*Plus에서 EXPLAIN PLAN 명령을 실행하면 PLAN_TABLE 테이블에서 데이터를 선택하고 생성된 실행 계획을 볼 수 있습니다. 최대 간단한 방법으로실행 계획을 보면 DBMS_XPLAIN 패키지를 사용하는 것입니다. DBMS_XPLAIN 패키지에는 5가지 사용 가능한 함수가 포함되어 있습니다.
- DISPLAY: 실행 계획의 형식화된 출력에 사용됩니다.
- DISPLAY_AWR: 형식화된 계획 출력에 사용됩니다. SQL 실행 AWR 저장소에 저장된 표현식.
- DISPLAY_CURSOR: 로드된 커서의 실행 계획 출력 형식을 지정하는 데 사용됩니다.
- DISPLAY_SQL_PLAN_BASELINE: 헤더로 식별되는 SQL 문에 대한 하나 이상의 실행 계획의 형식화된 출력에 사용됩니다.
- DISPLAY_SQLSET: SQL 튜닝 세트에 저장된 실행 계획의 형식화된 출력에 사용됩니다.
EXPLAIN PLAN 명령
- EXPLAIN PLAN 명령은 쿼리 실행 계획을 생성하는 데 사용됩니다.
- 계획이 생성되면 PLAN_TABLE 테이블의 정보를 쿼리하여 볼 수 있습니다.
PLAN TABLE은 전역 임시 테이블로 자동 생성되며 이후 모든 사용자가 실행 계획을 저장하는 데 사용됩니다. 스크립트를 사용하여 자신만의 PLAN TABLE을 생성할 수 있습니다. 실행 계획의 장기 저장이 필요한 경우 $ORACLE_HOME/rdbms/admin/utlxplan.sql.
EXPLAIN PLAN 명령 구조
EXPLAIN PLAN 명령은 실행 계획의 각 단계에 대해 PLAN TABLE에 행을 삽입합니다.
EXPLAIN PLAN 명령 예
이 명령표현식에 대한 실행 계획을 PLAN TABLE에 삽입하고 나중에 참조할 수 있도록 데모01 태그를 추가합니다.
실행 계획을 얻는 방법에는 여러 가지가 있습니다. 위의 방법은 EXPLAIN PLAN 명령을 사용하는 것입니다. 이 명령은 SQL 문을 실행하지 않고 그에 대한 실행 계획을 생성하고 그 결과를 PLAN TABLE에 배치합니다. PLAN TABLE은 ID 및 PARENT_ID 열과 CONNECT BY 절을 사용하여 표현식에 대한 실행 계획을 반환할 수 있는 트리 구조를 나타냅니다. SELECT 표현식.
PLAN TABLE의 내용 출력
위의 예에서는 DBMS_XPLAIN.DISPLAY 함수에 ALL 키를 사용하여 모든 내용을 볼 수 있습니다. 이용 가능한 정보 PLAN TABLE에 저장된 실행 계획에 대한 정보입니다. 이 결론표준정보 외에 추가 정보작업이 분산된 경우 PROJECTION, ALIAS 및 REMOTE SQL 정보와 같은 정보입니다.
출력 정보를 보다 정확하게 제어하기 위해 다음 주요 매개변수를 사용할 수 있습니다. 각 예어 PLAN TABLE의 정보 출력에 별도의 블록을 추가합니다. 키워드는 쉼표나 공백으로 구분해야 합니다.
- ROWS는 해당하는 경우 최적화 프로그램에서 계산할 것으로 예상되는 행 수를 표시합니다.
- 해당하는 경우 ROWS는 최적화 프로그램에서 계산할 것으로 예상되는 바이트 수를 표시합니다.
- 비용 해당되는 경우 비용을 표시합니다.아마도 옵티마이저에 의해 계산된 것 같습니다.
- 분할 적절한 경우 최적화 프로그램이 패트리샤를 폐기하는 모습을 보여줍니다.
- PARALLEL 또는 적절한 경우 PX 정보를 표시합니다(방법테이블 액세스 큐에 대한 정보 배포 및 정보)
- 술부또는 적절합니까? 술어에 대한 정보를 표시합니다.
- PROJECTION 또는 적절한 경우 섹션을 표시합니다.투영
SQL Developer에서 계획 설명 사용
자동 추적
표현이수행 SQL*Plus 또는 SQL Developer에서는 표현식의 실행 계획 및 실행 통계를 자동으로 얻을 수 있습니다. 보고서는 SELECT, INSERT, UPDATE 및 DELETE와 같은 모든 유형의 작업을 수행한 후 자동으로 생성됩니다. 이 정보 SQL 문의 성능을 진단하고 조정하는 데 사용할 수 있습니다.
AUTOTRACE를 사용하려면 데이터베이스에 PLAN TABLE을 생성해야 하며, AUTOTRACE를 수행하는 사용자에게 PLUSTRACE 역할을 부여해야 합니다. 역할PLUSTRACE는 스크립트를 사용하여 생성되고 DBA 역할에 발급됩니다.$ORACLE_HOME/sqlplus/admin/plustrce.sql
구문 AUTOTRACE
위 그림에 표시된 구문을 사용하여 Autotrace를 수행할 수 있습니다. 다음 옵션도 사용할 수 있습니다.
- OFF 추적 사용을 비활성화합니다.
- ON 자동 라우팅 사용을 활성화합니다.
- TRACE 자동 추적을 활성화하고 SQL 출력을 억제합니다.
- EXPLAIN 실행 계획을 표시하지만 통계는 표시하지 않습니다.
- STATISTICS 실행 계획 없이 통계를 표시합니다.
AUTOTRACE 사용 예
자동 추적: 통계
표현식을 실행할 때 서버가 기록한 통계는 볼륨을 반영합니다. 시스템 리소스, 표현식 실행에 소요되며 다음과 같은 주요 지표가 포함됩니다.
- 재귀 호출- 클라이언트 및 서버 측에서 생성된 재귀 호출 수 Oracle 데이터베이스는 내부 처리에 사용되는 테이블을 유지 관리합니다. Oracle 데이터베이스는 이러한 테이블을 변경해야 할 때 내부 SQL 문을 생성하고, 이는 다시 재귀 호출을 생성합니다.
- db 블록이 가져옵니다.- CURRENT 블록이 요청된 횟수
- 일관된 도착- 데이터 블록의 통합 읽기 동작을 요청하는 횟수입니다.
- 물리적 읽기- 디스크에서 읽은 데이터 블록 수입니다. 이 숫자는 값의 합을 나타냅니다. 물리적 읽기는 직접 읽기이고 모든 읽기는 버퍼에서 이루어집니다.은닉처.
- 크기를 다시 실행- 블록 단위로 생성된 총 리두 수
- SQL*Net을 통해 클라이언트로 전송된 바이트- 백그라운드 프로세스에서 클라이언트로 전송된 총 바이트 수입니다.
- 클라이언트로부터 SQL*Net을 통해 수신된 바이트- Oracle*Net 클라이언트로부터 수신된 총 바이트 수
- 클라이언트와의 SQL*Net 왕복- 클라이언트와 주고받은 Oracle NET 메시지의 총 개수입니다.
- 정렬(메모리)- 메모리에서 성공적으로 완료되었으며 디스크에 쓸 필요가 없는 정렬 작업의 수입니다.
- 정렬(디스크)- 적어도 하나의 디스크 작업이 필요한 정렬 작업의 수.
- 행 처리됨- 작업 중에 처리된 행 수입니다.
db_block_gets데이터베이스에서 현재 블록의 읽기 작업을 보여줍니다. 일관된 도착- 이는 다음을 만족해야 하는 블록 읽기 작업입니다. 특정 번호 SCN. 물리적 읽기디스크에서 블록을 읽는 모습을 보여줍니다. db_block_gets그리고 일관된 도착- 지속적으로 모니터링되는 통계 지표. 검색된 행 수에 비해 낮아야 합니다. 정렬은 디스크가 아닌 메모리에서 수행됩니다.
SQL*Developer를 사용한 자동 추적
V$SQL_PLAN 보기
이 보기에는 아직 라이브러리 캐시에 있는 커서에 대한 실행 계획이 표시됩니다. 이 뷰에 저장된 정보는 여러 면에서 PLAN TABLE의 정보와 유사합니다. 그러나 V$SQL_PLAN에는 이미 실행된 표현식에 대한 실행 계획이 포함되어 있습니다. EXPLAIN PLAN에서 생성된 실행 계획은 커서에 저장된 실제 실행 계획과 다를 수 있습니다. 이는 세션 매개변수 및 BIND 변수 값이 현재와 다를 수 있기 때문에 발생합니다.
또 다른 유용한 보기: V$SQL_PLAN_STATISTICS캐시된 각 커서의 실행 계획에서 각 작업에 대한 실행 통계를 제공합니다. 또 다른 유용한 아이디어 V$SQL_PLAN_STATISTIC_ALL의 실행 정보를 결합합니다. V$SQL_PLAN_STATISTICS그리고 V$SQL_WORKAREA 실행 계획이 저장된 경우 V$SQL_PLAN.
V$SQL_PLAN 뷰의 주요 열에 대한 설명
뷰에는 PLAN TABLE과 동일한 열과 몇 가지 추가 열이 포함되어 있습니다. PLAN TABLE에 존재하며 동일한 값을 갖는 열:
- 주소
- HASH_VALUE
PLAN_HASH_VALUE는 다음을 포함하는 열입니다. 수치 표현커서에 대한 SQL 표현식을 계획합니다. PLAN_HASH_VALUE 컬럼의 값을 비교하면 행별로 비교하지 않고도 동일한 표현식에 대한 실행 계획이 변경되는지 여부를 빠르게 확인할 수 있습니다.
V$SQL_PLAN_STATISTICS 보기
V$SQL_PLAN_STATISTICS 뷰는 다음을 제공합니다. 현재 통계처리된 행 수나 실행 시간 등 실행 계획의 각 작업에 대한 실행을 기준으로 합니다. 행 수를 제외한 모든 통계는 누적됩니다. 예를 들어, 테이블 조인 통계에는 3개의 테이블 조인 작업이 포함될 수 있습니다. V$SQL_PLAN_STATISTICS에 저장된 통계는 초기화 매개변수 STATISTICS_LEVEL = ALL 또는 GATHER_PLAN_STATISTICS 최적화 힌트를 사용하여 컴파일된 커서에 사용할 수 있습니다.
V$SQL_STATISTICS_ALL 뷰에는 SQL 메모리(정렬 또는 HASH 조인)를 사용한 모든 소스 행에 대한 메모리 사용량 통계가 포함되어 있습니다. 이 뷰는 V$SQL_PLAN 뷰에 저장된 정보와 V$SQL_PLAN_STATISTICS 및 V$SQL_WORKAREA 뷰의 실행 통계를 결합합니다. .
중요한 동적 성능 보기 간의 관계
V$SQLAREA공유 SQL 영역에 대한 통계를 표시하고 각 영역에 대해 한 줄을 포함합니다. SQL 문자열표현. 이 뷰는 메모리에서 이미 구문 분석되어 실행 준비가 된 SQL 문에 대한 통계를 제공합니다.
- SQL_ID- 라이브러리 캐시에 있는 상위 커서의 SQL 식별자
- VERSION_COUNT특정 상위 커서에 대한 캐시에 존재하는 하위 커서 수
V$SQL공유 SQL 영역에 대한 통계를 저장하고 상위 SQL 표현식에서 파생된 각 하위 SQL 표현식에 대해 하나의 행을 포함합니다.
- 주소주어진 커서의 상위 커서 헤더 주소를 나타냅니다.
- HASH_VALUE-라이브러리 캐시에 있는 상위 표현식의 값
- SQL_ID- 라이브러리 캐시에 있는 상위 커서의 SQL 식별자
- PLAN_HASH_VALUE- 주어진 커서에 대한 SQL 계획의 수치 표현
- CHILD_NUMBER- 하위 커서 번호
V$SQL에 저장된 통계는 SQL 문이 실행될 때 업데이트됩니다. 그러나 장기 실행 식의 경우 뷰의 정보는 5초마다 업데이트됩니다. 이를 통해 장기 실행 쿼리가 실행되는 동안 성능에 미치는 영향을 평가할 수 있습니다.
V$SQL_PLAN라이브러리 캐시에 로드된 각 하위 커서에 대한 실행 계획 정보를 포함합니다. 열 주소, HASH_VALUE그리고 CHILD_NUMBER연결하는 데 사용할 수 있습니다. V$SQL나중에 하위 커서를 정의하기 위해.
V$SQL_PLAN_통계각 하위 커서에 대한 소스 행 수준 실행 통계를 제공합니다.열 주소, HASH_VALUE 뷰와 결합하는 데 사용할 수 있습니다. V$SQLAREA부모를 결정하기 위해커서.열 주소, HASH_VALUE그리고 CHILD_NUMBER연결하는 데 사용할 수 있습니다.V$SQL하위 커서를 정의합니다.
V$SQL_PLAN_STATISTICS_ALL SQL 메모리(정렬 또는 HASH 조인)를 사용한 모든 소스 행에 대한 메모리 사용량 통계를 포함합니다. 이 보기는 보기에 저장된 정보를 집계합니다. V$SQL_PLAN뷰의 실행 통계 포함 V$SQL_PLAN_STATISTICS그리고 V$SQL_WORKAREA.
V$SQL_WORKAREA프로세스와 관련된 작업 영역에 대한 통계를 제공합니다. SQL 작업표현. 공유 풀에 저장된 각 SQL 문에는 하나 이상의 하위 커서가 있으며 이에 대한 정보는 V$SQL. V$SQL_WORKAREA이러한 하위 커서에 필요한 모든 작업 공간에 대한 정보가 포함되어 있습니다.
V$SQL_WORKAREA와 연결할 수 있다 V$SQLAREA(주소, HASH_VALUE)그리고 V$SQL( 주소, HASH_VALUE,CHILD_NUMBER).
사용 이 프레젠테이션다음 질문에 대한 답을 얻을 수 있습니다.
- 가장 많이 필요한 상위 10개 작업 영역수량캐시용 메모리
- AUTO 모드에서 실행되는 작업공간의 경우작업 공간의 몇 퍼센트가 다음을 사용하여 실행되고 있나요? 최대 수량메모리?
V$SQLSTATS SQL 커서에 대한 기본 성능 통계를 표시하며, 각 행은 SQL 표현식 텍스트와 SQL 실행 계획(조합)을 결합한 데이터를 나타냅니다. SQL_ID그리고 PLAN_HASH_VALUE). 열 V$SQLSTATS동일한, V$SQL그리고 V$SQLAREA. 그러나 프레젠테이션은 V$SQLSTATS~와 다르다 V$SQL그리고 V$SQLAREA처리 속도, 확장성, 긴 데이터 저장 기간(커서가 공유 풀에서 제거된 후에도 통계 데이터가 뷰에 저장될 수 있음)
V$SQL_PLAN 뷰에서 데이터를 쿼리하는 예
뷰에서 데이터를 쿼리할 수 있습니다. V$SQL_PLAN기능을 사용하여 DBMS_XPLAIN.DISPLAY_CURSOR()현재 또는 마지막으로 실행된 표현식을 표시합니다(예제 참조). 값을 전달할 수 있습니다. SQL_ID주어진 표현식에 대한 실행 계획을 얻기 위한 매개변수로 사용됩니다. SQL_ID - SQL_ID커서 캐시에 저장된 표현식 당신은 얻을 수 있습니다 해당 값열에서 정보 요청 SQL_ID V V$SQL그리고 V$SQLAREA. 또는 다음을 선택할 수 있습니다. PREV_SQL_ID특정 세션의 경우 V$세션. 기본적으로 이 옵션은 지정되지 않으며, 이 경우 마지막으로 실행된 커서에 저장된 계획이 표시됩니다.
- ISTATS: SQL 실행 프로세스가 실행 계획에 대한 기본 통계를 수집한다고 가정할 때 STATISTICS_LEVEL을 ALL로 설정하거나 HINT GATHER_PLAN_STATISTICS를 사용한다고 가정할 때 ALL을 지정한 경우(또는 LAST를 지정한 경우 마지막 것만) 전체에 대한 I/O 통계를 표시하는 형식입니다. 커서의 실행.
- 멤스태츠: 자동 PGA 관리가 사용된다고 가정하면(pga_aggregate_target이 0이 아닌 값으로 설정됨) 이 형식을 사용하면 메모리 사용량 통계를 표시할 수 있습니다. 이 유형통계는 HASH 조인, 정렬 또는 일부 비트맵 연산자와 같은 메모리 집약적 작업에만 적용할 수 있습니다.
- 모든 통계: 동의어 "IOSTATS MEMSTATS"
- 마지막: 기본적으로 모든 커서 실행에 대한 실행 계획 통계가 표시됩니다. LAST 키워드를 사용하면 마지막으로 실행된 이후 생성된 계획 통계를 볼 수 있습니다.
중요한 AWR 보기
Enterprise Manager에서 또는 AWR 보고서를 생성하여 AWR 데이터를 볼 수 있으며 AWR 데이터를 저장하는 다음 동적 성능 보기에 추가로 액세스할 수도 있습니다.
- V$ACTIVE_SESSION_HISTORY- 이 보기에는 매초 업데이트되는 최신 세션 활동에 대한 정보가 표시됩니다.
- V$ 메트릭 뷰는 시스템 성능을 추적하기 위한 메트릭 데이터를 제공합니다. V$METRICGROUP 뷰에 액세스하면 메트릭 뷰 목록을 볼 수 있습니다.
- DBA_HIST 뷰에는 데이터베이스에 저장된 기록 데이터가 포함되어 있습니다. 이 보기 그룹에는 다음이 포함됩니다.
- DBA_HIST_ACTIVE_SESS_HISTORY메모리에서 선택한 기록의 내용을 포함합니다. 활성 세션최근 시스템 활동으로
- DBA_HIST_BASELINE데이터베이스에 저장된 참조선에 대한 정보를 포함합니다.
- DBA_HIST_DATABASE_INSTANCE데이터베이스 환경에 대한 정보가 포함되어 있습니다.
- DBA_HIST_SNAPSHOT시스템에 저장된 스냅샷에 대한 정보가 포함되어 있습니다.
- DBA_HIST_SQL_PLAN실행 계획에 대한 정보가 포함되어 있습니다.
- DBA_HIST_WR_Control AWR 설정에 대한 정보가 포함되어 있습니다.
특정에 대한 보고서 생성SQLAWR 저장소에서
SQL 모니터링
도구 SQL 모니터링옵션을 선택하면 기본적으로 사용 가능 STATISTICS_LEVEL값으로 설정 전형적인또는 모두. 사용하기위한 이 악기의매개변수 값도 설정해야 합니다. CONTROL_MANAGEMENT_PACK_ACCESS의미상 진단+튜닝진단 및 구성 패키지를 활성화합니다.
기본적으로 SQL 모니터링은 SQL 문이 병렬로 실행되거나 단일 실행 중에 CPU 또는 I/O 시간을 5초 이상 소비하는 경우 자동으로 활성화됩니다.
표현식에 대한 SQL 모니터링을 명시적으로 활성화하거나 비활성화하는 두 가지 최적화 힌트가 있습니다. 감시 장치그리고 NO_MONITOR.
뷰를 사용하여 SQL 문 실행 통계를 추적할 수 있습니다. V$SQL_MONITOR그리고 V$SQL_PLAN_MONITOR.
동적 성능 보기에서 SQL 문 모니터링을 활성화한 후 V$SQL_MONITOR실행 시간, CPU 시간, 읽기 및 쓰기 수, I/O 대기 시간, 기타 대기 시간 지표 등 주요 성능 지표를 추적하는 데 필요한 정보를 추가합니다. 이 통계기본적으로 SQL 실행 중에 매초마다 실시간으로 업데이트됩니다. 실행이 완료된 후 실행에 대한 정보가 뷰에 저장됩니다. V$SQL_MONITOR 1분 더 지나면 제거됩니다.
샘플 SQL 모니터링 보고서
이 예에서는 SALES 테이블에서 데이터를 선택하고 다른 세션에서 SQL 모니터링을 실행한다고 가정합니다.
DBMS_SQLTUNE.REPORT_SQL_MONITOR 함수는 보고서의 세부 수준을 제한하거나 확장하는 여러 매개변수를 허용할 수 있습니다. 추가 매개변수를 사용하면 보고서의 출력 형식(TEXT, HTML 또는 XML)을 지정할 수도 있습니다. 기본적으로 보고서는 텍스트로 생성됩니다. 체재.
동일한 SQL 문의 두 실행을 고유하게 식별하기 위해 실행 키라는 복합 키가 생성됩니다. 이 키는 세 가지 속성으로 구성되며, 각 속성은 V$SQL_MONITOR의 열을 참조합니다.
- SQL_ID
- 주어진 내용을 보장하기 위해 내부적으로 생성된 식별자 기본 키실제로 고유합니다(SQL_EXEC_ID).
- 표현식 실행 시작 타임스탬프(SQL_EXEC_START)
실행 계획 해석
결론 계획을 설명하다실행 계획의 트리 구조를 표 형식으로 표현한 것입니다. 각 단계(실행 계획의 라인 또는 트리의 노드)는 행 소스를 나타냅니다.
parrent 아래의 노드 순서는 해당 수준의 노드 실행 순서를 나타냅니다. 두 단계가 동일한 레벨에 있는 경우 순서대로 첫 번째 단계가 먼저 실행됩니다.
트리 형식에서는 트리의 각 수준 왼쪽에 있는 잎이 실행이 시작되는 지점을 식별합니다.
실행 계획 단계는 번호가 매겨진 순서대로 실행되지 않습니다. 단계 사이에는 상위-하위 관계가 있습니다.
PLAN_TABLE 및 V$SQL_PLAN에서 중요한 요소트리 구조를 얻으려면 ID, PARRENT_ID 및 POSITION 열이 필요합니다. 추적 파일에서 이러한 열은 각각 id, pid 및 pos 필드에 해당합니다.
실행 계획을 읽는 한 가지 방법은 이를 트리 구조의 그래프로 변환하는 것입니다. 맨 위에서 시작할 수 있으며, ID=1인 항목이 트리의 맨 위 지점입니다. 이는 parrent_id 또는 pid 값이 1인 작업의 경우에 해당됩니다.
계획을 트리로 표현하려면 다음을 수행합니다.
- 가장 많은 신분증을 가져가세요 낮은 가치그리고 나무 꼭대기에 놓아주세요.
- 이 값과 동일한 PID(상위 ID)가 있는 행을 식별합니다.
- 왼쪽에서 오른쪽으로 가장 낮은 것부터 가장 높은 것까지 POS 값에 따라 상위 항목 아래 트리에 배치합니다.
- 모든 상위 ID를 찾으면 한 수준 아래로 다음 ID로 이동하고 프로세스를 반복하여 동일한 PID를 가진 새 행을 찾습니다.
실행 계획을 해석하는 표준 방법:
- 상단에서 시작
- 데이터를 생성하지만 아무것도 소비하지 않는 작업에 도달할 때까지 작업을 아래로 이동합니다. 이것이 작전의 시작이다.
- 이 부모가 가지고 있는 자식 작업을 살펴보십시오. 하위 작업은 다음과 같이 수행됩니다.
- 모든 거래가 검토될 때까지 트리 위로 이동합니다.
실행 계획 트리를 해석하는 표준 방법은 다음과 같습니다.
- 상단에서 시작
- 왼쪽 노드에 도달할 때까지 트리를 따라 아래로 왼쪽으로 이동하면 먼저 실행됩니다.
- 이 노드의 자식을 보세요. 이 아이들은 추가 처형을 당할 것입니다.
- 하위 작업이 실행된 후에도 상위 작업이 계속 실행됩니다.
- 이제 이 작업과 모든 하위 작업이 완료된 후 트리 위로 이동하여 원래 일련의 작업과 해당 상위 작업의 하위 항목을 살펴보세요. 동일한 원리에 따라 수행됩니다.
- 모든 거래가 검토될 때까지 트리를 탐색하세요.
실행 계획 해석: 예 1
위 그림은 표현식에 대한 실행 계획의 해석을 보여줍니다. 그림에 표시된 쿼리는 급여 표와 급여가 다른 직원을 찾으려고 시도합니다. 쿼리는 두 테이블에서 데이터를 선택하고 급여 수준을 확인하기 위해 다른 테이블의 선택을 기반으로 하는 하위 쿼리를 포함합니다.
이 요청의 실행 순서를 살펴보겠습니다. 이 그림과 이전 그림을 기반으로 실행 순서는 다음과 같습니다: 3-5-4-2-6-1:
- 3: 계획 실행은 EMP 테이블(ID=3)의 전체 스캔으로 시작됩니다.
- 5: 행은 중첩 루프(ID=2)를 제어하는 단계로 전달되며, 이 단계에서는 이를 사용하여 PK_DEPT 인덱스(ID=5)의 행을 조회합니다.
- 4: PK_DEPT를 스캔한 후 얻은 행의 ROWID는 DEPT 테이블(ID=4)에서 나머지 정보를 얻는 데 사용됩니다.
- 2: ID=2, 중첩 루프 병합 프로세스는 완료될 때까지 계속됩니다.
- 6: ID=2가 조인을 위한 모든 소스 행을 처리한 후 SALGRADE 테이블(ID=6)의 전체 스캔이 수행됩니다.
- 1: ID=6을 실행한 후 수신된 데이터는 ID=2 및 ID=6의 행을 필터링하는 데 사용됩니다.
실행 계획 해석: 예 2
이 쿼리는 부서가 시애틀에 있고 관리자가 있는 직원의 이름, 부서 이름 및 주소를 반환합니다.
서식을 쉽게 지정할 수 있도록 그림에 다른 번호가 추가되었습니다. 왼쪽 열은 ID를 나타내고 오른쪽 열은 PID를 나타냅니다. 쿼리 실행 계획은 두 개의 NESTED LOOP JOIN 작업을 보여줍니다. 위에 제시된 방법에 따라 실행 계획을 해석합니다.
- 위에서부터 시작합시다. ID=0
- 데이터를 생성하지만 아무것도 소비하지 않는 작업에 도달할 때까지 작업을 진행합니다. 안에 이 경우,ID 0,1,2,3이 데이터를 소비하고 있습니다. ID=4는 리소스를 소비하지 않지만 데이터를 생성하는 위에서부터 첫 번째 작업입니다. 이것이 첫 번째 데이터 소스입니다. INDEX RANGE SCAN은 LOCATIONS 테이블(ID=3)에서 데이터를 반환하는 데 사용될 행의 ROWID를 반환합니다.
- 트리에서 동일한 수준에 있는 이 행 소스의 형제 항목을 살펴보겠습니다. 같은 레벨의 형제, 자매는 ID=3, ID=5입니다. ID = 5에는 자식 ID = 6이 있으며 그 전에 실행됩니다. 이는 다른 인덱스에 대한 INDEX RANGE SCAN 작업으로, 실행 ID=5 동안 DEPARTMENTS 테이블에서 데이터를 검색하는 데 나중에 사용되는 ROWID를 반환합니다.
- 하위 작업이 실행된 후 제어권이 해당 상위 작업으로 이전됩니다. 다음 작업은 이전에 수신된 데이터를 결합하기 위한 ID=2의 NESTED LOOPS입니다.
- 이제 상위 작업과 모든 하위 항목이 완료되었으므로 트리에 올라가 상위 작업에 동일한 수준의 형제, 자매가 있는지 확인합니다. ID=2는 하위 ID=8이 있는 작업 ID=7과 동일한 수준에 있습니다. 이 아이가 먼저 처형될 것이다. INDEX UNIQUE SCAN이 실행되어 행의 ROWID를 얻은 다음 작업 ID=7에서 EMPLOYEES 테이블에서 데이터를 검색하는 데 사용됩니다.
- 현재 수준의 모든 작업과 해당 하위 작업이 처리된 후 더 높은 수준으로 이동합니다. 수행할 마지막 작업은 NESTED LOOPS를 ID=1과 병합하는 것이며, 그 후 결과는 ID=0으로 전송됩니다.
- 작업 순서는 다음과 같습니다: 4-3-6-5-2-8-7-1-0
아래는 상세 설명실행 계획:
먼저 CITY 열에 대한 인덱스 액세스를 사용하여 LOCATIONS를 선행 테이블로 사용하여 내부 중첩 루프가 실행됩니다. 시애틀에 있는 부서만 찾고 있기 때문에 작업이 작동합니다.
결과는 조인에 대한 LOCATION_ID 열의 인덱스를 사용하여 DEPARTMENTS 테이블에 조인됩니다. 첫 번째 조인 작업의 결과는 두 번째 중첩 루프의 선행 데이터 소스입니다.
두 번째 조인 작업에서는 EMPLOYEES 테이블의 EMPLOYEE_ID 열에 대한 인덱스를 검사합니다. 이 작업은 시스템이 (첫 번째 조인 작업부터) 시애틀에 있는 모든 부서 관리자의 ID를 알고 있기 때문에 수행될 수 있습니다. 이 경우 기본키 인덱스를 대상으로 스캔을 수행하므로 UNIQUE SCAN을 수행한다.
실행 순서는 다음과 같습니다: 3-5-6-4-2-1
병합 순서: T1-T2-T3
보다 포괄적인 실행 계획 읽기
왼쪽 그림에 표시된 계획은 데이터 사전의 쿼리를 통해 구축됩니다. 길이가 매우 길어서 첫 번째 연산을 찾기 위해 기존의 해석 방법을 적용하는 것은 매우 어렵습니다.
개요를 줄여서 더 읽기 쉽게 만들 수 있습니다. 오른쪽 그림은 동일한 실행 계획을 간략하게만 보여줍니다. 그림에 표시된 것처럼 이는 Enterprise Manager 또는 SQL*Developer를 사용하여 쉽게 수행할 수 있습니다. 그림에서 볼 수 있듯이 계획에는 두 지점을 병합하는 작업이 포함됩니다. 데이터 사전에 대한 지식을 통해 두 분기가 사전 관리 및 로컬 관리 테이블스페이스에 해당한다는 것을 이해할 수 있습니다. 데이터베이스에 대한 지식을 통해 데이터베이스에 사전 관리 테이블스페이스가 없다는 것을 이해할 수 있습니다. 이렇게 하면 문제가 발생하면 두 번째 지점에 있게 됩니다. 가정을 확인하려면 각 행 소스의 계획 정보와 실행 통계를 살펴보고 계획에서 가장 많은 리소스를 소비하는 부분을 확인해야 합니다. 그런 다음 문제가 발견된 분기를 확장해야 합니다. 사용하기위한 이 방법 V$SQL_PLAN_STATISTICS 뷰 또는 추적 파일에서 생성된 tkprof 보고서에서 찾을 수 있는 실행 통계를 추가로 사용해야 합니다. 예를 들어, tkprof는 각 상위 작업을 실행하는 데 걸리는 시간과 모든 하위 작업의 실행 시간을 합산합니다.
실행 계획 개요
OLTP 환경에서 SQL 표현식을 설정할 때 목표는 가장 높은 선택성 필터가 적용된 테이블부터 시작하는 것입니다. 이는 다음 작업에 더 적은 수의 행이 전달된다는 의미입니다. 다음 단계가 조인인 경우에는 더 적은 수의 행이 조인된다고 가정합니다. 또한 데이터 액세스 경로가 최적인지 확인해야 합니다. 실행 계획을 검토할 때 다음 사항에 유의하세요.
- 계획은 다음과 같이 설계되었습니다. 최고의 필터선행 테이블에 적용됨
- 조인 순서는 최소한의 행이 다음 단계로 전달되도록 설계되었습니다. 즉, 조인 순서는 아직 사용되지 않은 최상의 필터로 이동해야 합니다.
- 조인 방법은 조인을 위해 전달된 행 수와 일치합니다. 예를 들어 인덱스를 사용하는 NESTED LOOP 조인은 많은 행이 반환될 때 최적이 아닐 수 있습니다.
- 뷰가 효과적으로 사용됩니다. 보다 선택 목록뷰에 액세스해야 하는 위치를 결정합니다.
- 테이블의 데카르트 곱 연산은 없습니다(작은 테이블의 경우에도).
- 각 테이블을 효율적으로 읽습니다. 테이블의 행 수와 관련하여 SQL 표현식의 조건자를 고려하세요. 의심스러운 작업을 자세히 살펴보세요. 예를 들어 다음과 같은 테이블에 대한 전체 테이블 스캔이 있습니다. 큰 금액술어에 존재하는 문자열입니다.
전체 테이블 스캔은 작은 테이블에 효과적으로 사용하거나 반환된 행에 특정 조인 유형(예: HASH JOIN)을 적용하는 데 사용할 수 있습니다.
위의 조건 중 하나라도 최적이 아닌 경우 SQL을 다시 작성하거나 테이블에서 사용 가능한 인덱스를 검토해야 합니다.
실행 계획 자체는 쿼리 실행 효율성에 대한 정보를 제공할 수 없습니다. 예를 들어 EXPLAIN PLAN의 출력에 인덱스 사용량이 표시될 수 있지만 이것이 해당 식이 효과적이라는 의미는 아닙니다. 때로는 인덱스를 사용하는 것이 매우 비효율적일 수 있습니다.
결정을 위해 최적의 계획실행을 위해서는 초기 계획을 수립한 다음 테스트를 통해 더욱 최적의 실행을 위해 최적화해야 합니다. 실행 계획을 변경하는 동안 시스템 리소스 소비를 모니터링해야 합니다.
그것은 당신이 가장 좋아하는 신발 밑창에 박힌 못과 같습니다. 걸을 수는 있지만 제자리에 머물고 싶거나 다른 사람에게 작업을 위임하고 싶은 마음이 점점 더 커지고 있습니다. 사소한 불편은 작업 속도를 느리게 할 뿐만 아니라 동기를 감소시키고 프로세스를 방해하며 결과의 품질을 저하시킵니다. 그리고 그 못에 망치와 망치를 꽂는 법을 가르쳐 준 친구를 찾았다면 그의 도움에 대해 감사할 뿐만 아니라 다른 사람들을 스스로 도와 사소하지만 매우 성가신 장애물로부터 그들을 구하게 될 것입니다. 그렇기 때문에 포럼과 Habr과 같은 사이트에서 깊고 친밀한 지식뿐만 아니라 간단한 트릭과 "작은 트릭"도 소통하고 공유해야 합니다.
다른 텍스트와 마찬가지로 SQL의 쿼리 및 프로그램은 어떤 방식으로든 생성될 수 있습니다. 텍스트 에디터. 그러나 전문가라면 SQL을 자주 사용하고 구문 강조 기능과 자동 코드 형식 재지정 기능만으로는 더 이상 충분하지 않습니다. 특히 동일한 DBMS의 다른 버전이나 다른 DBMS 플랫폼 간에 전환해야 하는 경우에는 더욱 그렇습니다.
최근에 나는 주요 전문가 중 한 명과 대화를 나눴습니다. 오라클 DBMS. 그는 쿼리 실행 계획 작업에 관해 흥미로운 이야기를 많이 했습니다. 다른 버전이 DBMS를 사용하고 있으며 자신이 사용하는 도구와 기술에 대해 모든 사람에게 주저하지 않고 유용한 팁을 제공했습니다. 나는 그의 블로그에 있는 기사 중 하나를 번역했고 그것을 Khabravchan의 관심에 알리고 싶습니다. 설명된 기술이 Oracle과 작업하는 데 사용되었다는 사실에도 불구하고 이제는 MS SQL과 Sybase에서도 동일한 접근 방식을 성공적으로 사용하고 있습니다.
실행 쿼리를 실행하면 실행 계획이 포함된 쿼리 계획 탭이 나타납니다. 
다이어그램의 노드 위에 마우스를 올리면 쿼리 계획의 해당 실행 단계와 관련된 추가 유용한 정보가 나타납니다!
기본적으로 Rapid SQL은 실행 계획을 다음과 같이 표시합니다. 그래픽 형태. 나는 최적화의 낡은 세계에서 나왔다… 나는 선호한다 텍스트 버전, 그래서 나는 오른쪽 버튼계획이 있는 창에 마우스를 놓고 "텍스트로 보기"를 선택하세요.
요청 텍스트와 계획을 동시에 보는 것을 선호합니다. 
그것은 쉽습니다. 메인 창 하단에 ISQL 창 탭이 보이나요? 먼저 계획을 별도의 창에 표시하도록 Rapid SQL을 구성해야 합니다. 
옵션 버튼(왼쪽 빨간색 원)을 클릭한 다음 결과 창에 대해 '연결되지 않음' 옵션을 설정합니다. 이렇게 하면 두 개가 생성됩니다. 개별 북마크실행 쿼리 실행 후 Rapid SQL 하단에 있습니다. 이 창을 탭 옆으로 조금 드래그하면 이 창을 이동할 수 있는 위치에 직사각형이 나타납니다.
또는 프로그램의 기본 메뉴에서 타일 창 항목을 사용할 수 있습니다.
그리고 한 가지 더: 이 모든 것은 데이터베이스 관리자를 위한 솔루션인 DBArtisan에서도 작동합니다.