Oracle Database 12c의 새로운 성능 튜닝 기능 완벽 정리: 2부 — In-Memory 컬럼 스토어와 전체 DB 캐싱

TriCore 원문 게시일: 2017년 4월 12일

이 시리즈는 Oracle® Database의 새로운 성능 튜닝 기능을 두 부로 나누어 다룹니다. 1부에서는 Oracle Database 버전 12.1.0.1을 살펴보았으며, 이번 2부에서는 버전 12.1.0.2의 주요 기능을 소개합니다.

In-Memory 컬럼 스토어란?

In-Memory 컬럼 스토어(IM 컬럼 스토어)는 시스템 글로벌 영역(SGA) 내에 선택적으로 구성할 수 있는 영역으로, 테이블, 파티션 및 기타 데이터베이스 객체의 복사본을 빠른 스캔에 최적화된 컬럼 형식으로 저장합니다. 이를 통해 분석 업무, 데이터 웨어하우징, 온라인 트랜잭션 처리(OLTP) 애플리케이션의 데이터베이스 성능을 크게 향상시킬 수 있습니다.

IM 컬럼 스토어의 작동 방식

IM 컬럼 스토어는 데이터베이스 객체의 복사본을 SGA에 저장하며, 데이터베이스 버퍼 캐시를 대체하지 않습니다. 두 메모리 영역은 동일한 데이터를 서로 다른 형식으로 저장할 수 있습니다. IM 컬럼 스토어에 저장된 행은 컬럼 형식으로 대규모 메모리 영역으로 나뉘며, 각 영역 내에서 하나의 컬럼은 연속된 메모리 공간에 개별적으로 위치합니다.

다음 데이터베이스 객체에 대해 IM 컬럼 스토어를 활성화할 수 있습니다.

테이블
구체화 뷰(Materialized View)
파티션
테이블스페이스

테이블의 전체 컬럼을 IM 컬럼 스토어에 저장할 수도 있고, 일부 컬럼만 저장할 수도 있습니다. 마찬가지로 파티션된 테이블의 경우 전체 파티션 또는 일부 파티션만 선택하여 저장할 수 있습니다. 테이블스페이스 수준에서 IM 컬럼 스토어를 활성화하면, Oracle Database는 해당 테이블스페이스에 포함된 모든 테이블과 구체화 뷰에 대해 자동으로 IM 컬럼 스토어를 활성화합니다.

IM 컬럼 스토어 사용의 성능상 이점

데이터베이스 객체를 디스크가 아닌 메모리에 저장하면 Oracle Database가 스캔, 쿼리, 조인, 집계 작업을 훨씬 빠르게 수행할 수 있습니다. IM 컬럼 스토어는 다음과 같은 작업에서 성능 향상 효과를 발휘합니다.

대량의 행을 스캔하고 필터를 적용하는 작업
많은 수의 컬럼 중 일부만 조회하는 쿼리
소규모 테이블과 대규모 테이블 간의 조인, 특히 조인 조건이 대부분의 행을 필터링하는 경우
쿼리 내 데이터 집계 작업

또한 IM 컬럼 스토어는 DML(데이터 조작 언어) 문장의 성능도 개선합니다. OLTP 시스템에서는 자주 접근하는 컬럼에 대해 많은 인덱스를 생성해야 하는데, 이러한 인덱스는 DML 문장의 성능에 부정적인 영향을 줄 수 있습니다. 데이터베이스 객체를 IM 컬럼 스토어에 저장하면 스캔 속도가 크게 빨라져 불필요한 인덱스를 제거할 수 있고, 갱신해야 할 인덱스 수가 줄어들면서 DML 문장의 성능이 향상됩니다.

Oracle Database 12c의 새로운 성능 튜닝 기능 완벽 정리: 2부 — In-Memory 컬럼 스토어와 전체 DB 캐싱

이미지 출처: Oracle Learning Library YouTube 영상, Oracle Database 12c 데모: In-Memory Column Store Architecture Overview

IM 컬럼 스토어의 필요 용량 산정

IM 컬럼 스토어는 다음과 같은 압축 방식을 지원합니다.

압축 방식	인메모리 데이터 압축 순서	인메모리 데이터 압축률 비교
NO MEMCOMPRESS	1	NIL
MEMCOMPRESS FOR DML	2 (압축률 최소)	B<all
MEMCOMPRESS FOR QUERY LOW	3	B<C<D
MEMCOMPRESS FOR QUERY HIGH	4	C<D<E
MEMCOMPRESS FOR CAPACITY LOW	5	D<E<F
MEMCOMPRESS FOR CAPACITY HIGH	6 (압축률 최대)	all<F

