관계형 데이터베이스에서 성능 문제를 어떻게 설명합니까?

관계형 데이터베이스에서 성능 문제를 어떻게 설명합니까?

사용자의 기대를 충족하지 못하는 관계형 데이터베이스에서 실행 중인 쿼리가 있습니다.

이 사이트에서 효과적인 도움을 받으려면 어떤 정보를 제공하고 피해야 합니까?

Oracle Database의 경우 다음 정보를 제공합니다.

문제의 증상 설명

문제의 원인이 되는 동작을 설명합니다.쿼리 동작이 안정적인지 아니면 특정 매개 변수 또는 단순 랜덤으로 문제가 발생하는 경우만 발생하는지 여부입니다.이 동작을 IDE(예: SQL Developer)에서 재현할 수 있습니까?

환경 설명

Oracle의 정확한 버전 정의

 select * from v$version

드라이버, ORM, 프로그래밍 언어 등 데이터베이스에 연결하는 방법을 설명합니다.이름 및/또는 버전 번호를 제공합니다.

쿼리 설명

쿼리 텍스트를 게시합니다.단순화를 시도합니다. 최소한의 재현 가능한 예제를 보여줍니다.

예 - 문제가 있는 쿼리는 10개의 테이블에 조인합니다.조인이 9개 또는 8개인 쿼리에 동일한 증상이 있는지 확인합니다.문제가 표시되고 축소된 쿼리만 표시될 때까지 아래로 이동합니다.

예, 이는 비용이 많이 들지만 지원을 받을 가능성을 크게 높입니다.쿼리가 작을수록 지지자를 더 많이 끌어 모읍니다.

실행 계획 설명

실행 계획을 가져오려면 이 문을 실행합니다(쿼리 텍스트 대체).

 EXPLAIN PLAN  SET STATEMENT_ID = '<some_id>' into   plan_table  FOR
     select * from ....   -- your query here 
 ;

실행 계획은 다음에 저장됩니다.PLAN_TABLE이 쿼리를 실행하는 것을 확인합니다.

 SELECT * FROM table(DBMS_XPLAN.DISPLAY('plan_table', '<some_id>','ALL')); 

실행 계획이 있는 테이블뿐만 아니라 전체 결과를 표시합니다.가장 중요한 것은 술어 섹션과 아래의 참고 사항입니다.

예:select * from dual where dummy = :1;

Plan hash value: 272002086

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1 / DUAL@SEL$1

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("DUMMY"=:1)

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - "DUMMY"[VARCHAR2,1]

IDE 설명 계획의 그래픽 결과를 잘라내어 붙여넣지 마십시오.

이 실행 계획이 실제로 실행되는 것입니까?

불행하게도 항상은 아닙니다.설명한 실행 계획이 실제 실행 계획과 다를 수 있는 몇 가지 이유가 있습니다.

(특히 좋은 계획을 보았지만 쿼리가 잘못 실행될 때) 의심스러운 경우 DB 캐시에서 계획을 추출할 수 있습니다.SQL_ID.

 SELECT t.* FROM  table(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>',null,'ALL')) t; 

SQL_텍스트 일치 및/또는 데이터베이스 사용자와 함께 현재 실행 중인(또는 잠시 실행 중이고 여전히 캐시된) 쿼리의 ID를 찾을 수 있습니다.

select sql_id, sql_fulltext from v$sql a where 
 lower(sql_text) like lower('%<some identifying part of the query text>%') 
  and parsing_schema_name = '<user running the query>';

AWR 라이센스가 있으면 기록에서 실행 중인 쿼리에 대한 실행 계획을 얻을 수 있습니다.

SELECT t.*
FROM  table(DBMS_XPLAN.DISPLAY_AWR('10u2rj016s96k'  )) t;

SQL_ID는 다음을 사용하여 찾을 수 있습니다.

select sql_id, sql_text 
from dba_hist_sqltext a 
where lower(sql_text) like lower('%<some identifying part of the query text>%')

데이터 설명

해당 테이블에 있는 테이블 및 인덱스의 DDL을 표시합니다.

된 것을 합니다.dbms_stats진술을 모으다

중요 테이블의 경우 세그먼트 크기, 행 번호, 분할 등에 대한 정보를 제공합니다.

액세스 또는 조인에 사용되는 열은 고유한 값의 수에 대한 정보를 제공합니다.값이 균등하게 분포되어 있는지 또는 치우쳐 있는지(예: 매우 자주 발생하는 소수의 값과 많은 수의 희귀한 값).히스토그램을 정의합니까?

또 다른 건 없으세요?

물론 이것은 기본 사항일 뿐이며 시스템 통계 또는 최적화 도구 매개 변수와 같은 다른 정보가 여전히 필요할 수 있습니다.그러나 다시 한 번 문제를 식별할 수 있는 최소한의 정보를 제공하려고 합니다.요청 시 추가 정보를 게시합니다.

행운을 빕니다.

언급URL : https://stackoverflow.com/questions/34975406/how-to-describe-performance-issue-in-relational-database