SQL Trace 및 TKPROF 사용 시작

 
SQL*Trace(10046 이벤트와 동일)는 하나의 Trace 통계 보고서를 작성하는 방법으로 SQL을 사용한다Trace 우리는session 시기의 실행 시기의 통계를 trc 파일에 생성할 수 있습니다. tkprof를 통해 우리는 이 trc 파일을 리포트 형식의 출력으로 포맷해서 이 리포트를 쉽게 볼 수 있습니다. SQL Trace는 문제가 있는 sql 문장을 추적할 수 있고 일부 오류도 추적할 수 있습니다.
다음은 두 가지 예를 들어 그의 용법을 말하겠다
예 1, drop user 문제를 해결합니다.
한 번에 em를 사용하는 과정에서, 나의 잘못된 판단으로 인해repository가drop을 할 수 없습니다.
emca-deconfig dbcontrol db-repos drop을 실행하는 데 실패했습니다.
관련 log 파일 확인을 켜면 drop user MGMT 가 표시됩니다.VIEW cascade라는 문구가 실행될 때 오류가 발생했습니다.
아래와 같이 잘못 보고하다.ORA - 00604 :  error occurred at recursive SQL level 1
ORA - 00942 :  table  or  view does not exist  .
여기에 Recursive sql가 나타나면 이 sql가 실행할 때 다른 문장도 실행했음을 나타냅니다.
이 경우 sqltrace를 사용하면 sql가 실행되는 것을 볼 수 있습니다.
명령 alter session set SQL 사용TRACE=true로 스위치를 켤 수 있습니다.Alter system set SQLTRACE=true 이것은 모든 세션에 유효하므로 성능에 영향을 미칩니다.DBMSSession.set_sql_trace(true) 또는 DBMSSYSTEM.set_sql_trace_in_session(123, 1103, true);
그리고 모니터링이 필요한 문구를 실행하세요.
drop user MGMT_VIEW cascade;
sql 실행이 끝나면,
실행
alter session set SQL_TRACE=false
감시를 정지하다.
명령 실행
tkprof  ora9i_ora_140.trc drop-analysis
보고서 보기
이drop을 다시 실행할 때oracle에서 데이터 사전의 데이터를 업데이트합니다.그 중 하나는 관련 테이블이 없어서 오류가 발생했습니다. 원인을 알았습니다. 메타링크에서 관련 테이블의 정보를 찾아서 문제를 해결하는 방법을 찾았습니다.
예2.sql에 대한 모니터링
이상의 방법을 사용하다
다른 것은 tkprof XXXXXXXXX explain=user/pwd, 실행 계획 사용
리포트를 받아서 수상한 점을 찾았어요.
select recordstatus,categoryid,rcordlevel from record_detail a,category b where b.id=a.categoryid and id= 20030700400141 and recordstatus>0
call count cpu elapsed disk query current rows
call     count       cpu    elapsed       disk      query    current        rows
——- ——  ——– ———- ———- ———- ———-  ———-
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.70       0.69          0     225814          0           5
——- ——  ——– ———- ———- ———- ———-  ———-
total        3      0.70       0.69          0     225814          0        ********************************************************************************
이 수상한 225814가 의심스럽습니다.id로 읽는 건데 이렇게 높은query가 있어요.
비슷한 경험이 있는 사용자는 어떻게 된 일인지 알 수 있을 거예요.
계속 내려다보래요.
 
Rows     Row Source Operation
……….
 
이제 진실이 밝혀졌어요.
Misses in library cache during
parse: 1
Optimizer goal: CHOOSE
Parsing user id: 41
Rows Row Source Operation
——- —————————————————
0 ‘TABLE ACCESS FULL  RECORD_DETAIL’
1 INDEX RANGE SCAN (object id 3080) ********************************************************************************
여기에 전체 시계 스캐닝이 하나 있다
이어서 분석표의 구조와 index를 분석합니다.
SQL> select index_name,table_name,column_name from user_ind_columns 2 where table_name=upper(’record_detail’);
INDEX_NAME TABLE_NAME COLUMN_NAME
—————————— —————————— ——————–
IDX_RECORDID RECORD_DETAIL ID
SQL>desc record_detail
recorddetail의 id는 index로 만들어졌지만 표 구조에 따르면 id는varchar2 필드이고 문자형의 필드이며 조회할 때number 형식을 사용합니다. Oracle에서 잠재적인 데이터 형식 변환이 발생하면 Oracle에 대한 효과적인 index 사용은 값을 바꿀 수 없습니다. 여기서도 index를 효력을 상실합니다.
검색에 '' 를 더하면 문제가 해결된다.
수정 후, sqltrace 검사에서query는 10으로 낮아졌고, 비교해 보면 너무 멀었다.
물론 이런 문제들은 다른 방법을 통해 분석할 수 있지만 여기서 이러한 간단한 예를 통해 우리는 sqltrace에 대해 기본적으로 이해할 수 있을 뿐이다.
SQL trace는 성능 모니터링과 문제 조사가 상당히 실용적인 도구이자 사용에 있어 매우 깊이 있는 도구이다. 능숙하게 활용하려면 우리는 대량의 실례적인 학습과 끊임없는 정리를 통해 힘을 발휘할 수 있다.
 
4

만약 그'서른에 서라'는 말이 없다면 서른 살의 남자는 가볍게 느슨해질 수 있다.
4

전문 포럼http://www.inthirties.com

4

기술 블로그http://blog.csdn.net/inthirties

4

개인 사이트http://blog.inthirties.com

4

Oracle Mysql 기술 포럼 | 실용적인 Oracle Mysql 기술 교류 마당 만들기