SlideShare a Scribd company logo
Part 1 ORACLE │161
KEEP BUFFER 활용 방안
㈜엑셈 컨설팅본부/DB컨설팅팀 장 정민
개요
Oracle 은 유저가 요청한 작업을 빠르게 처리하기 위해 Buffer Cache 라는것을 사용한다.
Buffer Cache 는 SGA 에 위치하고 있으며, 오라클 인스턴스에 접속하는 모든 프로세스에 의해
공유된다. 이 Buffer Cache 는 오라클 I/O 관리의 핵심으로 자주 사용하는 데이터 파일의 블록
들을 메모리에 상주시킴으로써 물리적인 I/O Operation 을 줄이는 역할을 한다. Buffer Cache
를 효과적으로 사용하면 물리적 I/O 가 줄어들고 자연스럽게 I/O 성능문제를 해결할 수 있다.
오라클의 버전이 올라감에 따라 Buffer Cache 를 처리하는 알고리즘은 끊임없이 개선되었고,
더불어 새로운 관리 방법들이 제공되었다. Oracle 7 까지의 Buffer Cache 는 하나의 틀로서 운
영되었고, 각 Object 의 특성에 따른 차별적인 Buffer Cache 이용이 어려웠다. 이런 면을 해결
하기 위해 Oracle 8 부터 Multiple buffer pool 이라는 기능을 지원하게 되었는데, 이로 인해 각
Object 의 특성이나 엑세스 빈도 등 차별성을 고려하여 Buffer Cache 를 보다 세밀하게 관리 할
수 있게 되었다.
Keep Buffer 는 이 Multiple Buffer Pool 을 구성하는 여러 영역중의 하나이다.
KEEP Buffer 사용 목적 및 특성
Keep Buffer 의 사용 목적은 본래의 Buffer Cache 의 목적과 마찬가지로, Object 를 메모리에
상주시킴으로써 물리적인 I/O 를 피하는데 있다.
Keep Buffer Pool 과 Default Buffer Pool 이 데이터 블록을 Cache 하거나 Flush 할 때 서로 다
른 알고리즘을 사용하지는 않는다. 그럼에도 불구하고 하나였던 Buffer Cache 영역을 Multiple
Buffer Pool 로 나누게 된 이유는 Object 의 특성을 고려한 Buffer Cache 이용을 위함이다.
162│2013 기술백서 White Paper
KEEP Buffer 의 메모리 공간은 Sequential 하게 관리된다. 한번 KEEP 된 세그먼트는 KEEP
Buffer 의 메모리 공간을 모두 할당하기 전까지 메모리에 유지되다가 KEEP Buffer 공간을 모두
할당하게 되면, 가장 오래된 블록부터 default pool 로 밀려난다. 때문에 KEEP 대상이 되는 세
그먼트들의 사이즈를 정확히 계산하여 KEEP Buffer 크기를 적절히 할당해야 한다.
KEEP Buffer 사용 순서
Keep Buffer 의 사용은 다음과 같은 순서로 진행한다.
1. KEEP 대상 선정하기
2. OS Memory & SGA 공간 확인
3. KEEP Buffer 설정
4. 테이블/인덱스 속성 변경
5. 테이블/인덱스 Keeping
6. KEEP 효율성 체크
7. KEEP 대상 선정 기준
KEEP 대상 선정 하기
KEEP 대상 선정에 있어서 명확한 기준점은 없다. 실제 업무를 고려하여 각 DB 의 운영환경에
맞는 대상을 선정해야 한다. 만약 KEEP 하는 대상이 아주 빈번하게 사용되는 블록 이라면, 기본
적인 Default Buffer 를 사용해도 Cache 돼있을 가능성이 높은데, 이런 경우에는 Keep Buffer
사용이 성능상의 이점을 가져오지 못한다. 반대로 자주 사용되지 않는 블록을 Keep Buffer 에
상주시킨다면, 사용하지 않는 메모리를 가지고 있는 것이기 때문에 전반적인 성능을 저하시키는
요인이 될 수도 있다.
때문에 Keep 대상을 선정하는데 있어서는 실제 업무의 고려가 필수적이다. 예를 들어 하루에 1
번만 수행되는 프로그램인데 어떻게 해서든 수행시간을 단축시켜야 하는 경우나, 많은 업무를
처리하는 시간대에 꼭 수행 되야 하는데 많은 I/O 때문에 병목현상을 일으켜서 시스템에 전반적
으로 악영향을 끼치는 프로그램 등이 있을 수 있다. 이런 프로그램들이 사용하는 Object 들이
Part 1 ORACLE │163
Keep 대상이 될 수 있다. 그러나 위와 같은 업무 프로그램에 사용되는 모든 세그먼트를 KEEP
Buffer 에 상주 시킬 수 는 없다. 그러므로 KEEP Buffer 에 상주시킬 대상은 각 DB 운영환경을
고려하여 선정해야 한다. 이외에도 크기, DML 빈도, 데이터 엑세스 빈도에 따라 Keep 하기에 적
절한 세그먼트들이 존재한다.
선정 기준[1]. 프로그램 중요도
Keep 대상 선정에 있어서 가장 중요한 부분이 바로 해당 세그먼트를 조회하는 업무 프로그램의
중요도 이다. 해당 프로그램이 중요하지 않다면 굳이 Keep Buffer 를 사용해야 할 필요가 없다.
반대로 해당 세그먼트를 조회하는 프로그램이 중요도가 아주 높고 어떻게든 수행시간을 단축해
야 한다면 프로그램 수행 빈도와 상관없이 KEEP 대상으로의 선정을 고려할 수 있다.
선정 기준[2]. 세그먼트 크기
세그먼트 크기가 일정하지 않고, 과다하게 커지는 세그먼트는 Keep Buffer 의 효율성을 떨어뜨
릴 수 있다. Keep 된 세그먼트는 Keep Buffer 의 용량이 부족하면 오래된 블록부터 Default
Buffer 로 밀려나게 되는데, 크기가 계속 커지는 세그먼트가 Keep Buffer 에 존재한다면 타 세
그먼트를 조회하는 프로그램의 성능 저하를 가져올 수 있기 때문이다. 따라서 일정한 사이즈 또
는 변동 량이 심하지 않으면서 최대 크기가 일정 수준 이하인 경우의 세그먼트를 선정하는 것이
바람직하다. 예를 들면 ‘최대 크기가 10 만 블록 이하인 세그먼트’ 같은 기준을 정할 수 있다.
선정 기준[3]. Full Table Scan & Index Full Scan & Index Fast Full Scan
KEEP Buffer 에 KEEP 된 세그먼트를 조회할 때 효율성을 극대화 하기 위해서는 다소 많은 량을
처리해야 하는 경우이다. Scan 범위가 넓은 비효율 Index Scan 이나 Full Table Scan, Index
Fast Full Scan 으로 처리되는 세그먼트가 대상이 될 수 있다.
164│2013 기술백서 White Paper
KEEP 대상 선정 SQLScript
SELECT owner ,
table_name ,
index_name ,
partition_name ,
SUM( blocks ) AS t_blocks
FROM (
SELECT sg.owner ,
decode( SUBSTR( s.ob_type , 1 , 5 ) , 'TABLE' , s.ob_name , 'INDEX' , (
SELECT table_name
FROM dba_indexes
WHERE index_name = s.ob_name
) ) AS table_name ,
decode( SUBSTR( s.ob_type , 1 , 5 ) , 'INDEX' , s.ob_name ) AS index_name ,
sg.partition_name ,
sg.blocks
FROM (
SELECT DISTINCT object_name AS ob_name ,
object_type AS ob_type
FROM v$sql_plan
WHERE ( operation = 'TABLE ACCESS'
AND options = 'FULL' )
OR ( operation = 'INDEX'
AND options = 'FULL SCAN' )
OR ( operation = 'INDEX'
AND options = 'FAST FULL SCAN' ) --> 선정 기준[3]
) s ,
dba_segments sg
WHERE s.ob_name = sg.segment_name
)
GROUP BY owner ,
table_name ,
index_name ,
partition_name
HAVING SUM( blocks ) > 100000 --> 선정 기준[2]SELECT * FROM DUAL
Part 1 ORACLE │165
OS Memory & SGA 공간 확인
OS Memory SGA 공간 확인 SQLScript
$ cat /proc/meminfo
MemTotal: 4055152 kB
MemFree: 1390308 kB
Buffers: 166768 kB
Cached: 2019992 kB
SwapCached: 0 kB
Active: 1118484 kB
Inactive: 1277864 kB
………
SGA공간 확인 SQLScript
● SGA 전체 size 확인
SELECT name ,
ROUND( bytes/1024/1024 ) "size(MB)"
FROM V$SGAINFO;
NAME size(MB)
------------------------------- ----------
Fixed SGA Size 2
Redo Buffers 5
Buffer Cache Size 48
Shared Pool Size 128
Large Pool Size 0
Java Pool Size 24
Streams Pool Size 0
Shared IO Pool Size 0
Granule Size 4
Maximum SGA Size 207
Startup overhead in Shared Pool 72
Free SGA Memory Available 0
● Data Buffer size 확인
166│2013 기술백서 White Paper
SELECT name ,
current_size
FROM v$buffer_pool;
NAME CURRENT_SIZE
-------------------- ------------
DEFAULT 48
KEEP BUFFER 설정
KEEP Buffer 설정은 KEEP Buffer 크기와 SGA 여유공간에 따라, Online 작업 또는 Offline 작
업으로 수행한다. 이 문서의 스크립트는 SGA 영역의 메모리 관리를 수동으로 하는 경우를 바탕
으로 작성 하였다.
KEEP Buffer 설정 Script
@sga
NAME size(MB)
-------------------------------- ----------
Buffer Cache Size 500
Maximum SGA Size 1019
Free SGA Memory Available 228
@bc
NAME CURRENT_SIZE
-------------------- ------------
DEFAULT 500
● KEEP Buffer 의 크기가 SGA 의 Free 공간보다 작은 경우 Online ( KEEP Buffer 100M )
SQL> alter system set db_keep_cache_size = 100M scope = both;
System altered.
SQL> @sga
Part 1 ORACLE │167
NAME size(MB)
-------------------------------- ----------
Buffer Cache Size 600
Maximum SGA Size 1019
Free SGA Memory Available 128
SQL> @bc
NAME CURRENT_SIZE
-------------------- ------------
KEEP 100
DEFAULT 500
● KEEP Buffer 의 크기가 SGA 의 Free 공간보다 큰 경우 ( KEEP Buffer 300M )
1. SGA 전체 크기 늘린 후 KEEP Buffer 할당 Offline 작업 필요
SQL> alter system set sga_max_size = 1100M scope = spfile;
System altered.
SQL> alter system set db_keep_cache_size = 300M scope = spfile;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 1169227776 bytes
Fixed Size 2212696 bytes
Variable Size 301993128 bytes
Database Buffers 855638016 bytes
Redo Buffers 9383936 bytes
Database mounted.
Database opened.
SQL> @sga
168│2013 기술백서 White Paper
NAME size(MB)
-------------------------------- ----------
Buffer Cache Size 816
Maximum SGA Size 1115
Free SGA Memory Available 0
SQL> @bc
NAME CURRENT_SIZE
-------------------- ------------
KEEP 304
DEFAULT 512
=> SGA 전체 크기가 1G 를 초과하면서 Granule 크기가 16Mb 로 늘어났다
이 때 지정한 값 보다 큰 16 의 배수 중 가장 작은 크기의 값이 할당된다.
2. SGA 의 다른 영역의 크기를 줄인 후 KEEP Buffer 할당 할 경우 Online 작업 가능
Online 상태에서 변경 가능 Parameter 추출 Script
SELECT name ,
issys_modifiable
FROM v$parameter
WHERE name LIKE '%size%'
AND issys_modifiable = 'IMMEDIATE'
NAME ISSYS_MOD
--------------------------------------- ---------
shared_pool_size IMMEDIATE
large_pool_size IMMEDIATE
java_pool_size IMMEDIATE
streams_pool_size IMMEDIATE
db_cache_size IMMEDIATE
db_2k_cache_size IMMEDIATE
db_4k_cache_size IMMEDIATE
db_8k_cache_size IMMEDIATE
db_16k_cache_size IMMEDIATE
db_32k_cache_size IMMEDIATE
db_keep_cache_size IMMEDIATE
db_recycle_cache_size IMMEDIATE
_shared_io_pool_size IMMEDIATE
Part 1 ORACLE │169
db_flash_cache_size IMMEDIATE
db_recovery_file_dest_size IMMEDIATE
result_cache_max_size IMMEDIATE
workarea_size_policy IMMEDIATE
max_dump_file_size IMMEDIATE
=> 해당 Parameter 값을 적절히 조절하여 Free Memory 확보 후 KEEP 설정
테이블/인덱스 속성 변경
테이블/인덱스 속성 변경 Script
ALTER TABLE T1 STORAGE (BUFFER_POOL KEEP); --테이블 속성 변경
ALTER INDEX T1_PK STORAGE (BUFFER_POOL KEEP); --인덱스 속성 변경
ALTER TABLE P1 MODIFY PARTITION P1_1 STORAGE (BUFFER_POOL KEEP); --파티션 테이블 속성 변경
ALTER INDEX P1_ID1 MODIFY PARTITION P1_ID1_1 STORAGE (BUFFER_POOL KEEP);--파티션 인덱스 속성 변경
테이블/인덱스 Keeping
Segment 의 Buffer Pool 이 KEEP 으로 설정된 테이블과 인덱스는 Query 시 KEEP Buffer 에
해당 세그먼트의 블록을 로딩하게 된다. 그러므로 최초 세그먼트를 Loading 할 때에는 Disk I/O
가 발생하게 된다. 만일 처음 실행하는 때를 포함하여 모든 Application 의 조회에서 Disk I/O
를 제거하고 싶다면, 업무가 진행되기 전에 해당 세그먼트들을 Full Table Scan 이나 Index
Fast Full Scan 으로 KEEP Buffer 에 로딩시키면 된다.
KEEP Buffer 효율성 판단
KEEP Buffer 의 사용에 명확한 기준이 정해져 있는 것이 아니라 운영 환경에 따라 차이가 존재
한다. 때문에 모든 운영 환경에서 같은 방법으로 효율성을 판단하기에는 무리가 있다. 하지만 다
음과 같은 자료들이 KEEP Buffer 의 효율성을 판단하는데 근거가 될 수 있다.
KEEP Buffer Size & Hit Ratio SQLScript
170│2013 기술백서 White Paper
SELECT current_size keep_size ,
seg_size ,
ROUND( seg_size/current_size*100 , 1 ) "Ratio(%)"
FROM v$buffer_pool ,
(
SELECT SUM( bytes ) /1024 /1024 seg_size
FROM dba_segments
WHERE buffer_pool = 'KEEP'
)
WHERE name = 'KEEP'
KEEP_SIZE SEG_SIZE Ratio(%)
---------- ---------- ----------
304 118 38.8
SELECT db_block_gets ,
consistent_gets ,
physical_reads ,
CASE
WHEN db_block_gets+consistent_gets <> 0
THEN ROUND(( 1-( physical_reads/( db_block_gets+consistent_gets ) ) ) *100 , 2 )
END "Keep_Hit(%)"
FROM v$buffer_pool_statistics
WHERE name = 'KEEP'
DB_BLOCK_GETS CONSISTENT_GETS PHYSICAL_READS Keep_Hit(%)
------------- --------------- -------------- -----------
0 44474 4435 90.03
만약 KEEP Buffer 를 사용하는 Segment 크기의 총 합이 KEEP Buffer 크기보다 작은 경우, 해
당 Segment 들의 크기가 더 이상 커지지 않는다면, 한 번 KEEP 영역으로 올라간 Segment 의
Cache Hit Ratio 가 100%에 가깝게 될 것이다.
만일 KEEP Buffer 의 크기가 해당 영역을 사용하는 Segment 들의 크기보다 작다면 KEEP
Buffer 영역에서 경합이 발생하고, 그로 인해 Physical I/O 가 발생하여 Cache Hit Ratio 가 떨
어질 수 있다. 이때 KEEP Buffer 의 크기를 늘려주거나 중요도가 떨어지는 Segment 의 KEEP
Buffer 사용을 막는 방안을 고려 해 볼 수 있다. 반대로 KEEP Buffer 의 크기가 Segment 들의
Part 1 ORACLE │171
크기보다 많이 크다면, 사용하지 않는 메모리 공간을 차지하고 있는 것이므로 KEEP Buffer 의
크기를 줄이는 것을 고려 해 볼 수 있다. 따라서 시스템 성능과 Segment 들의 중요도에 따라 효
율적인 KEEP Buffer 의 크기 조절이 필요하다.
다음 스크립트로 dba_hist_seg_stat 뷰를 조회하여 Segment 조회시 발생하는 I/O 발생량에
대한 AWR 정보를 확인 하여 Segment 별 효율성을 판단 할 수 있다.
Segment I/O SQLScript
accept i_begin_time prompt 'Enter begin time[YYYYMMDDHH24]: '
accept i_end_time prompt 'Enter end time[YYYYMMDDHH24]: '
variable v_begin_time char(10)
variable v_end_time char(10)
exec :v_begin_time:=&i_begin_time
exec :v_end_time :=&i_end_time
SELECT /*+ leading(k) */
s.dbid ,
decode( SUBSTR( o.object_type , 1 , 5 ) , 'TABLE' , o.object_name , 'INDEX' , (
SELECT table_name
FROM dba_indexes
WHERE index_name = o.object_name
AND owner = k.owner
) ) AS table_name ,
decode( SUBSTR( o.object_type , 1 , 5 ) , 'INDEX' , o.object_name ) AS index_name ,
s.snap_id ,
TO_CHAR( w.begin_interval_time , 'yyyymmdd.hh24' ) AS begin_time ,
s.physical_reads_delta ,
s.physical_reads_direct_delta ,
s.physical_reads_delta + s.physical_reads_direct_delta AS total_diskio
FROM sys.wrm$_snapshot w ,
dba_hist_seg_stat s ,
dba_objects o ,
(
SELECT owner ,
segment_name
FROM dba_segments
172│2013 기술백서 White Paper
WHERE buffer_pool = 'KEEP'
) k
WHERE w.begin_interval_time >= to_timestamp( '2013062510' , 'yyyymmddhh24' )
AND w.end_interval_time <= to_timestamp( '2013062518' , 'yyyymmddhh24' )
AND w.snap_id = s.snap_id
AND w.dbid = s.dbid
AND w.instance_number = s.instance_number
AND s.obj# = o.object_id
AND k.segment_name = o.object_name
AND k.owner = o.owner
ORDER BY 2 , 3 , 5
결론
KEEP Buffer 를 사용하는데 있어 가장 중요한 것이 업무의 반영일 것이다. 자주 사용하는
Object 들만 상주하는 Buffer Cache 하나만 사용하는 것이 시스템 전체의 관점에서 보면 효율
적일 수도 있다. 하지만 업무의 중요성이나 특성을 고려한다면 다른 결과가 나올 수 있다. 적게
실행 되더라도 중요도가 높은 업무가 있을 수 있고, 수행시간 단축이 매우 중요한 업무가 있을
수 있다. 이러한 업무에 대한 특성을 반영한 운영계획을 세우는데 있어서, KEEP Buffer 를 효율
적으로 사용 할 수 있다면, 시스템 성능 향상에 큰 도움이 될 것이다.

