[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c の場合 by Japan Oracle User Group 山下正

100GB クラスのSGA を眺めてみよう。 Oracle Database 12c の場合
Japan Oracle User Group
Tadashi Yamashita
@tadayima_jp
#dbts2014 #jpoug
dbtech showcase Tokyo 2014
2014/11/13

Japan Oracle User Group
Home page
www.jpoug.org
Doorkeeperコミュニティ
http://jpoug.doorkeeper.jp/
Facebookページ
http://www.facebook.com/jpougfan?sk=wall
Googleグループ
https://groups.google.com/group/jpoug/

コンテンツ
•データベースとインスタンス
•仮想メモリとSGA
•使用量を測ってみる
•地図を描いてみる
•もう一度地図を描いてみる
•SGA Heat Map

データベースとインスタンス
Oracle Database Online Documentation 12cRelease 1 (12.1)Database Administration
https://docs.oracle.com/database/121/CNCPT/startup.htm#CNCPT89033
Oracle Database を学習する順番
-SQLの書き方
-Oracle Database の構造
-データベースとは
-インスタンスとは
-バックアップ・リカバリ
-データベースの運用
-チューニング
インスタンスとはメモリとプロセス群からなる
-Database Buffer Cache ってホントに四角いのか？
-RedoLogBufferって丸いの？
-SharedPoolの断片化ってなに？
…
<<本日のテーマ>>
実際にメモリ空間をのぞいてみよう！
※今回はバッファ・キャッシュだけ

仮想メモリとSGA
0x0000000000000000
0xffffffffffffffff
0x0000000000400000
text
data
BSS
heap
・・・
shared memory
stack
・・・
OS視点で見る

# ps-elf | grepora_smon
0 S root 20247 27324 0 77 0 -16357 pipe_w12:01 pts/2 00:00:00 grepora_smon
0 S ora121 33571 0 75 0 -26302179 -Nov03 ? 00:00:03 ora_smon_ora121
Oracle関連プロセスのPIDを特定してから、下記のコマンドでメモリ空間をのぞいてみる
-pmap-x PID
-ipcs
-cat /proc/PID/maps

# pmap-x 3357
3357: ora_smon_ora121
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 267508 23860 0 r-x--oracle
0000000010b3d000 2564 268 52 rw---oracle
0000000010dbe000 196 68 32 rw---[ anon ]
00000000191d4000 300 0 0 rw---[ anon ]
0000000060000000 4 0 0 r--s-[ shmid=0xc510008 ]
0000000060001000 4404 496 284 rw-s-[ shmid=0xc510008 ]
0000000070000000 104595456 42280 36580 rw-s-[ shmid=0xc518009 ]
0000001960000000 257736 3428 2964 rw-s-[ shmid=0xc52000a ]
0000001970000000 32 4 0 rw-s-[ shmid=0xc52800b ]
0000003752000000 112 104 0 r-x--ld-2.5.so
000000375221c000 4 0 0 r----ld-2.5.so
000000375221d000 4 0 0 rw---ld-2.5.so
0000003752400000 1340 476 0 r-x--libc-2.5.so
....

# ipcs
------共有メモリセグメント--------
キーshmid所有者権限バイトnattch状態
0x00000000 4915202 root 644 80 2
0x00000000 4947972 root 644 16384 2
0x00000000 4980741 root 644 280 2
0x00000000 18317319 ora121 600 393216 2 対象
0x00000000 206635016 ora121 640 4513792 162
0x00000000 206667785 ora121 640 107105746944 81
0x00000000 206700554 ora121 640 263921664 81
0x700cc044 206733323 ora121 640 32768 81
0x00000000 18350092 ora121 600 393216 2 対象
0x00000000 18382861 ora121 600 393216 2 対象
0x00000000 18415630 ora121 600 393216 2 対象
.......

# cat /proc/3357/maps
00400000-1093d000 r-xp00000000 08:03 81433700 /home/ora121/app/ora121/product/12.1.0/dbhome_1/bin/oracle
10b3d000-10dbe000 rw-p 1053d000 08:03 81433700 /home/ora121/app/ora121/product/12.1.0/dbhome_1/bin/oracle
10dbe000-10def000 rw-p 10dbe000 00:00 0
191d4000-1921f000 rw-p 191d4000 00:00 0 [heap]
60000000-60001000 r--s 00000000 00:09 206635016 /SYSV00000000 (deleted)
60001000-6044e000 rw-s 00001000 00:09 206635016 /SYSV00000000 (deleted)
70000000-1960000000 rw-s 00000000 00:09 206667785 /SYSV00000000 (deleted)
1960000000-196fbb2000 rw-s 00000000 00:09 206700554 /SYSV00000000 (deleted)
1970000000-1970008000 rw-s 00000000 00:09 206733323 /SYSV700cc044 (deleted)
3752000000-375201c000 r-xp00000000 08:03 20250947 /lib64/ld-2.5.so
375221c000-375221d000 r--p 0001c000 08:03 20250947 /lib64/ld-2.5.so
375221d000-375221e000 rw-p 0001d000 08:03 20250947 /lib64/ld-2.5.so
3752400000-375254f000 r-xp00000000 08:03 20250948 /lib64/libc-2.5.so.............

0x0000000000000000
0xffffffffffffffff
0x0000000000400000
text
data
BSS
heap
・・・
shared memory
stack
・・・
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
Oracle関連共有メモリのアドレスをマッピング
※カッコ内は先頭アドレスからのバイト位置

SQL> oradebugsetmypid
SQL> oradebugipc
Oracle視点で見る

Processing Oradebugcommand 'ipc'
Dump of unix-generic skgmcontext
areaflags00001fb7
………
Handle: 0x28a14740 `/home/ora121/app/ora121/product/12.1.0/dbhome_1ora121'
Dump of unix-generic realm handle `/home/ora121/app/ora121/product/12.1.0/dbhome_1ora121', flags = 00000010
key 1879883844 actual_key1879883844 num_areas4 num_subareas4
primary shmid: 206733323 primary sanum3 version 3
deferred alloc: FALSE (0) def_post_create: FALSE (0) exp_memlock: 100G
Area #0 `Fixed Size' containing Subareas 2-2
Total size 000000000044daa8 Minimum Subarea size 00000000
Area Subarea ShmidSegment AddrStable AddrActual Addr
0 2 206635016 0x00000060000000 0x000000600000000x00000060000000
Subarea size Segment size Req_ProtectCur_protect
000000000044e000 000000000044e000default readwrite
Area #1 `Variable Size' containing Subareas 0-0
Total size 00000018f0000000 Minimum Subarea size 10000000
1 0 206667785 0x00000070000000 0x000000700000000x00000070000000
00000018f0000000 00000018f0000000default readwrite
………
Fixed Size
Actual Addr: 0x00000060000000
Variable Size
Actual Addr: 0x00000070000000

………
Area #2 `Redo Buffers' containing Subareas 1-1
Total size 000000000fbb2000 Minimum Subarea size 00001000
2 1 206700554 0x00001960000000 0x000019600000000x00001960000000
000000000fbb2000 000000000fbb2000default readwrite
Area #3 `skgmoverhead' containing Subareas 3-3
Total size 0000000000008000 Minimum Subarea size 00000000
3 3 206733323 0x00001970000000 0x000019700000000x00001970000000
0000000000008000 0000000000008000 default readwrite
*********************** Dumping process map ********************
00400000-1093d000 r-xp00000000 08:03 81433700 /home/ora121/app/ora121/product/12.1.0/dbhome_1/bin/oracle
10b3d000-10dbe000 rw-p 1053d000 08:03 81433700 /home/ora121/app/ora121/product/12.1.0/dbhome_1/bin/oracle
10dbe000-10def000 rw-p 10dbe000 00:00 0
28a10000-28a5b000 rw-p 28a10000 00:00 0 [heap]
60000000-60001000 r--s 00000000 00:09 206635016 /SYSV00000000 (deleted)
60001000-6044e000 rw-s 00001000 00:09 206635016 /SYSV00000000 (deleted)
70000000-1960000000 rw-s 00000000 00:09 206667785 /SYSV00000000 (deleted)
1960000000-196fbb2000 rw-s 00000000 00:09 206700554 /SYSV00000000 (deleted)
1970000000-1970008000 rw-s 00000000 00:09 206733323 /SYSV700cc044 (deleted)………
Redo Buffers
Actual Addr: 0x00001960000000
Skgmoverhead
Actual Addr: 0x00001970000000

0x0000000000000000
0xffffffffffffffff
0x0000000000400000
text
data
BSS
heap
・・・
shared memory
stack
・・・
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
Fixed Area
Variable Area
Redo Buffer
skgmoverhead
256MB
99.75GB
256MB
Oracle視点で見る

SQL> select * from v$sga;
NAME VALUE CON_ID
-------------------------------------------
Fixed Size 4512424 0
Variable Size 6710887768 0
Database Buffers 100394860544 0
Redo Buffers 263921664 0
V$SGAで確認

NAME
VALUE
SIZEfrom ADDRESS
Fixed Size
4512424
256MB
=268435456
VariableSize(a)
6710887768
(a)+(b)=107105748312
99.75GB
=107105746944
Database Buffers(b)
100394860544
Redo Buffers
263921664
256MB
=268435456
V$SGAの結果とADDRESSでは少し差分がある

NAME
VALUE
SIZEfrom ADDRESS
Fixed Size
4512424
256MB
=268435456
VariableSize(a)
6710887768
(a)+(b)=107105748312
△1368
99.75GB
=107105746944
Database Buffers(b)
100394860544
Redo Buffers
263921664
256MB
=268435456
Variable Sizeで1368byteの違い…

areaflags00001fb7
………
0 2 206635016 0x00000060000000 0x000000600000000x00000060000000
1 0 206667785 0x00000070000000 0x000000700000000x00000070000000
………
Fixed Size
Actual Addr: 0x00000060000000
Variable Size
Actual Addr: 0x00000070000000
Total size 000000000044daa8Minimum Subarea size 00000000
Area Subarea ShmidSegment AddrStable Addr
0 2 206635016 0x00000060000000 0x00000060000000
Subarea size Segment size Req_Protect
000000000044e000000000000044e000
1368

SQL> select * from v$sgainfo;
NAME BYTES RESIZEABL CON_ID
-----------------------------------------------------------
Fixed SGA Size 4512424 No 0
Redo Buffers 263921664 No 0
Buffer Cache Size 100394860544 Yes 0
In-Memory Area Size 0 No 0
Shared Pool Size 5368709120 Yes 0
Large Pool Size 536870912 Yes 0
Java Pool Size 805306368 Yes 0
.....
Shared IO Pool Size 536870912 Yes 0
Data Transfer Cache Size 0 Yes 0
Granule Size 268435456 No 0
Maximum SGA Size 107374182400 No 0
.....
sum(6710886400)
!= v$sga.value[Variable Size] (6710887768)
△1368
= v$sga.value[Database Buffers]
V$SGAとV$SGAINFOの結果も少しちがう

NAME
VALUE
SIZEfrom ADDRESS
Fixed Size
4512424
256MB
=268435456
VariableSize(a)
6710887768
(a)+(b)=107105748312
△1368
99.75GB
=107105746944
Database Buffers(b)
100394860544
Redo Buffers
263921664
△4513792(4408K)
256MB
=268435456
初期化パラメータ
log_buffer= 255819776
RedoBufferの割り当てサイズも、ちと違う

LOG_BUFFER
特性説明
パラメータ・タイプ大整数
デフォルト値5 MBから32 MB(SGAのサイズ、CPUの数、およびオペレーティング・システムが32ビット版と64ビット版のどちらかに応じて異なる)
変更可能いいえ
値の範囲2MB以上。上限は、オペレーティング・システム依存。
基本いいえ
LOG_BUFFERには、REDOエントリをREDOログ・ファイルにバッファリングするときに使用されるメモリー容量を、バイト単位で指定します。REDOログ・エントリには、データベース・ブロック・バッファに加えられた変更の記録が含まれています。 REDOログ・エントリは、LGWRプロセスによってログ・バッファからREDOログ・ファイルに書き込まれます。
ログ・バッファ・サイズはシステム内のREDOストランドの数に応じて異なります。REDOストランドは16個のCPUごとに1つ割り当てられ、そのデフォルト・サイズは2MBです。Oracleによってインスタンスごとに2つ以上のREDOストランドが割り当てられます。ログ・バッファ・サイズが指定されていない場合には、REDOグラニュル内の残りのメモリーがログ・バッファに提供されます。
Oracle® Databaseリファレンス12c リリース1 (12.1) https://docs.oracle.com/cd/E57425_01/121/REFRN/refrn10094.htm#CHDFGEAF

areaflags00001fb7
………
0 2 206635016 0x00000060000000 0x000000600000000x00000060000000
1 0 206667785 0x00000070000000 0x000000700000000x00000070000000
………
Fixed Size
Actual Addr: 0x00000060000000
Variable Size
Actual Addr: 0x00000070000000
Area Subarea ShmidSegment AddrStable Addr
0 2 206635016 0x00000060000000 0x00000060000000
Subarea size Segment size Req_Protect
000000000044e000000000000044e000
4513792(4408K)

0x0000000000000000
0xffffffffffffffff
0x0000000000400000
text
data
BSS
heap
・・・
shared memory
stack
・・・
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
Fixed Area
Variable Area
Redo Buffer
skgmoverhead
256MB
99.75GB
256MB
Database Buffer = 100394860544(93.5GB)
Shared Pool + Large Pool + Java Pool = 6710886400(6.25GB)
Oracle視点で確認した内訳

動的パラメータ
PARAMETER VALUE
-----------------------------------------
__db_cache_size99857989632
__java_pool_size805306368
__large_pool_size536870912
__pga_aggregate_target16106127360
__shared_io_pool_size536870912
__shared_pool_size5368709120
__streams_pool_size0
.....
DatabaseBufferのサイズが動的パラメータの値と違う…

動的パラメータ
PARAMETER VALUE
-----------------------------------------
__db_cache_size99857989632
__java_pool_size805306368
__large_pool_size536870912
__pga_aggregate_target16106127360
__shared_io_pool_size536870912
__shared_pool_size5368709120
__streams_pool_size0
.....
99857989632(93GB)+536870912(512MB)
= 100394860544(93.5GB)
でも、Oracleが自動割り当てするshared_io_pool_size 分を考慮して…

使用量を測ってみる
•DatabaseBuffer
•X$BH.BA
SQL> descx$bh
名前NULL? 型
-----------------------------------------------------
ADDR RAW(8)
INDX NUMBER
……
FLAG NUMBER
……
LRU_FLAG NUMBER
……
DBABLK NUMBER
CLASS NUMBER
STATE NUMBER
……
OBJ NUMBER
BA RAW(8)
.....

SQL> select count(*),min(BA),max(BA) from x$bh
COUNT(*) MIN(BA) MAX(BA)
------------------------------------------------------
10471 00000008D1484000 00000017CF628000
SQL> select round((to_number(max(BA),'XXXXXXXXXXXXXXXX')
2 -to_number(min(BA),'XXXXXXXXXXXXXXXX'))/1024/1024/1024,2) GB
3 from x$bh;
GB
-------------
59.97
レンジで見ると約60GB…

0x0000000000000000
0xffffffffffffffff
0x0000000000400000
text
data
BSS
heap
・・・
shared memory
stack
・・・
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
Fixed Area
Variable Area
Redo Buffer
skgmoverhead
256MB
256MB
Database Buffer
0x00000008D1484000
0x00000017CF628000
59.97GB
99.75GB

SQL> select round(count(*) * 8192 /1024 /1024 /1024 ,2) GB from x$bh;
GB
-------------
.08
キャッシュされているデータ・ブロックの数を数えると約80MB…

地図を描いてみる
がらがら

拡大しても、がらがら
1セルは1MB分の領域に相当
よって、8192bytesのデータ・ブロックは最大 128block格納できる

0
1
2
3
16
・・・
98
99
361
(A)
(B)
362
363
・・・
820
69
(c)
128
9
・・・
974
975
(A)= 361 * 100 * 1024 * 1024= 37853593600 = 0x00000008D0400000
(B)=361 * 100 * 1024 * 1024 + 16 * 1024 * 1024 = 37870370816 = 0x00000008D1400000
(C)= 820 *100 * 1024 * 1024 = 85983232000 =0x0000001405000000
1cell : 1MB
各セルを1MBの領域で表現しています
各セルに相対する仮想メモリアドレス上の先頭アドレスは下記のように算出できます

SQL> select owner,object_name,object_type
2 from dba_objects,x$bh
3 where trunc(to_number(ba,'XXXXXXXXXXXXXXXX')/1024/1024,0) = 820*100
4 and ( obj=object_idor obj= data_object_id)
5 group by owner,object_name,object_type;
OWNER OBJECT_NAME OBJECT_TYP
----------------------------------------
TTT T1 TABLE
各セルに相当する仮想メモリアドレス上に存在するオブジェクトを確認する

set linesize500
col valfor a400
set pagesize10
with ba_base(i) as
( select trunc(trunc(to_number(min(ba),'XXXXXXXXXXXXXXXX')/1024/1024,0)/100,0)*100 from x$bh
union all
select i+1
from ba_base
where i+1 <= ( select ceil(to_number(max(ba),'XXXXXXXXXXXXXXXX')/1024/1024) from x$bh)
)
select ba_range2
, sys_connect_by_path(decode(count_no,null,' ',to_char(count_no,'FM000')),'-') val
from (
select trunc(ba_base.i/100,0) ba_range2
, count_no
, row_number() over ( partition by trunc(ba_base.i/100,0) order by ba_base.i) ba_range2_order
, count(*) over ( partition by trunc(ba_base.i/100,0)) cnt
from ( select trunc(to_number(bh.ba,'XXXXXXXXXXXXXXXX')/1024/1024,0) ba_range
, count(bh.ba) count_no
from x$bhbh
group by trunc(to_number(bh.ba,'XXXXXXXXXXXXXXXX')/1024/1024,0)
order by ba_range
) bh
, ba_base
where ba_base.i= bh.ba_range(+)
)
where level = cnt
start with ba_range2_order = 1
connect by prior ba_range2 = ba_range2
and prior ba_range2_order = ba_range2_order-1
SGA MAP(X$BH)用のSQL

もう一度地図を描いてみる
今度は、
めいっぱい
詰め込む

バッファ・キャッシュをフルに埋めてみた

ブロックサイズ8192 bytes の環境なので1セル(1MB) あたり、128blocks 収まっている

これなに？
これなに？

すみません。
よくわかりません。
これなに？

BufferCache: 246MB+ Blank : 10MB
(repeat)
白い縞模様は一定間隔で現れています

SQL> select * from v$sgainfo;
NAME BYTES RESIZEABL CON_ID
-----------------------------------------------------------
.....
Granule Size 268435456 No 0
.....
BufferCache: 246MB+ Blank : 10MB ・・・Granule
BufferCache: 246MB+ Blank : 10MB・・・Granule
BufferCache: 246MB+ Blank : 10MB・・・Granule
(repeat)
どうやらGranule 単位…

SQL>select avg(
2 (length( ADDR ))+
3 (length( INDX ))+
4 (length( INST_ID ))+
5 (length( CON_ID ))+
6 (length( HLADDR ))+
7 (length( BLSIZ ))+
.......
58 (length( TCH ))+
59 (length( TIM ))+
60 (length( CR_RFCNT ))+
61 (length( SHR_RFCNT ))) avg_len_bh
62 ,count(*)
63 from x$bhwhere rownum< 1000;
AVG_LEN_BH COUNT(*)
--------------------------
348.690690691 999
Buffer Header Length
≒350 bytes

Buffer Header Size / Granule
-128 blocks / 1MB * 246 MB = 31488 blocks
-31488 blocks * 350 bytes = 11020800 bytes(≒10.5MB)
上記より、、
-246MB内に格納されるデータ・ブロックは31488 blocks
-データ・ブロックの管理情報であるバッファ・ヘッダは1データ・ブロックあたり約350 bytes
-よって、246MB分のデータ・ブロック（31488 blocks）に対して、約10.5MBのバッファ・ヘッダが必要
-これらが1Granule(当該環境では256MB)に収まっていると考えられる

すみません。
よくわかりません。
バッファ・ヘッダみたいです。

0x0000000000000000
0xffffffffffffffff
0x0000000000400000
text
data
BSS
heap
・・・
shared memory
stack
・・・
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
0x0000000060000000( 1.5 GB)
0x0000000070000000( 1.75GB)
0x0000001960000000(101.5 GB)
0x0000001970000000 (101.75GB)
Fixed Area
Variable Area
Redo Buffer
skgmoverhead
256MB
256MB
Database Buffer
0x0000000080002000
0x00000017CF628000
93.24GB
99.75GB

SGAHeat Map
Before Data Load
80MB
データがあまりキャッシュされていない状態
60GB弱のレンジ内に、80MB程度しかキャッシュされておらず、データ・ブロックはまばらに配置されている
データ・ブロックがバッファ・キャッシュを埋め尽くすまでの途中経過を見てみると、、、

SGAHeat Map
40GB
40GB程度キャッシュされている状態
データ・ブロックは仮想メモリアドレスの高い方（図の下方）から徐々に埋まってくる

SGAHeat Map
50GB
当初の60GB弱のレンジが少しずつ広がり始めている状態

SGAHeat Map
80GB
仮想メモリアドレスの高い方から埋まりつつある
データ・ブロックが埋まった領域において、バッファ・ヘッダが格納されているとみられる白いスリット上の領域が確認できる

SGAHeat Map
Buffer Cache Full
93GB
バッファ・キャッシュがほぼ埋まった状態で、赤い領域（Hot Buffer）が発生していることが確認できる

SGAHeat Map
Buffer Rewrite
93GB
バッファ・キャッシュがほぼ埋まった状態で、データのロード処理を継続していると、赤い領域（Hot Buffer）がバッファ・キャッシュのメモリ空間のほぼ中段の位置で発生していることが確認できる
LRUリストのCOLD領域に位置するデータ・ブロックがちょうどこの位置にはキャッシュされていると推測される

SGAHeat Map
End of Data Load
93GB
データのロード処理を停止すると、赤い領域（Hot Buffer）が消える
メモリ上の激しいバッファの書き換えが収まったためと考えられる

SGAHeat Map
•幼児
同一BAのBHレコード
1MB / 8192 bytes = 128 blocks
128 blocks 以上表示されるエリアを”赤いセル”で表現
実際には、1MBのエリアに8192 bytes のブロックが128 blocks 以上存在するはずはない。
X$BHを検索中にダーティーリードが発生した結果、バッファー・キャッシュ内の書き換えが激しいアドレスのブロックが複数現れてしまうことで、見かけ上128 blocks以上存在するように見える。つまり、ホット・バッファ。
赤い領域（Hot Buffer）の拡大イメージ

SGAHeat Map
SQL> select ADDR,INDX,BA,NXT_HASH,PRV_HASH
2 fromx$bh
3 where bain ( select ba
4 from x$bh
5 where trunc(to_number(ba,'XXXXXXXXXXXXXXXX')/1024/1024,0) = 639*100+16
6 group by ba
7 having count(ba) > 2
8 )
9 order by ba;
ADDR INDX BA NXT_HASH PRV_HASH
-------------------------------------------------------------------------------------------------------
00002B4D0CC34E60 9353301 0000000F9ACAE000 000000193D50AF78 000000193D50AF78
00002B4D0CC35518 8077473 0000000F9ACAE000 000000195B920E80 000000195B920E80
00002B4D0CC35268 11432377 0000000F9ACAE000 0000001920DAA7B8 0000001920DAA7B8
00002B4D0CC35518 8113471 0000000F9ACC6000 000000193BB8CB98 000000193BB8CB98
00002B4D0CC34FB8 9389297 0000000F9ACC6000 000000194D700710 000000194D700710
00002B4D0CC35110 11069055 0000000F9ACC6000 000000195F5B9720 000000195F5B9720
00002B4D0CC34FB8 9425309 0000000F9ACDE000 000000195D424540 000000195D424540
00002B4D0CC34E60 10705717 0000000F9ACDE000 000000193F042E78 000000193F042E78
00002B4D0CC34FB8 8149442 0000000F9ACDE000 000000193BD23C88 000000193BD23C88
00002B4D0CC34FB8 9461313 0000000F9ACF6000 000000195D5BB630 000000195D5BB630
00002B4D0CC35518 10342351 0000000F9ACF6000 000000194EA56040 000000194EA56040
00002B4D0CC34FB8 8185434 0000000F9ACF6000 000000194BF19430 000000194BF19430
12行が選択されました。
バッファ・アドレスが重複している（ように見える）ケース

おさらい
-OracleのSGAがOS視点でメモリ空間のどの位置に存在しているかを確認してみた
-今回は、さらにSGA内のバッファ・キャッシュがどのように配置されているかをイメージで確認できるようにトライしてみた
-その結果、バッファ・キャッシュにキャッシュされるデータ・ブロックはデータ量が少ないときはまばらにキャッシュされ、必ずしも連続してキャッシュされるわけではないことが判明
-また、データ・ブロックがキャッシュされていく場合、仮想メモリアドレスの上位側から徐々に埋まっていくことを把握
-バッファ・キャッシュがほぼデータ・ブロックで埋まった状態では、データ・ブロック以外にバッファ・ヘッダの領域が仮想メモリアドレス上で一定間隔で確保されていることが明らかに
-この間隔はGranule単位であると思われる(当環境では256MB)

おさらい２
-このバッファ・ヘッダは1データ・ブロックあたり約350bytesであると見込まれる
-この領域を確保するため、バッファ・キャッシュ上におよそ4%程度（今回の結果から導出）のバッファ・ヘッダ領域が必要
-つまり、100GBのバッファ・キャッシュを設定した場合、実際にキャッシュされるデータ・ブロックはおよそ96GB程度になると思われる
-バッファ・キャッシュがほぼ埋まった状態で、さらに新しいデータ・ブロックをキャッシュする場合は、仮想メモリ上でもバッファの書き換えが発生する
-書き換え対象になるデータ・ブロックは、Oracle Database のバッファ・キャッシュ用のLRU管理により選択される

おさらい３
-書き換え対象になるバッファはLRUリストのCOLD側にあるデータ・ブロックを格納しているバッファになる
-バッファ・キャッシュがほぼ未使用の状態から開始した今回の検証では、前半にキャッシュされたデータ・ブロックはLRUリストのHOT側で管理され、後半にキャッシュされたデータ・ブロックはCOLD側にキャッシュされた可能性がある
-よって、バッファ・キャッシュがほぼ100%埋まったあと、バッファ・キャッシュからの追い出しが行われるデータ・ブロックは、仮想メモリアドレス上の下位のアドレス（資料中の図の上側）に位置していた可能性が高い
-そのため、資料中では赤い領域（Hot Buffer）が中段より上方で発生していたと考えられる(※)
※当資料ではバッファ・キャッシュの下位アドレス側のイメージを載せている為、絵的に下の方が赤くなっているように見えますが、実際のHot Buffer は全体の上側（仮想メモリアドレスの下位側）に偏っています。

[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c の場合 by Japan Oracle User Group 山下正

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to [db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c の場合 by Japan Oracle User Group 山下正

Similar to [db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c の場合 by Japan Oracle User Group 山下正 (20)

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (12)

[db tech showcase Tokyo 2014] L35: 100GB クラスの SGA を眺めてみよう。Oracle Database 12c の場合 by Japan Oracle User Group 山下正