TIBERO6 인덱스 튜닝 방법 및 인덱스 변경 시 최적화 시간 최소화 방안
1. TIBERO6 인덱싱 개요
1.1. TIBERO6 인덱스 구조의 기초
TIBERO6는 관계형 데이터베이스 시스템에서 데이터 검색 성능을 향상시키기 위해 인덱스를 사용합니다. TIBERO6 인덱스는 B-트리 구조를 기반으로 하며 , 이는 균형 잡힌 트리 형태를 유지하여 검색, 삽입, 삭제 연산의 효율성을 보장합니다. 각 인덱스 항목은 인덱싱된 컬럼의 값과 해당 데이터 행의 물리적 위치를 가리키는 ROWID를 포함합니다. B-트리 구조는 계층적인 특성을 지니므로, 특정 값을 찾는 데 필요한 탐색 깊이가 데이터의 양에 비해 매우 작아 검색 속도가 빠릅니다. ROWID는 인덱스를 통해 특정 데이터 행에 직접 접근할 수 있도록 하는 핵심 요소입니다. 인덱스를 활용한 데이터 접근은 먼저 B-트리에서 ROWID를 찾은 후, 이 ROWID를 이용하여 테이블에서 실제 데이터를 가져오는 두 단계로 이루어집니다. 따라서 효율적인 인덱스 사용은 B-트리 탐색 횟수와 ROWID를 통한 테이블 접근 횟수를 최소화하는 데 중점을 둡니다.
1.2. TIBERO6 인덱스 스캔 방식 및 성능 영향
TIBERO6는 다양한 인덱스 스캔 방식을 지원하며, 각 방식은 쿼리 성능에 서로 다른 영향을 미칩니다. 가장 일반적인 방식은 인덱스 범위 스캔(Index Range Scan)으로, 특정 범위 내의 데이터를 효율적으로 검색하는 데 사용됩니다. 이는 인덱스의 정렬된 특성을 활용하여 검색 범위를 좁히고 필요한 데이터만 읽어 들입니다. 인덱스 전체 스캔(Index Full Scan)은 인덱스의 모든 항목을 순차적으로 읽는 방식으로, 인덱스가 테이블보다 훨씬 작거나 쿼리가 인덱스의 대부분 데이터를 필요로 할 때 고려될 수 있습니다. 인덱스 고유 스캔(Index Unique Scan)은 고유 인덱스를 사용하여 단 하나의 행을 검색할 때 가장 효율적인 방식입니다. 이 외에도 인덱스 건너뛰기 스캔(Index Skip Scan)이 언급되기도 하지만 , TIBERO6에서 해당 기능을 공식적으로 지원하는지 여부는 추가적인 확인이 필요합니다. 옵티마이저는 쿼리의 조건, 인덱스 구조, 데이터 분포 등을 고려하여 가장 적합한 스캔 방식을 선택합니다. 따라서 데이터베이스 관리자는 실행 계획을 분석하여 어떤 스캔 방식이 사용되고 있는지 확인하고, 필요에 따라 인덱스를 재설계하거나 쿼리를 수정하여 보다 효율적인 스캔 방식을 유도할 수 있습니다.
1.3. 옵티마이저의 인덱스 선택 역할
TIBERO6의 옵티마이저는 비용 기반으로 SQL 쿼리의 최적 실행 계획을 결정하며, 인덱스 사용 여부와 방법을 포함합니다. 옵티마이저는 쿼리 실행에 필요한 예상 비용을 다양한 실행 계획에 대해 산정하고, 가장 낮은 비용의 계획을 선택합니다. 이때 데이터 분포 및 특성에 대한 통계 정보가 중요한 역할을 합니다. 옵티마이저는 테이블 및 인덱스의 크기, 컬럼의 고유 값 개수, 데이터 분포 등을 나타내는 통계 정보를 활용하여 인덱스 스캔과 전체 테이블 스캔 중 어떤 방식이 더 효율적인지 판단합니다. 만약 통계 정보가 오래되었거나 정확하지 않으면 옵티마이저가 최적의 선택을 하지 못할 수 있습니다. 따라서 데이터베이스 성능을 유지하기 위해서는 통계 정보를 주기적으로 갱신하는 것이 매우 중요합니다. 또한, 옵티마이저의 결정을 개발자나 관리자가 직접 제어해야 할 필요가 있는 특정 상황에서는 인덱스 힌트를 사용하여 특정 인덱스를 사용하도록 지시할 수도 있습니다.
2. 효과적인 TIBERO6 인덱스 튜닝 방법
2.1. 성능 병목 지점 식별 및 튜닝 대상 SQL 쿼리 선정
TIBERO6 성능 튜닝의 첫 단계는 성능 병목 지점을 식별하고 튜닝할 대상 SQL 쿼리를 선정하는 것입니다. APM(Application Performance Monitoring) 도구를 사용하여 시스템 전반의 성능을 분석하고, 응답 시간이 느리거나 CPU 사용률이 높은 SQL 쿼리를 찾을 수 있습니다. LONGOPS View를 통해 장시간 실행되는 쿼리를 파악하는 것도 중요합니다. 또한, 시스템 사용자로부터 성능 문제에 대한 요청이 있는 경우 해당 쿼리를 튜닝 대상으로 고려해야 합니다. 쿼리 응답 시간이 짧더라도 실행 빈도가 매우 높은 쿼리는 시스템에 상당한 부하를 줄 수 있으므로, 이러한 쿼리도 튜닝 대상에 포함하여 전체 시스템 성능 향상을 도모해야 합니다. 튜닝 대상을 선정할 때는 단순히 개별 쿼리의 성능뿐만 아니라 시스템 전체의 처리량과 응답성을 종합적으로 고려해야 합니다.
2.2. TIBERO6 실행 계획 분석 도구 활용
튜닝 대상으로 선정된 SQL 쿼리에 대해 TIBERO6가 어떤 실행 계획을 수립했는지 분석하는 것은 매우 중요합니다. TIBERO6는 다양한 도구를 제공하여 실행 계획을 확인할 수 있도록 지원합니다. V$SQL_PLAN 뷰를 조회하면 현재 실행 중이거나 캐시에 저장된 쿼리의 실행 계획을 확인할 수 있습니다. TBSQL 프로그램의 AUTOTRACE 기능을 사용하면 쿼리 실행 결과와 함께 실행 계획 및 통계 정보를 쉽게 확인할 수 있습니다. SQLTRACE 기능을 활성화하여 쿼리 실행 과정을 상세하게 추적하고, 생성된 트레이스 파일을 TBPROF 프로그램을 사용하여 분석하면 더욱 심층적인 정보를 얻을 수 있습니다. 또한, EXPLAIN PLAN 문을 사용하여 쿼리를 실제로 실행하지 않고 실행 계획을 PLAN_TABLE에 저장하여 확인할 수도 있습니다. Tmax 기술 자료에 따르면, TIBERO6에서 SQL 쿼리의 실행 계획과 통계 정보를 조회하는 다양한 방법이 제공됩니다. 이러한 도구들을 활용하여 쿼리가 어떤 인덱스를 사용하고 있는지, 전체 테이블 스캔이 발생하는지, 비효율적인 조인 방식이 사용되고 있는지 등을 파악할 수 있습니다.
2.3. 쿼리 패턴 및 데이터 특성에 따른 최적 인덱스 컬럼 선정 전략
최적의 인덱스 컬럼을 선정하기 위해서는 쿼리 패턴과 데이터 특성을 면밀히 분석해야 합니다. WHERE 절, JOIN 조건, ORDER BY 절에서 자주 사용되는 컬럼은 인덱싱의 주요 대상입니다. 특히, 특정 값으로 검색하거나 범위 검색 조건에 자주 사용되는 컬럼에 인덱스를 생성하면 검색 성능을 크게 향상시킬 수 있습니다. 컬럼의 카디널리티(고유 값의 수)와 선택도(특정 값이 나타나는 비율)도 중요한 고려 사항입니다. 카디널리티가 높고 선택도가 낮은 컬럼은 인덱스를 통해 검색 범위를 효과적으로 좁힐 수 있으므로 인덱싱에 유리합니다. 반대로, 카디널리티가 낮은 컬럼을 인덱싱하는 것은 검색 효율성이 떨어질 수 있습니다. 따라서 쿼리에서 자주 사용되는 컬럼 중 고유 값이 많고 특정 값의 검색 비율이 낮은 컬럼을 우선적으로 인덱싱하는 전략이 효과적입니다.
2.4. 복합 인덱스 활용 및 컬럼 순서의 중요성
여러 컬럼을 함께 인덱싱하는 복합 인덱스는 여러 조건을 동시에 사용하는 쿼리의 성능을 향상시키는 데 매우 효과적입니다. 복합 인덱스에서 컬럼의 순서는 매우 중요합니다. 일반적으로 쿼리의 WHERE 절에서 가장 자주 사용되고 검색 효율성이 높은 컬럼을 복합 인덱스의 첫 번째 컬럼으로 지정하는 것이 좋습니다. 이는 인덱스가 첫 번째 컬럼을 기준으로 정렬되기 때문에, 첫 번째 컬럼에 대한 조건만으로도 검색 범위를 크게 줄일 수 있기 때문입니다. 예를 들어, 학년과 학과를 기준으로 검색하는 쿼리가 자주 실행된다면, (학과, 학년) 순서로 복합 인덱스를 생성하는 것이 (학년, 학과) 순서보다 더 효율적일 수 있습니다. 이는 일반적으로 학과의 종류가 학년보다 많아 첫 번째 조건으로 학과를 사용하는 것이 더 많은 검색 범위를 줄일 수 있기 때문입니다. 따라서 쿼리 패턴을 분석하여 함께 자주 사용되는 컬럼들을 파악하고, 각 컬럼의 선택도를 고려하여 최적의 순서로 복합 인덱스를 설계하는 것이 중요합니다.
2.5. 커버링 인덱스 활용 및 TIBERO6에서의 이점
커버링 인덱스는 쿼리에 필요한 모든 컬럼을 인덱스에 포함하는 방식입니다. 일반적인 인덱스는 검색 조건을 만족하는 ROWID를 찾은 후, 해당 ROWID를 이용하여 테이블에서 실제 데이터를 가져오는 반면, 커버링 인덱스는 인덱스 자체에 필요한 모든 데이터가 포함되어 있으므로 테이블 접근 없이 인덱스만으로 쿼리를 처리할 수 있습니다. 이는 디스크 I/O를 줄이고 쿼리 성능을 크게 향상시키는 이점을 제공합니다. TIBERO6에서 특정 컬럼을 포함하는 인덱스를 생성하는 기능(예: Oracle의 INCLUDE와 유사한 기능)을 활용하여 커버링 인덱스를 구현할 수 있습니다. 자주 실행되는 쿼리 중 소수의 컬럼만 필요로 하는 경우, 해당 컬럼들을 포함하는 커버링 인덱스를 생성하는 것을 고려해볼 수 있습니다.
2.6. TIBERO6 옵티마이저 힌트 활용
TIBERO6는 옵티마이저에게 특정 인덱스나 접근 방식을 사용하도록 지시하는 힌트 기능을 제공합니다. 예를 들어, INDEX 힌트를 사용하여 특정 테이블에 대해 명시된 인덱스를 사용하도록 강제할 수 있으며 , NO_INDEX 힌트를 사용하여 특정 인덱스의 사용을 막을 수도 있습니다. INDEX_ASC와 INDEX_DESC 힌트를 사용하여 인덱스 스캔 순서를 오름차순 또는 내림차순으로 지정할 수 있으며 , NO_INDEX_FFS 힌트를 사용하여 특정 인덱스에 대한 Fast Full Scan을 방지할 수 있습니다. 힌트는 SELECT, INSERT, UPDATE, DELETE 키워드 뒤에 /*+ hint [hint]... */ 또는 --+ hint [hint]... 형태로 작성합니다. 힌트를 사용할 때는 문법 규칙을 정확히 지켜야 하며, 테이블을 지정할 때는 별칭을 사용하는 것이 좋습니다. 힌트는 옵티마이저가 최적의 실행 계획을 선택하지 못하는 특정 상황에서 유용하게 사용될 수 있지만, 과도한 사용은 오히려 성능 저하를 초래할 수 있으므로 신중하게 적용해야 합니다.
2.7. TIBERO6 인덱스 클러스터링 팩터 이해 및 관리
TIBERO6의 인덱스 클러스터링 팩터는 특정 컬럼을 기준으로 동일한 값을 갖는 데이터가 물리적으로 얼마나 가깝게 저장되어 있는지를 나타내는 지표입니다. 클러스터링 팩터가 낮을수록 (즉, 물리적 저장 순서가 인덱스 순서와 유사할수록) 인덱스 범위 스캔 시 디스크 I/O 효율성이 높아집니다. 이는 필요한 데이터를 찾기 위해 더 적은 수의 데이터 블록만 읽어도 되기 때문입니다. 반대로, 클러스터링 팩터가 높으면 인덱스 순서대로 데이터를 읽더라도 실제 데이터 블록은 여기저기 흩어져 있어 많은 랜덤 액세스가 발생할 수 있습니다. 시간이 지남에 따라 데이터의 삽입, 삭제, 갱신 작업으로 인해 클러스터링 팩터가 저하될 수 있습니다. TIBERO6에서 클러스터링 팩터를 모니터링하고 필요에 따라 테이블 재구성 등의 방법을 통해 관리하는 것이 중요합니다.
3. TIBERO6 인덱스 변경 시 최적화 시간 최소화 방안
3.1. 인덱스 생성 및 변경 계획 수립 및 구현
인덱스를 생성하거나 변경하기 전에 쿼리 성능에 미치는 영향을 철저히 분석하고 계획을 수립하는 것이 중요합니다. 1 인덱스 변경은 시스템 자원(CPU, I/O, 저장 공간)에 상당한 영향을 미칠 수 있으므로, 피크 시간대를 피하여 작업 시간을 계획해야 합니다. 또한, 예기치 않은 성능 저하가 발생할 경우를 대비하여 롤백 계획을 마련해 두어야 합니다. 테이블 크기와 인덱스 복잡성을 고려하여 예상 작업 시간을 산정하고, 변경 전후의 관련 쿼리 실행 계획을 분석하여 성능 변화를 예측해야 합니다.
3.2. 시스템 성능에 미치는 영향 최소화 전략
TIBERO6가 온라인 인덱스 생성 및 재구축을 지원하는지 공식 문서를 통해 확인하고, 가능하다면 이 기능을 활용하여 시스템 가용성에 미치는 영향을 최소화해야 합니다. 온라인 인덱스 작업은 테이블에 대한 동시 접근을 허용하므로, 서비스 중단 시간을 줄일 수 있습니다. 매우 큰 테이블의 경우, 파티셔닝을 활용하고 파티션별로 인덱스를 생성하는 방법을 고려할 수 있습니다.
3.3. TIBERO6 온라인 및 오프라인 인덱스 작업 고려 사항
TIBERO6가 온라인 인덱스 작업을 지원한다면, 시스템의 가용성을 최대한 유지하기 위해 온라인 방식을 우선적으로 고려해야 합니다. 온라인 인덱스 작업은 테이블에 공유 잠금을 사용하여 동시 읽기 및 쓰기 작업을 허용하지만, 인덱스 구축 단계에서 추가적인 자원을 소비할 수 있습니다. 반면, 오프라인 인덱스 작업은 테이블에 배타적 잠금을 걸어 작업 동안 테이블 접근을 막으므로 서비스 중단이 불가피합니다. 따라서 시스템의 요구 사항과 제약 사항을 고려하여 적절한 방식을 선택해야 합니다.
3.4. 인덱스 변경 효과의 신속한 검증 기법
인덱스를 생성하거나 변경한 후에는 해당 변경 사항이 쿼리 성능에 실제로 긍정적인 영향을 미치는지 신속하게 검증해야 합니다. 변경 직후 대상 SQL 쿼리를 실행하고 실행 계획을 분석하여 새로운 인덱스가 사용되고 있는지 확인합니다. AUTOTRACE나 EXPLAIN PLAN을 사용하여 변경 전후의 실행 시간과 자원 사용량을 비교합니다. 성능이 향상되었다면 변경 사항을 유지하고, 그렇지 않다면 롤백하거나 추가적인 조치를 취해야 합니다.
3.5. TIBERO6 모니터링 도구를 활용한 인덱스 변경 영향 평가
TIBERO6에서 제공하는 모니터링 도구(예: V$SQL_PLAN, AUTOTRACE, SQLTRACE/TBPROF, TPR)를 활용하여 인덱스 변경이 시스템 성능에 미치는 영향을 종합적으로 평가해야 합니다. CPU 사용률, 디스크 I/O, 쿼리 실행 시간 등의 주요 성능 지표를 변경 전후로 비교 분석하여 지속적인 성능 개선 효과를 확인합니다. 장기적인 성능 추이를 관찰하여 예상치 못한 부작용이나 새로운 병목 지점이 발생하는지 여부를 확인하는 것도 중요합니다.
3.6. 일반적인 데이터베이스 인덱스 재구축 및 재구성 전략과 TIBERO6 적용 가능성
인덱스는 데이터 변경 작업으로 인해 시간이 지남에 따라 단편화될 수 있으며, 이는 성능 저하의 원인이 됩니다. 따라서 정기적으로 인덱스를 재구축하거나 재구성하여 효율성을 유지해야 합니다. 인덱스 재구축은 인덱스를 완전히 새로 만드는 작업으로, 단편화를 해소하고 성능을 최적화하는 데 효과적이지만 시간이 오래 걸릴 수 있습니다. 인덱스 재구성은 기존 인덱스 구조를 재정렬하는 작업으로, 재구축보다 빠르지만 단편화 해소 효과는 다소 낮을 수 있습니다. TIBERO6에서 인덱스 재구축 및 재구성에 대한 특정 명령어나 옵션을 제공하는지 공식 문서를 통해 확인하고, 시스템 환경과 요구 사항에 맞는 전략을 수립해야 합니다. 온라인 인덱스 재구축 기능이 있다면 가용성을 유지하면서 성능을 개선할 수 있습니다.
4. TIBERO6 인덱스 관리를 위한 실질적인 고려 사항 및 모범 사례
4.1. 최적의 인덱스 성능 유지를 위한 지침
TIBERO6에서 최적의 인덱스 성능을 유지하기 위해서는 지속적인 관리가 필요합니다. 데이터베이스 통계 정보를 정기적으로 갱신하여 옵티마이저가 정확한 정보를 바탕으로 최적의 실행 계획을 수립하도록 해야 합니다. 인덱스 사용 현황을 주기적으로 모니터링하여 사용되지 않는 인덱스를 식별하고 제거함으로써 불필요한 오버헤드를 줄여야 합니다. 또한, 데이터 볼륨 증가나 쿼리 패턴 변화에 따라 기존 인덱스의 효율성이 떨어질 수 있으므로, 주기적인 분석과 재검토를 통해 인덱스를 조정해야 합니다.
4.2. 정기적인 인덱스 모니터링 및 분석 권장 사항
중요한 SQL 쿼리의 실행 계획을 정기적으로 검토하여 인덱스가 여전히 효과적으로 사용되고 있는지 확인해야 합니다. TIBERO6에서 제공하는 모니터링 도구를 사용하여 인덱스 스캔 횟수, 인덱스 관련 대기 이벤트 등 인덱스 사용과 관련된 주요 성능 지표를 모니터링합니다. 데이터 볼륨, 분포, 쿼리 패턴의 변화는 인덱스의 효율성에 영향을 미칠 수 있으므로, 이러한 변화를 감지하고 인덱스 튜닝 필요성을 판단하기 위해 정기적인 모니터링이 필수적입니다.
4.3. TIBERO6 인덱스 튜닝 시 흔히 발생하는 문제점 및 해결 방안
TIBERO6 인덱스 튜닝 시 과도한 인덱싱은 데이터 변경 작업의 오버헤드를 증가시키고 저장 공간을 낭비할 수 있습니다. 카디널리티가 낮은 컬럼에 대한 인덱싱은 검색 효율성이 미미하므로 피해야 합니다. 여러 컬럼에 대한 조건을 사용하는 쿼리에는 복합 인덱스를 고려하고, 컬럼 순서를 최적화해야 합니다. 또한, 통계 정보의 중요성을 간과하면 옵티마이저가 잘못된 판단을 내릴 수 있으므로 통계 정보를 항상 최신 상태로 유지해야 합니다. 이러한 일반적인 문제점을 이해하고 적절한 해결 방안을 적용하는 것이 효과적인 인덱스 튜닝의 핵심입니다.
5. 예시 및 사례 연구
5.1. TIBERO6 인덱스 튜닝 기법 적용 사례
부서 번호와 업무를 기준으로 인덱스가 생성된 테이블에서 부서 번호와 연봉으로 검색하는 경우, 부서 번호에 해당하는 데이터가 많으면 많은 랜덤 액세스가 발생할 수 있습니다. 이 때, 인덱스에 연봉 컬럼을 추가하여 (부서 번호 + 업무 + 연봉) 형태의 복합 인덱스를 생성하면, 부서 번호와 연봉으로 검색 시 스캔량은 동일하더라도 테이블 랜덤 액세스 횟수를 줄여 성능을 향상시킬 수 있습니다. 또 다른 예로, 1000만 건의 데이터를 대상으로 쿼리 최적화를 적용하여 실행 시간을 9초에서 4.8초로 단축시킨 사례가 있습니다.
5.2. 인덱스 변경 시 최적화 시간 최소화 사례
TIBERO6에서 온라인 인덱스 생성 기능을 지원한다고 가정하고, 매우 큰 테이블에 새로운 인덱스를 생성해야 하는 경우를 생각해 볼 수 있습니다. 오프라인으로 인덱스를 생성하면 작업 시간 동안 테이블이 잠겨 서비스 중단이 발생할 수 있습니다. 하지만 온라인 인덱스 생성 기능을 활용하면 테이블 가용성을 유지하면서 인덱스를 구축할 수 있습니다. 또 다른 시나리오로, 파티셔닝된 테이블에서 특정 파티션에 대해서만 인덱스를 생성하거나 재구축하는 방법을 고려할 수 있습니다. 이는 전체 테이블에 대한 작업보다 훨씬 짧은 시간에 완료될 수 있으며, 영향을 받는 범위도 줄일 수 있습니다.
6. 결론
TIBERO6에서 효과적인 인덱스 튜닝은 데이터베이스 성능 향상에 필수적입니다. 이를 위해서는 TIBERO6 인덱스 구조와 스캔 방식에 대한 깊이 있는 이해를 바탕으로, 성능 병목 지점을 정확히 식별하고 쿼리 패턴 및 데이터 특성에 맞는 최적의 인덱스를 설계해야 합니다. 복합 인덱스, 커버링 인덱스, 옵티마이저 힌트 등의 다양한 기법을 적절히 활용하고, 인덱스 클러스터링 팩터를 관리하는 것도 중요합니다. 또한, 인덱스를 변경할 때는 시스템 성능에 미치는 영향을 최소화하기 위해 충분한 계획 수립, 온라인 작업 활용 (가능한 경우), 신속한 효과 검증, 그리고 지속적인 모니터링 및 관리가 이루어져야 합니다. 체계적인 접근 방식을 통해 TIBERO6 데이터베이스의 성능을 최적화하고 사용자에게 빠르고 안정적인 서비스를 제공할 수 있습니다.
표 1: TIBERO6 인덱스 스캔 방식 및 성능 영향
| 인덱스 범위 스캔 (Index Range Scan) | 조건절의 범위나 특정 값에 해당하는 데이터를 찾기 위해 인덱스의 일부를 스캔하는 방식 | 특정 범위의 데이터 조회, 조건절에 비교 연산자나 BETWEEN, LIKE 등이 사용된 경우 | 선택적인 데이터 검색에 효율적 |
| 인덱스 전체 스캔 (Index Full Scan) | 인덱스의 모든 리프 노드 블록을 순차적으로 읽는 방식 | 조건절에 인덱스의 선행 컬럼이 없거나, 쿼리가 인덱스의 대부분 데이터를 필요로 하는 경우, 인덱스가 테이블보다 훨씬 작은 경우 | 테이블 전체 스캔보다 효율적일 수 있지만, 인덱스가 크면 비효율적일 수 있음 |
| 인덱스 고유 스캔 (Index Unique Scan) | 고유 인덱스를 사용하여 단 하나의 행을 찾는 방식 | 고유 키 컬럼에 대해 '=' 조건으로 검색하는 경우 | 매우 빠름 |
표 2: 일반적인 TIBERO6 인덱스 튜닝 힌트
| INDEX | 특정 테이블에 대해 명시된 인덱스를 사용하도록 지시 | 옵티마이저가 최적의 인덱스를 선택하지 못하는 경우, 특정 인덱스를 강제로 사용하고자 할 때 |
| NO_INDEX | 특정 테이블에 대해 명시된 인덱스를 사용하지 않도록 지시 | 특정 인덱스가 쿼리 성능을 저하시키는 것으로 판단될 때 |
| INDEX_ASC | 특정 테이블에 대해 명시된 인덱스를 사용하여 오름차순으로 스캔하도록 지시 | 결과 집합을 특정 인덱스 순서대로 오름차순 정렬하고자 할 때 |
| INDEX_DESC | 특정 테이블에 대해 명시된 인덱스를 사용하여 내림차순으로 스캔하도록 지시 | 결과 집합을 특정 인덱스 순서대로 내림차순 정렬하고자 할 때 |
| NO_INDEX_FFS | 특정 테이블에 대해 명시된 인덱스에 대해 Fast Full Scan을 수행하지 않도록 지시 | Fast Full Scan이 예상보다 많은 자원을 소비하거나 비효율적인 것으로 판단될 때 |
표 3: TIBERO6 인덱스 분석을 위한 모니터링 도구
| V$SQL_PLAN | 현재 실행 중이거나 캐시에 저장된 SQL 쿼리의 실행 계획 | 쿼리가 어떤 인덱스를 사용하고 있는지, 전체 테이블 스캔이 발생하는지 등 쿼리 실행 과정을 파악하여 인덱스 사용 효율성을 분석 |
| AUTOTRACE | TBSQL 유틸리티 내에서 쿼리 실행 결과, 실행 계획, 통계 정보 제공 | 쿼리 실행 시 인덱스 사용 여부 및 성능 지표를 간편하게 확인하여 인덱스 튜닝 효과를 즉시 검증 |
| SQLTRACE / TBPROF | SQL 쿼리 실행 과정 상세 추적 및 분석 결과 제공 (실행 단계, 물리적/논리적 읽기 수 등) | 특정 쿼리의 성능 병목 지점을 심층적으로 분석하고, 인덱스 사용이 I/O에 미치는 영향을 파악하여 세밀한 튜닝 수행 |
| TPR (Tibero Performance Repository) | 주기적으로 수집된 TIBERO6 성능 통계 정보 및 보고서 제공 (SQL, 메모리, I/O 등) | 장기간에 걸쳐 시스템 성능 변화를 추적하고, 특정 기간 동안의 SQL 성능 분석을 통해 인덱스 변경의 장기적인 영향 평가 및 튜닝 대상 발굴 |
보고서에서 사용된 소스
읽었지만 보고서에서 사용되지 않은 소스
출처: Gemini
'컴퓨터 활용(한글, 오피스 등) > 기타' 카테고리의 다른 글
| 국채택국제회계기준에서 가상통화의 분류 (0) | 2025.04.29 |
|---|---|
| IFRS 해석위원회 논의결과 가상통화 보유 (0) | 2025.04.29 |
| 소프트웨어 사업 관련 법 (0) | 2025.04.26 |
| 엑셀 표 열 행추가 삽입&삭제 단축키 간단정리 (0) | 2025.04.26 |
| 썬더버드 thunderbird 추가 기능, 이메일 내보내기 가져오기 (0) | 2025.04.25 |
