안녕? 나야 :)

#) 새로 샘플 테이블 생성. (nologging 조건으로 생성) create table hr.emp nologging as select * from hr.employees; create table hr.dept nologging as select * from hr.departments; create table hr.loc nologging as select * from hr.locations; #) 프로시저 생성 exec dbms_stats.gather_table_stats('hr', 'emp'); exec dbms_stats.gather_table_stats('hr', 'dept'); exec dbms_stats.gather_table_stats('hr', 'loc'); #) 생성 확인 select ..

■ sort operation select /*+ gather_plan_statistics */ * from employees order by salary desc; select * from table(dbms_xplan.display_cursor(null, null, 'allstats last')); select /*+ gather_plan_statistics */ department_id, sum(salary) from employees group by department_id; select * from table(dbms_xplan.display_cursor(null, null, 'allstats last')); → HASH GROUP BY : 정렬 되지 않음. select /*+ gather_pl..

■ batch i/o - inner 쪽 인덱스와 조인하면서 중간 결과 집할을 만든 후에 inner 쪽 테이블과 일괄 (batch) 처리한다. - 힌트: nlj_batching(일괄 처리), no_nlj_batching(일괄처리 X) #) d.location_id = 2500 의 건수 | d.location_id에 index 확인 SELECT /*+ gather_plan_statistics leading(d, e) use_nl(e) */ e.last_name, e.first_name, e.salary, e.job_id, d.department_name FROM departments d, employees e WHERE e.department_id = d.department_id AND d.location_..

■ PGA - SQL 수행 도중 데이터 정렬이 필요할 떄 오라클은 PGA 메모리에 sort area 를 할당하며 완료여부에 따라 두 가지 유형으로 수행된다. 1) 메모리 소트(in memory sort): 전체 데이터의 정렬 작업을 메모리 내에서 완료. internal sort 2) 디스크 소트 (to dist sort): 할당받은 sort area 내에서 정렬을 완료하지 못해 디스크 공간까지 사용. external sort #) sort area 내에서 데이터 정렬을 마무리 하는 것이 최적이나(optimal), 양이 많을 때는 정렬된 중간 결과 집합(sort run이라고도 한다)을 temporary tablesapce의 temp segment 에 임시 저장한다. #1) optimal sort: sort..

■ B-Tree 구조 인덱스 1. 정의 - 우리가 자주 사용하는 index의 일반적인 형태 (root-branch-leaf) - Balanced tree 의 약자 - Binary tree 의 약자 - 즉, Balanced binary Search Tree 구조이다. (균형 이진 탐색 트리) - 테이블이 크고 대부분의 쿼리가 테이블에서 2~4% 미만의 행을 검색할 때 유용하다. 2. B-Tree 생성기준 1) where 조건절에 자주 사용되는 컬럼 2) 유일키값으로 구성되어 있는 컬럼 3) 열의 null값은 제외하고 인덱스 생성해야 함 (null은 스캔 안함) 4) order by 절에 자주 사용되는 컬럼 - 인덱스가 생성될 때 정렬되어서 생성되기 때문에 min, max 함수를 사용할때 cost가 적다 ■..

■ ROW chaining 1) 정의: 한 블록에 저장할 수 있는 한 행의 크기가 블록 크기를 초과하여 해당 행이 여러 블록에 걸쳐 저장되는 현상. 2) 원인: 모델링 오류 또는 블록 크기를 작게 설정한 경우. 3) 문제점: 성능 저하 및 i/o 비용 증가. 4) 해결 방법: 모델링을 재고, 블록 크기를 조절하여 적절한 크기로 설정. # 테이블 row, block, 평균 바이트값 조회 select num_rows, blocks, avg_row_len from dba_tables where owner='HR' and table_name='EMP'; -- num_rows : row의 수 -- blocks : block의 수 -- avg_row_len : 한 행에 평균 바이트값 (체인화를 예방하기위해 확인해볼..

■ CLUSTERING FACTOR 1) 정의: 특정 컬럼을 기준으로 한 인덱스의 클러스터링 정도를 나타내는 지표. 서로 다른 행들의 데이터가 같은 블록에 모여 있는 정도를 나타난다. 2) 좋은 CLUSTERING_FACTO - 해당 컬럼에 인덱스를 사용할 때 I/O를 최소화할 수 있다. Range Scan 등의 작업에서 성능 향상이 기대됨. (해당 컬럼에 대한 인덱스를 사용할 때 성능이 향상되는 효과를 기대할 수 있다.) - Buffer Pinning이 수행되기 때문에 Latch를 점유하는 시간이 감소할 수 있다. 따라서 블록에 대한 접근이 더 효율적으로 이루어질 수 있다. 3) 예시 상황 - 파티션 분리: 데이터가 특정 범위 또는 순서에 따라 파티션으로 나뉘어 있거나, ORDER BY에서 사용되는 정..

#) 한번에 읽을 수 있는 블록의 개수 확인 show parameter db_file_multiblock_read_count - direct path read: 병렬처리할 경우 발생하는 대기 이벤트, 22 번 올렸다. ■ Serial direct read 1. full scan 및 multi block i/o : 데이터베이스에서 전체 테이블 또는 인덱스를 스캔할 때, 여러 블록을 한 번에 읽는 Multi Block I/O가 발생. 2. Data buffer cache 부담 : 데이터 버퍼 캐시에 부하 가능성 3. Latch: cache buffers lru chain 이벤트 : 데이터 파일의 블록을 메모리로 읽어올 때 `cache buffers lru chain` 이벤트에 따른 Latch를 사용 4. L..

■ v$sql_plan library cache(shared pool) 에 있는 실행계획을 표시. select s.prev_sql_id, s.prev_child_number, v.sql_text from v$session s, v$sql v where s.prev_sql_id = v.sql_id and s.prev_child_number = v.child_number and s.username = 'HR'; #) 실제 실행계획 select * from table(dbms_xplan.display_cursor('2sgjc8u8ha0m4', 0, 'typical')); #) 바로 직전의 SQL문장 실행계획을 보여준다. select * from hr.employees where employee_id = 110..

■ autotrace 1) 정의 - SQL*PLUS나 SQL DEVELOPER 등에서 사용할 수 있는 도구로, SQL문 실행 후 실행계획, 실행 결과, 그리고 실행 통계 정보를 출력하는 기능. 2) 사용 가능 도구 - SQL*PLUS, SQL DEVELOPER 가능 3) 사용 방법 - SQL*PLUS나 SQL DEVELOPER에서 `AUTOTRACE`를 활성화하여 SQL문을 실행하면 실행계획, 실행 결과, 통계 정보를 자동으로 출력함. - 특정 세션에 대한 실행 통계 정보를 확인하기 위해서는 `PLAN_TABLE`이라는 테이블이 필요하며, `PLUSTRACE` 롤(role)에 접근 권한이 있어야 함. 4) 장점 - SQL문의 성능을 빠르게 분석하고 최적화할 수 있는 편리한 도구. - 실행계획, 결과, 통..