다음 예제는 oe.product_information 테이블에 대해 IM 컬럼 스토어를 활성화하고, 압축 방식으로 MEMCOMPRESS FOR CAPACITY HIGH를 지정하는 방법을 보여줍니다.

SQL> ALTER TABLE oe.product_information INMEMORY MEMCOMPRESS FOR CAPACITY HIGH;

IM 컬럼 스토어 크기 설정

데이터베이스 객체를 IM 컬럼 스토어에 저장하는 데 필요한 메모리 용량을 산정한 후에는 INMEMORY_SIZE 초기화 파라미터를 사용해 크기를 지정할 수 있습니다.

IM 컬럼 스토어의 크기를 설정하는 절차는 다음과 같습니다.

INMEMORY_SIZE 초기화 파라미터를 필요한 크기로 설정합니다.

이 파라미터의 기본값은 0이며, 이 경우 IM 컬럼 스토어가 사용되지 않습니다. IM 컬럼 스토어를 활성화하려면 이 값을 0이 아닌 값으로 설정해야 합니다.

멀티테넌트 환경에서는 PDB(pluggable database)별로 이 파라미터를 설정하여 각 PDB의 IM 컬럼 스토어 크기를 지정할 수 있습니다. PDB별 값의 합계가 CDB(container database)의 값과 일치할 필요는 없으며, 오히려 더 클 수도 있습니다.
IM 컬럼 스토어의 크기를 설정한 후에는 데이터베이스 객체를 저장할 수 있도록 데이터베이스 인스턴스를 재시작해야 합니다.

다음 예제는 IM 컬럼 스토어의 크기를 100GB로 설정하는 방법입니다.
```
ALTER SYSTEM SET INMEMORY_SIZE = 100G;
```

IM 컬럼 스토어의 관리 기능 지원

SQL Monitor 리포트, ASH(Active Session History) 리포트, AWR(Automatic Workload Repository) 리포트에서 이제 다양한 인메모리 작업에 대한 통계 정보를 확인할 수 있습니다.

데이터베이스 캐싱 모드

데이터베이스 캐싱 모드는 두 가지입니다.

이전 버전의 Oracle Database에서 사용하던 기본(default) 데이터베이스 캐싱 모드
Oracle Database 12c 릴리스 1(12.1.0.2)부터 새롭게 도입된 강제 전체(force full) 데이터베이스 캐싱 모드

기본 데이터베이스 캐싱 모드

기본적으로 Oracle Database는 전체 테이블 스캔을 수행할 때 기본 데이터베이스 캐싱 모드를 사용합니다.

Oracle Database 인스턴스가 버퍼 캐시에 전체 데이터베이스를 캐싱하기에 충분한 공간이 있고 그렇게 하는 것이 유익하다고 판단하면, 인스턴스는 자동으로 전체 데이터베이스를 버퍼 캐시에 캐싱합니다.

반면, 버퍼 캐시에 전체 데이터베이스를 캐싱하기에 충분한 공간이 없다고 판단되면 인스턴스는 다음과 같이 동작합니다.

버퍼 캐시 크기의 2% 미만인 소형 테이블: 메모리에 로드합니다.
중간 크기의 테이블: 마지막 테이블 스캔 시점과 버퍼 캐시의 에이징 타임스탬프 사이의 간격을 분석합니다. 마지막 스캔에서 재사용된 테이블의 크기가 남은 버퍼 캐시 크기보다 크면 해당 테이블을 캐싱합니다.
대형 테이블: 사용자가 명시적으로 KEEP 버퍼 풀에 지정하지 않는 한 메모리에 로드하지 않습니다.

강제 전체 데이터베이스 캐싱 모드

강제 전체 데이터베이스 캐싱 모드를 사용하면 데이터베이스 전체를 메모리에 캐싱할 수 있으며, 전체 테이블 스캔이나 LOB(Large Object) 접근 시 상당한 성능 향상을 기대할 수 있습니다.

기본 캐싱 모드에서는 사용자가 대형 테이블을 조회하더라도 Oracle Database가 항상 기반 데이터를 캐싱하지는 않습니다. 반면 강제 전체 데이터베이스 캐싱 모드에서는 버퍼 캐시가 전체 데이터베이스를 캐싱하기에 충분하다고 가정하고, 쿼리가 접근하는 모든 블록을 캐싱하려고 시도합니다. 데이터베이스 크기가 데이터베이스 버퍼 캐시 크기보다 작으면 캐싱에 성공합니다.

Oracle Database는 NOCACHE LOB와 SecureFiles를 사용하는 LOB를 포함하여, 접근되는 모든 데이터 파일을 버퍼 캐시에 로드합니다.