More Related Content

What's hot

MySQL innoDB split and merge pages
MySQL innoDB split and merge pagesMySQL innoDB split and merge pages
MySQL innoDB split and merge pages
Marco Tusa
 
Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)
Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)
Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)
涛 吴
 
State transfer With Galera
State transfer With GaleraState transfer With Galera
State transfer With Galera
Mydbops
 
What is data engineer?資料工程師是什麼?
What is data engineer?資料工程師是什麼?What is data engineer?資料工程師是什麼?
What is data engineer?資料工程師是什麼?
Anna Yen
 
PostgreSQL and RAM usage
PostgreSQL and RAM usagePostgreSQL and RAM usage
PostgreSQL and RAM usage
Alexey Bashtanov
 
PySpark Best Practices
PySpark Best PracticesPySpark Best Practices
PySpark Best Practices
Cloudera, Inc.
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?takezoe
 
Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...
Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...
Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...
Ceph Community
 
Change Data Feed in Delta
Change Data Feed in DeltaChange Data Feed in Delta
Change Data Feed in Delta
Databricks
 
Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...
Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...
Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...
Databricks
 
Streaming replication in practice
Streaming replication in practiceStreaming replication in practice
Streaming replication in practice
Alexey Lesovsky
 
Oracle Data Warehouse
Oracle Data WarehouseOracle Data Warehouse
Oracle Data Warehouse
DataminingTools Inc
 
Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...
Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...
Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...
confluent
 
