mellowg

top 

top 명령어는 리눅스에서 실시간으로 시스템 상태를 확인하는 명령어이다.

CPU 사용률, 메모리 사용량, 실행 중인 프로세스 정보 등을 실시간으로 보여준다.

top 실행하기

# top 실행하기
$ top

위 명령어를 입력하면 시스템의 상태가 실시간으로 갱신되며 화면에 출력된다. (종료하려면 q 입력)

🔎 top 화면 구성 해석하기

📌 상단 요약 정보 (시스템 전체 상태) : Linux

top - 19:53:32 up 1 min, 0 user, load average: 0.54, 0.19, 0.06

• 시간 : 현재 시각
• up : 시스템이 켜진 시간(업타임)
• users : 현재 로그인한 사용자 수
• load average : CPU 작업 대기열 평균 (1분, 5분, 15분 단위) -> 1.00이면 CPU 1개가 100%로 꽉 차있다는 의미

✔︎ 즉, 현재 리눅스 서버는 19:53:32 시각이며, 시스템이 켜진 시간은 1분, 현재 로그인한 사용자 수는 0명, CPU 평균 부하는 54%, 19%, 6%이다.

📌 상단 요약 정보 및 태스크/CPU/메모리 상태 : MacOS

Processes: 528 total, 3 running, 525 sleeping, 2705 threads 19:57:00

Load Avg: 1.99, 2.50, 2.90 CPU usage: 8.40% user, 5.64% sys, 85.95% idle SharedLibs: 688M resident, 142M data, 56M linkedit.

MemRegions: 307218 total, 3956M resident, 707M private, 2431M shared. PhysMem: 15G used (1278M wired, 0B compressor), 946M unused.

VM: 230T vsize, 4921M framework vsize, 0(0) swapins, 0(0) swapouts. Networks: packets: 37883/32M in, 24766/8573K out. Disks: 217510/4878M read, 127757/3757M written.

1) Processes: 528 total, 3 running, 525 sleeping, 2705 threads 19:57:00

• 528 total : 총 528개의 프로세스가 실행 중
• 3 running : 현재 CPU에서 실행중인 프로세스는 3개
• 525 sleeping : 나머지 525개는 대시 상태 (I/O 나 이벤트 대기 등)
• 2705 threads : 모든 프로세스의 스레드를 합친 수
• 19:57:00 : 현재 시각

💡 thread는 프로세스 내부에서 실행되는 작업 단위이고, 일반적으로 하나의 프로세스는 하나 이상의 스레드를 가진다.

2) Load Avg: 1.99, 2.50, 2.90 

• Load Average : CPU 작업 큐에 대기중인 평균 프로세스 수로, 각 수치는 1분, 5분, 15분 간격의 평균
  
  • 해석
    • 1분 평균 : 1.99
    • 5분 평균 : 2.50
    • 15분 평균 2.90

💡 Mac은 CPU 여러 개일 수 있기 때문에, 예를 들어 CPU 가 4개면 Load Avg가 4를 넘지 않으면 괜찮은 상태라고 볼 수 있다.

3) CPU usage: 8.40% user, 5.64% sys, 85.95% idle 

• 8.40% user : 일반 사용자 프로그램이 사용한 CPU 시간
• 5.64% sys : 커널/시스템 호출이 사용한 CPU 시간
• 85.95% idle : 놀고 있는 시간 (CPU가 여유 있음)

💡 idle 이 높을수록 좋음. 여유가 있다는 뜻

4) SharedLibs: 688M resident, 142M data, 56M linkedit.

• SharedLibs는 시스템에서 사용하는 공유 라이브러리 관련 메모리 정보
  • 912M resident : 실제 물리 메모리에 올라와 있는 라이브러리 메모리
  • 142M data : 데이터 부분
  • 82M linkedit : 링크 편집 관련 데이터
• 대부분 시스템/공유 라이브러리에 대한 정보이고, 이 수치는 참고만 하면 된다.

5) MemRegions: 307218 total, 3956M resident, 707M private, 2431M shared.

