[db tech showcase tokyo 2014] l35: 100gb クラスの sga を眺めてみよう。oracle database...

100GB クラスの SGA を眺めてみよう。Oracle Database 12c の場合

Japan Oracle User Group

Tadashi Yamashita

@tadayima_jp

#dbts2014 #jpoug

db tech 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/

http://www.jpoug.org/

http://jpoug.doorkeeper.jp/

http://www.facebook.com/jpougfan?sk=wall

https://groups.google.com/group/jpoug/

コンテンツ

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

データベースとインスタンス

Oracle Database Online Documentation 12cRelease 1 (12.1) Database Administrationhttps://docs.oracle.com/database/121/CNCPT/startup.htm#CNCPT89033

Oracle Database を学習する順番- SQLの書き方- Oracle Database の構造

- データベースとは- インスタンスとは

- バックアップ・リカバリ- データベースの運用- チューニング

インスタンスとはメモリとプロセス群からなる- Database Buffer Cache ってホントに四角いのか？

- Redo Log Bufferって丸いの？- Shared Poolの断片化ってなに？

…

<<本日のテーマ>>

実際にメモリ空間をのぞいてみよう！※今回はバッファ・キャッシュだけ

コンテンツ


仮想メモリとSGA0x0000000000000000

0xffffffffffffffff

0x0000000000400000text

data

BSS

heap・・・

shared memory

stack

・・・

OS視点で見る

仮想メモリとSGA

# ps -elf | grep ora_smon

0 S root 20247 27324 0 77 0 - 16357 pipe_w 12:01 pts/2 00:00:00 grep ora_smon

0 S ora121 3357 1 0 75 0 - 26302179 - Nov03 ? 00:00:03 ora_smon_ora121

Oracle関連プロセスのPIDを特定してから、下記のコマンドでメモリ空間をのぞいてみる- pmap -x PID- ipcs- cat /proc/PID/maps

仮想メモリとSGA# pmap -x 33573357: 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

....

仮想メモリとSGA# 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 対象

.......

仮想メモリとSGA# cat /proc/3357/maps

00400000-1093d000 r-xp 00000000 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-xp 00000000 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-xp 00000000 08:03 20250948 /lib64/libc-2.5.so.............

仮想メモリとSGA0x0000000000000000

0xffffffffffffffff

0x0000000000400000text

data

BSS

heap・・・

shared memory

stack

・・・

0x0000000060000000 ( 1.5 GB)

0x0000000070000000 ( 1.75GB)

0x0000001960000000 (101.5 GB)

0x0000001970000000 (101.75GB)

Oracle関連共有メモリのアドレスをマッピング※カッコ内は先頭アドレスからのバイト位置

仮想メモリとSGASQL> oradebug setmypid

SQL> oradebug ipc Oracle視点で見る

仮想メモリとSGAProcessing Oradebug command 'ipc'

Dump of unix-generic skgm context

areaflags 00001fb7

………

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_key 1879883844 num_areas 4 num_subareas 4

primary shmid: 206733323 primary sanum 3 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 Shmid Segment Addr Stable Addr Actual Addr

0 2 206635016 0x00000060000000 0x00000060000000 0x00000060000000

Subarea size Segment size Req_Protect Cur_protect

000000000044e000 000000000044e000 default readwrite

Area #1 `Variable Size' containing Subareas 0-0

Total size 00000018f0000000 Minimum Subarea size 10000000


1 0 206667785 0x00000070000000 0x00000070000000 0x00000070000000


00000018f0000000 00000018f0000000 default readwrite

………

Fixed SizeActual Addr : 0x00000060000000

Variable SizeActual Addr : 0x00000070000000

仮想メモリとSGA………

Area #2 `Redo Buffers' containing Subareas 1-1

Total size 000000000fbb2000 Minimum Subarea size 00001000


2 1 206700554 0x00001960000000 0x00001960000000 0x00001960000000


000000000fbb2000 000000000fbb2000 default readwrite

Area #3 `skgm overhead' containing Subareas 3-3

Total size 0000000000008000 Minimum Subarea size 00000000


3 3 206733323 0x00001970000000 0x00001970000000 0x00001970000000


0000000000008000 0000000000008000 default readwrite

*********************** Dumping process map ********************

00400000-1093d000 r-xp 00000000 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 BuffersActual Addr : 0x00001960000000

Skgm overheadActual Addr : 0x00001970000000

仮想メモリとSGA0x0000000000000000

0xffffffffffffffff

0x0000000000400000text

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

skgm overhead

256MB

99.75GB

256MB

Oracle視点で見る

仮想メモリとSGASQL> 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 SIZE from ADDRESS

Fixed Size 4512424 256MB=268435456

Variable Size(a) 6710887768 (a)+(b)=107105748312 99.75GB=107105746944

Database Buffers(b) 100394860544

Redo Buffers 263921664 256MB=268435456

