tb.log

sar 데이터 보관 기간은 sar 명령 자체가 정하는 것이 아니라 sysstat 설정과 수집 주기에 따라 달라집니다.보통 Linux에서는 아래 경로에 저장됩니다./var/log/sa/ 예시: ls -lh /var/log/sa/ 보통 이런 파일이 있습니다. sa01sa02sa03...sa30sar01sar02... saDD는 sar가 읽는 바이너리 성능 데이터 파일이고, sarDD는 일일 리포트 형태의 텍스트 파일입니다. 여기서 DD는 날짜입니다. 예를 들어 sa01은 1일자 데이터입니다.1. sar 데이터는 언제까지 보관되나?보관 기간은 설정 파일에서 확인합니다.RHEL / CentOS / Rocky 계열 cat /etc/sysconfig/sysstat 또는 grep HISTORY /etc/sysconf..

Tibero DBMS_XPLAN 사용 방법DBMS_XPLAN은 Tibero에서 SQL 실행 계획을 확인할 때 사용하는 패키지입니다. 실행 계획을 보면 SQL이 어떤 테이블을 읽는지, 인덱스를 사용하는지, 조인 방식은 무엇인지, 실제 처리 Row 수와 Buffer Get은 어느 정도인지 확인할 수 있습니다.Oracle 예제에서는 보통 EXPLAIN PLAN FOR 후 DBMS_XPLAN.DISPLAY를 사용하는 경우가 많지만, Tibero 실무에서는 DISPLAY_CURSOR를 사용하는 방식이 더 유용합니다. DISPLAY_CURSOR는 실제 수행되어 Physical Plan Cache에 등록된 SQL의 실행 계획을 조회하기 때문입니다.1. 기본 사용 순서ALTER SESSION SET GATHER_SQL..

DB_KEEP_CACHE_SIZE와 BUFFER_POOL KEEP 정리문의의 핵심은 “첫 수행은 6분, 두 번째 수행부터는 10초 이내로 빨라지는 쿼리를 메모리에 고정할 수 있는가?”입니다.결론부터 말하면, DB_KEEP_CACHE_SIZE는 특정 쿼리 결과를 고정하는 기능이 아니라,지정한 Table / Index 블록이 KEEP Buffer Pool을 사용하도록 설정하는 기능입니다.1. 문의내용고객 환경에서는 특정 쿼리를 처음 수행할 때 약 6분 정도 소요되지만, 두 번째 수행부터는 10초 이내로 수행되는 현상이 발생했습니다.이 현상은 보통 첫 수행 시에는 디스크에서 데이터를 많이 읽고, 두 번째 수행부터는 이미 읽은 데이터 블록이 Buffer Cache에 남아 있어 빠르게 조회되는 경우에 나타납니다...

먼저 화면 왼쪽 1번, 도입 배경 및 필요성을 보시면 됩니다. 분석성 쿼리에서는 동일한 집계, 동일한 조인이 반복 수행되는 경우가 매우 많습니다. 동일한 무거운 계산을 매번 처음부터 수행하는 것은 자원 낭비이며, 응답 시간 면에서도 큰 비효율이 발생합니다. Materialized View는 이러한 반복 계산 결과를 사전에 저장해두고, Query Rewrite는 사용자의 SQL을 자동으로 분석해 가능한 경우 그 결과를 활용하도록 SQL을 재작성하는 기능입니다. 사용자는 원본 SQL을 변경하지 않아도, 시스템이 자동으로 빠른 경로를 선택해 성능을 향상시킵니다. 화면 가운데 2번, 동작 구조를 보시면 됩니다. Materialized View는 집계, 조인 등의 결과를 사전 계산해 별도의 객체로 저장합니다. 사..

이번 장에서는 Concurrent DML During Parallel DPI 기능에 대해 설명드리겠습니다. 먼저 화면 왼쪽 1번, 도입 배경 및 필요성입니다. Parallel Direct Path Insert는 대량 데이터를 빠르게 적재하기 위한 방식입니다.일반적인 Insert보다 적재 경로를 단순화하고, 병렬 처리를 활용할 수 있기 때문에 대량 배치나 이력 데이터 적재에 효과적입니다. 하지만 기존 방식에서는 대량 적재 중 대상 테이블에 강한 잠금(배타적 lock) 이 발생할 수 있는데이 경우 같은 테이블에 대해 다른 세션이 수행하는 INSERT, UPDATE, DELETE 작업이 대기하거나 제한될 수 있습니다.즉, 적재 성능은 높지만 그 시간 동안 온라인 업무 트랜잭션이 영향을 받을 수 있는 구조였습니..