• 307218 total : 메모리 영역(region)의 총 개수 (각종 코드/데이터 블록 포함)
• 3956M resident : 실제 물리 메모리에 상주 중인 총 용량
• 707M private : 이 프로세스만 단독으로 사용하는 메모리
• 2431M shared : 다른 프로세스들과 공유하는 메모리

💡 Resident 가 많으면 메모리를 많이 쓰는 거고, Private이 많으면 해당 프로세스가 독점적으로 메모리 쓰는 비중이 크다는 뜻

6) PhysMem: 15G used (1278M wired, 0B compressor), 946M unused.

• 15 Used : 현재 사용중인 물리 메모리 (RAM)
• 1278 wired : Wired Memory는 OS나 커널이 반드시 RAM에 고정해둬야 하는 메모리 (절대 swap 불가)
• 0B compressor : 메모리 압추게 사용된 영역 (현재 없음)
• 946M unused : 사용 가능한 여유 메모리

💡 wired가 너무 커지면 커널이 RAM을 많이 차지하고 있다는 의미로, 시스템 자원 여유를 줄이게 됨.

7) VM: 230T vsize, 4921M framework vsize, 0(0) swapins, 0(0) swapouts. 

• 230T vsize : 전체 가상 메모리 크기 (굉장히 큰 값이지만 걱정할 필요 없음, 대부분 예약 영역)
• 4921M framework vsize : macOS 프레임워크가 차지한 가상 메모리
• 0(0) swapins/swapouts : 디스크로부터 swap 영역을 읽거나 쓴 횟수 및 크기로, 현재 0 - swqp 이 일어나지 않고 있음

8) Networks: packets: 37883/32M in, 24766/8573K out. 

• packets: 37883/32M in : 37883개의 패킷 / 총 32M 수신(in)
• 24766/8573K out : 24766개의 패킷 / 총 8573K 송신(out)

💡 네트워크 트래픽 상태. 네트워크 사용량 확인할 수 있음

9) Disks: 217510/4878M read, 127757/3757M written.

• 217510번 읽기 / 총 4878M 읽음
• 127757번 쓰기 / 총 3757M 기록

💡 디스크 I/O 활동량, 디스크 과부하 원인 추적 시 유용

📌 Task / CPU/Memory 상태 확인: Linux

Tasks: 3 total, 1 running, 2 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
MiB Mem : 7837.6 total, 7313.0 free, 441.2 used, 233.8 buff/cache
MiB Swap: 1024.0 total, 1024.0 free, 0.0 used. 7396.4 avail Mem

✔︎ Tasks & CPU 상태

Tasks: 3 total, 1 running, 2 sleeping, 0 stopped, 0 zombie

• 3 total : 전체 3개 프로세스
• 1 running : 현재 CPU에서 실행중인 프로세스 1개 
• 2 sleeping : 대기 중인 프로세스 2개
• 0 stopped/zombie : 정지되거나 종료되었으나 수거되지 않은 프로세스 없음

💡 좀비(zombie) 는 자식 프로세스가 종료되었지만 부모 프로세스가 wait()로 회수하지 않은 경우이다.

✔︎ CPU 사용율

%Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st

• us (user) : 0.0% -> 사용자 프로세스가 거의 CPU를 사용하지 않음
• sy (system) : 0.1% -> 커널/시스템 수준에서 약간의 사용
• id (idle) : 99.8% -> CPU가 거의 놀고 있음 (매우 여유 있음)
• wa (wait) : 0.0% -> I/O 대기 없음
• hi/si :  하드웨어/소프트웨어 인터럽트 거의 없음

✔︎ 메모리 사용량

MiB Mem : 7837.6 total, 7313.0 free, 441.2 used, 233.8 buff/cache

• total : 전체 메모리 7.8GB
• free : 7.3GB 사용가능 (대부분 사용 안하고 있음)
• used : 441MB만 실제로 사용 중
• buffer/cache : 234MB는 디스크 캐시 등으로 일시적으로 사용됨

✔︎ 스왑 영역

MiB Swap: 1024.0 total, 1024.0 free, 0.0 used. 7396.4 avail Mem

• total : 스왑공간이 1GB 할당되어 있음
• free : 남은 스왑공간
• used : 스왑 사용량 
• avail Mem : 애플리케이션이 사용할 수 있는 실질적인 여유 메모리