V$SGAの結果とADDRESSでは少し差分がある



Fixed Size 4512424 256MB=268435456

Variable Size(a) 6710887768 (a)+(b)=107105748312△1368

99.75GB=107105746944


Redo Buffers 263921664 256MB=268435456

Variable Sizeで1368byteの違い…



areaflags 00001fb7

………









0 2 206635016 0x00000060000000 0x00000060000000 0x00000060000000






1 0 206667785 0x00000070000000 0x00000070000000 0x00000070000000



………





areaflags 00001fb7

………









0 2 206635016 0x00000060000000 0x00000060000000 0x00000060000000






1 0 206667785 0x00000070000000 0x00000070000000 0x00000070000000



………





Area Subarea Shmid Segment Addr Stable Addr

0 2 206635016 0x00000060000000 0x00000060000000

Subarea size Segment size Req_Protect

000000000044e000 000000000044e000

1368

仮想メモリとSGASQL> 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の結果も少しちがう



Fixed Size 4512424 256MB=268435456

Variable Size(a) 6710887768 (a)+(b)=107105748312△1368

99.75GB=107105746944


Redo Buffers 263921664△4513792(4408K)

256MB=268435456

初期化パラメータlog_buffer = 255819776

Redo Bufferの割り当てサイズも、ちと違う

仮想メモリとSGALOG_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



areaflags 00001fb7

………









0 2 206635016 0x00000060000000 0x00000060000000 0x00000060000000






1 0 206667785 0x00000070000000 0x00000070000000 0x00000070000000



………





Area Subarea Shmid Segment Addr Stable Addr

0 2 206635016 0x00000060000000 0x00000060000000

Subarea size Segment size Req_Protect

000000000044e000 000000000044e000

4513792(4408K)

仮想メモリとSGA0x0000000000000000

0xffffffffffffffff

0x0000000000400000text

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

skgm overhead

256MB

99.75GB

256MB

Database Buffer = 100394860544(93.5GB)

Shared Pool + Large Pool + Java Pool = 6710886400(6.25GB)

Oracle視点で確認した内訳

仮想メモリとSGA動的パラメータ

PARAMETER VALUE

-------------------------- ---------------

__db_cache_size 99857989632

__java_pool_size 805306368

__large_pool_size 536870912

__pga_aggregate_target 16106127360

__shared_io_pool_size 536870912

__shared_pool_size 5368709120

__streams_pool_size 0

.....

Database Bufferのサイズ

が動的パラメータの値と違う…

仮想メモリとSGA動的パラメータ

PARAMETER VALUE

-------------------------- ---------------

__db_cache_size 99857989632

__java_pool_size 805306368

__large_pool_size 536870912

__pga_aggregate_target 16106127360

__shared_io_pool_size 536870912

__shared_pool_size 5368709120

__streams_pool_size 0

.....

99857989632(93GB)+536870912(512MB)= 100394860544(93.5GB)

でも、Oracleが自動割り当てするshared_io_pool_size

分を考慮して…

コンテンツ


使用量を測ってみる

• Database Buffer

• X$BH.BA

SQL> desc x$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…

仮想メモリとSGA0x0000000000000000

0xffffffffffffffff

0x0000000000400000text

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

skgm overhead

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_id or obj = data_object_id)

5 group by owner,object_name,object_type;

OWNER OBJECT_NAME OBJECT_TYP

---------- -------------------- ----------

TTT T1 TABLE

各セルに相当する仮想メモリアドレス上に存在するオブジェクトを確認する

地図を描いてみるset linesize 500col val for a400set pagesize 10

with ba_base(i) as( select trunc(trunc(to_number(min(ba),'XXXXXXXXXXXXXXXX')/1024/1024,0)/100,0)*100 from x$bhunion allselect i+1

from ba_basewhere 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')),'-') valfrom (

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$bh bhgroup 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 = cntstart with ba_range2_order = 1connect by prior ba_range2 = ba_range2

and prior ba_range2_order = ba_range2_order-1

SGA MAP(X$BH)用のSQL

仮想メモリとSGA0x0000000000000000

0xffffffffffffffff

0x0000000000400000text

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

skgm overhead

256MB

256MB

Database Buffer

0x00000008D1484000

0x00000017CF628000

59.97GB

99.75GB

コンテンツ


もう一度地図を描いてみる

今度は、めいっぱい詰め込む


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


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


これなに？

これなに？


すみません。

よくわかりません。

これなに？


Buffer Cache : 246MB + Blank : 10MBBuffer Cache : 246MB + Blank : 10MBBuffer Cache : 246MB + Blank : 10MB

(repeat)

白い縞模様は一定間隔で現れています


SQL> select * from v$sgainfo ;

NAME BYTES RESIZEABL CON_ID

------------------------ ------------- --------- -------------

.....

Granule Size 268435456 No 0

.....

Buffer Cache : 246MB + Blank : 10MB ・・・ GranuleBuffer Cache : 246MB + Blank : 10MB ・・・ GranuleBuffer Cache : 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$bh where rownum < 1000;

AVG_LEN_BH COUNT(*)

------------- -------------

348.690690691 999

Buffer Header Length≒ 350 bytes

もう一度地図を描いてみるBuffer Header Size / Granule

-128 blocks / 1 MB * 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)に収まっていると考えられる


