오라클 14

SQL 튜닝 - 실행 계획 생성기

개요이번 글에서는 실행 계획 생성기(Plan Generator)에 대해 자세히 다루어보겠다. 옵티마이저의 마지막 구성 요소인 실행 계획 생성기는 다양한 실행 계획을 생성하고, 각 계획의 예상 비용을 계산하여 최적의 실행 계획을 선택하는 역할을 한다. 실행 계획이 어떻게 생성되는지에 대한 개요를 제공하고 주요 개념을 간단한 예제를 통하여 다루어 보겠다.실행 계획 생성기의 역할실행 계획 생성기는 다양한 접근 경로, 조인 방법, 조인 순서를 시도하여 여러 실행 계획을 생성한다. 생성된 각 계획의 비용을 추정기 (Estimator)가 계산한 후, 가장 성능이 좋은 계획을 선택하여 Row Source Generator에 전달한다.실행 계획 생성 방법접근 경로: 접근 경로는 테이블 데이터를 읽는 방법을 나타낸다. ..

DB&SQL 2024.05.29

SQL 튜닝 - 선택성과 카디널리티

개요이번 글에서는 선택성(Selectivity)와 카디널리티에 대해 자세히 알아본다. 선택성은 전체 테이블에서 반환되는 행의 비율이고 카디널리티는 선택되는 행의 수이다. 이는 옵티마이저의 비용 계산 실행 계획 관리 등에서 사용된다.선택성이란?선택성은 쿼리에서 반환되는 행의 비율이다. 테이블의 총 행 수에 대한 비율로 계산된다.SELECT COUNT(*) FROM sales WHERE promo_id = 22; sales 테이블에 약 90만 개의 레코드가 있다고 가정할 때 이 쿼리에서 반환되는 행 수가 약 80만개라고 하면 이 쿼리는 거의 모든 레코드를 반환하므로 선택성이 낮다. 반면에 promo_id를 33으로 변경하여 2000개의 행이 반환될 경우 선택성이 높아진다.선택성은 쿼리에서 반환되는 행 수를 ..

DB&SQL 2024.05.27

SQL 튜닝 - SQL 실행 과정

개요이번 글에서는 SQL 문장을 실행할 때 Oracle 서박 따르는 단계들에 대해 다룬다. 쿼리를 실행하면 Oracle 서버는 문장을 실행하기 전에 몇가지 중요한 단계를 거친다. 각 단계를 짚으며 이해를 해보도록 하겠다. 1. 구문 검사(Syntax Check)쿼리를 실행할 떄 서버가 가장 먼저 하는 일은 쿼리의 구문을 검사하는 일이다. 이 단계에서는 SQL 문장이 구문적으로 올바른지 확인한다. 구문 오류가 있으면 서버는 즉시 오류를 반환하고 실행을 종료한다.2. 의미 검사(Semantic Check)다음 단계는 시멘틱 체크이다. 여기서는 데이터베이스에 테이블이 존재하는지, SELECT * 문을 사용할 때 어떤 컬럼이 있는지 등을 확인한다. 이러한 정보는 데이터 딕셔너리 캐시에 저장되어 있으며 여기에서 ..

DB&SQL 2024.05.22

SQL 튜닝 - 파티셔닝

개요이번 글에서는 데이터베이스 파티셔닝의 중요성과 그 이점에 대해서 다룬다. 파티셔닝은 대규모 테이블의 성능을 향상시키기 위한 효과적인 방법 중 하나이다. 먼저 서버가 테이블 데이터를 어떻게 읽는지 이해한 뒤에 파티셔닝이 어떻게 성능을 향상시키는지 확인해보도록 하겠다.서버가 데이터를 읽는 방법쿼리를 실행할 때 Oracle은 다음과 같은 과정을 거친다.결과 캐시 확인: 쿼리 결과가 결과 캐시에 있는지 확인한다.메모리 확인: 메모리에 쿼리 결과가 있는지 확인한다.실행 계획 생성: 실행 계획을 생성한다. 이 과정에서 공유 SQL 영역에서 유사항 실행 계획을 찾고 없으면 새로운 실행 계획을 생성한다.버퍼 캐시 확인: 버퍼 캐시에 쿼리와 관련된 데이터가 있는지 확인한다.디스크에서 데이터 읽기: 위 단계에서 데이터..

DB&SQL 2024.05.21

SQL 튜닝 - 효과적인 데이터베이스 스키마 설계

개요데이터베이스 스키마를 효과적으로 설계하는 것은 개발자가 성능 튜닝을 시작하는 첫번째 단계이다. 잘못된 스키마 설계는 성능 문제를 일으키며 많은 쿼리를 튜닝해야할 상황을 만들 수 있다. 반면 잘 설계된 스키마는 수백 개의 쿼리를 튜닝하지 않고도 성능을 향상시킬 수 있다. 이 글에서는 좋은 스키마를 만들기 위해 주의해야할 주요 사항과 추가적인 실무 팁을 다룬다.데이터 타입 선택가변 길이 데이터 타입과 고정 길이 데이터 타입테이블을 생성하거나 수정할 때 데이터 타입을 신중하게 선택해야 한다. 특히 가변 길이 데이터 타입과 고정 길이 데이터 타입을 구분하는 것이 중요하다. 예를 들어, VARCHAR2(1000) 타입에 2바이트 데이터를 삽입하면 2바이트만 사용되지만 CHAR(1000) 타입은 항상 1000바..