🔎 top 명령어 사용법

💡 자주 사용하는 옵션들

# 자주 사용하는 top 옵션들
$ top -u [사용자명] # 특정 사용자의 프로세스만 보기
$ top -p [PID] # 특정 PID만 추적
$ top -n [횟수] # 지정한 횟수만큼 갱신 후 종료
$ top -d [초] # 갱신 간격 설정 (기본 3초)

# 예시
$ top -u root 
$ top -d 1
$ top -n 5
$ top -p 1234

✅ 관련 명령어

리스너 로그 확인

리스너 로그를 통해서 언제 어떤 클라이언트가 접속을 시도했는지 확인할 수 있다. 그러나 client의 접속 요청이 Listener에게 도달하기 전에 문제가 발생한 경우에는 리스너 로그에 아무것도 남지 않는다. 

만약 client 접속 요청이 실패하는 경우 리스너로그 확인 후 리스너 로그에 아무런 로그가 남아있지 않다면 네트워크 쪽을 확인해보거나 해야 하며, 로그가 남은 경우에 로그 기록에 따라 조치를 취하면 된다.

리스너 로그 조회

$ cat $TB_HOME/instance/$TB_SID/log/lsnr
$ vi trace_list.log 
# or $ tail -n10 trace_list.log

로그 예시

# 세션에 클라이언트 접속요청 후 접속 성공한 경우 발생하는 로그
2025/07/30 16:08:43.990291 [5] listener:1452 a new client connection detected.
2025/07/30 16:08:43.990326 [5] listener:1371 a client connection from [127.0.0.1:44318] # 접속 요청한 클라이언트 정보
2025/07/30 16:08:43.990332 [5] listener:1494 a client from IP socket
2025/07/30 16:08:43.990344 [5] listener:3104 sent a connection fd to the WTHR process 1 successfully. # 클라이언트 WTHR(WORKER THREAD) 커넥션 성공

리스너 로그가 현재 어떤 포트를 리스닝하는지 확인

$  netstat -tlpn | grep tblistener
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8629            0.0.0.0:*               LISTEN      2026/tblistener

DB 접속 세션 끊기

DBA가 DB관련 작업을 할 때 모든 세션을 끊고 작업을 해야하는 경우가 있다. 실제 운영중인 서버인 경우 세션이 붙어있을 것이다. 이때는 세션이 연결되지 못하도록 막고, 기존 세션들을 끊는 작업이 필요하다. 

반드시 세션이 연결되지 못하도록 막는 것이 선행되어야 한다. (은행 창구에 대입하여 생각하면 이해하기 쉽다.)

은행 번호표 뽑는 것을 막지 않고 기존 고객을 쫒아내더라도 번호표는 계속 뽑히고 있을테니 계속해서 손님은 들어올 것이다. 번호표 기계를 먼저 종료한 후 기존 고객 거래를 끝내야 은행창구에 아무도 없을 것이다.

세션이 연결되지 못하도록 하려면 어떻게 해야할까?

세션을 연결하도록 하는 것은 Listener의 역할이다. Listener가 더이상 세션 연결 요청을 리스닝하지 못하도록 OFF 하는 방법이 있다.

1. 신규 세션 생성 막기

리스닝 OFF

리스닝 off 의 경우 아래 명령어를 실행하면 된다. 반대로 리스닝 ON은 OFF를 ON으로 변경하여 실행하면 된다.

ALTER SYSTEM LISTENER REMOTE OFF;

작업 후 netstat -tlpn | grep tblistener 조회해보면 아무것도 출력되지 않은 것을 확인할 수 있다.

2. 기존 세션 연결 끊기

기존 세션 연결 끊는 명령어는 아래와 같다. SID 와 SERIAL# 값은 V$SESSION 시스템뷰나 tm(tibero monotor)를 통해서 조회할 수 있다. 여기서는 V$SESSION을 통해 조회해보자