すみません。

よくわかりません。バッファ・

ヘッダみたいです。

仮想メモリとSGA0x0000000000000000

0xffffffffffffffff

0x0000000000400000text

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

skgm overhead

256MB

256MB

Database Buffer

0x0000000080002000

0x00000017CF628000

93.24GB

99.75GB

コンテンツ


SGA Heat Map

Before Data Load80MB

データがあまりキャッシュされていない状態60GB弱のレンジ内に、80MB程度しかキャッシュさ

れておらず、データ・ブロックはまばらに配置されている

データ・ブロックがバッファ・キャッシュを埋め尽くすまでの途中経過を見てみると、、、

SGA Heat Map

40GB

40GB程度キャッシュされている状態

データ・ブロックは仮想メモリアドレスの高い方（図の下方）から徐々に埋まってくる

SGA Heat Map

50GB

50GB程度キャッシュされている状態当初の60GB弱のレンジが少しずつ広がり始めている状態

SGA Heat Map

80GB

80GB程度キャッシュされている状態仮想メモリアドレスの高い方から埋まりつつある

データ・ブロックが埋まった領域において、バッファ・ヘッダが格納されているとみられる白いスリット上の領域が確認できる

SGA Heat Map

Buffer Cache Full93GB


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

SGA Heat Map

Buffer Rewrite 93GB


バッファ・キャッシュがほぼ埋まった状態で、データのロード処理を継続していると、赤い領域（Hot Buffer）がバッファ・キャッシュのメモリ空間のほぼ中段の位置で発生していることが確認できる

LRUリストのCOLD領域に位置するデータ・ブロック

がちょうどこの位置にはキャッシュされていると推測される

SGA Heat Map

End of Data Load93GB

90GB程度キャッシュされている状態データのロード処理を停止すると、赤い領域（Hot Buffer）が消える

メモリ上の激しいバッファの書き換えが収まったためと考えられる

SGA Heat Map

•幼児

同一BAのBHレコード

1MB / 8192 bytes = 128 blocks128 blocks 以上表示されるエリアを”赤いセル”で表現

実際には、1MBのエリアに8192 bytes のブロックが 128 blocks 以上存在するはずはない。X$BHを検索中にダーティーリードが発生した結果、バッファー・キャッシュ内の書き換えが激しいアドレスのブロックが複数現れてしまうことで、見かけ上128 blocks以上存在するように見える。つまり、ホット・バッファ。

赤い領域（Hot Buffer）の拡大イメージ

SGA Heat MapSQL> select ADDR,INDX,BA,NXT_HASH,PRV_HASH2 from x$bh3 where ba in ( select ba4 from x$bh5 where trunc(to_number(ba,'XXXXXXXXXXXXXXXX')/1024/1024,0) = 639*100+166 group by ba7 having count(ba) > 28 )9 order by ba;

ADDR INDX BA NXT_HASH PRV_HASH------------------------------ ------------- ------------------- --------------------- --------------------00002B4D0CC34E60 9353301 0000000F9ACAE000 000000193D50AF78 000000193D50AF7800002B4D0CC35518 8077473 0000000F9ACAE000 000000195B920E80 000000195B920E8000002B4D0CC35268 11432377 0000000F9ACAE000 0000001920DAA7B8 0000001920DAA7B800002B4D0CC35518 8113471 0000000F9ACC6000 000000193BB8CB98 000000193BB8CB9800002B4D0CC34FB8 9389297 0000000F9ACC6000 000000194D700710 000000194D70071000002B4D0CC35110 11069055 0000000F9ACC6000 000000195F5B9720 000000195F5B972000002B4D0CC34FB8 9425309 0000000F9ACDE000 000000195D424540 000000195D42454000002B4D0CC34E60 10705717 0000000F9ACDE000 000000193F042E78 000000193F042E7800002B4D0CC34FB8 8149442 0000000F9ACDE000 000000193BD23C88 000000193BD23C8800002B4D0CC34FB8 9461313 0000000F9ACF6000 000000195D5BB630 000000195D5BB63000002B4D0CC35518 10342351 0000000F9ACF6000 000000194EA56040 000000194EA5604000002B4D0CC34FB8 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 は全体の上側（仮想メモリアドレスの下位側）に偏っています。

Thank you for your time!!

[db tech showcase tokyo 2014] l35: 100gb クラスの sga を眺めてみよう。oracle database...

Technology