MySQL GTID 시작하기
MySQL GTID 시작하기MySQL GTID 시작하기
MySQL GTID 시작하기
I Goo Lee
 
Apache Calcite Tutorial - BOSS 21
Apache Calcite Tutorial - BOSS 21Apache Calcite Tutorial - BOSS 21
Apache Calcite Tutorial - BOSS 21
Stamatis Zampetakis
 
Spotify: Automating Cassandra repairs
Spotify: Automating Cassandra repairsSpotify: Automating Cassandra repairs
Spotify: Automating Cassandra repairs
DataStax Academy
 
MongoDB WiredTiger Internals
MongoDB WiredTiger InternalsMongoDB WiredTiger Internals
MongoDB WiredTiger Internals
Norberto Leite
 
plProxy, pgBouncer, pgBalancer
plProxy, pgBouncer, pgBalancerplProxy, pgBouncer, pgBalancer
plProxy, pgBouncer, pgBalancer
elliando dias
 
Spark performance tuning - Maksud Ibrahimov
Spark performance tuning - Maksud IbrahimovSpark performance tuning - Maksud Ibrahimov
Spark performance tuning - Maksud Ibrahimov
Maksud Ibrahimov
 
Writing Continuous Applications with Structured Streaming PySpark API
Writing Continuous Applications with Structured Streaming PySpark APIWriting Continuous Applications with Structured Streaming PySpark API
Writing Continuous Applications with Structured Streaming PySpark API
Databricks
 