ALTER SYSTEM KILL SESSION(SID, SERIAL#);

V$SESSION을 통해 SID, SERIAL# 값 조회하기

VT_MYTID를 통해 나는 어떤 SID를 사용중인지 확인이 꼭 필요하다. 실수로 나의 연결을 끊어버릴 수 있기 때문이다.

SELECT 
	SID, 
	SERIAL#,
	USERNAME,
	PROG_NAME
FROM V$SESSION;

# 조회 결과
#	SID	SERIAL#	USERNAME	PROG_NAME
1	77	6,058	SYS	tbsql
2	87	632	TIBERO	Studio
3	88	1,360	SYS	tbsql
4	89	1,051	SYS	Studio

# 나는 어떤 SID 사용중인지?
SQL > SELECT * FROM VT_MYTID; -- 77

# 기존 접속 끊기
ALTER SYSTEM KILL SESSION(87, 632);
ALTER SYSTEM KILL SESSION(88, 1360);
ALTER SYSTEM KILL SESSION(89, 1051);

Tibero Instance Paramter 파일 (TIP파일)

TIP 파일은 Tibero 데이터베이스의 초기화 파라미터(Parameter)를 정의한 설정 파일이다.

• 확장자 : .tip
• 기본 위치 : $TB_HOME/config/$TB_SID.tip
• 역할 : DB 인스턴스 구동 시 필요한 환경설정 값 로딩
• 주요 설정 : 메모리 크기, 로그 경로, 백업 설정, listener 포트

# 파라미터 파일 내용 예시
# DB 이름
DB_NAME=tibero
# 리스너 포트
LISTENER_PORT=8629
# 컨트롤 파일
CONTROL_FILES="/tibero/tbdata/control_1/c1.ctl","/tibero/tbdata/control_2/c2.ctl"
# db에서 생성된 파일 기본 저장 경로
DB_CREATE_FILE_DEST="/tibero/tbdata/data_1"
# 로그 아카이브 파일 경로
LOG_ARCHIVE_DEST="/tibero/tbdata/arch"

# 최대 연결 가능 세션 수
MAX_SESSION_COUNT=20
# 공유 메모리 사이즈
TOTAL_SHM_SIZE=1500M
# 전체 메모리 사이즈
MEMORY_TARGET=2048M

### LOG
# 로그 기본 경로
LOG_DEFAULT_DEST="/tibero/tibero7/instance/tibero/log"
# sys log 전체 최대 사이즈 => 오래된 순서로 삭제됨.
SLOG_TOTAL_SIZE_LIMIT=300M
# 리스너 로그 최대 사이즈
LSNR_LOG_TOTAL_SIZE_LIMIT=300M
# ilog 최대 사이즈
ILOG_TOTAL_SIZE_LIMIT=700M
# dbms 로그 최대 사이즈
DBMS_LOG_TOTAL_SIZE_LIMIT=300M
# sys 로그 파일 하나 당 사이즈
SLOG_FILE_SIZE=100M
# 리스너 로그 파일 하나 당 사이즈
LSNR_LOG_FILE_SIZE=10M
# ilog 파일 하나 당 사이즈
ILOG_FILE_SIZE=10M
# dbms 로그 파일 하나 당 사이즈
DBMS_LOG_FILE_SIZE=100M

### ETC
GATHER_SQL_PLAN_STAT=Y
# 날짜 포맷
NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"

SQL 쿼리문으로 티베로 파라미터 정보 조회하기

- V$PARAMETERS 라는 시스템뷰를 통해 티베로 파라미터를 조회할 수 있다.

-- 예시코드
SELECT
	NAME
    , VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('MEMORY_TARGET', 'TOTAL_SHM_SIZE')
;

공유 메모리(TSM) 크기 정보 조회

-- FIXED MEMORY (REDO LOG BUFFER, SYSTEM AREA, DATABASE BUFFER CACHE)
-- TSM에서 FIXED MEMORY에 해당하지 않는 것은 SHARED CACHE
SELECT
	NAME
    , ROUND(TOTAL / 1024 / 1024, 1) AS "TOTAL(MB)"
    , ROUND(USED / 1024 / 1024, 1) AS "USED(MB)"
FROM V$SGA;

*SQL WORK AREA → SORT_AREA_SIZE를 통해 사이즈 설정이 가능하다. (DEFAULT PGA의 30%)
*MEMORY TUNER → 티베로 내부적으로 SQL WORK AREA 메모리 사용할 때 3초 단위(감시 단위 변경 가능)로 확인하면서 메모리 사용량을 조절해준다.

-- SORT 작업용 메모리 크기
SORT_AREA_SIZE

-- HASH 조인용 해시테이블 할당 메모리 크기 설정
HASH_AREA_SIZE

-- PGA 메모리의 SQL WORK AREA 공간 크기 검사 주기
EX_MEMORY_COMPENSATE_INTERVAL

* 위 3개 파라미터 조회 쿼리
SELECT NAME, VALUE, DFLT_VALUE
FROM V$PARAMETERS
WHERE 1=1
AND NAME IN ('SORT_AREA_SIZE', 'HASH_AREA_SIZE', 'EX_MEMORY_COMPENSATE_INTERVAL');

Tibero Process 확인

# 현재 실행중인 티베로 프로세스 조회
$ ps -ef | grep tbsvr 

# 현재 실행중인 티베로 리스너 조회
$ ps -ef | grep tblistener

조회 예시

# 티베로 프로세스 조회
$ ps -ef | grep tbsvr

tibero      2025       1  0 14:09 pts/0    00:00:01 tbsvr          -t NORMAL -SVR_SID tibero # monitor process
tibero      2027    2025  0 14:09 pts/0    00:00:00 tbsvr_MGWP     -t NORMAL -SVR_SID tibero # 관리자 접속용 
tibero      2028    2025  0 14:09 pts/0    00:00:00 tbsvr_FGWP000  -t NORMAL -SVR_SID tibero # Worker Process
tibero      2029    2025  0 14:09 pts/0    00:00:01 tbsvr_FGWP001  -t NORMAL -SVR_SID tibero # Worker Process
tibero      2030    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP000  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2031    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP001  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2032    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP002  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2033    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP003  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2034    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP004  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2035    2025  0 14:09 pts/0    00:00:00 tbsvr_PEWP005  -t NORMAL -SVR_SID tibero # 병렬실행
tibero      2036    2025  0 14:09 pts/0    00:00:02 tbsvr_AGNT     -t NORMAL -SVR_SID tibero # 에이전트
tibero      2037    2025  0 14:09 pts/0    00:00:00 tbsvr_DBWR     -t NORMAL -SVR_SID tibero # DB Writer process
tibero      2038    2025  0 14:09 pts/0    00:00:00 tbsvr_RCWP     -t NORMAL -SVR_SID tibero # 복구 프로세스

# 리스너 프로세스 조회
$ ps -ef | grep listener 
[tibero@T6:/tibero/tibero7/config]$ ps -ef | grep listener
root         934       1  0 12:12 ?        00:00:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
tibero      2026    2025  0 14:09 pts/0    00:00:00 /tibero/tibero7/bin/tblistener -n 11 -t NORMAL -SVR_SID tibero

Tibero Memory Structure

Tibero Memory 구조는 TSM(Tibero Shared Memroy=SGA)와 PGA(Process Global Area)로 구성되어 있다.

• PGA는 프로세스 끼리 서로 공유하지 않는 메모리 공간으로 MEMORY_TARGET - TOTAL_SHM_SIZE 즉, 전체 메모리 크기에서 TSM 크기를 뺀 나머지 사이즈가 PGA 크기이다. 
• TSM은 인스턴스끼리 공유하는 메모리 영역으로, 사이즈는 TOTAL_SHM_SIZE 파라미터로 지정한다.

TSM (Tibero Shared Memory)

1. DB Buffer Cache

  - 최근 테이블, 인덱스의 데이터를 저장한다.

  - DB_CACHE_SIZE 파라미터로 크기를 지정한다.

  - DB Buffer Cache에 올라온 데이터 블록은 재사용된다.

  - DB Buffer Cache Hit 율이 높다. ▶️ 버퍼 캐시 내의 데이터 블록들의 재사용성이 높다. ▶️ Disk I/O가 적다

2. Redo Log Buffer

  - 데이터 처리 작업 내용을 저장 한다.

  - 기본 10MB 크기이며, LOG_BUFFER 파라미터로 크기를 설정하낟.

  - 데이터 수정 내역을 저장한다.

  - 여러 사용자들의 Redo Log 들이 Redo Log Buffer에 저장된다.

  - Redo Log Buffer 내용은 Redo Log File에 저장된다.

3. System Area

  - 전역변수 공간으로, Worker Thread를 관리하는 공간이다.

  - 세션정보 관리 공간으로 구성된다.

4. Shared Cache

  1) PP Cache(Physical Plan Cache)

    - 최근 실행환 쿼리문, 구문 분석(파싱)정보, 실행계획 정보를 저장한다.

  2) DD Cache(Dictionray Cache)

    - 최근 실행한 SQL에서 사용하는 오브젝트(테이블, 컬럼, 사용자, 권한)의 데이터 사전 정보 저장