DB&SQL 2024.05.20

나쁜 SQL이란 무엇인가

개요이번 글에서는 나쁜 SQL이 무엇인지 그리고 이를 발견했을 때 어떤 조치를 취해야하는지에 대해 다룬다. SQL은 다양한 방식으로 작성될 수 있지만 같은 결과를 반환하면서도 성능에는 큰 차이가 날 수 있다. 이때 성능이 저하된 쿼리를 '나쁜 SQL'로 간주한다. 이러한 쿼리는 자원을 비효율적으로 사용하며 전체 시스템 성능을 저하시킨다. 나쁜 SQL 정의나쁜 SQL은 비효율적으로 자원을 사용하는 SQL 문장을 의미한다. 같은 결과를 반환하는 여러 SQL 문장이 있을 수 있지만 이들 중 일부는 성능이 현저히 떨어질 수 있다. 주요 성능 저하 요인은 다음과 같다: 파싱 시간(Parsing Time)입출력(I/O)CPU 시간대기 시간(Wait Time)성능 저하 요인1. 파싱시간쿼리가 실행될 떄 데이터베이스 ..

DB&SQL 2024.05.19

오라클 아키텍처 - 논리 및 물리적 구조

논리 및 물리적 데이터베이스 구조(Logical and Physical Database Structure) 개요데이터베이스 시스템을 효과적으로 관리하고 최적화하기 위해서는 그 내부 구조에 대한 이해가 필수적이다. 오라클 데이터베이스의 논리적 및 물리적 구조를 간략히 살펴보고 각각의 주요 구성 요소들에 대해서 알아본다. 주요 주제는 데이터 블록, 익스텐스, 세그먼트, 테이블스페이스 및 스키마이다. 본론데이터 블록데이터 블록은 데이터베이스에서 가장 작은 단위로 디스크와 메모리에서 데이터를 저장하는 기본 단위이다. Oracle 데이터베이스에서 데이터 블록의 크기는 2킬로바이트에서 32킬로바이트까지 지정할 수 있다. 이는 여러 운영체제 데이터 블록의 조합으로 구성되며 논리적 구조로 간주된다.익스텐스와 세그먼트다..

DB&SQL 2024.05.17

오라클 아키텍처 - 데이터베이스 저장 관리 체계

데이터베이스 저장 관리 체계(Database Storege Architecture) 개요오라클 데이터베이스의 저장 관리 체계에 대하여 전반적인 개념을 소개한다. 오라클 데이터베이스의 '저장소(Storege)는 디스크에 저장된 파일들을 의미하며 메모리는 저장소로 간주되지 않는다. 본론오라클 데이터베이스에는 다양한 유형의 저장 파일이 존재하며 각각의 파일은 데이터베이스 운영에 있어 중요한 역할을 수행한다. 제어 파일(Control File): 제어 파일은 데이터베이스의 물리적 구조정보를 포함하고 있으며 이 파일 없이는 데이터베이스 내 데이터에 접근할 수 없다. 따라서 제어 파일은 데이터베이스 관리에 있어 필수적이다.데이터 파일(Data File): 데이터 파일은 데이터베이스의 실제 데이터를 저장하며 테이블,..

DB&SQL 2024.05.16

오라클 아키텍쳐 - 자동 메모리 관리

개요오라클 데이터베이스의 자동 메모리 관리 기능을 간략히 다룬다. 자동 메모리 관리는 DBA가 다루는 주제이나 비 DBA인 개발자들에게 도움이 될 수 있는 기초적인 지식을 다룬다. 본론자동 메모리 관리는 오라클 데이터베이스의 성능 향상을 위해 중요한 역할을 한다. SQL 코드의 실행 성능은 각 메모리의 영역의 크기에 크게 의존한다. 특정 메모리 영역이 부족할 경우 쿼리의 성능이 저하된다. 이를 효과적으로 관리하기 위해 오라클은 자동 메모리 관리 기능을 지니고 있다. 이 기능은 오라클 전체 메모리 관리에 관여를 하여 SGA와 PGA, PGA들 강의 메모리 배분 등을 자동으로 조절한다. 자동 메모리 관리가 도입되기 전에는 DBA가 각각의 메모리 크기를 수동으로 설정해야 했으나 자동 메모리 관리 기능이 최적화..

DB&SQL 2024.05.15

오라클 아키텍처 - DML 실행 프로세스

DML 실행 프로세스 개요DML 실행 프로세스는 Shared Pool에 데이터가 있는지 체크한 뒤 Buffer Chache와 Undo Segments를 체크하여 요청 관련 블록을 카피 변경 잠금하는 과정을 거친다. 이후 커밋이 이루어질 경우 Redo Log를 기록하고 디스크에 변경 사항을 반영하는 과정을 거친다. Shared Pool Check우선 서버는 라이브러리 캐시 내에 유사 SQL 문장이 있는지 검사한다. 이미 존재한다면 같은 쿼리를 파싱할 필요가 없기에 비용을 아낄 수 있다. 다음으로 데이터 딕셔너리 캐시를 확인한다. 관련 테이블 정보가 있다면 관련 테이블의 권한이나 정의를 가져올 비용을 아낄 수 있다. 두 캐시에 관련 데이터가 없을 경우 디스크에서 데이터를 읽어들여 캐시 영역에 쓴다. Buff..

DB&SQL 2024.05.14