Oracle Database 12c 릴리스 12.1.0.0의 새로운 성능 조정 기능:2부

원래 TriCore 발행:2017년 4월 12일

두 부분으로 구성된 이 블로그 게시물 시리즈에서는 Oracle® Database의 새로운 성능 조정 기능을 다룹니다. 1부에서는 OracleDatabase 버전 12.1.0.1에 대해 설명했습니다. 이 후속 게시물은 버전 12.1.0.2를 다룹니다.

메모리 내 열 저장소 소개

메모리 내 열 저장소(IM 열 저장소)는 빠른 스캔에 최적화된 열 형식으로 테이블, 파티션 및 기타 데이터베이스 개체의 복사본을 저장하는 SGA(SystemGlobal Area)의 선택적 영역입니다. IM 열 저장소는 분석, 데이터 웨어하우징 및 OLTP(온라인 트랜잭션 처리) 애플리케이션의 데이터베이스 성능을 가속화합니다.

IM 열 저장소 작동 방식

IM 열 저장소는 SGA에 데이터베이스 개체의 복사본을 저장합니다. 데이터베이스 버퍼 캐시를 대체하지 않습니다. 두 메모리 영역은 동일한 데이터를 다른 형식으로 저장할 수 있습니다. IM 열 저장소에 저장된 행은 열 형식의 큰 메모리 영역으로 나뉩니다. 열은 각 영역 내 메모리의 인접 영역에 별도로 상주합니다.

다음 데이터베이스 개체에 대해 IM 열 저장소를 활성화할 수 있습니다.

테이블
구체화된 보기
파티션
테이블스페이스

테이블의 모든 열을 IM 열 저장소에 저장하거나 일부만 저장할 수 있습니다. 마찬가지로 분할된 테이블의 경우 테이블의 모든 파티션을 저장하거나 일부만 저장할 수 있습니다. 테이블스페이스 수준에서 IMcolumn 저장소를 활성화하면 Oracle Database는 IM 칼럼 저장소에 대해 테이블스페이스의 모든 테이블과 구체화된 뷰를 자동으로 활성화합니다.

IM 열 저장소 사용의 성능 이점

데이터베이스 객체를 디스크 대신 메모리에 저장하면 OracleDatabase가 스캔, 쿼리, 조인 및 집계를 훨씬 빠르게 수행할 수 있습니다. IMcolumn 저장소는 다음 작업을 수행할 때 성능을 향상시킬 수 있습니다.

많은 행 스캔 및 필터 사용
큰 열 집합의 작은 하위 집합 쿼리
특히 조인 조건이 대부분의 행을 필터링할 때 작은 테이블을 큰 테이블에 조인
쿼리에서 데이터 집계

IM 컬럼 저장소는 또한 데이터 조작 언어(DML) 문의 성능을 향상시킵니다. OLTP 시스템은 일반적으로 일반적으로 액세스되는 열에 대해 많은 인덱스를 생성해야 합니다. 이러한 인덱스는 DML 문의 성능에 부정적인 영향을 미칠 수 있습니다. IM columnstore에 데이터베이스 개체를 저장하면 스캔이 훨씬 빠르게 실행되기 때문에 이러한 인덱스가 필요하지 않습니다. 불필요한 인덱스를 제거하면 업데이트해야 하는 인덱스가 더 적기 때문에 DML 문의 성능이 향상됩니다.

Oracle Database 12c 릴리스 12.1.0.0의 새로운 성능 조정 기능:2부

이미지 출처 :Oracle Learning Library YouTube 동영상:Oracle Database 12cdemos:In-Memory Column Store ArchitectureOverview

IM 열 저장소의 필요한 크기 추정

IM 열 저장소는 다음 압축 방법을 지원합니다.

압축 방법	인메모리 데이터 압축 순서	메모리 내 데이터 압축 비교
MEMCOMPRESS 없음	1	무효
DML용 MEMCOMPRESS	2(최소 압축)	B<모두
QUERY LOW에 대한 MEMCOMPRESS	3	B
QUERY HIGH용 MEMCOMPRESS	4	C
용량 부족용 MEMCOMPRESS	5	D
높은 용량을 위한 MEMCOMPRESS	6(고압축)	모두

다음 예는 oe.product_information을 활성화하는 방법을 보여줍니다. IM 열 저장소용 테이블 및 압축 방법 지정 MEMCOMPRESS FOR CAPACITY HIGH :

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

IM 열 저장소 크기 조정

IMcolumn 저장소에 데이터베이스 개체를 저장하는 데 필요한 메모리를 결정한 후 INMEMORY_SIZE를 사용하여 크기를 설정할 수 있습니다. 초기화 매개변수.

