WareValleyhttp://www.WareValley.com

WareValley

Oracle중소기업 DB관리자를 위한 데이터베이스

성능 최적화 및 품질 고도화 전문가 과정 #4

오렌지팀 윤석준 선임연구원

- 1일차 : Tuning 도구- D/B Tuning이 어려운 이유- Oracle D/B 구조- Tuning Tools : AutoTrace, SQL*Trace, V$SQLAREA

- 2일차 : SQL Tuning #1 : Optimizer- Rule-based Optimizer- Cost-based Optimizer- 통계정보, Histogram- Hint

- 3일차 : SQL Tuning #2 : Index, Join- Index- Join

- 4일차 : Server Tuning- Shared pool tuning- Data buffer cache tuning* NoSQL 소개

Oracle Tuning Tools

Design Tuning

Case Tool

SQL Tuning

Turning Tool

(Oracle Enterprise Manager)

Explain Plan

SQL*Trace & TKPROF

Analyze command

Histogram

DBMS_STATS

Stored Outline

Trace 10053 Event

Server Tuning

Turning Tool

(Oracle Enterprise Manager)

STATSPACK

Performance Dynamic View

Data Dictionary

Alert & Trace File

STATSPACK Package

• 두 시점 사이의 상태 값들의 평균/차이 등을 수집하여 분석

• 8i까지는 utlbstat.sql , tulestat.sql Script를 실행

• 9i에서는 STATSPACK Package를 사용

• 10g 이후부터는 AWR를 사용

(Automatic Workload Repository)

Dynamic Performance View #1

RedoLog

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$sesstatv$sysstat(목표: 적중률 90%)

v$bhv$cachev$buffer_pool

v$sgastatv$shared_pool_reserved(목표: request_failures = 0)

v$librarycache(목표: 비율 90%이상)

v$sqlareav$sqltextv$db_object_cache

v$sgastat

v$rowcache(목표: getmisses-gets 15%)

v$sysstat(목표: request, wait-time값 0)

v$session_wait• 동적으로 변화는 성능에 관련된 정보

• Memory 영역, Process 영역, File 영역 성능에 관련된 정보

Dynamic Performance View #2

• 동시에 많은 사용자가 작업을 실행할 경우 성능 저하 가능

Background Process

PMON SMON DBWR CKPT LGWR ARCn etc

Data files

Tempfiles

RBSfiles

Controlfiles

Redo logfiles

db_write_processesdbwr_io_slavesdb_file_simultaneous_writesdisk_asynch_io

checkpoint_processlog_checkpoint_intervallog_checkpoint_timeoutlog_checkpoint_to_alert

dbwr_io_slavesdisk_asynch_io

v$filestat(목표: 분산배치)

v$datafilev$lock

v$sort_segmentv$sort_usagev$sysstat(목표: disk-mem 5%이하)

v$sysstat(목표: wait-get 1%이하)

v$rollstat(목표: waits-gets 5%이하)

v$transaction

v$system_eventv$controlfile

v$sysstatv$system_eventv$logv$logfile

Dynamic Performance View (예제)

SELECT * FROM V$SGASTAT;

SGA 영역의 현재 상태를 참조 활성화된 메모리 구조 및 각 영역의 크기

SELECT * FROM V$SYSSTAT;

어떤 Resource에서 Wait Event가발생했는지 확인

SELECT * FROM V$FILESTAT;

물리적 구조에서의 R/W 할 때발생하는 File I/O 정보

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 실행

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 에 대해서 간단하게 설명

Shared Pool 현상분석

SELECT * FROM V$LIBRARYCACHE;

90% 이상 유지

SELECT SUM(PINS), SUM(RELOADS),SUM(RELOADS) / SUM(PINS)

FROM V$LIBRARYCACHE;

1% 이하 유지

PINS : 메모리에 남아있는 문장 RELOADS : 제거된 문장

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;

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

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 단위로 할당)

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 ] );

