뷰는 쿼라 문장을 담고 있는 가상의 테이블이므로 물리적인 저장 공간을 필요로 하지 않는다. 뷰를 조회할 때, 데이터 딕셔너리에 미리 저장해 둔 쿼리 문장을 실행함으로써 결과 집합을 반환한다. Redo 로그1) Database Recovery물리적으로 디스크에 결함이 생

DB는 데이터를 메모리 (버퍼 캐시)에서 바꾸고, 나중에 디스크 (데이터 파일)에 반영한다. 그런데 디스크 반영 전에 장애가 발생하면 메모리 변경분이 날아간다. 이걸 복구하려고, 변경 내용을 Redo 로그에 먼저 기록해둔다.데이터 블록을 디스크에 쓰기 전에, 그 변경에

부분범위 처리, 소트 생략 파트 공부하자 문제풀 때 생각할 것들! 집합적 사고! 불필요한 조인 제거! 조인 순서 변경! (큰 테이블 먼저 조인하지 말고 필터된 애들 작은 테이블 고려!) 함수적 종속관계! Index Skip Scan이 작동하기 위한 조건 최선두

쿼리1의 뷰 쿼리 블록은 액세스 쿼리 블록과의 머지 과정을 거쳐 쿼리2와 같은 형태로 변환되는데, 이를 '뷰 Merging'이라고 한다. (힌트: merge, no_merge)조건절과 조인문만을 포함하는 단순 뷰는 no_merge 힌트를 사용하지 않는 한 언제든 Mer

(1) 서브쿼리의 분류 서브쿼리는 하나의 SQL 문장 내에서 괄호로 묶인 별도의 쿼리 블록을 말한다. 인라인 뷰: from 절에 나타나는 서브쿼리 중첩된 서브쿼리: 결과집합을 한정하기 위해 where 절에 사용된 서브쿼리 스칼라 서브쿼리: 한 레코드당 정확히 하나의

비용기반 옵티마이저는 사용자 SQL을 최적화에 유리한 형태로 재작성하는 작업을 먼저 한다. 서브 엔진으로서 Query Transformer가 해당 역할을 담당한다. 즉, 쿼리 변환은 쿼리 옵티마이저가 SQL을 분석해 의미적으로 동일하면서도 더 나은 성능이 기대되는 형태

SQL 최적화 과정옵티마이저가 SQL을 최적화할 때 많은 일을 수행한다. 테이블, 컬럼, 인덱스 구성에 관한 기본 정보오브젝트 통계: 테이블, 인덱스, 컬럼 통계시스템 통계: CPU 속도, Single, Multi Block I/O 속도 등옵티마이저 관련 파라미터 하나

세션 레벨에서 Sort Area 크기를 조정하거나, 시스템 레벨에서 각 세션에 할당될 수 있는 총 크기를 조정해야 할 때가 있다. Sort Area 크기 조정을 통한 튜닝의 핵심은, 디스크 소트가 발생하지 않도록 하는 것을 1차 목표로 삼고 불가피할 때는 Onepass

소트 연산이 불가피하다면 메모리 내에서 처리를 완료할 수 있도록 노력해야 한다. 1번 SQL은 레코드당 60(30+30) 바이트로 가공된 결과치를 Sort Area에 담는다. 반면 2번 SQL은 가공되지 않은 상태로 정렬을 완료하고 나서 최종 출력할 때 가공하므로 1번

인덱스는 항상 키 컬럼 순으로 정렬된 상태를 유지하므로 이를 이용해 소트 오퍼레이션을 생략 할 수 있다. region + custid 순으로 구성된 인덱스를 사용한다면 sort order by 연산을 대체할 수 있다.region이 선두 컬럼인 결합 인덱스나 단일 컬럼

PK 컬럼인 empno를 select-list에 포함하므로 두 집합간에는 중복 가능성이 전혀 없다. 따라서 UNION ALL을 사용해야 한다!distinct를 사용하는 경우도 대부분 exists 서브쿼리로 대체함으로써 소트 연산을 없앨 수 있다. 입력한 과금연월 이전에

(1) Sort Aggregate Sort Aggregate는 전체 로우를 대상으로 집계를 수행할 때 나타나는데, 실제 소트가 발생하지는 않는다. (2) Sort Order By 데이터 정렬을 위해 order by 오퍼레이션을 수행할 때 나타난다. (3) Sort

소트 오퍼레이션은 수행과정에서 CPU와 메모리를 많이 사용하고, 데이터량이 많을 때는 디스크 I/O까지 일으킨다. 많은 서버 리소스를 사용하는 것도 문제지만 부분범위처리를 불가능하게 해 OLTP 환경에서 애플리케이션 성능을 저하시키는 주요인으로 작용하기도 한다. SQL

테이블을 파티셔닝하면 성능 향상 및 경합 분산에 도움이 되고, 백업 및 복구, 대량 데이터 변경 및 삭제 등을 파티션 단위로 빠르게 처리할 수 있어 가용성이 향상된다.but, 여유 공간을 세그먼트 단위로 관리하기 때문에 저장 공간 측면에서는 오히려 효율성이 떨어진다.

파티션 Pruning은 하드파싱이나 실행 시점에 SQL 조건절을 분석하여 읽지 않아도 되는 파티션 세그먼트를 액세스 대상에서 제외시키는 기능이다. 파티션 테이블에 대한 쿼리나 DML을 수행할 때 극적인 성능 개선을 가져다 주는 핵심 원리가 파티션 Pruing에 있다!

파티셔닝은 테이블과 인덱스 데이터를 파티션 단위로 나누어 저장하는 것을 말한다테이블을 파티셔닝하면 하나의 테이블일지라도 파티션 키에 따라 물리적으로는 별도의 세그먼트에 데이터가 저장되며, 인덱스도 마찬가지다. 파티셔닝이 왜 필요한가? 관리적 측면: 파티션 단위 백업,

사용자 정의 함수는 소량의 데이터 조회 시 대용량 데이터를 조회할 때는 부분범위처리가 가능한 상황에서 제한적으로 사용 조인 또는 스칼라 서브쿼리 형태로 변환 어쩔 수 없을 경우 함수를 쓰되 호출 횟수를 최소화 함수 호출 부하 해소 방안 페이지 처리 또는 부분범위처리

PL/SQL은 인터프리터 언어이므로 그것으로 작성한 함수 실행 시 매번 SQL 실행 엔진과 PL/SQL 가상머신 사이에 컨텍스트 스위칭이 일어난다. SQL에서 함수를 호출할 때마다 SQL 실행엔진이 사용하던 레지스터 정보들을 백업했다가 PL/SQL 엔진이 실행을 마치면

05 데이터베이스 Call 최소화 원리 데이터베이스 Call을 커서의 활동상태에 따라 Parse, Execute, Fetch로 나눔 Call이 어디서 발생하느냐에 따라 User call과 Recursive Call로 나눔 Call 통계 User Call vs Re