<11/10> Pathétique

varchar2 4000 위에서 아래? 아래에서 위?

set long 1000000

regexp_like 정규표현식 

orcl@SYS> exec dbms_workload_repository.create_snapshot();

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.12

수동 스냅샷

version count cursor의 새끼?

스칼라 서브쿼리는 메모리에 올려서 쓸 수 있다

query execution cache

hidden parameter = 128k

alter system set "_queryexecution_cache_max_size" = 2097152

SGA가 작으면 리소스에 대한 경합이 커지고 I/O CPU 사용량이 증가

ssd? flash cache?

db던 어플리케이션이던 누굴 만나던 분석이 먼저다

업무 프로세스의 최적화

비 효율적 프로세스를 개선

시스템의 구조

트랜잭션의 처리량 안정성 유지 보수성 등을 고려한 구조로 결정

용량 산정(H/W Spec)

확장성까지 고려를 통한 예상치 산정

인덱스를 타는 내부적인 방법도 많다

인덱스의 정책

인덱스 선정 정책

인덱스 튜닝 정책

하지만 둘은 같다 

가장 먼저 고려해야 할 것은 테이블이다

index tuning(선정) 절차

Table Architecture 검토 : 해당 업무에 적합한 Table 구조 인지 확인

기존 Index 확인 : 어떤 Index가 존재하는지, 결합 index 순서는 어떤지...

개괄적인 index 분석 : index 개수, 결합 index 순서에 따른 처리 범위 예상

Access Path 검토 : Access path 수집, 분류, 분석 Access Advisor

비효율적인 index 제거 및 변경 : DML 성능을 고려한 불필요한 index 확인 및 조정

Index tuning 검증 및 Test : index tuning이 수행된 SQL에 대한 검증 및 test

네트워크 트래픽이 급증한다? 리스너 체크? 하나더 늘리다

리스너에 들어오는 패킷 사이즈도 제어가 가능하다 SDU

Sesson Data Unit 2k~ 32K 까지 가능

한번에 많이 들어와서 처리하는게 중요할 경우? SDU 사이즈 증가

정규화는 공간 사용량을 줄이게 된다 다만 join을 꼭 해야 한다

그리하여 역 정규화도 고려하는것이다.

일반적 튜닝 시나리오

look at wait events 1000개가 넘는

latch의 종류는 200개가 있다 

어떤 래치의 종류냐? shard pool과 library cache latch 갑자기 parsing?

v$sysstat통해 조회해보니 parse time elapsed > parse time CPU and hard parses

V$SQL을 통해 hard parse를 만드는 sql을 찾는다

table objects 진단 후 review SQL

literals duplicate SQL 중복 SQL 발견됨

커서 공유가 되지 않고 있었다 즉 hard parsing 발생

임시로 Cursor_sharing force 처방을 한다

방법론 절차 체계적 흐름을 이해해야 한다.