What's hot (20)

MySQL innoDB split and merge pages
MySQL innoDB split and merge pagesMySQL innoDB split and merge pages
MySQL innoDB split and merge pages
 
Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)
Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)
Pegasus: Designing a Distributed Key Value System (Arch summit beijing-2016)
 
State transfer With Galera
State transfer With GaleraState transfer With Galera
State transfer With Galera
 
What is data engineer?資料工程師是什麼?
What is data engineer?資料工程師是什麼?What is data engineer?資料工程師是什麼?
What is data engineer?資料工程師是什麼?
 
PostgreSQL and RAM usage
PostgreSQL and RAM usagePostgreSQL and RAM usage
PostgreSQL and RAM usage
 
PySpark Best Practices
PySpark Best PracticesPySpark Best Practices
PySpark Best Practices
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
 
Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...
Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...
Ceph Day London 2014 - Best Practices for Ceph-powered Implementations of Sto...
 
Change Data Feed in Delta
Change Data Feed in DeltaChange Data Feed in Delta
Change Data Feed in Delta
 
Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...
Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...
Everyday I'm Shuffling - Tips for Writing Better Spark Programs, Strata San J...
 
Streaming replication in practice
Streaming replication in practiceStreaming replication in practice
Streaming replication in practice
 
Oracle Data Warehouse
Oracle Data WarehouseOracle Data Warehouse
Oracle Data Warehouse
 
Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...
Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...
Streaming Design Patterns Using Alpakka Kafka Connector (Sean Glover, Lightbe...
 
MySQL GTID 시작하기
MySQL GTID 시작하기MySQL GTID 시작하기
MySQL GTID 시작하기
 
Apache Calcite Tutorial - BOSS 21
Apache Calcite Tutorial - BOSS 21Apache Calcite Tutorial - BOSS 21
Apache Calcite Tutorial - BOSS 21
 
Spotify: Automating Cassandra repairs
Spotify: Automating Cassandra repairsSpotify: Automating Cassandra repairs
Spotify: Automating Cassandra repairs
 
MongoDB WiredTiger Internals
MongoDB WiredTiger InternalsMongoDB WiredTiger Internals
MongoDB WiredTiger Internals
 
plProxy, pgBouncer, pgBalancer
plProxy, pgBouncer, pgBalancerplProxy, pgBouncer, pgBalancer
plProxy, pgBouncer, pgBalancer
 
Spark performance tuning - Maksud Ibrahimov
Spark performance tuning - Maksud IbrahimovSpark performance tuning - Maksud Ibrahimov
Spark performance tuning - Maksud Ibrahimov
 
Writing Continuous Applications with Structured Streaming PySpark API
Writing Continuous Applications with Structured Streaming PySpark APIWriting Continuous Applications with Structured Streaming PySpark API
Writing Continuous Applications with Structured Streaming PySpark API
 

Viewers also liked

IBM JVM GC_Wh apm
IBM JVM GC_Wh apmIBM JVM GC_Wh apm
IBM JVM GC_Wh apm
엑셈
 
Class Loader_Wh apm
Class Loader_Wh apmClass Loader_Wh apm
Class Loader_Wh apm
엑셈
 
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracleSQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
엑셈
 
SQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracleSQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracle
엑셈
 
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracleORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
엑셈
 
NLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracleNLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracle
엑셈
 
JVM Synchronization_Wh apm
JVM Synchronization_Wh apmJVM Synchronization_Wh apm
JVM Synchronization_Wh apm
엑셈
 
Runtime Data Areas_Wh apm
Runtime Data Areas_Wh apmRuntime Data Areas_Wh apm
Runtime Data Areas_Wh apm
엑셈
 
스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm
엑셈
 
Result Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracleResult Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracle
엑셈
 
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracleWINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
엑셈
 
TCP 연결 과정_Wh apm
TCP 연결 과정_Wh apmTCP 연결 과정_Wh apm
TCP 연결 과정_Wh apm
엑셈
 
네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm
엑셈
 
All about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apmAll about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apm
엑셈
 
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracleSPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
엑셈
 
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracleSQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
엑셈
 
Hotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apmHotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apm
엑셈
 
웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm
엑셈
 
TP-Monitor_Wh apm
TP-Monitor_Wh apmTP-Monitor_Wh apm
TP-Monitor_Wh apm
엑셈
 
배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle
배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle
배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle
엑셈
 

Viewers also liked (20)

IBM JVM GC_Wh apm
IBM JVM GC_Wh apmIBM JVM GC_Wh apm
IBM JVM GC_Wh apm
 
Class Loader_Wh apm
Class Loader_Wh apmClass Loader_Wh apm
Class Loader_Wh apm
 
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracleSQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
 
SQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracleSQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracle
 
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracleORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
 
NLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracleNLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracle
 
JVM Synchronization_Wh apm
JVM Synchronization_Wh apmJVM Synchronization_Wh apm
JVM Synchronization_Wh apm
 
Runtime Data Areas_Wh apm
Runtime Data Areas_Wh apmRuntime Data Areas_Wh apm
Runtime Data Areas_Wh apm
 
스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm
 
Result Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracleResult Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracle
 
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracleWINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
 
TCP 연결 과정_Wh apm
TCP 연결 과정_Wh apmTCP 연결 과정_Wh apm
TCP 연결 과정_Wh apm
 
네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm
 
All about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apmAll about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apm
 
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracleSPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
 
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracleSQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
 
Hotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apmHotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apm
 
웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm
 
TP-Monitor_Wh apm
TP-Monitor_Wh apmTP-Monitor_Wh apm
TP-Monitor_Wh apm
 
배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle
배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle
배치 프로그램에서 튜닝대상 SQL 추출하기_Wh oracle
 

Similar to KEEP BUFFER 활용 방안_Wh oracle

Gpdb best practices v a01 20150313
Gpdb best practices v a01 20150313Gpdb best practices v a01 20150313
Gpdb best practices v a01 20150313
Sanghee Lee
 
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4Seok-joon Yun
 
DBMS 아키텍처
DBMS 아키텍처DBMS 아키텍처
DBMS 아키텍처
HaksunLEE6
 
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
Seok-joon Yun
 
Oracle History #7
Oracle History #7Oracle History #7
Oracle History #7
Kyung Sang Jang
 
Oracle Query Optimizer 관련 Parameter_OracleParameter
Oracle Query Optimizer 관련 Parameter_OracleParameterOracle Query Optimizer 관련 Parameter_OracleParameter
Oracle Query Optimizer 관련 Parameter_OracleParameter
엑셈
 
OracleHistory1
OracleHistory1OracleHistory1
OracleHistory1
Kyung Sang Jang
 
MySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docxMySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docx
NeoClova
 
steeleye Replication
steeleye Replication steeleye Replication
steeleye Replication
시온시큐리티
 
Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)
중선 곽
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
cranbe95
 
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
PgDay.Seoul
 
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018Amazon Web Services Korea
 