Oracle Database 12c의 새로운 성능 튜닝 기능 완벽 정리: 2부 — In-Memory 컬럼 스토어와 전체 DB 캐싱

이미지 출처: Full DB In-Memory Caching

강제 전체 데이터베이스 캐싱 모드를 사용해야 하는 경우

다음과 같은 상황이라면 강제 전체 데이터베이스 캐싱 모드 사용을 고려해 보세요.

논리적 데이터베이스 크기(또는 실제 사용 공간)가 Oracle RAC(Real Application Clusters) 환경에서 각 데이터베이스 인스턴스의 개별 버퍼 캐시보다 작은 경우. 이 권장 사항은 비(非)RAC 데이터베이스에도 동일하게 적용됩니다.
Oracle RAC 환경에서 잘 분배된 워크로드(인스턴스별 접근 기준)에 대해 논리적 데이터베이스 크기가 모든 데이터베이스 인스턴스의 버퍼 캐시 크기 합계의 80% 미만인 경우.
데이터베이스가 SGA_TARGET 또는 MEMORY_TARGET을 사용하는 경우.
NOCACHE LOB를 캐싱해야 하는 경우. NOCACHE LOB는 강제 전체 데이터베이스 캐싱을 사용하지 않으면 절대 캐싱되지 않습니다.

처음 세 가지 상황에서는 성능 지표가 기대치를 충족하는지 확인하기 위해 시스템 성능을 주기적으로 모니터링해야 합니다.

참고: 하나의 Oracle RAC 데이터베이스 인스턴스가 강제 전체 데이터베이스 캐싱 모드를 사용하면, 해당 Oracle RAC 환경의 다른 모든 데이터베이스 인스턴스도 이 모드를 사용하게 됩니다. 멀티테넌트 환경에서는 강제 전체 데이터베이스 캐싱 모드가 모든 PDB를 포함하는 CDB 전체에 적용됩니다.

데이터베이스 캐싱 모드 설정 및 확인

먼저 데이터베이스와 메모리 크기를 확인합니다. 다음 예제와 같이 SYSAUX 테이블스페이스는 제외할 수 있습니다.

SQL> col size_mb format 9999
SQL> SELECT sum(bytes)/1024/1024 seg_size_mb FROM dba_segments WHERE tablespace_name != 'SYSAUX';

SEG_SIZE_MB
-----------
      4971

다음 명령으로 버퍼 캐시의 크기를 확인합니다.

SQL> SELECT round(sum(cnum_set * blk_size)/1024/1024) size_mb FROM X$KCBWDS;

    SIZE_MB
----------
      5283

다음 절차에 따라 강제 전체 데이터베이스 캐싱을 위한 데이터베이스를 구성합니다.

SQL> startup mount;
Database mounted.

SQL> ALTER DATABASE FORCE FULL DATABASE CACHING;
Database altered.

SQL> SELECT force_full_db_caching FROM v$database;

FOR
---
YES

SQL> alter database open;
Database altered.

강제 전체 데이터베이스 캐싱 모드가 활성화되었는지 확인하는 절차는 다음과 같습니다.

다음 명령으로 V$DATABASE 뷰를 조회합니다.
```
SQL> SELECT FORCE_FULL_DB_CACHING FROM V$DATABASE;
```
출력 결과는 YES 또는 NO입니다.
강제 전체 데이터베이스 캐싱 모드를 활성화하려면 다음 ALTER DATABASE 명령을 사용합니다.
```
ALTER DATABASE FORCE FULL DATABASE CACHING;
```
명령 실행 후 다음과 같은 확인 메시지가 반환됩니다.
```
Database altered.
```
강제 전체 데이터베이스 캐싱을 비활성화하려면 다음 명령을 사용합니다.
```
SQL> ALTER DATABASE NO FORCE FULL DATABASE CACHING;
```
명령 실행 후 다음과 같은 확인 메시지가 반환됩니다.
```
Database altered.
```

결론

정리하자면, IM 컬럼 스토어는 DML 문장의 실행 시간을 단축시키며, 강제 전체 데이터베이스 캐싱 모드는 상당한 성능 향상을 제공합니다. Oracle Database의 새로운 성능 튜닝 기능에 대한 자세한 내용은 Oracle Enterprise Manager(OEM)가 제공하는 리포트를 참고하기 바랍니다.

의견이나 질문이 있다면 피드백 탭을 이용해 남겨주세요.

참고 자료

이 글을 작성하며 참고한 자료는 다음과 같습니다.

Database Performance Tuning Guide: Performance Benefits of Using the In-Memory Column Store
Full DB In-Memory Caching
Oracle Database 12c demos: In-Memory Column Store Architecture Overview