PGA(Process Global Area)

Worker Process 간에 공유하지 않는 독립적인 메모리 영역이다.

PGA 크기 = MEMORY_TARGET - TOTAL_SHM_SIZE

1. SQL Work Area

  - Worker Thread가 SQL 수행 시 Sorting, Merge 조인, Hash 조인 작업 공간으로 사용 

  - 크기가 부족하면 임시 세그먼트 (Temporary Tablespace)를 사용하여 성능이 저하된다.

2. Process Memory

  - 프로세스가 동작하는 데 필요한 공간

3. SQL Info Area

  - 커서 정보 영역으로 SQL문을 처리하는데 필요한 공간

4. Session Info Area

  - 로그인 및 세션 관련 정보 저장

✅ 관리자 입장에서의 메모리 관리 

1. 각각의 메모리 크기 관리

2. 메모리들이 본래 목적에 맞게 잘 돌아가는지 확인

  - Hit율로 확인한다. ➡️ 100%에 가까울수록 좋다 ➡️ Hit율이 높다는 것은 그만큼 프로세스간 메모리 공유가 잘 된다는 것 

  - 크기, Hit율을 파악하여 조치해야 한다.

    ✔︎ 메모리 추가

    ✔︎ 기존 메모리 비율 재설정

    ✔︎ 기존 메모리를 효율적으로 사용하도록 수정 (ex, SQL Query 튜닝)