Resource Governor in sql server 2008
Resource Governor in sql server 2008Resource Governor in sql server 2008
Resource Governor in sql server 2008
Bora Choi
 
Memcached의 확장성 개선
Memcached의 확장성 개선Memcached의 확장성 개선
Memcached의 확장성 개선NAVER D2
 
Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018
Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018
Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018Amazon Web Services Korea
 
Linux Performan tuning Part I
Linux Performan tuning Part ILinux Performan tuning Part I
Linux Performan tuning Part Isprdd
 
Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석
Sung wook Kang
 
Object storage의 이해와 활용
Object storage의 이해와 활용Object storage의 이해와 활용
Object storage의 이해와 활용
Seoro Kim
 
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
Amazon Web Services Korea
 

Similar to KEEP BUFFER 활용 방안_Wh oracle (20)

Gpdb best practices v a01 20150313
Gpdb best practices v a01 20150313Gpdb best practices v a01 20150313
Gpdb best practices v a01 20150313
 
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
[2015 07-06-윤석준] Oracle 성능 최적화 및 품질 고도화 4
 
DBMS 아키텍처
DBMS 아키텍처DBMS 아키텍처
DBMS 아키텍처
 
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
[2015-06-12] Oracle 성능 최적화 및 품질 고도화 1
 
Oracle History #7
Oracle History #7Oracle History #7
Oracle History #7
 
Oracle Query Optimizer 관련 Parameter_OracleParameter
Oracle Query Optimizer 관련 Parameter_OracleParameterOracle Query Optimizer 관련 Parameter_OracleParameter
Oracle Query Optimizer 관련 Parameter_OracleParameter
 
OracleHistory1
OracleHistory1OracleHistory1
OracleHistory1
 
MySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docxMySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docx
 
steeleye Replication
steeleye Replication steeleye Replication
steeleye Replication
 
Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
 
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
[pgday.Seoul 2022] PostgreSQL구조 - 윤성재
 
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
 
Resource Governor in sql server 2008
Resource Governor in sql server 2008Resource Governor in sql server 2008
Resource Governor in sql server 2008
 
Memcached의 확장성 개선
Memcached의 확장성 개선Memcached의 확장성 개선
Memcached의 확장성 개선
 
Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018
Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018
Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018
 
Linux Performan tuning Part I
Linux Performan tuning Part ILinux Performan tuning Part I
Linux Performan tuning Part I
 
Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석Windows 성능모니터를 이용한 SQL Server 성능 분석
Windows 성능모니터를 이용한 SQL Server 성능 분석
 
Object storage의 이해와 활용
Object storage의 이해와 활용Object storage의 이해와 활용
Object storage의 이해와 활용
 
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018
 

More from 엑셈

WAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apmWAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apm
엑셈
 
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracleTABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
엑셈
 
SSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracleSSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracle
엑셈
 
대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle
엑셈
 
Commit Wait Class 대기시간 감소 방안_Wh oracle
Commit Wait Class 대기시간 감소 방안_Wh oracleCommit Wait Class 대기시간 감소 방안_Wh oracle
Commit Wait Class 대기시간 감소 방안_Wh oracle
엑셈
 
BlOOM FILTER의 이해와 활용방법_Wh oracle
BlOOM FILTER의 이해와 활용방법_Wh oracleBlOOM FILTER의 이해와 활용방법_Wh oracle
BlOOM FILTER의 이해와 활용방법_Wh oracle
엑셈
 
Bind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracle
Bind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracleBind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracle
Bind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracle
엑셈
 
System Capa Planning_DBA oracle edu
System Capa Planning_DBA oracle eduSystem Capa Planning_DBA oracle edu
System Capa Planning_DBA oracle edu
엑셈
 
TX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case study
TX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case studyTX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case study
TX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case study
엑셈
 

More from 엑셈 (9)

WAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apmWAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apm
 
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracleTABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
 
SSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracleSSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracle
 
대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle
 
Commit Wait Class 대기시간 감소 방안_Wh oracle
Commit Wait Class 대기시간 감소 방안_Wh oracleCommit Wait Class 대기시간 감소 방안_Wh oracle
Commit Wait Class 대기시간 감소 방안_Wh oracle
 