Data Buffer Cache Tuning

3. 자주 사용되는 Table을 Caching

CREATE TABLE [table name] [ CACHE | NOCACHE ];

ALTER TABLE [table name] [ CACHE | NOCACHE ];

SELECT /*+CACHE*/ ...

Data Buffer Cache Tuning

4. Multi Block 구조로 생성

CREATE TABLESPACE [tablespace name]

DATAFILE [file경로 및 이름]

SIZE [크기]

BLOCKSIZE [n] K

10g 이후부터 Tablesapce 별로 Block 크기 설정 가능

Block 별로 Header 영역의 크기가 약 300 byte 정도

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;

NoSQL 이란 ?

No SQL , Not Only SQL( SQL이 아니다. )

Non-Relational Operational Database SQL(관계형 Database가 아닌 SQL)

Data Repository의 변화

50년대 말 Mainframe 시대 (Host 중심)

- File System

90년대 Internet 시대 (PC의 등장으로 Server/Client 중심)

- RDBMS (MB, GB 단위)

2000년대 무선 Internet 시대 (SNS , Cloud 중심)

- NoSQL (TB, PB 단위)

NoSQL의 장/단점1. NoSQL의 장점

특성 내용

확장성과 탄력성 데이터가 증가함에 따라서 Node만 늘려주면 된다. 미리부터 시스템의 규모를 예측할 필요가 없다.

고성능 자료 구조가 단순하기에 미리 데이터 인덱싱을 생성할 수 있다. 낮고 예측 가능한 응답시간은NoSQL의 최대 장점이다. 대부분 O(1) ~ O(n)의 시간 복잡도 지원

분산시스템 Cluster에서 Node중 하나가 죽더라도 전체 서비스에 지장이 없다. 물론 RDBMS에도 Replication 할수 있는 시스템은 있으나 NoSQL의 그것과 비교할 때 비용이 크다.

Schema less Scheme가 없기 때문에 유연한 데이터 모델을 가져갈 수 있고, 구조 변경에 따른 비용유발이RDBMS에 비해 매우 적고, 초기 설계기간도 단축된다.

2. NoSQL의 단점

특성 내용

데이터 일관성 트랜잭션을 지원하지 않거나 낮은 수준(Application단 구현)으로 지원한다.복잡한 처리에 적합하지 않다.

데이터 무결성 어플리케이션 단에서 모든 무결성을 보장해야 한다.

Schema less 단일 구조의 데이터 형식이라 Join 과 같은 복잡한 형태의 데이터 조회 방식이 어렵다.

NoSQL의 특징

1. Clouding Computing 환경에 가장 적합하다.

- Open Source이기에 각 기업 환경에 최적화 구축이 가능

2. 유연한 Data Model 구축이 가능하다.

- Schema가 없으므로 정규화가 필요없음

- 설계 기간 단축 및 운영 중 변경이 유연함

3. Big Data 처리에 효과적이다.

- Memory Mapping 기술로 구현되어 Read/Write 작업이 빠름

4. 구축 비용 및 기간이 RDBMS에 비해 경제적이다.

NoSQL 제품의 종류

1. Key-Value Database

- Amazon

- Riak, Voldemort, Tokyo*

2. Column-based Database

- Google

- Hbase, Casandra, Hypertable

Data Model에 따른 NoSQL 종류

NoSQL 제품의 종류

3. Document Database

(JSON / XML)

- Lotus

- MongoDB, Cough DB

4. Graph Database

- Euler & Graph Theory

- AllegroGraph, Sones

Database 제품군

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

JSONhttp://www.10gen.comhttp://www.mongodb.org

MongoDB Terminology

SCOTT.EMP

_ID Field(Primary Key)

BSON Field(Column)

BSON Document(Row)

Collection(Table)

Embedded & Linking(RelationShip)

SCOTT.DEPT

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});