*튜닝이 필요한 쿼리 찾기 ➡️ 쿼리 모니터링(PP Cache) ➡️  쿼리 튜닝을 통해 Temp Tablespace를 적게 사용하도록 하거나, 실행계획을 조금 더 효율적으로 수정하거나 등등,,

OLTP 와 OLAP

• OLTP(Online Transaction Processing)
  
  • 온라인 트랜잭션 처리 시스템
  • 사용자들이 실시간으로 데이터에 접근하고 처리하는 시스템을 의미
  • ex) 은행 ATM 이체, 온라인 쇼핑몰 상품 주문 등
• OLAP(Online Analytical Processing)
  • 온라인 분석 처리 시스템
  • 대량의 데이터를 분석하고 인사이트를 얻기 위한 시스템
  • ex) 매출 분석 보고서, 고객 행동 패턴 분석

✔︎ OLTP vs OLAP 비교표

업무 성격에 따른 메모리 크기 비율 설정 ( OLTP, OLAP )

1. OLTP → 8(TSM) : 2 (PGA) 비율

  - OLTP는 소량 데이터를 여러 세션에서 접근하는 경우가 많다. 소량의 데이터를 버퍼 캐시에서 빠르게 접근하기 때문에 PGA 크기가 많이 필요하지 않다. (소량 데이터라 처리 부담이 적음)

2. OLAP → 5(TSM) : 5 (PGA) 비율

  - OLAP는 대량의 데이터를 분석, 집계하는 경우로, 대량 데이터 처리(sorting 등 ) 하는데 작업 공간이 많이 필요하다. PGA가 커야 원할하게 작업을 처리할 수 있다. 대량 데이터 처리 환경에서는 1년치 데이터 or 테이블 모든 데이터 접근 하기 위해서 대량 데이터를 버퍼 캐시에 올려야 한다. 기존 버퍼 캐시 재사용이 잘 되지 않는다.