BlOOM FILTER의 이해와 활용방법_Wh oracle
BlOOM FILTER의 이해와 활용방법_Wh oracleBlOOM FILTER의 이해와 활용방법_Wh oracle
BlOOM FILTER의 이해와 활용방법_Wh oracle
 
Bind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracle
Bind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracleBind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracle
Bind Peeking 한계에 따른 Adaptive Cursor Sharing 등장_Wh oracle
 
System Capa Planning_DBA oracle edu
System Capa Planning_DBA oracle eduSystem Capa Planning_DBA oracle edu
System Capa Planning_DBA oracle edu
 
TX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case study
TX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case studyTX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case study
TX락 경험에 의한 시스템 성능 저하 분석 사례_Maxgauge case study
 

KEEP BUFFER 활용 방안_Wh oracle

  • 1. Part 1 ORACLE │161 KEEP BUFFER 활용 방안 ㈜엑셈 컨설팅본부/DB컨설팅팀 장 정민 개요 Oracle 은 유저가 요청한 작업을 빠르게 처리하기 위해 Buffer Cache 라는것을 사용한다. Buffer Cache 는 SGA 에 위치하고 있으며, 오라클 인스턴스에 접속하는 모든 프로세스에 의해 공유된다. 이 Buffer Cache 는 오라클 I/O 관리의 핵심으로 자주 사용하는 데이터 파일의 블록 들을 메모리에 상주시킴으로써 물리적인 I/O Operation 을 줄이는 역할을 한다. Buffer Cache 를 효과적으로 사용하면 물리적 I/O 가 줄어들고 자연스럽게 I/O 성능문제를 해결할 수 있다. 오라클의 버전이 올라감에 따라 Buffer Cache 를 처리하는 알고리즘은 끊임없이 개선되었고, 더불어 새로운 관리 방법들이 제공되었다. Oracle 7 까지의 Buffer Cache 는 하나의 틀로서 운 영되었고, 각 Object 의 특성에 따른 차별적인 Buffer Cache 이용이 어려웠다. 이런 면을 해결 하기 위해 Oracle 8 부터 Multiple buffer pool 이라는 기능을 지원하게 되었는데, 이로 인해 각 Object 의 특성이나 엑세스 빈도 등 차별성을 고려하여 Buffer Cache 를 보다 세밀하게 관리 할 수 있게 되었다. Keep Buffer 는 이 Multiple Buffer Pool 을 구성하는 여러 영역중의 하나이다. KEEP Buffer 사용 목적 및 특성 Keep Buffer 의 사용 목적은 본래의 Buffer Cache 의 목적과 마찬가지로, Object 를 메모리에 상주시킴으로써 물리적인 I/O 를 피하는데 있다. Keep Buffer Pool 과 Default Buffer Pool 이 데이터 블록을 Cache 하거나 Flush 할 때 서로 다 른 알고리즘을 사용하지는 않는다. 그럼에도 불구하고 하나였던 Buffer Cache 영역을 Multiple Buffer Pool 로 나누게 된 이유는 Object 의 특성을 고려한 Buffer Cache 이용을 위함이다.
  • 2. 162│2013 기술백서 White Paper KEEP Buffer 의 메모리 공간은 Sequential 하게 관리된다. 한번 KEEP 된 세그먼트는 KEEP Buffer 의 메모리 공간을 모두 할당하기 전까지 메모리에 유지되다가 KEEP Buffer 공간을 모두 할당하게 되면, 가장 오래된 블록부터 default pool 로 밀려난다. 때문에 KEEP 대상이 되는 세 그먼트들의 사이즈를 정확히 계산하여 KEEP Buffer 크기를 적절히 할당해야 한다. KEEP Buffer 사용 순서 Keep Buffer 의 사용은 다음과 같은 순서로 진행한다. 1. KEEP 대상 선정하기 2. OS Memory & SGA 공간 확인 3. KEEP Buffer 설정 4. 테이블/인덱스 속성 변경 5. 테이블/인덱스 Keeping 6. KEEP 효율성 체크 7. KEEP 대상 선정 기준 KEEP 대상 선정 하기 KEEP 대상 선정에 있어서 명확한 기준점은 없다. 실제 업무를 고려하여 각 DB 의 운영환경에 맞는 대상을 선정해야 한다. 만약 KEEP 하는 대상이 아주 빈번하게 사용되는 블록 이라면, 기본 적인 Default Buffer 를 사용해도 Cache 돼있을 가능성이 높은데, 이런 경우에는 Keep Buffer 사용이 성능상의 이점을 가져오지 못한다. 반대로 자주 사용되지 않는 블록을 Keep Buffer 에 상주시킨다면, 사용하지 않는 메모리를 가지고 있는 것이기 때문에 전반적인 성능을 저하시키는 요인이 될 수도 있다. 때문에 Keep 대상을 선정하는데 있어서는 실제 업무의 고려가 필수적이다. 예를 들어 하루에 1 번만 수행되는 프로그램인데 어떻게 해서든 수행시간을 단축시켜야 하는 경우나, 많은 업무를 처리하는 시간대에 꼭 수행 되야 하는데 많은 I/O 때문에 병목현상을 일으켜서 시스템에 전반적 으로 악영향을 끼치는 프로그램 등이 있을 수 있다. 이런 프로그램들이 사용하는 Object 들이
  • 3. Part 1 ORACLE │163 Keep 대상이 될 수 있다. 그러나 위와 같은 업무 프로그램에 사용되는 모든 세그먼트를 KEEP Buffer 에 상주 시킬 수 는 없다. 그러므로 KEEP Buffer 에 상주시킬 대상은 각 DB 운영환경을 고려하여 선정해야 한다. 이외에도 크기, DML 빈도, 데이터 엑세스 빈도에 따라 Keep 하기에 적 절한 세그먼트들이 존재한다. 선정 기준[1]. 프로그램 중요도 Keep 대상 선정에 있어서 가장 중요한 부분이 바로 해당 세그먼트를 조회하는 업무 프로그램의 중요도 이다. 해당 프로그램이 중요하지 않다면 굳이 Keep Buffer 를 사용해야 할 필요가 없다. 반대로 해당 세그먼트를 조회하는 프로그램이 중요도가 아주 높고 어떻게든 수행시간을 단축해 야 한다면 프로그램 수행 빈도와 상관없이 KEEP 대상으로의 선정을 고려할 수 있다. 선정 기준[2]. 세그먼트 크기 세그먼트 크기가 일정하지 않고, 과다하게 커지는 세그먼트는 Keep Buffer 의 효율성을 떨어뜨 릴 수 있다. Keep 된 세그먼트는 Keep Buffer 의 용량이 부족하면 오래된 블록부터 Default Buffer 로 밀려나게 되는데, 크기가 계속 커지는 세그먼트가 Keep Buffer 에 존재한다면 타 세 그먼트를 조회하는 프로그램의 성능 저하를 가져올 수 있기 때문이다. 따라서 일정한 사이즈 또 는 변동 량이 심하지 않으면서 최대 크기가 일정 수준 이하인 경우의 세그먼트를 선정하는 것이 바람직하다. 예를 들면 ‘최대 크기가 10 만 블록 이하인 세그먼트’ 같은 기준을 정할 수 있다. 선정 기준[3]. Full Table Scan & Index Full Scan & Index Fast Full Scan KEEP Buffer 에 KEEP 된 세그먼트를 조회할 때 효율성을 극대화 하기 위해서는 다소 많은 량을 처리해야 하는 경우이다. Scan 범위가 넓은 비효율 Index Scan 이나 Full Table Scan, Index Fast Full Scan 으로 처리되는 세그먼트가 대상이 될 수 있다.
  • 4. 164│2013 기술백서 White Paper KEEP 대상 선정 SQLScript SELECT owner , table_name , index_name , partition_name , SUM( blocks ) AS t_blocks FROM ( SELECT sg.owner , decode( SUBSTR( s.ob_type , 1 , 5 ) , 'TABLE' , s.ob_name , 'INDEX' , ( SELECT table_name FROM dba_indexes WHERE index_name = s.ob_name ) ) AS table_name , decode( SUBSTR( s.ob_type , 1 , 5 ) , 'INDEX' , s.ob_name ) AS index_name , sg.partition_name , sg.blocks FROM ( SELECT DISTINCT object_name AS ob_name , object_type AS ob_type FROM v$sql_plan WHERE ( operation = 'TABLE ACCESS' AND options = 'FULL' ) OR ( operation = 'INDEX' AND options = 'FULL SCAN' ) OR ( operation = 'INDEX' AND options = 'FAST FULL SCAN' ) --> 선정 기준[3] ) s , dba_segments sg WHERE s.ob_name = sg.segment_name ) GROUP BY owner , table_name , index_name , partition_name HAVING SUM( blocks ) > 100000 --> 선정 기준[2]SELECT * FROM DUAL
  • 5. Part 1 ORACLE │165 OS Memory & SGA 공간 확인 OS Memory SGA 공간 확인 SQLScript $ cat /proc/meminfo MemTotal: 4055152 kB MemFree: 1390308 kB Buffers: 166768 kB Cached: 2019992 kB SwapCached: 0 kB Active: 1118484 kB Inactive: 1277864 kB ……… SGA공간 확인 SQLScript ● SGA 전체 size 확인 SELECT name , ROUND( bytes/1024/1024 ) "size(MB)" FROM V$SGAINFO; NAME size(MB) ------------------------------- ---------- Fixed SGA Size 2 Redo Buffers 5 Buffer Cache Size 48 Shared Pool Size 128 Large Pool Size 0 Java Pool Size 24 Streams Pool Size 0 Shared IO Pool Size 0 Granule Size 4 Maximum SGA Size 207 Startup overhead in Shared Pool 72 Free SGA Memory Available 0 ● Data Buffer size 확인
  • 6. 166│2013 기술백서 White Paper SELECT name , current_size FROM v$buffer_pool; NAME CURRENT_SIZE -------------------- ------------ DEFAULT 48 KEEP BUFFER 설정 KEEP Buffer 설정은 KEEP Buffer 크기와 SGA 여유공간에 따라, Online 작업 또는 Offline 작 업으로 수행한다. 이 문서의 스크립트는 SGA 영역의 메모리 관리를 수동으로 하는 경우를 바탕 으로 작성 하였다. KEEP Buffer 설정 Script @sga NAME size(MB) -------------------------------- ---------- Buffer Cache Size 500 Maximum SGA Size 1019 Free SGA Memory Available 228 @bc NAME CURRENT_SIZE -------------------- ------------ DEFAULT 500 ● KEEP Buffer 의 크기가 SGA 의 Free 공간보다 작은 경우 Online ( KEEP Buffer 100M ) SQL> alter system set db_keep_cache_size = 100M scope = both; System altered. SQL> @sga
  • 7. Part 1 ORACLE │167 NAME size(MB) -------------------------------- ---------- Buffer Cache Size 600 Maximum SGA Size 1019 Free SGA Memory Available 128 SQL> @bc NAME CURRENT_SIZE -------------------- ------------ KEEP 100 DEFAULT 500 ● KEEP Buffer 의 크기가 SGA 의 Free 공간보다 큰 경우 ( KEEP Buffer 300M ) 1. SGA 전체 크기 늘린 후 KEEP Buffer 할당 Offline 작업 필요 SQL> alter system set sga_max_size = 1100M scope = spfile; System altered. SQL> alter system set db_keep_cache_size = 300M scope = spfile; System altered. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 1169227776 bytes Fixed Size 2212696 bytes Variable Size 301993128 bytes Database Buffers 855638016 bytes Redo Buffers 9383936 bytes Database mounted. Database opened. SQL> @sga
  • 8. 168│2013 기술백서 White Paper NAME size(MB) -------------------------------- ---------- Buffer Cache Size 816 Maximum SGA Size 1115 Free SGA Memory Available 0 SQL> @bc NAME CURRENT_SIZE -------------------- ------------ KEEP 304 DEFAULT 512 => SGA 전체 크기가 1G 를 초과하면서 Granule 크기가 16Mb 로 늘어났다 이 때 지정한 값 보다 큰 16 의 배수 중 가장 작은 크기의 값이 할당된다. 2. SGA 의 다른 영역의 크기를 줄인 후 KEEP Buffer 할당 할 경우 Online 작업 가능 Online 상태에서 변경 가능 Parameter 추출 Script SELECT name , issys_modifiable FROM v$parameter WHERE name LIKE '%size%' AND issys_modifiable = 'IMMEDIATE' NAME ISSYS_MOD --------------------------------------- --------- shared_pool_size IMMEDIATE large_pool_size IMMEDIATE java_pool_size IMMEDIATE streams_pool_size IMMEDIATE db_cache_size IMMEDIATE db_2k_cache_size IMMEDIATE db_4k_cache_size IMMEDIATE db_8k_cache_size IMMEDIATE db_16k_cache_size IMMEDIATE db_32k_cache_size IMMEDIATE db_keep_cache_size IMMEDIATE db_recycle_cache_size IMMEDIATE _shared_io_pool_size IMMEDIATE
  • 9. Part 1 ORACLE │169 db_flash_cache_size IMMEDIATE db_recovery_file_dest_size IMMEDIATE result_cache_max_size IMMEDIATE workarea_size_policy IMMEDIATE max_dump_file_size IMMEDIATE => 해당 Parameter 값을 적절히 조절하여 Free Memory 확보 후 KEEP 설정 테이블/인덱스 속성 변경 테이블/인덱스 속성 변경 Script ALTER TABLE T1 STORAGE (BUFFER_POOL KEEP); --테이블 속성 변경 ALTER INDEX T1_PK STORAGE (BUFFER_POOL KEEP); --인덱스 속성 변경 ALTER TABLE P1 MODIFY PARTITION P1_1 STORAGE (BUFFER_POOL KEEP); --파티션 테이블 속성 변경 ALTER INDEX P1_ID1 MODIFY PARTITION P1_ID1_1 STORAGE (BUFFER_POOL KEEP);--파티션 인덱스 속성 변경 테이블/인덱스 Keeping Segment 의 Buffer Pool 이 KEEP 으로 설정된 테이블과 인덱스는 Query 시 KEEP Buffer 에 해당 세그먼트의 블록을 로딩하게 된다. 그러므로 최초 세그먼트를 Loading 할 때에는 Disk I/O 가 발생하게 된다. 만일 처음 실행하는 때를 포함하여 모든 Application 의 조회에서 Disk I/O 를 제거하고 싶다면, 업무가 진행되기 전에 해당 세그먼트들을 Full Table Scan 이나 Index Fast Full Scan 으로 KEEP Buffer 에 로딩시키면 된다. KEEP Buffer 효율성 판단 KEEP Buffer 의 사용에 명확한 기준이 정해져 있는 것이 아니라 운영 환경에 따라 차이가 존재 한다. 때문에 모든 운영 환경에서 같은 방법으로 효율성을 판단하기에는 무리가 있다. 하지만 다 음과 같은 자료들이 KEEP Buffer 의 효율성을 판단하는데 근거가 될 수 있다. KEEP Buffer Size & Hit Ratio SQLScript
  • 10. 170│2013 기술백서 White Paper SELECT current_size keep_size , seg_size , ROUND( seg_size/current_size*100 , 1 ) "Ratio(%)" FROM v$buffer_pool , ( SELECT SUM( bytes ) /1024 /1024 seg_size FROM dba_segments WHERE buffer_pool = 'KEEP' ) WHERE name = 'KEEP' KEEP_SIZE SEG_SIZE Ratio(%) ---------- ---------- ---------- 304 118 38.8 SELECT db_block_gets , consistent_gets , physical_reads , CASE WHEN db_block_gets+consistent_gets <> 0 THEN ROUND(( 1-( physical_reads/( db_block_gets+consistent_gets ) ) ) *100 , 2 ) END "Keep_Hit(%)" FROM v$buffer_pool_statistics WHERE name = 'KEEP' DB_BLOCK_GETS CONSISTENT_GETS PHYSICAL_READS Keep_Hit(%) ------------- --------------- -------------- ----------- 0 44474 4435 90.03 만약 KEEP Buffer 를 사용하는 Segment 크기의 총 합이 KEEP Buffer 크기보다 작은 경우, 해 당 Segment 들의 크기가 더 이상 커지지 않는다면, 한 번 KEEP 영역으로 올라간 Segment 의 Cache Hit Ratio 가 100%에 가깝게 될 것이다. 만일 KEEP Buffer 의 크기가 해당 영역을 사용하는 Segment 들의 크기보다 작다면 KEEP Buffer 영역에서 경합이 발생하고, 그로 인해 Physical I/O 가 발생하여 Cache Hit Ratio 가 떨 어질 수 있다. 이때 KEEP Buffer 의 크기를 늘려주거나 중요도가 떨어지는 Segment 의 KEEP Buffer 사용을 막는 방안을 고려 해 볼 수 있다. 반대로 KEEP Buffer 의 크기가 Segment 들의
  • 11. Part 1 ORACLE │171 크기보다 많이 크다면, 사용하지 않는 메모리 공간을 차지하고 있는 것이므로 KEEP Buffer 의 크기를 줄이는 것을 고려 해 볼 수 있다. 따라서 시스템 성능과 Segment 들의 중요도에 따라 효 율적인 KEEP Buffer 의 크기 조절이 필요하다. 다음 스크립트로 dba_hist_seg_stat 뷰를 조회하여 Segment 조회시 발생하는 I/O 발생량에 대한 AWR 정보를 확인 하여 Segment 별 효율성을 판단 할 수 있다. Segment I/O SQLScript accept i_begin_time prompt 'Enter begin time[YYYYMMDDHH24]: ' accept i_end_time prompt 'Enter end time[YYYYMMDDHH24]: ' variable v_begin_time char(10) variable v_end_time char(10) exec :v_begin_time:=&i_begin_time exec :v_end_time :=&i_end_time SELECT /*+ leading(k) */ s.dbid , decode( SUBSTR( o.object_type , 1 , 5 ) , 'TABLE' , o.object_name , 'INDEX' , ( SELECT table_name FROM dba_indexes WHERE index_name = o.object_name AND owner = k.owner ) ) AS table_name , decode( SUBSTR( o.object_type , 1 , 5 ) , 'INDEX' , o.object_name ) AS index_name , s.snap_id , TO_CHAR( w.begin_interval_time , 'yyyymmdd.hh24' ) AS begin_time , s.physical_reads_delta , s.physical_reads_direct_delta , s.physical_reads_delta + s.physical_reads_direct_delta AS total_diskio FROM sys.wrm$_snapshot w , dba_hist_seg_stat s , dba_objects o , ( SELECT owner , segment_name FROM dba_segments
  • 12. 172│2013 기술백서 White Paper WHERE buffer_pool = 'KEEP' ) k WHERE w.begin_interval_time >= to_timestamp( '2013062510' , 'yyyymmddhh24' ) AND w.end_interval_time <= to_timestamp( '2013062518' , 'yyyymmddhh24' ) AND w.snap_id = s.snap_id AND w.dbid = s.dbid AND w.instance_number = s.instance_number AND s.obj# = o.object_id AND k.segment_name = o.object_name AND k.owner = o.owner ORDER BY 2 , 3 , 5 결론 KEEP Buffer 를 사용하는데 있어 가장 중요한 것이 업무의 반영일 것이다. 자주 사용하는 Object 들만 상주하는 Buffer Cache 하나만 사용하는 것이 시스템 전체의 관점에서 보면 효율 적일 수도 있다. 하지만 업무의 중요성이나 특성을 고려한다면 다른 결과가 나올 수 있다. 적게 실행 되더라도 중요도가 높은 업무가 있을 수 있고, 수행시간 단축이 매우 중요한 업무가 있을 수 있다. 이러한 업무에 대한 특성을 반영한 운영계획을 세우는데 있어서, KEEP Buffer 를 효율 적으로 사용 할 수 있다면, 시스템 성능 향상에 큰 도움이 될 것이다.