IM 열 저장소의 크기를 설정하려면 다음 단계를 사용하십시오.

INMEMORY_SIZE 설정 필요한 크기로 초기화 매개변수를 지정합니다.

이 매개변수의 기본값은 0입니다. , 이는 IM columnstore가 사용되지 않음을 의미합니다. IM 컬럼 저장소를 활성화하려면 이 매개변수를 0이 아닌 값으로 설정하십시오.

다중 테넌트 환경에서는 PDB별로 이 매개 변수를 설정하여 각 PDB(플러그 가능 데이터베이스)에 대한 IM columnstore의 크기를 지정할 수 있습니다. 그보다 클 수도 있습니다.
IM 열 저장소의 크기를 설정한 후 데이터베이스 개체를 저장할 수 있도록 데이터베이스 인스턴스를 다시 시작해야 합니다.

다음 예는 IM 컬럼 저장소의 크기를 100GB로 설정하는 방법을 보여줍니다.
```
 ALTER SYSTEM SET INMEMORY_SIZE = 100G;
```

IM 열 저장소에 대한 관리 용이성 지원

SQL 모니터 보고서, 활성 세션 기록(ASH) 보고서 및 자동 작업 부하 저장소(AWR) 보고서는 이제 다양한 메모리 내 작업에 대한 통계를 표시합니다.

데이터베이스 캐싱 모드

두 가지 데이터베이스 캐싱 모드가 있습니다.

이전 버전의 Oracle Database가 사용하는 기본 데이터베이스 캐싱 모드
Oracle Database 12cRelease 1(12.1.0.2)의 새로운 기능인 강제 전체 데이터베이스 캐싱 모드

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

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

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

인스턴스가 버퍼 캐시에 전체 데이터베이스를 캐시할 공간이 충분하지 않다고 판단하면 다음 작업을 수행합니다.

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

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

강제 전체 데이터베이스 캐싱 모드를 사용하면 전체 데이터베이스 메모리를 캐시할 수 있으므로 전체 테이블 스캔을 수행하거나 대형 개체(LOB)에 액세스할 때 상당한 성능 향상을 제공할 수 있습니다.

기본 캐싱 모드에서 Oracle Database는 사용자가 큰 테이블을 쿼리할 때 항상 기본 데이터를 캐싱하지 않습니다. 강제 전체 데이터베이스 캐싱 모드에서 Oracle 데이터베이스는 버퍼 캐시가 전체 데이터베이스를 캐시하기에 충분히 크다고 가정하고 액세스를 쿼리하는 모든 블록을 캐시하려고 시도합니다. 데이터베이스의 크기가 데이터베이스 버퍼 캐시 크기보다 작을 때 성공합니다.

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

Oracle Database 12c 릴리스 12.1.0.0의 새로운 성능 조정 기능:2부

이미지 출처 :전체 DB In-MemoryCaching.

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

다음 상황에서는 강제 전체 데이터베이스 캐싱 모드를 사용하는 것이 좋습니다.

논리 데이터베이스 크기(또는 실제 사용 공간)가 Oracle RAC(RealApplication Clusters) 환경에서 각 데이터베이스 인스턴스의 개별 버퍼 캐시보다 작습니다. 이 권장 사항은 Oracle이 아닌 RAC 데이터베이스에도 적용됩니다.
논리적 데이터베이스 크기는 Oracle RAC 환경에서 잘 분할된 워크로드(인스턴스 액세스 기준)에 대한 모든 데이터베이스 인스턴스의 결합된 버퍼 캐시 크기의 80%보다 작습니다.
데이터베이스는 SGA_TARGET를 사용합니다. 또는 MEMORY_TARGET .
NOCACHE LOB를 캐시해야 합니다. NOCACHE 강제 전체 데이터베이스 캐싱을 사용하지 않는 한 LOB는 캐싱되지 않습니다.

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

참고 참고:하나의 Oracle RAC 데이터베이스 인스턴스가 강제 전체 데이터베이스 캐싱 모드를 사용하는 경우 Oracle RAC 환경의 다른 모든 데이터베이스 인스턴스도 이 모드를 사용합니다. 다중 테넌트 환경에서 강제 fulldatabase 캐싱 모드는 모든 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;
FORslug: '' ---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)가 제공하는 보고서를 확인하십시오.

피드백 탭을 사용하여 의견을 남기거나 질문하십시오.

참조

다음 출처는 이 블로그 게시물의 참조로 사용되었습니다.

데이터베이스 성능 조정 가이드:메모리 내 열 저장소 사용의 성능 이점
전체 DB 인메모리 캐싱
Oracle Database 12c 데모:메모리 내 열 저장소 아키텍처 개요