| 1.튜닝의 순서 가.튜닝 단계 1)설계 튜닝 2)어플리케이션 튜닝 3)메모리 튜닝 4)IO 튜닝 5)경합 튜닝 6)운영체체 튜닝 나.핵심 튜닝 이슈 1)훌륭한 초기설계 2)역할을 분명하게 정의 3)어플리케이션 튜닝 수행 4)수치로 표현할 수 있는 목표 설정 2.오라클 트레이스(추적) 파일.얼러트(경고) 파일 가.백그라운드 프로세스 추적파일 제어 1)오라클 서버는 백그라운드 프로세스에 의하여 탐지된 오류에 관한 정보를 추적 파일에 모아 놓는다 2)Oracle Support는 이들 추적 파일을 이용하여 문제를 진단하고 해결. 3)사용자 SQL문 추적한다. 나.오라클 대기 이벤트 1)대기 이벤트를 수집하여 여러 이유로 기다려야 하는 세션에 대하여 정보를 얻을 수 있다. 2)통계 이벤트 뷰 가)모든 세션에 대한 이벤트 총대기(V$System_Event) 나)기다려야 했던 각 세션에 대한 이벤트 대기(V$Session_Event) 다)대기중에 있는 현활동 세션에 대한 이벤트 대기 (V$Session_Wait) 다.진단 정보 1)추적 파일 가)경고 로그 파일 나)백그라운드 프로세스 추적 파일 다)사용자 추적 파일 2)이벤트 가)오라클 대기 이벤트 나)OEM 이벤트 라.얼러트(경고)로그 파일 1)경고 로그 파일은 시간 순으로 생성된 메시지와 오류 로그로 구성되어 있다. 2)경고 로그 파일을 정기적으로 검사 가)내부오류(ORA-600) 및 블록 파손 오류 탐지 나)데이터베이스 작업 감시 다)비 디폴트 초기화 파라미터 조회 3)정기적 점검 후 삭제 및 정리 마.백그라운드 프로세스 추적(Trace) 파일 제어 1)오라클 서버는 백그라운드 프로세스에 의하여 탐지된 오류에 관한 정보를 추적파일에 모아 놓는다. 2)ORacle Support는 이들 추적 파일을 사용하여 문제 진단 및 해결 바.사용자 추적(Trace) 파일 1)서버 프로세스 추적은 다음에 의하여 세션 레벨이나 인스턴스 레벨에서 활성화 또는 비활성화 된다. 가)Alter Session 명령어 나)Set_SQL_TRACE_IN_SESSION 프로시저 다)초기화 파라미터 SQL_TRACE 2)사용자 추적 파일은 다음의 내용을 포함 가)세션에 대해 추적된 SQL문에 관한 통계 3)사용자 추적 파일은 SQL 튜닝에 유용 4)오라클은 서버 프로세스 마다 사용자 추적 파일 생성 바.오라클 대기 이벤트 1)대기 이벤트를 수집하여 여러 이유로 기다려야 하는 세션에 관한 정보 습득 가)V$EVENT_NAME view: -event# -name -parameter1 -parameter2 -parameter3 3.라이브러리 캐쉬 튜닝 가.라이브러리 캐쉬 1)사용자가 공유하는 SQL문과 PL/SQL 블록을 저장하는 사용 2)LRU(최근 최저사용빈도) 알고리즘에 의하여 관리 3)사용자가 이미 캐쉬에 존재하는 문장을 실행 시킬 경우, 오라클 서버는 문장의 구문을 재분석 하지 않고 캐쉬에 저장된 버전을 사용함. 4)문장이 이미 캐쉬에 저장되어 있는가를 찾기 위해 오라클 서버는 다음 수행 가)ASCII 텍스트의 수치고 문장을 줄임 나)이 수치에 해시 함수 사용 나.라이브러리 캐쉬 튜닝 : 구문 분석을 최소로 유지하여 실패 감소. 1)사용자가 문장을 공유할수 있도록 화인 2)충분한 공간을 할당하여 문장이 오래되어 삭제되지 않도록 예방 3)무효가 되어 구문을 재분석 하지 않도록 예방 다.다음을 통하여 단편화를 피함 1)대용량의 메모리 요구에 대해 공간예약 2)빈번하게 요구되는 큰 객체 고정 3)익명의 큰 PL/SQL 블록 제거 4)MTS 연결의 UGA 소모 감소 라.라이브러리 튜닝을 위한 진단 툴들 1)뷰의 설명 2)V$SGASTST : 모든 SGA 구조의 크기 3)V$LibraryCache : 라이브러리 캐쉬 관리에 관한 통계 4)V$SQLAREA : 모든 공유 커서에 대한 전체 통계와 SQL 문의 처음 1000개의 문자 5)V$SQLTEXT : 자르지 않은 전체 SQL 텍스트, 복수 행으로 표시 6)V$DB_OBJECT_CACHE : 패키지 등 캐쉬에 저장된 데이터베이스 객체; 또한 SQL 문에서 참조는 테이블 또는 동의어 와 같은 객체 마.V$LibraryCache 뷰를 통해 커서가 공유되고 있는가 확인 GETHITratio는 비율이 90대 후반의 값이어야 함. 그렇지 않을 경우 애플리케이션 코드의 효율성을 향상시켜야 함. 바.라이브러리 캐쉬 재로드 1)V$LibraryCache 뷰 : 이뷰는 이미 구문분석이 된 문장들이 캐쉬에서 오래되어 삭제되었는지의 여부를 표시 2)RELOADS 수는 PINS 수의 1%를 넘어서는 안됨 사.라이브러리 캐쉬 크기 조정 1)내장 객체(패키지,뷰 등)에 필요한 글로벌 공간 정의 2)일반적인 SQL문에 의해 사용되는 메모리 양 정의 3)캐쉬 실패와 단편화를 피하기 위하여 대용량 메모리 요구에 대해 공간 예약 4)자주 사용되는 객체 보관 5)익명의 큰 PL 블록을 패키지된 함수를 호출하는 익명의 작은 블록으로 전환 아.대용량 메모리 요구 1)대용량의 연속 메모리 요구 요청 만족 2)공유 풀 내에 단편화 가능성이 없는 메모리 예약 4.버퍼 캐쉬 튜닝 가.튜닝 목표 -물리적 I/O 작업은 많은 시간을 소요하고 CPU 요구를 증가시키기 때문에, 서버가 필요로 하는 대부분의 블록을 메모리에서 찾게 될 때 오라클 성능이 향상될 수 있습니다. 데이터베이스 버퍼 캐쉬를 측정하는 통계는 캐쉬 적중율입니다. 이 통계는 메모리에서 발견되는 블록의 수 대 액세스된 블록의 수의 비율입니다. 데이터베이스 버퍼 캐쉬가 너무 작을 때, 시스템은 너무 많은 I/O 작업을 수행하기 때문에 더 느려집니다. 나.버퍼 캐쉬는 I/O 성능에 결정적 다.주요 튜닝 목표는 캐쉬 적용율 90% 라.필요한대로 DB_BLOCK_BUFFER를 조정 마.객체들을 복수 버퍼 풀에 분리 바.테이블을 캐쉬 5.리두로그 버퍼 튜닝 가.목적 1)프로세스가 리두로그 버퍼의 공간을 기다리고 ㅇ있는지의 여부 결정 2)리두로그 버퍼의 크기 적절하게 조정 3)리두 작업 감소 나.리두로그 버퍼 크기 조정 1)LOG_BUFFER 파라미터 2)디폴트값 : 특정 OS에 따라 다름, 일반적으로 4* 최대 블록 크기 3)특히 트랜잭션이 길거나 많을 경우, 값이 클수록 로그 파일 I/O가 감소 4)빈번한 COMMIT 문은 버퍼를 비우게 되어, 버퍼 크기가 더 작게 됩니다. 다.NOLOGGING 사용하여 리두 작업 감소 1)테이블, 파티션, 테이블스페이스, 인덱스에 적용 2)리두 로그 버퍼에 있는 데이터에 대한 변경내역을 기록하지 않습니다 3)INSERT 문 레벨에서 속성으로 지정되어 있지 않지만, 테이블, 파티션, 인덱스, 또는 테이블스페이스에 대해 ALTER나 CREATE 명령어를 사용할 때 지정 4)이 모드는 로드 이전에 설정되며 로드가 완료될 때 LOGGING으로 재설정 |
출처:http://blog.naver.com/hwknoc?Redirect=Log&logNo=130006215316
