4. STATSPACK Package
• 두 시점 사이의 상태 값들의 평균/차이 등을 수집하여 분석
• 8i까지는 utlbstat.sql , tulestat.sql Script를 실행
• 9i에서는 STATSPACK Package를 사용
• 10g 이후부터는 AWR를 사용
(Automatic Workload Repository)
5. Dynamic Performance View #1
Redo
Log
BufferRECYCLE DEFAULT
Data Buffer Cache
SGA
(System Global Area)
Java Pool
Large Pool
Streams Pool
Library Cache
•SQL, SQL(recursive SQL)
•Parse Test
•Execution Plan
Data Dictionary Cache
•Row Cache
•Object Information
•Security
Shared Pool
v$sesstat
v$sysstat
(목표: 적중률 90%)
v$bh
v$cache
v$buffer_pool
v$sgastat
v$shared_pool_reserved
(목표: request_failures = 0)
v$librarycache
(목표: 비율 90%이상)
v$sqlarea
v$sqltext
v$db_object_cache
v$sgastat
v$rowcache
(목표: getmisses-gets 15%)
v$sysstat
(목표: request, wait-time값 0)
v$session_wait
• 동적으로 변화는 성능에 관련된 정보
• Memory 영역, Process 영역, File 영역 성능에 관련된 정보
6. Dynamic Performance View #2
• 동시에 많은 사용자가 작업을 실행할 경우 성능 저하 가능
Background Process
PMON SMON DBWR CKPT LGWR ARCn etc
Data
files
Temp
files
RBS
files
Control
files
Redo log
files
db_write_processes
dbwr_io_slaves
db_file_simultaneous_writes
disk_asynch_io
checkpoint_process
log_checkpoint_interval
log_checkpoint_timeout
log_checkpoint_to_alert
dbwr_io_slaves
disk_asynch_io
v$filestat
(목표: 분산배치)
v$datafile
v$lock
v$sort_segment
v$sort_usage
v$sysstat
(목표: disk-mem 5%이하)
v$sysstat
(목표: wait-get 1%이하)
v$rollstat
(목표: waits-gets 5%이하)
v$transaction
v$system_event
v$controlfile
v$sysstat
v$system_event
v$log
v$logfile
7. Dynamic Performance View (예제)
SELECT * FROM V$SGASTAT;
SGA 영역의 현재 상태를 참조
활성화된 메모리 구조 및 각 영역의 크기
SELECT * FROM V$SYSSTAT;
어떤 Resource에서 Wait Event가
발생했는지 확인
SELECT * FROM V$FILESTAT;
물리적 구조에서의 R/W 할 때
발생하는 File I/O 정보
8. Alert 파일과 Trace 파일
• BACKGROUND_DUMP_DEST Parameter 위치에 생성
1. alert_<SID>.log
Oracle Database 시작 및 종료시간
시작할 때의 init<SID>.ora 파일의 Parameter 값
Redo file들의 log 스위치된 시간과 마지막 file명
관리자가 새로운 구조를 추가하거나
삭제한 시간과 실행한 SQL문장
Checkpoint가 발생한 시간과 상태
Backup에 관련된 정보 및 Tuning 관련 정보
File의 마지막 부분이 가장 최신 정보
2. Trace 파일 ( *.trc )
Background Processor에 의해서 생성
-> 성능 문제 발생시
사용자가 생성
-> SQL*TRACE 실행
9. Oracle Server Tuning
Instance Tuning ( = Memory Tuning = SGA Tuning + Process Tuning )
Database Tuning ( = Disk-I/O Tuning = File Tuning )
Resource Tuning ( = Race Condition Tuning = Redo Log, Undo Segment 등… )
* 여기선 Instance Tuning 중 Shared Pool, Data Buffer Cache 에 대해서 간단하게 설명
10. Shared Pool 현상분석
SELECT * FROM V$LIBRARYCACHE;
90% 이상 유지
SELECT SUM(PINS), SUM(RELOADS),
SUM(RELOADS) / SUM(PINS)
FROM V$LIBRARYCACHE;
1% 이하 유지
PINS : 메모리에 남아있는 문장
RELOADS : 제거된 문장
11. Shared Pool Tuning
1. SHARED_POOL_SIZE를 늘려라. (하지만 근본적 해결책은 아니다.)
2. SQL문 표준화 작업을 하라.
3. Library Cache 관련 Parameter를 조정해라.
- CURSOR_SPACE_FOR_TIME (default false) : FALSE는 FIFO로 동작 , TRUE는 LRU로 동작
- SESSION_CAHCED_CURSORS (default 50) : 세션당 50개의 SQL문 이하로는 제거하지 마라.
- OPEN_CURSORS (default 300) : 세션당 동시에 Open 가능한 Cursor 수
4. 자주 사용하는 PL-SQL문을 Caching 하라.
- 길이가 짧고 자주 실행하는 Procedure가 있다면 ?
-> Shared Pool에 KEEP 가능
EXEC DBMS_SHARED_POOL.KEEP(‘<procedure name>’);
- 내리는 건 UNKEEP
- 실제로 KEEP되는 건 이후 최초 실행 시
5. Shared Pool을 RESET
ALTER SYSTEM FLUSH SHARED_POOL;
12. Data Buffer Cache 현상분석
90% 이상 유지
SELECT 1 - (P.VALUE / (C.VALUE + S.VALUE)) "Cache Hit Ratio"
FROM V$SYSSTAT C,
V$SYSSTAT S,
V$SYSSTAT P
WHERE C.NAME = 'db block gets'
AND S.NAME = 'consistent gets'
AND P.NAME = 'physical reads'
1. DB_CAHCE_SIZE를 늘려라. (하지만 근본적 해결책은 아니다.)
Data Buffer Cache Tuning
13. Data Buffer Cache Tuning
2. Multi Buffer Cache 영역 할당
- DB_CACHE_SIZE : 일반적인 SQL문
- DB_KEEP_CACHE_SIZE : 소량의 Data가 빈번하게 사용
- DB_RECYCLE_CACHE_SIZE : 대용량의 Data가 드물게 사용
(Loader 작업이 끝나면 Clear)
ALTER SYSTEM SET DB_KEEP_CACHE_SIZE = 4M;
ALTER SYSTEM SET DB_RECYCLE_CACHE_SIZE = 4M;
(9i 이전에는 bytes 단위로 할당하였지만, 10g 이후는 Granule 단위로 할당)
14. Data Buffer Cache Tuning
2. Multi Buffer Cache 영역 할당
- Multi Buffer Cache에 Loading 될 Table 설정
CREATE TABLE [table name]
( ... )
STORAGE (BUFFER_POOL [ KEEP | RECYCLE ] );
ALTER TABLE [table name]
STORAGE (BUFFER_POOL [ KEEP | RECYCLE ] );
15. Data Buffer Cache Tuning
3. 자주 사용되는 Table을 Caching
CREATE TABLE [table name] [ CACHE | NOCACHE ];
ALTER TABLE [table name] [ CACHE | NOCACHE ];
SELECT /*+CACHE*/ ...
16. Data Buffer Cache Tuning
4. Multi Block 구조로 생성
CREATE TABLESPACE [tablespace name]
DATAFILE [file경로 및 이름]
SIZE [크기]
BLOCKSIZE [n] K
10g 이후부터 Tablesapce 별로 Block 크기 설정 가능
Block 별로 Header 영역의 크기가 약 300 byte 정도
17. Data Buffer Cache Tuning
4. Multi Block 구조로 생성
Block Size가 작을 수록
(한 Block에 적은 Row가 저장되므로)
Block Size가 클 수록
(한 Block에 많은 Row가 저장되므로)
경합이 적게 발생 집중적인 경합이 발생
WHERE 조건에 의한 Random Scan에 탁월한 성능 개선 Full Table Scan에 탁월한 성능 개선
불필요한 Block Header가 많이 발생 Block Header의 오버헤드가 적게 발생
Index Scan 시 많은 Block을 읽어야 하므로 성능 저하 발생 Index Scan 시 적은 Block을 읽어도 되므로 성능개선이 기대
많은 사용자가 동시에 작업을 수행하는
OLTP (Online Transaction Processing)에 적합
소수의 사용자가 대용량 데이터 위주로 검색하는
DW (Data Warehouse) 환경에 적합
5. Buffer Cache를 RESET
ALTER SYSTEM FLUSH BUFFER_CACHE;
18. NoSQL 이란 ?
No SQL , Not Only SQL
( SQL이 아니다. )
Non-Relational Operational Database SQL
(관계형 Database가 아닌 SQL)
19. Data Repository의 변화
50년대 말 Mainframe 시대 (Host 중심)
- File System
90년대 Internet 시대 (PC의 등장으로 Server/Client 중심)
- RDBMS (MB, GB 단위)
2000년대 무선 Internet 시대 (SNS , Cloud 중심)
- NoSQL (TB, PB 단위)
20. NoSQL의 장/단점
1. NoSQL의 장점
특성 내용
확장성과 탄력성 데이터가 증가함에 따라서 Node만 늘려주면 된다. 미리부터 시스템의 규모를 예측할 필요가 없다.
고성능 자료 구조가 단순하기에 미리 데이터 인덱싱을 생성할 수 있다. 낮고 예측 가능한 응답시간은
NoSQL의 최대 장점이다. 대부분 O(1) ~ O(n)의 시간 복잡도 지원
분산시스템 Cluster에서 Node중 하나가 죽더라도 전체 서비스에 지장이 없다. 물론 RDBMS에도 Replication 할
수 있는 시스템은 있으나 NoSQL의 그것과 비교할 때 비용이 크다.
Schema less Scheme가 없기 때문에 유연한 데이터 모델을 가져갈 수 있고, 구조 변경에 따른 비용유발이
RDBMS에 비해 매우 적고, 초기 설계기간도 단축된다.
2. NoSQL의 단점
특성 내용
데이터 일관성 트랜잭션을 지원하지 않거나 낮은 수준(Application단 구현)으로 지원한다.
복잡한 처리에 적합하지 않다.
데이터 무결성 어플리케이션 단에서 모든 무결성을 보장해야 한다.
Schema less 단일 구조의 데이터 형식이라 Join 과 같은 복잡한 형태의 데이터 조회 방식이 어렵다.
21. NoSQL의 특징
1. Clouding Computing 환경에 가장 적합하다.
- Open Source이기에 각 기업 환경에 최적화 구축이 가능
2. 유연한 Data Model 구축이 가능하다.
- Schema가 없으므로 정규화가 필요없음
- 설계 기간 단축 및 운영 중 변경이 유연함
3. Big Data 처리에 효과적이다.
- Memory Mapping 기술로 구현되어 Read/Write 작업이 빠름
4. 구축 비용 및 기간이 RDBMS에 비해 경제적이다.
22. NoSQL 제품의 종류
1. Key-Value Database
- Amazon
- Riak, Voldemort, Tokyo*
2. Column-based Database
- Google
- Hbase, Casandra, Hypertable
Data Model에 따른 NoSQL 종류
23. NoSQL 제품의 종류
3. Document Database
(JSON / XML)
- Lotus
- MongoDB, Cough DB
4. Graph Database
- Euler & Graph Theory
- AllegroGraph, Sones
Database 제품군
24. MongoDB 특징
• humongous 사에서 2007년에 제작, 현재는 10gen으로 회사명 변경
• Document-Oriented Storage : JSON Type (Javascript Object Notation)
• No Schema : Relation을 포기하고 Performance 와 Scalability를 선택
• Auto-sharding : Master DB의 Write 연산을 분산처리
• Replica Sets : Master-Slave 에서 장애 시 자동처리
{ _id: ObjectID('4bd9e8e17cefd644108961bb'),
title: 'Adventures in Databases',
author: 'msmith',
vote_count: 20,
tags: ['databases', 'mongodb', 'indexing'],
image: {
url: 'http://example.com/db.jpg',
caption: '',
type: 'jpg',
size: 75381,
data: 'Binary' },
comments: [
{ user: 'bjones',
text: 'Interesting article!’},
{ user: 'blogger‘,
text: 'Another related' }
]
}
Master
Master Master
Slave Slave Slave Slave Slave Slave Slave
SlaveRecovering
Replica Sets
JSON
http://www.10gen.com
http://www.mongodb.org
26. MongoDB Command
SELECT * FROM emp; db.emp.find();
SELECT * FROM emp WHERE age = 33; db.emp.find({age:33});
CREATE INDEX emp_ename ON emp(ename); db.emp.ensureindex(ename:1);
INSERT INTO emp VALUES (1,'Luna'); db.emp.insert({empno:1, ename:’Luna’});
UPDATE emp SET ename = ‘Star’
WHERE empno = 1;
db.emp.update({empno:1}, {ename:’Star’});
DELETE FROM emp WHERE empno = 1; db.emp.remove({empno:1});
