잃어버린 시간을 찾는 개발자

개요이번 글에서는 SQL 튜닝의 기본 원칙과 전략에 대해서 다루어본다. SQL 실행 계획의 생성 과정과 서능 튜닝의 중요성에 대해서 배우고 문제를 식별하고 해결하는 단계별 절차를 통해 성능을 최적화하는 방법을 배운다.문제 식별SQL 쿼리에서 문제가 발생하면 첫 번쨰로 해야 할 일은 문제를 식별하는 것이다. 네트워크나 CPU와 같은 외부 요인으로 인해 같은 외부 요인으로 인해 발생할 수 있으므로 문제의 정확한 원인을 파악하는 것이 중요하다. 문제가 쿼리나 데이터베이스 내부에 있는지 확인한 후 세부 사항을 명확히 해야한다.데이터 수집성능이 저하된 쿼리에 대한 데이터를 수집한다. SQL 성능 분석기, SQL 추적 도구, TKPROF, 운영 체제 보고서, 클라이언트 보고서 AWR 보고서 등 다양한 도구를 사용할..

개요이번 글에서는 로우 소스 생성기(Row Source Generator)에 대해 다루어보겠다. 로우 소스 생성기는 실행 계획 생성기의 다음 단계로 볼 수 있다. 실행 계획 생성기가 최적의 계획을 생성하면 이를 로우 소스 생성기에 전달하여 실제로 데이터베이스에서 실행 가능한 반복적 실행 계획을 생성한다. 이를 통해 쿼리가 최적의 성능으로 실행된다.로우 소스 생성기로우 소스 생성기는 실행 계획 생성기로부터 최적의 실행계획을 받아 이를 기반으로 실행 가능한 단계별 계획을 생성한다. 각 단계에서 생성된 행 집합(row set)을 다음 단계로 전달하며, 최종적으로 반복적 실행 계획(iterative execution plan)을 만든다.Row Source란 무엇인가?로우 소스는 행 집합을 가져오는 영역을 의미한..

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

개요이번 글에서는 쿼리의 비용에 대해 다루어본다. 기본적인 비용 개념은 전반적으로 이해가능한 부분이고 따라서 이전 글들에서도 가볍게 다루었지만 비용이 어떻게 계산되는지 그리고 비용이 무엇을 의미하는지 깊이 있게 다루어보지는 않았다. 이를 이햄함으로써 성능 튜닝을 이해하는 데에도 더욱 도움이 될 수 있을 것이다.쿼리 비용이란비용은 옵티마이저가 SQL 문을 실행하기 위해 예상되는 I/O 작업의 수이다. 비용 단위는 단일 블록을 읽는 작업을 의미한다. 예를 들어 실행 계획의 비용이 1,000이라면, 해당 쿼리를 실행하기 위해 1000개의 단일 블록을 읽어야 한다는 의미이다. 하지만 이는 단순한 추정치에 불과하다.비용 계산 방법비용은 디스크 I/O, CPU 사용량, 메모리 사용량을 종합하여 계산된다. 비용 계산..

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

개요이번 글에서는 Query Transformer에 대해서 알아보겠다. 이전 글에서 쿼리 최적화의 첫 번째 단계가 쿼리 변환이라는 것을 다루었따. 같은 결과를 반환하는 여러 쿼리가 있을 수 있지만 우리가 작성한 쿼리가 항상 최적의 것은 아니다. 쿼리 변환을 통해 오라클은 성능을 향상시키는 방향으로 쿼리를 변환하려고 시도한다. 물론 이는 쿼리의 의미를 변경하지는 않는다.쿼리 변환의 필요성우리가 작성한 쿼리가 항상 최적의 실행 계획을 가지고 있는 것은 아니다. 쿼리 변환기를 사용하여 오라클은 동일한 결과를 반환하지만 성능이 더 나은 쿼리로 변환한다. 하지만 이는 항상 적용되는 것은 아니며 원본 쿼리가 더 나은 경우 변환되지 않는다.쿼리 변환 방법오라클은 쿼리 성능을 향상시키기 위해 몇 가지 변환 방법을 사용..

개요이번 글에서는 옵티마이저의 필요성에 대해서 알아본다. SQL 튜닝에선 옵티마이저를 잘 이해하는 것이 중요하다. 이는 우리의 쿼리가 어떻게 실행되는지를 옵티마이저가 결정하며 옵티마이저가 잘못된 실행 계획을 생성할 때 성능이 저하된 쿼리를 얻게 될 수도 있기 때문이다. 따라서 우리는 옵티마이저가 더 나은 실행계획을 생성할 수 있도록 이해해야 한다. 옵티마이저의 필요성데이터 볼륨의 증가기술 발전에 따라 데이터베이스의 데이터 볼륨이 빠르게 증가하고 있다. 완벽하게 빠른 데이터베이스 서버가 있다고 해도 서버가 효율적으로 쿼리를 실행하지 않으면 우리에게 충분히 서비스를 제공할 수 없다. 또한 하드웨어 비용을 줄이기 위해 추가 서버를 구매하는 대신 쿼리 실행을 최적화 하는 것이 중요하다. 오라클은 옵티마이저라는 ..

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

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

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