이번 장에서는 Parallel Statistics Gathering 기능에 대해 설명드리겠습니다. 먼저 화면 왼쪽 1번, 도입 배경 및 필요성입니다. DB Optimizer는 SQL을 실행할 때 어떤 인덱스를 사용할지,어떤 테이블을 먼저 읽을지, 조인 방식은 무엇으로 할지를 통계 정보를 기준으로 판단합니다. 즉, 통계 정보는 SQL 실행 계획을 결정하는 핵심 기준입니다. 문제는 운영 데이터가 계속 증가하면서 테이블과 파티션의 크기도 함께 커진다는 점입니다! 대용량 테이블에서는 통계 수집 자체가 오래 걸릴 수 있고, 야간 배치 후 통계를 제때 갱신하지 못하면 Optimizer가 오래된 통계를 기준으로 실행 계획을 선택할 수 있습니다. 이 경우 실제 데이터 분포와 실행 계획이 맞지 않아 불필요한 Full ..

이번 장에서는 Parallel Query와 Parallel DML 기능에 대해 설명드리겠습니다. 먼저 화면 왼쪽 1번, 도입 배경 및 필요성입니다.대용량 테이블을 조회하거나 대량 데이터를 변경하는 작업은 단일 프로세스로 처리하면 시간이 오래 걸릴 수 있습니다.특히 통계 조회, 대량 INSERT, UPDATE, DELETE 같은 작업은 많은 CPU와 I/O 자원을 필요로 합니다. 다음으로 화면 가운데 2번, 동작 구조를 보겠습니다.Parallel Query와 Parallel DML은 SQL 작업을 여러 실행 단위로 나누고, 여러 프로세스가 동시에 처리하는 방식입니다.PARALLEL 구문을 통해 병렬도를 지정하면, DB는 대상 데이터를 여러 범위로 나누어 병렬 실행 프로세스가 동시에 처리하도록 합니다. 화면..

이번 장에서는 Basic Table Compression 기능에 대해 설명드리겠습니다. 먼저 화면 왼쪽 1번, 도입 배경 및 필요성입니다.대용량 테이블은 시간이 지날수록 저장 공간을 많이 사용합니다.특히 변경이 많지 않고 조회 위주로 사용되는 테이블은 압축을 통해 저장 효율을 높일 수 있습니다. 다음으로 화면 가운데 2번, 동작 구조를 보겠습니다.Basic Table Compression은 TABLE COMPRESS 구문을 통해 테이블 데이터를 압축 저장하는 방식입니다.테이블 블록 내부에서 반복되는 값을 압축해 같은 블록 안에 더 많은 데이터를 저장할 수 있게 합니다. 화면 하단 3번, 기존 한계와 개선 효과입니다.압축을 적용하지 않으면 대용량 테이블은 많은 데이터 블록을 사용하고, 조회 시 읽어야 할 ..

오늘은 Bitmap Index 계열 기능에 대해 설명드리겠습니다. 먼저 화면 왼쪽 1번, 도입 배경입니다. OLAP나 DW 환경에서는 고객이나 주문 데이터를 여러 기준으로 나눠서 조회하는 경우가 많습니다.예를 들어 성별, 지역, 상태, 상품분류, 연령대 같은 조건입니다.이런 컬럼들은 값의 종류가 많지는 않습니다. 성별은 남성, 여성 정도이고, 상태값도 정상, 해지, 완료, 취소처럼 정해진 값 안에서 반복됩니다.그런데 실제 조회할 때는 조건 하나만 보는 경우보다, 여러 조건을 함께 조합하는 경우가 많습니다.예를 들어 “서울에 사는 여성 고객 중 정상 상태이고, 특정 상품군을 구매한 고객”을 찾는 경우입니다.또는 “수도권 고객 중 판매완료 상태이고, 가전 상품을 구매한 30대 고객”을 찾는 경우도 있습니다...

오늘은 Prefix Compression, 또는 Key Compression 기능에 대해 설명드리겠습니다. 먼저 화면 왼쪽 1번, 도입 배경입니다. 복합 인덱스에서는 앞쪽 컬럼 값이 반복되는 경우가 많습니다. 예를 들어 지역코드 + 고객번호, 부서코드 + 사번 형태의 인덱스에서는 지역코드나 부서코드가 여러 행에서 반복될 수 있습니다. 화면 가운데 2번, 동작 구조를 보시면 됩니다. Prefix Compression은 인덱스 키에서 반복되는 앞부분 값을 한 번만 저장하고, 나머지 키 값만 저장하는 방식으로 공간을 줄입니다. 즉, 인덱스의 중복 접두어를 압축하는 개념입니다. 화면 하단 3번, 기존 한계와 개선 효과입니다. 압축하지 않은 인덱스는 반복 키 값도 매번 저장하므로 인덱스 크기가 커질 수 있습니다...