[ DB 분석 항목 ] 1. PARAMETER 2. SESSION & PROCESS 3. MEMORY 현황 4. SGA 상태 체크 5. PGA 상태체크 6. DATABASE SPACE 분석 7. SQL 프로파일링 8. 하드파싱 추이분석 9. 일별 I/O 추이분석 10. SEGMENT I/O 추이분석 11. METRIC 분석 ( DB Time, Cpu Time, TPS 등 ) 12. TOP 100 ( Time, Buffer 등 ) 13. Undo 14. Redo 15. 계정별 Object 현황 16. Wait Event 체크현장에 나오면 하게 되는 분석 항목!
튜닝 프로젝트 4개월현재 DB AWR RETENTION 기간 2개월, AWR RETENTION 을 4개월로 늘려보자★ 참고 : 프로젝트 남은 기간이 10% 도달할 때 쯤이면 최종 보고서 작성을 해야한다. 보고서 내용에 들어갈 핵심적인 자료들은 반드시 추세(Trend)적인 그래프로 가시성을 확보해야 한다. 이유는 고객들에게 사랑?을 받을수 있기 때문이다. 그러므로 그래프에 필요한 원천 데이터인 AWR 데이터 확보는 필수적이다. 1. AWR 설정 정보 SELECT * FROM DBA_HIST_WR_CONTROL;AWR 설정 정보 조회 결과 2. AWR 설정 변경 : 172800 = 120(일) X 24(시간) X 60(분) exec DBMS_WORKLOAD_REPOSITORY.MODIFY_SN..
1. 동일 Row 변경에 의한 TX Enqueue : http://www.exemwiki.com/?p=1949 : Enqueue는 lock의 종류이다. Oltp 환경에서 자주 볼 수 있는 Tx Enqueue는 A 사용자가 Dml 후, Commit or Rollback을 하지 않은 상태체서, B 사용자가 Dml 작업 시도시 무한대기 하고 있을때 나타난다.이를 해소하기 위해서는 A 사용자의 Dml Transaction을 Commit or Rollback 처리하여, 종료를 시켜야 한다. 운영Db에 이와 같은 상황이 발생이 잦다면, 문제 모듈을 분석하여 최대한 DML후 다른 작업 없이 Commit or Rollback 이 되도록 수정해야 한다.2. Sql 파싱( Hard Parsing & Soft Parsin..
오라클에서 성능수치를 추출하다보면, 데이터 값 단위가 보통 "마이크로초", "밀리초", "센티초" 나타냄을 알 수 있다. 1 마이크로초 = 1/1,000,000 초 = μs = 1 microsecond1 밀리초 = 1/1,000 초 = ms = 1 millisecond1 센티초 = 1/100 초 = cs = 1 centisecond 즉, 오라클에서 위 단위로 데이터가 있으면 단위에 맞게 나누기하면 "초" 단위로 조회된다. [ 예시 ] SELECT ELAPSED_TIME , ELAPSED_TIME / 1000000 , ELAPSED_TIME / POWER(10,6) , ELAPSED_TIME / 1E6 FROM V$SQL ORDER BY 1 DESC; S..
[ 목차 ] 1. 목표 2. 테스트 계획 3. 실행 결과 분석 3.1. Buffer 관점 3.2 Fetch 중 데이터 변화 추이 관점 3.2.1. 일반 함수 vs Deterministic vs ( Deterministic + 스칼라 서브쿼리 ) 분석 3.2.2 일반 함수 vs Result Cache vs ( Result Cache + 스칼라 서브쿼리 ) 분석 4. 정리 1. 목표 : 사용자 함수를 다양한 경우의 수로 Call 하고, 함수 유형 및 호출 방법에 따른 우선 순위 및 결과 분석을 하고자 함 ※ 호출 방법 경우의 수 : Result Cache는 미리 Input/Ouput값을 캐싱 한 후에 실행 함 함수 유형에 따른 운영 관리 촛점을 두면 매우 길어지므로 위 목표에 한해 이해하고자 함..
Literal SQL을 검색한다는 것은 논리상 동일한 SQL임에도 불구하고 지속적으로 Hard Parsing 을 발생키시는 SQL을 찾는것이다. 보통 Literal Sql을 찾을때는 아래 쿼리를 사용한다. select *from ( select parsing_schema_name, sql_id, sql_text, executions , sum(executions) over (partition by force_matching_signature ) executions_sum , row_number() over (partition by force_matching_signature order by sql_id desc) rnum , count(*) over (partition ..
WHERE LIKE '%'|| :1 || '%' 양 퍼센트 성능 개선을 위한 방법을 알아보자 [ 문제 ] 개발자들은 Like :1 ||'%' 쓰기도하나, 습관 또는 어플리케이션에 적용해도 업무 데이터에 문제가 없다는 이유로 LIKE '%' || :1 || '%' 두기도 한다. 그래서 다양한 방법으로 Like 양 '%' 를 테스트하여 성능 개선이 되는지 테스트 하려고 한다. 우선 최적의 솔루션인 =, 앞 '%' 제거하는 2가지의 결과는 생략한다. 불가피하게 '%' || :1 || '%' 를 쓸 수 밖에 없는 상태에서 어떻게 해야할까? 고민의 흔적이다. [ Test 테이블 ] 1 .테이블명 : TB_EMP_BIG2 / 1,000,000 건 / 61,440 Block / 480 MB 2. 인..
[ 1 ] 문제 공공 차세대 프로젝트에 DB 튜너로 투입되었습니다. OZ Report에서 질의하는 SQL이 Literal Sql로써, Hard Parsing 처리 되는 문제점을 확인 하였습니다. 즉, SQL 질의하면 매번 많은 "실행계획 생성 > Cost 평가 > 그 중 가장 낮은 실행계획 선택 > 소스 생성 " > SQL 실행 됩니다.DB CPU 사용률, SQL Parsing Time 증가 되는 현상이 발생되며, Report 사용이 많을 수록 그 현상은 뚜렷해집니다. [ 2 ] 해결 방법 - ODI 파일 > 데이터 셋(마다) 속성 > "컴파일된 질의문 사용" > True 변경[ 3 ] 검증 1. "컴파일된 질의문 사용" > FALSE > 2번 질의 > DB SQL 조회 : SQL Curs..
배치 튜닝시 DBMS_SQLTUNE 패키지로 실시간 SQL 모니터링하여 "실행 계획 및 데이터 분배 점검"을 한다. select dbms_sqltune.report_sql_monitor(sql_id=>'6f4131zagk5rg') from dual; 그런데 패키지 이용시 "SQL Monitoring Report" 문구만 출력되는 경우가 있다. 이때 아래 1가지 설정 변경 후 해결이 되었다. 1. _sqlmon_max_planlines Parameter 수치 변경 : Parmeter 의미는 실시간 SQL 모니터링 될 수 있는 SQL의 "실행 계획 라인"의 최대 개수이다. 오라클 디폴트 값 300.개인 경험으로는 금융권 배치 튜닝시 실행 플랜이 대부분 300 라인수를 넘어서 v$sql_monitor..