[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成

2014/11/26
目指せExadata!! Oracle DB 高速化を目指した構成
宇佐美茂正

P2
自己紹介
•氏名：宇佐美茂正（うさみしげまさ）
•勤務先：ヤフー株式会社
•職種：DBA
•業務
–DB環境構築
–運用業務
–チューニング
–DB監査
–Oracle関連の業務を主に担当
Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

P3
このセッションの概要
ExadataはストレージデバイスにSSD、ノード間通信、ストレージ間通信にInfiniBand、そしてストレージノード側に独自のシステム Exadata Smart Scanを搭載し最強、最高のパフォーマンスを謳っています。しかしその導入コストは非常に高く、敬遠しているユーザーも多いのが現状です。弊社では、このExadataに迫るパフォーマンスのDB システム構成を検討し、今年の２月に導入に至っています。このセッションでは、弊社のOracle高速DBシステムの構成と、行ってきた検証や性能比較、そして問題点は何処に有るのかを明らかにしたいと思います。

P4
アジェンダ
•弊社のRDB運用状況の紹介
•SSD x InfiniBandの構成
–具体的な構成、使っている技術 etc…
•パフォーマンス比較
-HDD x 10G、ODA、Exadataとの比較
•問題点
–経験した障害とその原因
•今後
–更なる性能改善

弊社のRDB運用状況の紹介
運用体制、規模感、etc…

P6
「全社DB」と呼ばれるプロジェクトがあります
•全社DB
社内のRDBを統括管理するプロジェクト
弊社の各サービスの為にDB関連業務を行っています。
DB環境構築、チューニング、運用、監査、etc…
•目的
–コスト削減
•複数のサービス用DBを集約して運用
•DBサーバ、ストレージ等の機器の共有
–工数削減
•サービス、開発側はDB環境構築、運用に携わらなくていい
–セキュリティ
•DBアクセスの監査

P7
全社DBプロジェクトで運用しているDB
•DB数 187
•バージョン Oracle 11.2.0.2、 11.2.0.4
運用DB数 582
DBサーバ数 330
•DB数 395
•バージョン MySQL 5.1、 5.5
利用サービス
広告、ヤフオク!、Yahoo!ショッピング
Yahoo!ニュース、Yahoo!トラベル
Yahoo!天気、Yahoo!スポーツ
Yahoo!知恵袋、Yahoo!ブログ
Yahoo!きっず、etc…

PCI-SSD x InfiniBandの構成
具体的な構成、使っている技術、etc…

P9
システム構成の概要図
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
DB node 1
DB node 2
DB node 3
InfiniBand Switch
Network 01(56Gbps)
InfiniBand Switch
Network 02(56Gbps)
IB HCA
IB HCA
IB HCA
IB HCA
PCI-SSD
PCI-SSD Verident
LUN
IB HCA
IB HCA
Storage node 1
Storage node 2
Storage node 3
PCI-SSD
LUN
PCI-SSD
LUN
PCI-SSD
LUN
PCI-SSD
PCI-SSD Verident
LUN
PCI-SSD
LUN
IB HCA
IB HCA
PCI-SSD
LUN
PCI-SSD
LUN
IB HCA
IB HCA
PCI-SSD
LUN
PCI-SSD
LUN
IB HCA
IB HCA
PCI-SSD
LUN
PCI-SSD
LUN
Storage node 4
Storage node 5
Storage node 6
•データベース用のストレージデバイスは全てSSD
•データベースシステム内での通信は全てInfiniBand

ハードウェアとソフトウェアの構成

P11
PCI-SSDに関して
•Virident FlashMaxIIを採用
HGST社製のSSD製品
•特徴
Readの性能がかなり速い
カード自身にガベージ・コレクションの機能が入っておりサーバ側のCPU負荷を抑える
•RDBとの相性
Write性能は他社製品のFusion-ioの方が優れていた。
大半のDBではReadの割合が多いためReadの性能を重視

P12
InfiniBand Switch に関して
•Mellanox製 InfiniBand Switchを採用
製品名 SX6036（エッジスイッチ）
•特徴
•1Uスイッチに36 FDR ( 56Gbps ) ポート
•InfiniBandとEthernet接続をサポート
•IPoIBで通常のEthernetと同じように通信も可能
•4.032Tb/s のスイッチング能力

P13
DBノードのOS & ハードウェア構成
•DBサーバ機器
Fujitsu RX200 S8
•構成
•CPU : E5-2667 ( 6コア 12スレッド ) x 1
•メモリ : 128GB
•NIC : 1Gbps Eth x 4
Bonding用
•富士通製 FDR InfiniBand HCA (Dual Port)
•56Gb/s
•ドライバはMellanox製のOFED
•OS ＆ Oracle Software
OS : Oracle Linux 6.4
Oracle Database : 11.2.0.4
Grid Infrastructure : 11.2.0.4

P14
ストレージノードのOS & ハードウェア構成
•ストレージサーバ機器
Fujitsu RX200 S8
•構成
•CPU : E5-2630L ( 6コア 12スレッド ) x 1
•メモリ : 32GB
•NIC : 1Gbps Eth x 2
•富士通製 FDR InfiniBand HCA (Dual Port)
•56Gb/s
•ドライバはMellanox製のOFED
•Virident FlashMaxⅡ(2.2 TB) x 2
•OS
Oracle Linux 6.4

InfiniBandネットワークでの通信
利用プロトコルとその内容

P16
本システムでのInfiniBand通信
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
DB node 1
DB node 2
DB node 3
InfiniBand Switch
Network 01(56Gbps)
InfiniBand Switch
Network 02(56Gbps)
IB HCA
IB HCA
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Verident
LUN
IB HCA
IB HCA
Storage node 1
Storage node 2
Storage node 3
PCI-SSD
LUN
PCI-SSD
LUN
PCI-SSD
LUN
PCI-SSD
PCI-SSD
Verident
LUN
PCI-SSD
LUN
IB HCA
IB HCA
PCI-SSD
LUN
PCI-SSD
LUN
IB HCA
IB HCA
PCI-SSD
LUN
PCI-SSD
LUN
IB HCA
IB HCA
PCI-SSD
LUN
PCI-SSD
LUN
Storage node 4
Storage node 5
Storage node 6
•DBサーバ間で発生するOracle Interconnect 通信
•IPoIB
•DBサーバとストレージサーバ間で発生するSSDデバイスへのI/O通信
•iSER

P17
IPoIB (IP over InfiniBand)の概要
•InfiniBand上にIPネットワーク層を構成するサービス
•InfiniBand HCAの各ポートにIPを割り振ることが出来る
•Ethernetと同様に通信可能
•InfiniBandネットワーク経由でIP指定でEthernetと同様に処理が行えます
•例えばSSHやSCPコマンドも使えます
•但しこの使い方ではInfiniBand特有の低レイテンシな通信は得られません
•ただの帯域が広いEthernetと言う感じの使い方

P18
iSER (iSCSI Extensions for RDMA)の概要
•iSCSIとはリモートサーバのLUNを自分のローカルデバイスのように見せてI/Oすることが出来るプロトコルです。
•iSCSI上でRDMA通信を利用可能にしているのがiSER
•iSCSIのターゲット側の設定を変更する事で簡単に利用可能です
•パラメータ「default-driver = iser」を設定するのみ
•オペレーションや各種設定はiSCSIとほぼ同様に可能
•通常のiSCSIに比べて低レイテンシーなI/Oが可能となる

P19
RDMA(Remote Direct Memory Access)通信
アプリケーション1
バッファ1
OS
バッファ1
NIC
バッファ1
Node 01
IB HCA
バッファ1
OS
バッファ1
NIC
バッファ1
Node 02
IB HCA
User
Kernel
Hardware
RDMA over InfiniBand
TCP/IP
•TCP/IP通信はノード内の各レイヤーでのバッファのコピーが必要
•それに比べRDMA通信は直接送信先メモリへ転送することが可能
•通信に必要なスタックが減り低レイテンシーが実現
•また、スタックが減る為CPUの使用率低下にも期待できる

ストレージの設定
SSDデバイスをASMに登録するまでの流れ

P21
DM-Multipath の概要
•デバイスマッパーマルチパッシング
•異なる経路で認識させた独立したデバイスを統合可能
•パスの多重化による可用性とパフォーマンスの向上が期待できる
Storage
Raid Group
Server
Mapping Device
HBA 1
HBA 2
Controler 1
LUN
SAN 2
device 2
device 1
SAN 1
Controler 2

P22
新構成のストレージデバイス設定(概要図)
•2つのInfiniBandネットワークは独立させています
•これを利用してSSDデバイスをマルチパスでDBノードに認識させます
•Active/Activeでパスを利用し且つ可用性も担保する事を狙った構成です。
•56Gbps x 2 で 112GbpsのI/O帯域となります
IB HCA
IB HCA
IB HCA
IB HCA
PCI-SSD
Partition
IB Switch
Network 01
IB Switch
Network 02
Storage node
dm-01 (MULTIPATH DEVICE)
DB node
×N
56Gbps
56Gbps
iSER
iSER

P23
ASMに登録する
•作成したマッピングデバイス群でASMを構成
•ストレージレベルの障害を考慮して障害グループを設定
•ストレージノード毎にグルーピングしたDisk群で障害グループを構成
Disk1
Disk2
data1
mirror
Disk3
Disk4
data1
Disk5
Disk6
data2
mirror
data2
FAIL GROUP 02
FAIL GROUP 01
data3
data3
mirror
ASM Disk Group
FAIL GROUP 03
Storage Node 01
Storage Node 02
Storage Node 03

P24
ASMに登録する
•作成したマッピングデバイス群でASMを構成
•ストレージレベルの障害を考慮して障害グループを設定
•ストレージノード毎にグルーピングしたDisk群で障害グループを構成
Disk1
Disk2
data1
mirror
Disk3
Disk4
data1
Disk5
Disk6
data2
mirror
data2
FAIL GROUP 02
FAIL GROUP 01
data3
data3
mirror
ASM Disk Group
FAIL GROUP 03
Storage Node 01
Storage Node 02
Storage Node 03
※ディスクグループ作成 ( 例 )
CREATE DISKGROUP <Disk Group Name>
NORMAL REDUNDANCY
FAILGROUP ST01 DISK ‘/dev/ST01_DISK01' NAME ST01_DISK01
～全ディスクを羅列～
ATTRIBUTE 'compatible.asm' = '11.2.0.0.0',
'compatible.rdbms' = '11.2.0.0.0',
'compatible.advm' = '11.2.0.0.0';

P25
システム構成の全体像
Oracle ASM (Auto Storage Manager)
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
DB Instance 1
DB Instance 2
DB Instance 3
Oracle Grid Infrastructure
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Partition 1
Partition 1
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Partition 1
Partition 1
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Partition 1
Partition 1
Storage node 1
Storage node 2
Storage node 3
RAC DB
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Partition 1
Partition 1
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Partition 1
Partition 1
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Partition 1
Partition 1
Storage node 4
Storage node 5
Storage node 6
Network 01(56Gbps)
InfiniBand Switch
InfiniBand Switch
Network 02(56Gbps)
High Performance
•Storage
•SSD
•112Gb/s
•RDMA
•Interconnect
•112Gb/s
High Availability
•Storage
•Multipath
•ASM Mirror
•Interconnect
•IB NW x 2
DB node 1
DB node 2
DB node 3

障害時の動作テスト
サーバやIBスイッチの障害を想定したテスト

P27
実施した障害テスト一覧
大分類
テスト内容
想定の動作
ASMテスト (ストレージ関連の障害)
ストレージサーバのIB NW 2重障害
対象ストレージのDiskがOFFLINEとなる
ストレージサーバ DOWN
tgtd プロセス障害
ASM プロセス障害
対象DBサーバのASM, DBインスタンスで
再起動が発生する
RACテスト
サービス NW 2重障害
生存DBノードにVIPのフェイルオーバー対象DBサーバのDB ServiceはDOWNする
DBサーバの IB NW 2重障害
対象DBサーバがクラスタから切り離される
DBサーバ DOWN
DB インスタンスプロセス障害
対象DBインスタンスの再起動が発生
IBスイッチテスト
IBスイッチ片系障害
マルチパスの対象パス切り離される
DBサーバダウンは発生しない

P28
障害テストで想定外の挙動となった点
•マルチパスのパス障害時の挙動
–特定ストレージノードのDOWN
•想定
–対象ストレージノードのDisk OFFLINEが発生
•実際
–Disk GroupがDismountされ全クラスターダウン
–IBスイッチの片系障害
•想定
–パスの切り離しが発生するがクラスターは稼動を続ける
•実際
–Disk GroupがDismountされ全クラスターダウン

P29
パスの切り離しがうまく行かなかった原因
•ASMのメタデータ更新に失敗
–11.2.0.4ではASMのメタデータ更新のタイムアウトが15秒
–これが出来なかった場合、対象Disk GroupはDismountされる
–パスの障害検知はこの時間内に完了させる必要がある
•マルチパス障害検知に関わる設定
–iSCSI
•死活監視間隔 5秒
–node.conn[0].timeo.noop_out_interval = 5
•死活監視がエラーと判断するまでの待ち時間 5秒
–node.conn[0].timeo.noop_out_timeout = 5
•復旧待ち時間 120秒
–node.session.timeo.replacement_timeout = 120
iSCSIセッションが切れた際にエラーと判断されるまでに、126～130秒
–Multipath
•パスのチェック間隔 5秒
–polling_interval = 5
•パスチェック時のリトライ 0回
–no_path_retry = 0
パスの障害と判断されるまでに、1～5秒
パスの経路障害と判断されるまでに、127～135秒掛かる

パフォーマンスの比較
•HDD x 10G
•ODA
•Exadata
•SSD x IB

P31
HDD x 10G
DB Storage 02
DB node 1
DB node 2
DB node 3
DB Storage 01
DB Storage 03
Storage Network
10G Ethernet
Interconnect Network
1G Ethernet
【機器】
•DBサーバ
•台数 : 3台
•機種 : HP DL360 G7
•CPU : E5-2643(4コア)x2
•メモリ : 72GB
•OS : Oracle Linux 5.9
•DB Storage : NetApp
•台数 : 3台
•機種 : FAS 3270
•構成Disk : SAS HDD (15K rpm) x 51 【ネットワーク】
•ストレージ間ネットワーク(SAN)： 10G Ethernet (10BASE-SR)
•ノード間通信ネットワーク(Interconnect NW)： 1G Ethernet

P32
ODA ( Oracle Database Appliance)
Oracleのアプライアンス製品【機器】
•DBサーバ
•台数 : 2台
•CPU : E5-2697(12コア) x 2
•メモリ : 256GB
•DB Storage
•機種 : 製品付属のストレージシェルフ
•構成Disk
•SAS HDD (10K rpm) x 20 ( データファイル格納用 )
•SSD x 4 ( Redo 格納用 ) 【ネットワーク】
•ストレージ間ネットワーク(SAN)： 6Gb/s (SAS-2 HBA)
•ノード間通信ネットワーク(Interconnect NW)： 1G Ethernet (クロスケーブル)

P33
Exadata (X2-2 Full RAC)
Oracleのアプライアンス製品【機器】
•DBサーバ
•台数 : 8台
•CPU : X5670(6コア) x 2
•メモリ : 96GB
•DB Storage
•機種 : 製品付属のストレージサーバ群
•台数 : 14台
•構成Disk
•SAS HDD (15K rpm) x 28 ( データファイル＆ REDO 格納用 )
•Flashデバイス ( Oracle DB 2次キャッシュ用 ) 【ネットワーク】
•ストレージ間ネットワーク(SAN)兼ノード間通信ネットワーク(Interconnect)
•InfiniBand QDR 40Gb/s

IO性能比較
秒間 I/O, 転送量, レイテンシ

P35
IO性能の測定方法
•CALIBRATE_IOプロシージャーを利用
•DBシステムのストレージ性能の測定が可能
•システムが耐えられる秒間 I/Oリクエスト
•システムが耐えられる秒間 I/O MB
•MAX I/O時のレイテンシ
SET SERVEROUTPUT ON
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
DBMS_RESOURCE_MANAGER.CALIBRATE_IO (8, 10, iops, mbps, lat);
DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/

P36
MAX MBPS (最大秒間転送量)
4587
3085
19771
17516
0
5000
10000
15000
20000
25000
ODA
HDD x 10G
Exadata
SSD x IB
MAX MBPS

P37
MAX IOPS (最大秒間 I/O リクエスト)
17112
268875
111338
1153229
0
200000
400000
600000
800000
1000000
1200000
1400000
ODA
HDD x 10G
Exadata
SSD x IB
MAX IOPS

P38
MAX IOPS時の平均待機時間(ミリ秒)
8
0
8
0
0
1
2
3
4
5
6
7
8
9
ODA
HDD x 10G
Exadata
SSD x IB
LATENCY
レイテンシ
1ミリ秒以下
レイテンシ
1ミリ秒以下

SQLの性能比較

P40
SQLパフォーマンスの比較方法
•Swingbench
•概要
•Oracleに擬似的に負荷を掛けるアプリのように動作する
•Java動作
•テーブルとデータの作成、スループットの表示をやってくれる
•ベンチマークの種類
下記のテンプレートが用意されている
カスタマイズも可能
名前
説明
Read/Write 割合
Max size
Order Entry
TCP-C(OLTP系)
6 : 4
100GB
Calling Circle
Oracle版
OLTP ベンチマーク
7 : 3
100GB
Stress Test
単純な負荷を掛ける
ストレステスト
5 : 5
-
Sales History
TCP-Hベース(DWH系)
10 : 0
1TB
※ この測定に関してはExadata(X2-2)環境では取得できていません

P41
秒間トランザクションの比較 (TPS)
293
870
966
981
649
2539
3756
3710
2030
7880
7932
6821
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10
100
300
500
Session
TPS
ODA
HDD x 10G
SSD x IB

P42
検証時のCPU使用率(%)
20
40
50
60
10
60
70
70
40
100
100
100
0
10
20
30
40
50
60
70
80
90
100
10
100
300
500
Session
CPU
ODA
HDD x 10G
SSD x IB

P43
平均レスポンスタイム(ミリ秒)
36
219
689
1153
11
33
68
95
4
13
49
106
1
10
100
1,000
10,000
10
100
300
500
Session
Average Responce Time
ODA
HDD x 10G
SSD x IB

P44
TOP5 待機イベントの割合(10 Session時)
db file sequential read
DB CPU
enq: KO - fast object checkpoint
direct path read
db file parallel read
ODA
log file sync
gc current block 2- way
gc buffer busy acquire
read by other session
HDD x 10G
DB CPU
log file sync
gc cr grant 2-way
gc current block 2-way
SSD x IB
■ ODA
db file sequential read のWaitが多い
■ HDD x 10G
db file sequential read のWaitが多い
■ SSD x IB
db file sequential read のWaitの割合が減少
CPU処理時間が50%

P45
TOP5 待機イベントの平均待機時間(ms)
ODA
HDD x 10G
SSD x IB
7
3
DB CPU
-
DB CPU
-
log file sync
1
0
enq: KO – fast object checkpoint
9
0
log file sync
0
direct path read
7
3
gc cr grant 2-way
0
10
5
0
10 Session 時
SSD x IBの構成は処理における各イベントの待機時間が少なくなっています

P46
TOP5 待機イベントの平均待機時間(ms)
ODA
HDD x 10G
SSD x IB
15
8
Log file sync
3
direct path read
143
8
DB CPU
-
enq: KO – fast object checkpoint
167
enq: TX – row lock content
11
Db file sequential read
1
DB CPU
-
log file sync
1
gc cr grant 2-way
0
27
11
0
100 Session 時
10セッション時と同様に、
SSD x IBの構成は処理における各イベントの待機時間が少なくなっています

新構成へ移行したDBの性能
HDD x 10G ⇒ SSD x IB

P48
SQLの実行時間とI/O時間の比較
対象SQL
比較項目
従来構成
HDD x 10G
新構成
SSD x IB
SQLその１
実行時間(s)
10.63
0.10
I/O時間
10.41
0.07
DB CPU(%)
0.6
32.1
I/O(%)
97.9
70.6
SQLその2
実行時間(s)
20.29
0.13
I/O時間
20.18
0.09
DB CPU(%)
0.5
33.1
I/O(%)
99.5
70.6
•パフォーマンスが問題となっていたSQLの性能を比較しました
•SQLその１
•実行時間が10秒掛かっていたものが0.1秒に減少
•I/Oに掛かっていた時間が大幅に減少した為
•SQLその２
•実行時間が20秒掛かっていたものが0.1秒に減少
•I/Oに掛かっていた時間が大幅に減少した為

P49
待機クラスの比較
Wait Class
項目
従来構成
HDD x 10G
新構成
SSD x IB
User I/O
DB Time(%)
79.3
3.5
Avg Wait(ms)
53
0
Commit
DB Time(%)
4.3
0.2
Avg Wait(ms)
83
1
Cluster
DB Time(%)
3.7
0.4
Avg Wait(ms)
12
0
DB CPU
DB Time(%)
13.7
56.3
Avg Wait(ms)
-
-
•移行前の環境で上位に来ていた待機クラスで比較
•User I/Oの待機クラスの割合が80%を占めていたが移行後は3.5%に減少
•Commitの待機クラスも減少
•Cluster ( クラスタ関連処理ノード間通信 etc…)も減少
•他の待機クラスが減りDB処理時間の割合はCPUが大半を占めるようになった

P50
性能比較のまとめと価格面のメリット
【パフォーマンス】
•速い！
–SQL実行時間が平均で10倍速い
–物理読込が多いSQLでは100倍程速かった
–IO関連の待機イベントが大幅に減っている
–Cluster系の待機イベントに関しても多少改善が見られた
【価格】
•弊社の従来構成とほぼ同額で導入可能

問題点
経験した障害とその原因

P52
ストレージ間通信の失敗による障害
•I/Oの失敗が続きOracleの自発的パニックリブート発生
※Voting DiskへのI/Oやノード間通信が規定時間以上途絶えると Oracleの自発的パニックリブートが発生します
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
DB node 2
DB node 3
InfiniBand Switch
Network 01(56Gbps)
InfiniBand Switch
Network 02(56Gbps)
IB HCA
IB HCA
IB HCA
IB HCA
PCI-SSD
PCI-SSD
Verident
LUN
IB HCA
IB HCA
Storage node 1
Storage node 2
Storage node 3
PCI-SSD
LUN
PCI-SSD
LUN
PCI-SSD
LUN
PCI-SSD
PCI-SSD
Verident
LUN
PCI-SSD
LUN
DB node 1
I/O
Error
DOWN

P53
InfiniBand通信の設定が原因
バッファ1
IB HCA
Node 01
バッファ1
IB HCA
Node 02
IP over InfiniBand
RDMA通信
User
Hardware
•通信時のバッファが連続領域で確保されていました
•IPoIBの設定が絡んでいます
•メモリが枯渇すると通信に失敗する可能性が高まります
•設定を変える事でこれは回避できる
※メラノックス製InfiniBandスイッチ、ドライバの不具合ではありません

今後
更なる性能改善を狙ってみたい

P55
RDS over InfiniBand
•Oracleのインターコネクト通信ではUDPと「RDS」が利用可能
•RDS(Reliable Datagram Socket)
–InfiniBand上でRDMA通信が可能
•導入するとCluster関連の待機イベントの改善が期待できる
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
IB HCA
DB node 2
DB node 3
InfiniBand Switch
Network 01(56Gbps)
InfiniBand Switch
Network 02(56Gbps)
DB node 1
Oracle Interconnect
UDP
↓
RDS

P56
Smart Flash Cacheの利用
Oracle ASM (Auto Storage Manager)
DB Instance
Datafiles
DB node 1
DB node 2
DB node 3
Flash Cache
•PCI-SSD x InfiniBandで構成したDiskグループをOracle の二次キャッシュ領域として利用
•設定は容易（DBパラメータ）
•DB_FLASH_CACHE_FILE ( ASM or OS上でパスを指定 )
•DB_FLASH_CACHE_SIZE ( サイズを指定 )
•二次キャッシュの方が性能が出るのではないか？

最後に

P58
I/O性能が改善される事によるメリット
【従来構成】
•従来構成ではI/O処理がかなりネックになっていた
•これはDBシステムが理想とする本来の姿ではない
•CPUライセンスを払っているのに実際ネックになっているのはI/O
•CPUリソースを使い切る前にI/Oが限界を迎えてしまう
•増設や移行計画はCPUリソースを使い切った末に検討されるのが理想
【新構成】
•新構成ではI/Oがネックになっていた部分が解消された
•その結果DB処理時間の大半がCPU実行時間に変わっています
•CPUリソースを使い切る理想的なシステム構成になった
•高いOracleのポテンシャルを最大限に発揮できるようになった

ご清聴ありがとうございました

[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成

More Related Content

What's hot

Viewers also liked

Similar to [dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成

More from Yahoo!デベロッパーネットワーク

[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成