Oracle Database 11g Release 2 富士通 SPARC Enterprise … · 富士通 SPARC Enterprise上でのDatabase Smart Flash CacheによるOLTP ... Database Smart Flash Cache Oracle Database

Copyright © 2010, Oracle. All rights reserved Copyright © 2010, FUJITSU LIMITED. All rights reserved

.

オラクル・ホワイトペーパー

2010年 4月

Oracle Database 11g Release 2

富士通 SPARC Enterprise上でのDatabase Smart

Flash CacheによるOLTPシステムの性能向上


富士通 SPARC Enterprise上でのDatabase Smart Flash CacheによるOLTPシステムの性能向上

Copyright © 2010, Oracle. All rights reserved. Copyright © 2010, FUJITSU LIMITED. All rights reserved.

1

はじめに

日本オラクル株式会社（以降、日本オラクル）と富士通株式会社（以降、富士通）は、1989 年に

OEM 契約を締結して以来、お客様が安心してご利用頂けるソリューションを提供するためにシス

テム構築、共同検証、導入後のサポートなど、様々なアライアンス活動を行って参りました。

2006 年 11 月、日本オラクルは富士通をはじめとするグリッド戦略パートナー各社と協業体制を確

立し、企業のシステム基盤の最適化を実現する次世代のビジネス・ソリューションを構築するため、

先鋭の技術を集結した「Oracle GRID Center1」を開設しました。

富士通はその開設に賛同し、富士通製のサーバ、ストレージ製品を使用した共同検証を行っていま

す。

本資料では SPARC Enterprise M3000 と ETERNUS DX80 で構成される OLTP システムにおいて、

Oracle Database 11g Release 2 の新機能である Database Smart Flash Cache を使用する優位性を報告致

します。

1Oracle GRID Center は多くの技術レポートを公開しています。

Oracle GRID Center （http://www.oracle.co.jp/solutions/grid_center/index.html）




2

概要 ................................................................................................... 3

検証目的 ............................................................................................ 4

検証結果サマリー .............................................................................. 4

Oracle ORIONによるHDD及びSSDのI/O性能 ............................... 4

OLTP系アプリケーションの性能比較 ........................................... 4

Oracle製品機能紹介 .......................................................................... 6

Database Smart Flash Cache ........................................................ 6

プラットフォーム紹介 ....................................................................... 7

富士通 SPARC Enterprise ............................................................ 7

ストレージシステム ETERNUS .................................................... 8

検証環境 .......................................................................................... 12

システム構成 ............................................................................... 12

検証結果 .......................................................................................... 16

Oracle ORIONによるHDD及びSSDのI/O性能 ............................. 16

OLTP系アプリケーションの性能比較 ......................................... 22

総括 ................................................................................................. 39

Appendix A ...................................................................................... 40

Database Smart Flash Cacheのチューニング ............................. 40

Appendix B ...................................................................................... 43

SPARC Enterpriseのご紹介 ......................................................... 43

ETERNUS DX series ................................................................... 44




3

概要

近年、企業内業務の大部分が高度にシステム化されるとともに、法制度の改正やコンプライアンス

に関する要件のため、システムが扱うデータ量は 2 年で 3 倍に上るとも言われています。

データ量の増加に伴う問題は、一般的にデータウェアハウス・システムで発生すると考えられがち

ですが、オンライントランザクション処理（以降、OLTP）システムにおいても同様の問題が発生

する傾向があります。従来の OLTP システムでは、データベース・バッファ・キャッシュ（以降、

バッファ・キャッシュ）に大部分のデータがキャッシュされることで、CPU リソースを最大限活

用した高速処理が実現されていました。しかしながら、データ量の増加によるバッファ・キャッシ

ュ・ヒット率の低下に伴い、低速な Hard Disk Drive（以降、HDD）への I/O が頻発し、結果、CPU

リソースを使い切れず、OLTP システムの性能が制限されているケースが増えてきています。

このような問題に対する従来の一般的な対処法として、データベース・サーバにメモリを追加し、

バッファ・キャッシュのサイズを増加させる方法があります。しかし、メモリは高価であり、かつ

サーバに搭載可能な容量にも限界があるため、従来以上に頻発するストレージへの I/O を高速化す

ることが重要となります。その方法として、HDD の本数を追加し、I/O を分散（ストライピング）

させるアプローチがあります。しかしながら、CPU 性能とバランスが取れたストレージの I/O 性

能を得るには膨大な数の HDD が必要となるため、使用電力や設置スペース等の IT コスト削減の

観点からも適用が困難と考えられます（図 1）。

図 1 ストレージI/O性能ボトルネック改善のアプローチ




4

そこで、Oracle Database 11g Release 2 では Solid State Drive（以降、SSD）を活用し、この課題を解

決する Database Smart Flash Cache2を実装しました。

本文書では、SPARC Enterprise M3000 と ETERNUS DX80 で構成される OLTP システムにおいて、

Database Smart Flash Cache を使用することで低コストにストレージの I/O 性能のボトルネックを改

善し、OLTP システムの性能向上を実現するソリューションを紹介します。

検証目的

SSD をデータベース・システムで使用する場合、下記の 2 通りの使用方法が考えられます。

HDDの代替

Database Smart Flash Cache

本検証は、各使用方法の特徴を確認し、データベース・システムにおける SSD の使用方法のベス

ト・プラクティスを確立することを目的として、Oracle GRID Center にて実施しました。

検証結果サマリー

今回の検証内容と結果の概要を次に示します。詳細については後続の該当章をご参照下さい。

Oracle ORION による HDD 及び SSD の I/O 性能

Oracle Database の I/O ワークロードをシミュレートする Oracle ORION を使用して HDD 及び SSD

の I/O 性能を測定しました。その結果、SSD は HDD と比較してランダム読み込みの IOPS 性能が

特に高いことを確認しました。また、読み込みと書き込みが混在したランダム I/O の場合は、書き

込みの割合が増加するほど SSD の IOPS 最大値が減尐する傾向も確認しました。

詳細⇒Oracle ORION による HDD 及び SSD の I/O 性能

OLTP 系アプリケーションの性能比較

SSD を HDD の代替として使用した場合の性能

2対応エディションは、Enterprise Edition、対応プラットフォームは、Sun SPARC Solaris、Sun x86-

64 Solaris 及び Oracle Enterprise Linux




5

データベース・スキーマを HDD 及び SSD 上に配置した環境を構成し、それぞれの OLTP 処理性能

を比較しました。その結果、データベース・スキーマを SSD 上に配置することによって HDD の

IOPS 性能のボトルネックを改善し、OLTP システムの性能向上が可能であることを確認しました。

詳細⇒データベース・スキーマを HDD 及び SSD 上に配置

データベースが大規模である場合、データベース・スキーマ全体を SSD 上に配置することは現実

的ではありません。その場合、HDD からの読み込みが多いスキーマ・オブジェクトを分析し、優

先して SSD 上に配置する方法が考えられます。このような環境を構成し、OLTP 処理性能を測定

しました。その結果、OLTP システムの性能向上が確認できましたが、SSD を最大限活用できてい

ませんでした。

詳細⇒スキーマ・オブジェクトを選別して SSD 上に配置

Database Smart Flash Cache を使用した場合の性能

Oracle Database 11g Release 2 で実装された Database Smart Flash Cache は、SSD を Database のキャッ

シュとして活用します。Database Smart Flash Cache 領域には、アクセス頻度が高いにも関わらず、

バッファ・キャッシュからキャッシュ・アウトされたデータ・ブロックが自動的に配置されます。

その結果、HDD の代替として使用した場合に実施したような分析を行うことなく、SSD を最大限

活用した OLTP システムの性能向上が可能であることを確認しました。

詳細⇒Database Smart Flash Cache を使用した場合の性能




6

Oracle製品機能紹介

Database Smart Flash Cache

Oracle Database では、HDD から取得したデータ・ブロックをメインメモリ上のバッファ・キャッ

シュに保持します。これにより、キャッシュされているデータ・ブロックは、HDD への I/O を行

うことなくバッファ・キャッシュから取得され、高速なレスポンス・タイムを実現します。また、

バッファ・キャッシュでは Least Recently Used（以降、LRU）アルゴリズムにより、アクセス頻度

が高いデータ・ブロックが最大限キャッシュされるよう自動的に管理されています。

近年では、HDD に比べ IOPS 性能が圧倒的に高い SSD が注目を浴びています。HDD より高価です

がメモリより安価である SSD の高い IOPS 性能を活用する方法として、HDD の代替として SSD 上

にデータベース・ファイルを配置する新しいアプローチが考えられるようになりました。しかし、

SSD は容量あたりのコストが高く（2010 年 4 月現在）、増加し続けるデータを格納するのは現実

的ではありません。

Database Smart Flash Cache は SSD をバッファ・キャッシュ（レベル 1 キャッシュ）の拡張領域と

して使用し、データ・ブロックにレベル 2 キャッシュを提供します（図 2）。Database Smart Flash

Cache 領域には、バッファ・キャッシュからキャッシュ・アウトされたデータ・ブロックが、LRU

アルゴリズムよりも更に優れたアルゴリズムにより自動的に配置されます。これにより、従来では

アクセス頻度が高いにも関わらずバッファ・キャッシュのサイズ不足によりキャッシュ・アウトさ

れていたデータ・ブロックが Database Smart Flash Cache 領域から高速に取得されます。そのため、

同容量のメモリを追加するより遥かに低いコストで OLTP 処理性能の向上が期待できます。

図 2 Database Smart Flash Cacheの適用

Database Smart Flash Cache 領域には、HDD に書き込み済みのデータ・ブロック（クリーン・ブロ

ック）のみが配置されます。これにより、ユーザーは SSD 上のデータを意識せずに、従来通りの




7

方法でデータファイルのバックアップが可能です。また、クリーン・ブロックだけがキャッシュさ

れているため、SSD に障害が発生した場合でもデータの一貫性は保たれます。

プラットフォーム紹介

富士通 SPARC Enterprise

今日の企業ビジネスにおいて、IT システムの果たす役割はますます重要となっています。企業が

扱うデータ量は増加し、Web サーバ、アプリケーション・サーバ、データベース・サーバなど、

企業内のサーバ用途は大きく広がっています。一方で、従来から IT システムの課題となっていた

サーバの処理性能の不足やサーバ台数増による運用コストの増大に加え、地球環境における企業

/IT が果たすべき社会的役割もますます重要になっています。このような課題を解決すべくコスト

削減および IT システム効率化、そして CO2 排出削減の面から、物理的、仮想的なサーバ統合やミ

ドルウェア等を活用した IT システムの全体最適化の必要性が近年とみに高まっています。

「SPARC Enterprise」は、スピード経営、業務の継続性、TCO 削減、環境貢献等、企業が抱える

様々な経営課題に応えるために、メインフレーム並みの高信頼性を持ちミッションクリティカル業

務に最適な SPARC Enterprise M9000, M8000, M5000, M4000, M3000 と、Web フロント業務に最適な

高いスループット性能を持った SPARC Enterprise T5440, T5240, T5220, T5140, T5120 をご用意して

います。

SPARC Enterprise M3000

「SPARC Enterprise M3000」は、「SPARC64 Ⅶ」を搭載し、最大で 4 コア/8 スレッドのマルチコ

ア・マルチスレッド環境を実現しました。メモリは最大 64GB 搭載可能で、SAS は 1 ポート、PCI

Express は 4 スロット標準装備するなど、わずか 2U のスペースに業務に必要な機能をすべて実装

できます。エントリークラスのモデルにおける最高クラスの性能を発揮し、アプリケーション・サ

ーバやデータベース・サーバなどの幅広い業務に適用可能となっています。

また「SPARC Enterprise M3000」は、上位モデルの高信頼性を踏襲しています。LSI レベル、ユニ

ットレベル、システムレベルとシステム全体で信頼性を積み上げ、高い信頼性を確保しています。

さらに、「SPARC Enterprise M3000」は、富士通が独自に定める環境配慮型製品である、スーパー

グリーン製品です。コンパクトな 2U（ユニット）サイズで、PRIMEPOWER450（4U）と比較し、

50％の省スペースと軽量化を実現しています。消費電力は最大 505W（100V）と 54％も削減可能

です。性能の向上と合わせて、CO2 排出量を年間約 65％削減できます。しかも、一般的なサーバ

設置場所の環境温度 25℃の音圧レベルで 47dB という静音設計で、他社 4 コアサーバと比較しても、

消費電力値や騒音値において、最も優れたエコロジーサーバとなっています。




8

また、Solaris10 には、Solaris コンテナ3と呼ばれる仮想化技術を標準で装備しています。「SPARC

Enterprise M3000」でも Solaris コンテナを使用したサーバ統合により資源を集約することが可能と

なっており、システムの効率化を実現できます。

SPARC Enterprise M3000 の特長

- SPARC/Solaris エントリークラス最高のプロセッサコア性能を実現

- ミッドレンジクラスの高信頼技術をエントリークラスに継承

- 省電力/省スペースなど「Green Policy Innovation」の具現化

ストレージシステム ETERNUS

企業経営と IT の一体が進行した昨今、経営情報を中心とする情報活用、リスクマネージメントと

いった企業経営と社会責任に対応した IT インフラの整備が欠かせなくなっています。

富士通では、お客様の様々なニーズに対応するために、次の３つを基本要件と捉え、ストレージシ

ステム ETERNUS を開発しております。

1. 大量の情報を活用するためのスケーラビリティと情報の遅滞の無い提供を実現するビジネスの

継続性への備え

2. 情報を正しく保存するためのデータ保存性とセキュリティの確保

3. 企業レベルの大量の情報を適切かつ柔軟に運用管理し、TCOを削減

ストレージシステム ETERNUS では、お客様のビジネス目標を達成するために業務環境の変化に応

じて、業務アプリケーション、業務プロセスから、定められた権限の下、必要なデータ、必要なス

トレージリソースにいつでもアクセスし続けるストレージインフラとサービスを提供しております。

ETERNUS DX80

ETERNUS DX80 は、環境への配慮を追及した省エネ設計、上位クラスの機能、信頼性を備えた、

エントリークラスのディスクアレイです。

ETERNUS DX80 は、これまで培ったノウハウをコンパクトな筐体に集約し、コストパフォーマン

スが求められる中小規模システムを対象に、最適なストレージソリューションを提供します。

3 Oracle Real Application Clusters は Solaris コンテナ上での動作をサポートしておりません。




9

環境配慮・エコ

- 消費電力を 8%削減し、年間 CO2 排出量を最大 100kg 削減[注 1]

- ファン回転制御を最適化し、最大 6dB の低騒音化を実現[注 1]

- 低消費電力、高信頼・高性能な SSD をサポート

- バッテリーフリーにより産業廃棄物の低減を実現

- MAID 技術を応用したエコモードにより電力消費量を削減

柔軟な運用管理

- アドバンスト・コピー機能により瞬時にデータ複製

- わかり易い GUI で直感的に操作可能

- 3.5 インチディスクドライブより約 50％省電力[注 2]な、軽量の 2.5 インチディスクドライブ

をサポート

高信頼・データ保護

- 主要コンポーネントの二重化と、RAID5 より信頼性と性能に優れた RAID5+0、ディスクの

二重故障に対応する RAID6 をサポート

- ディスクに書き込むデータを富士通独自方式で暗号化

- 格納される全データにチェックコードを付与し整合性を保証

[注 1] 周囲環境温度 25℃、12 台の 450GB(15,000rpm) 3.5 インチディスクドライブ動作時におけ

る従来機種（ETERNUS2000）との当社比

[注 2] 120 台の 300GB(10,000rpm) 2.5 インチディスクドライブと 120 台の 600GB(15,000rpm)3.5

インチディスクドライブ搭載時における当社比（DX80 最大構成相当）

SSD (Solid State Drive)

SSD とは、フラッシュメモリを利用した記憶装置です。SSD は、高速、省電力などの特長がある

ため、大規模データベースなどの極めて高速な処理が求められるシステムに最適です。

SSD は、ETERNUS DX80 に最大 9 台搭載可能です。




10

表 1 ETERNUS DX80/DX90のHDDとSSDの比較

SSD HDD

速度

[注1]

◎

READ時：HDDの16倍

WRITE時：HDDの11倍

○

省電力

[注2]

◎

IDLE時：HDDの74%

I/O走行時：HDDの49%

×

対衝

撃性

○

駆動部分がないため

故障しにくい

×

振動や衝撃に弱い

容量 ○

200GB, 100GB

◎

3.5”SASディスク：600GB, 450GB, 300GB

3.5”ニアラインSASディスク：2TB, 1TB, 750GB

2.5”SASディスク：300GB, 146GB

コスト ×

容量あたりの単価が高い ○

[注 1] ETERNUS DX80/DX90 装置で比較

[注 2] SSD/3.5"SAS ディスク単体性能で比較

ETERNUS DX serires では、STEC 社製の SSD を採用しています。

また、ETERNUS DX80 で SSD を使用する場合は、表 2に示す RAID グループを構成することが可

能です4。

表 2 ETERNUS DX80で構成可能なSSDのRAID構成

RAIDレベル SSD本数構成名

RAID1 2 RAID1 (1+1)

RAID5 4 RAID5 (3+1)

ETERNUS SF Storage Cruiser と ETERNUS SF AdvancedCopy Manager

ETERNUS SF Storage Cruiser は、ETERNUS ディスクアレイのディスクドライブから業務サーバの

ファイルシステム、接続パス、ミラーディスク、データベース等のリソースを関連付け、運用管理

4 2010 年 1 月より RAID1+0（2+2）の構成もサポートされるようになりました。




11

を行います。各リソース間の関係を簡単に把握し、ストレージシステムの増設や障害リカバリー、

性能情報の取得/表示を確実に行うことが可能です。

ETERNUS SF AdvancedCopy Manager は、ETERNUS ディスクアレイと連携し、アドバンスト・コ

ピー機能による高速バックアップ/リストア、レプリケーション運用を実現します。アドバンス

ト・コピー機能は、ある時点における業務ボリュームを短時間で同じディスクアレイ内の別ボリュ

ーム（複製ボリューム）にコピーします。コピー完了後の複製ボリュームを使ってテープ装置へバ

ックアップすることができます。ETERNUS SF AdvancedCopy Manager のテープサーバオプション

を使用すると、コピー完了とテープバックアップ開始のスケジューリング、ディスクとテープを

別々に管理するなどの煩雑さを解消した上でディスクからテープまで一貫してバックアップできま

す。また、複製ボリュームは業務ボリュームと切り離されるため、業務を継続しても書き換えられ

ることはありません




12

検証環境

システム構成

図 3 システム構成

【データベース・クライアント】

【ストレージ管理】

【ストレージ（HDD搭載機）】【ストレージ（SSD搭載機）】

BX620 S5

【データベース・サーバ】

Storage Area Network

（8Gbps Fibre Channel）

クラスタ・インターコネクト（1000Base-T）

業務LAN（1000Base-T）

【データベース・サーバ】

RX300 S3




13

データベース・サーバ

富士通 SPARC Enterprise M3000 を 2 台使用し、2 ノードの Oracle Real Application Clusters を Oracle

Database 11g Release 2 Enterprise Edition で構成しています。

モデル富士通 SPARC Enterprise M3000

CPU SPARC 64 Ⅶ 2.75GHz（4コア、8スレッド）

メモリ 32GB

OS Solaris 10 Operating System（Generic_141444-09）

データベース Oracle Database 11g Release 2 Enterprise Edition

Oracle Real Application Clusters

ストレージ

SSD を搭載した ETERNUS DX80 と HDD を搭載した ETERNUS DX80 の 2 台の ETERNUS DX80 を

使用しています。

SSD搭載機

モデル富士通 ETERNUS DX80

ディスクドライブ SSD 100GB x 8

HDD 300GB（15,000rpm）SASディスクドライブ x 2

HDD搭載機

モデル富士通 ETERNUS DX80

ディスクドライブ HDD 300GB（15,000rpm）SASディスクドライブ x 24

（拡張ドライブエンクロージャ x 1）




14

RAID及びASMディスク・グループ構成

図 4 RAID及びASMディスク・グループ構成1（SSD RAID1構成）

図 5 RAID及びASMディスク・グループ構成2（SSD RAID5構成）




15

データベース・クライアント

クライアントには富士通 PRIMERGY BX600 ブレードサーバシリーズの BX620 S5 を 2 ブレード使

用して業務アプリケーションを実行しています。

モデル富士通 PRIMERGY BX620 S5

CPU インテル Xeon プロセッサー X5570 2.93GHz（4コア）x 2

メモリ 24GB

OS Red Hat Enterprise Linux Server Release 5.3（Tikanga）

ストレージ管理クライアント

ETERNUS SF Storage Cruiser を使用して、ETERNUS を管理しています。

モデル富士通 PRIMERGY RX300 S3

CPU インテル Xeon 5160 プロセッサー 3.00GHz（2コア）

メモリ 3GB

OS Microsoft Windows Server 2003 R2

ストレージ管理 ETERNUS SF Storage Cruiser 14.1

ETERNUS SF AdvancedCopy Manager 14.1




16

検証結果

Oracle ORION による HDD 及び SSD の I/O 性能

Database Smart Flash Cache の性能測定の前に HDD 及び SSD の I/O 性能の傾向を確認します。各ド

ライブから構成される Logical Unit（以降、LU）に対して、OLTP 系アプリケーションから発行さ

れる SQL を想定したランダム読み込み及び書き込み時の I/O 性能（IOPS）を Oracle ORION5を使

用して測定しました。ETERNUS DX80 のコントローラーのライト・キャッシュは HDD、SSD 共に

有効な状態で測定しました。

ランダム読み込み性能

ETERNUS DX80 で SSD を使用する場合に構成可能な RAID レベルとドライブ本数を基準として、

HDD も同様の RAID グループを構成し、各 RAID グループから 1 つの LU を作成しました。測定

に使用した RAID レベルとドライブ本数の一覧を図 6に示します。

5 Oracle ORION は、Oracle Database の I/O ワークロードをシミュレートする I/O 性能測定ツールで

す。Oracle Database をインストールする必要は無く、RAID 構成や ASM ディスク・グループ、デ

ータベース・ブロックサイズ等を想定したシーケンシャル I/O やランダム I/O を生成し、ストレー

ジの I/O 性能を測定することが可能です。Oracle ORION はプラットフォーム毎に提供されており、

Oracle Technology Network （http://www.oracle.com/technology/software/tech/orion/index.html）からダ

ウンロードすることが可能です。




17

種別 RAIDレベルドライブ本数構成名

HDD RAID1 2 HDD - RAID1 (1+1)


SSD RAID1 2 SSD - RAID1 (1+1)


図 6 HDD及びSSDのストレージ構成

次のグラフ（図 7）は、I/O サイズを Oracle Database で使用可能なデータベース・ブロックサイズ

（2KB～32KB）に設定した場合のランダム読み込み性能（IOPS）の測定結果です。

図 7 HDD及びSSDのIOPS




18

ランダム読み込み性能の測定結果から、SSD は全ての I/O サイズにおいて HDD より IOPS が高い

ことを確認できました。その性能は OLTP システムの標準的なデータベース・ブロックサイズであ

る 8KB の場合、RAID1 において HDD の約 14 倍、RAID5 において HDD の約 9 倍を記録していま

す。

ランダム書き込み性能

ランダム読み込み性能の測定時と同様の RAID グループを構成しました。測定に使用した RAID レ

ベルとドライブ本数の一覧を図 8に示します。

種別 RAIDレベルドライブ本数構成名






次のグラフ（図 9）は、I/O サイズを Oracle Database で使用可能なデータベース・ブロックサイズ

（2KB～32KB）に設定した場合のランダム書き込み性能（IOPS）の測定結果です。




19


ランダム書き込み性能の測定結果から、SSD は全ての I/O サイズにおいて HDD より IOPS が高い

ことを確認できました。その性能は OLTP システムの標準的なデータベース・ブロックサイズであ

る 8KB の場合、RAID1 において HDD の約 21 倍、RAID5 において HDD の約 9 倍を記録していま

す。

読み込みと書き込みを混在したランダム I/O 性能

OLTP システムにおいて発行される SQL は、SELECT だけではなく、INSERT や UPDATE、

DELETE も混在しているため、読み込みと書き込みを混在させた I/O ワークロードを生成しました。

I/O 単位としては 8KB での IOPS を測定しました。

測定に使用したストレージ構成を図 10に示します。本項では、RAID1（1+1）で構成した SSD と

同等の IOPS が期待できる HDD 構成を確認するため、搭載されている全ての HDD を使用して I/O

を分散（ストライピング）させました。これにより、SSD2 本に対して HDD24 本を使用していま

す6。

6 なお、『ランダム読み込み性能』の項では、SSD の IOPS は OLTP システムの標準的なデータベ

ース・ブロックサイズである 8KB の場合、RAID1 において HDD の約 14 倍を記録しました。理論

上、RAID1（1+1）で構成した SSD と同等のランダム読み込み性能を得るためには HDD28 本が必

要ですが、搭載ドライブ数の都合上 HDD を 24 本使用しました。




20

種別 RAIDレベル

とドライブ数

RAID

グループ数総ドライブ数構成名

HDD RAID1+0 (3+3) 4グループ HDD x 24 HDD - RAID1+0 (3+3) x 4

SSD RAID1 (1+1) 1グループ SSD x 2 SSD - RAID1 (1+1) x 1


次のグラフ（図 11）は、読み込みと書き込みを混在させ、その割合を変化させた場合のランダム

I/O 性能（IOPS）の測定結果です。SSD はいずれのパターンにおいても IOPS が高いことを確認で

きました。また、いずれのドライブも書き込みが混在する割合が増加するほど IOPS が減尐する傾

向を確認できました。





21

HDD 及び SSD のランダム I/O 性能のまとめ

以上の Oracle ORION による I/O 性能の測定結果から確認できた SSD の特長は、表 3の通りです。

表 3 HDD及びSSDのI/O性能

ドライブランダム

読み込み書き込み

SSD HDDに比べ非常に高速 HDDに比べ非常に高速

HDD SSDに比べ非常に低速 SSDに比べ非常に低速

SSD は HDD と比較してランダム I/O（IOPS）性能が非常に高いことを確認できました。SSD は記

憶媒体としてフラッシュメモリを用いているため、HDD のデータアクセス時に必要であったヘッ

ドをディスク上で移動させる時間（シークタイム）や、目的のデータがヘッド位置まで回転してく

るまでの待ち時間（サーチタイム）が発生せず、ランダム I/O 性能に優れています。

また、いずれのドライブも書き込みが混在する割合が増加するほど IOPS が減尐する傾向を確認で

きました。

http://e-words.jp/w/E38387E382A3E382B9E382AF.html

http://e-words.jp/w/E382B7E383BCE382AFE382BFE382A4E383A0.html

http://e-words.jp/w/E38387E383BCE382BF.html




22

OLTP 系アプリケーションの性能比較

Oracle ORION による HDD 及び SSD の I/O 性能の測定結果より、ランダム I/O が頻発する OLTP 系

アプリケーションから発行される SQL において SSD を使用することによる性能向上が期待できま

す。本節からは、OLTP 系アプリケーションによる検証結果を報告します。

汎用的な OLTP 処理を実装した負荷生成ツール

本検証で使用した負荷生成ツールは、Oracle JDBC OCI Driver 11g を使用して Oracle インスタンス

に接続し任意の SQL を実行する Java カスタム･アプリケーションです。今回は、Spring Framework

にサンプルとして付属する JPetStore アプリケーションのデータベース・スキーマを使用し、図 12

のユーザー・シナリオに沿った汎用的な SQL を実行しました。本検証で使用したトランザクショ

ンの特徴を下記に示します。

Tx1：商品を検索し、購入するトランザクション

- 注文処理により INSERT 及び UPDATE の SQL を発行

Tx2：商品の検索のみで購入はしないトランザクション

- SQL は SELECT のみ

図 12 ユーザー・シナリオとトランザクションの定義

各トランザクションの割合は、一般的にオンラインショッピングサイトを利用するユーザーは主に

検索を行うことを想定し、Tx1 と Tx2 の割合を 2:8 としました。




23

本検証では、アプリケーションの同時実行数（以降、スレッド数）とアクセスするデータの範囲

（以降、検索範囲）を増加させることで、OLTP システムにおけるデータベース・クライアントが

アクセスするデータ量の増加を表現しました。

図 13 検索範囲の変更

データベース・スキーマ構成

本検証では、検証項目に合わせて大小 2 種類のデータベース・スキーマ（以降、スキーマ）を作成

しました。1 つ目のスキーマは SSD で構成された 1 つの LU の最大容量に合わせ、約 90GB のスキ

ーマを作成しました。2 つ目のスキーマは、データ量が増加したデータベースを想定し、500GB の

スキーマを作成しました。スキーマの構成は下記の通りです。

表 4 表

種別表名パーティション備考

master

ACCOUNT なし利用ユーザー

PROFILE なしユーザープロファイル

SIGNON なしパスワード管理

CATEGORY なし商品リンク

PRODUCT なし商品マスタ

INVENTORY なし商品項目在庫管理

ITEM なし商品項目管理

transaction

ORDERS hash (256) 注文IDや注文者

ORDERSTATUS hash (256) 注文日時や状況

LINEITEM なし注文数や注文単価




24

表 5 索引

表名索引名備考

ACCOUNT PK_ACCOUNT 主キー用索引

PROFILE PK_PROFILE 主キー用索引

SIGNON PK_SIGNON 主キー用索引

CATEGORY PK_CATEGORY 主キー用索引

PRODUCT

PK_PRODUCT 主キー用索引

PRODUCT_NAME 商品名（商品検索用）

PRODUCT_CATEGORY 商品カテゴリー

（商品検索用）

PRODUCT_DESCN 商品概要（商品検索用）

INVENTORY PK_INVENTORY 主キー用索引

ITEM ITEMPROD PRODUCTID列

PK_ITEM 主キー用索引

ORDERS PK_ORDERS 主キー用索引（ローカル）

ORDERSTATUS PK_ORDERSTATUS 主キー用索引（ローカル）

LINEITEM PK_LINEITEM 主キー用索引（ローカル）

SSD を HDD の代替として使用した場合の性能

本項では、SSD を HDD の代替として使用した場合の OLTP システムの性能向上とその特徴を報告

します。

データベース・スキーマをHDD及びSSD上に配置

図 14は、スキーマを HDD 及び SSD 上に配置した場合のストレージ構成です。HDD のみで構成さ

れた ASM ディスク・グループ（DG_HDD）と SSD のみで構成された ASM ディスク・グループ

（DG_SSD）に表領域を作成し、DG_SSD の最大容量である約 90GB のスキーマを表領域毎に作成

しました。




25

図 14 スキーマをHDD及びSSD上に配置した場合のストレージ構成

次のグラフ（図 15）は、構成毎にスレッド数を増加させた場合の OLTP 処理性能の測定結果です。

図 15 スキーマをHDD及びSSD上に配置した場合のOLTP処理性能

スキーマを SSD 上に配置することで、HDD に配置した場合に発生していた IOPS 性能のボトルネ

ックを改善し、300 スレッドにおいて最大 2 倍の TPS を記録しています。CPU 使用率とドライブ

毎の IOPS を図 16に示します。




26

図 16 スキーマをHDD及びSSD上に配置した場合のOS統計

スキーマを HDD に配置した場合は、200 スレッドの時点で HDD の IOPS 性能がボトルネックとな

り、TPS が頭打ちになりました。SSD 上に配置した場合は、300 スレッドの時点でも SSD の IOPS

性能の限界には達しておらず、CPU 使用率が 100%となったため、TPS が頭打ちになりました。そ

のため、Oracle Real Application Clusters のノード追加やデータベース・サーバを上位機種へ変更す

ることで、更なる性能向上が期待できます。

本項の測定結果から、スキーマを SSD 上に配置することで HDD の IOPS 性能のボトルネックを改

善し、OLTP システムの性能向上が可能であることを確認できました（図 17）。

図 17 スキーマをSSD上に配置することによるOLTPシステム性能向上




27

スキーマ・オブジェクトを選別してSSD上に配置

SSD は HDD と比較して容量あたりのコストが高く、スキーマ全体を SSD 上に配置するのは非常

にコストがかかり現実的ではありません。システム構築時点でスキーマ全体を SSD 上に配置可能

だとしても、更にデータ量が増加した場合、SSD を追加する対応も高いコストがかかります。そ

のため、貴重な SSD の容量を効率的に使用するために、配置するスキーマ・オブジェクトをユー

ザーが選別する方法が考えられます。更に、Oracle ORION の測定結果から、書き込みが混在する

割合が増加するほど IOPS の最大値が減尐する傾向を確認できたため、発行される SQL の多くが

SELECT である OLTP システムでは読み込みを可能な限り HDD から SSD へ移すことによって、コ

ストパフォーマンスの最大化が期待できます。

本検証では、HDD からの読み込み（物理読み込み）が多いスキーマ・オブジェクトを AWR レポ

ートの”Segments by Physical Reads”の項目より特定し、優先して SSD 上に配置しました。図 18は、

スキーマを HDD に配置した場合の AWR レポートの”Segments by Physical Reads”の項目です。

図 18 AWRレポートのSegments by Physical Readsの項目

最も物理読み込みが多いスキーマ・オブジェクトの ITEM と比較して、 PK_ITEM と

PK_INVENTORY の物理読み込みの数はほぼ同じ値ですが、オブジェクト・サイズは大きな差があ

ります（表 6）。物理読み込みを可能な限り SSD へ移すためには、オブジェクト・サイズを考慮

して SSD の容量を効率的に使用する必要があります。

表 6 物理読み込みが多いオブジェクト・サイズ

オブジェクト名サイズ（GB） PHYSICAL READS PHYSICAL READS /

サイズ（GB）

ITEM 134.27 486,565 3624

PK_ITEM 66.35 469,820 7081

PK_INVENTORY 66.35 469,691 7079

INVENTORY 59.94 454,410 7581

PRODUCT 25.24 370,374 14674

サイズあたりの物理読み込み（表 6の PHYSICAL READS / サイズ（GB））の値が大きいスキー

マ・オブジェクトを SSD 上に配置することが最も効率的だと考えられます。また、SSD の IOPS




28

最大値の劣化を防ぐため、商品在庫の管理している UPDATE 対象の INVENTORY は候補から除外

しました。本検証では、全体の約 57%の物理読み込みにあたる PK_ITEM、PK_INVENROTY、

PRODUCT の 3 つのスキーマ・オブジェクトを SSD 上に配置しました（図 19）。

図 19 スキーマ・オブジェクトを選別してSSD上に配置した場合のストレージ構成

次のグラフ（図 20）は、構成毎に 200 スレッドで検索範囲を変更した場合の OLTP 処理性能の測

定結果です。

図 20 スキーマ・オブジェクトを選別してSSD上に配置した場合のOLTP処理性能

スキーマ・オブジェクトを選別して SSD 上に配置した場合の測定結果から、スキーマ全体を SSD

上に配置できない場合でも、物理読み込みが多いスキーマ・オブジェクトを優先して SSD 上に配

置することで HDD の IOPS 性能のボトルネックを改善し、OLTP システムの性能向上が可能であ

ることを確認できました（図 21）。




29

図 21 スキーマ・オブジェクトを選別してSSD上に配置することによるOLTPシステム性能向上

次のグラフ（図 22）は、各測定の CPU 使用率及びドライブ毎の IOPS です。

図 22 スキーマ・オブジェクトを選別してSSD上に配置した場合のOS統計

全体の約 57%の物理読み込みを SSD に移してはいますが、依然として HDD の IOPS 性能のボトル

ネックが続き、OLTP 処理性能が頭打ちになっていました。一般的に、スキーマ・オブジェクト内

のデータに対するアクセス頻度には偏りがあるため、SSD 上に配置されているスキーマ・オブジ

ェクトにはアクセス頻度が低いデータ・ブロックも含まれています（図 23）。SSD の容量を最大

限効率的に使用するには、アクセス頻度が高いデータ・ブロックを極力 SSD 上に配置する必要が

あります。




30

図 23 アクセス頻度が高いデータ・ブロックと低いデータ・ブロックの混在

より効率的にSSDの容量を使用するアプローチ

本検証では実施していませんが、アクセス頻度が高いデータ・ブロックを極力 SSD 上に配置し、

より効率的に SSD の容量を使用するアプローチとして下記の 2 つが考えられます。




31

① Oracle PartitioningによるInformation Lifecycle Management（ILM）

物理読み込みが多いオブジェクトをパーティション化し、アクセス頻度が高いパーティション

のみを SSD 上に配置することで SSD の容量の使用効率を向上させます。その結果、より多く

の物理読み込みが HDD から SSD へ移り、OLTP システムの性能向上が期待できます。

図 24 Oracle PartitioningによるILM

ILM の有効性については参考文献を参照して下さい。

富士通 ETERNUS / SPARC Enterprise による Oracle Database ILM ソリューション

(http://storage-system.fujitsu.com/jp/news/2009/0616/)




32

SSDをHDDの代替として使用した場合のまとめ

スキーマを SSD 上に配置することで OLTP システムの性能向上が可能です。しなしながら、一般

的にデータベース・スキーマ全体を SSD 上に配置するのは高コストであるため、スキーマ・オブ

ジェクトを選別して SSD 上に配置する必要があります。本検証では、HDD からの読み込みが多い

スキーマ・オブジェクトを優先して SSD 上に配置しました。その結果、OLTP システムの性能向

上が可能ではありますが、アクセス頻度が低いデータ・ブロックも SSD 上に配置されており、

SSD のコストパフォーマンスが最大化されていないことを確認しました。

② Advanced Compression - OLTP表圧縮の導入

表オブジェクトのサイズを圧縮することによって SSD 上に配置可能なオブジェクト数が増加

し、より多くの物理読み込みを HDD から SSD へ移すことが可能になります。更に、1 つのデ

ータ・ブロックに格納されるレコード数が増加することでクエリー時に取得する必要があるデ

ータ・ブロック数が減尐し、OLTP システムの性能向上が期待できます。

図 25 Advanced Compression - OLTP表圧縮

圧縮機能の有効性については参考文献を参照して下さい。

富士通 SPARC Enterprise による Oracle 11g データ・ウェアハウス検証

(http://primeserver.fujitsu.com/sparcenterprise/news/article/08/0527/)




33

Database Smart Flash Cache を使用した場合の性能

本項では、Database Smart Flash Cache を使用した場合の OLTP システムの性能向上とその特徴を報

告します。

Database Smart Flash CacheによるOLTPシステム性能向上

図 26のように、合計 12 本の HDD 上に構成されたデータベース・システムに対し、ETERNUS

DX80 上の SSD を Database Smart Flash Cache 領域として追加します。

図 26 Database Smart Flash Cacheを使用した場合のストレージ構成

RAC 環境ではノード毎に Database Smart Flash Cache 領域が必要です。本環境で使用した SSD の構

成とノード毎の Database Smart Flash Cache 領域のサイズを表 7に示します。

表 7 Database Smart Flash Cache領域のLU数とノード毎のサイズ

RAID構成 LU数総容量

（GB）

ノード毎のDATABASE SMART

FLASH CACHE領域サイズ（GB）

RAID1（1+1） 2LU 180 90

本検証では、データ量と Database Smart Flash Cache 領域のサイズによる OLTP 処理性能の傾向を確

認するために、アクセス対象のデータ範囲をアプリケーションで制御し、検索範囲（Select

Range）を変更しながらテストを実施しました。次のグラフ（図 27）は、その測定結果です。




34

図 27 Database Smart Flash CacheによるOLTP処理性能向上

この測定結果から、Database Smart Flash Cache を使用することで HDD の IOPS 性能のボトルネッ

クを改善し、OLTP システムの性能向上が可能であることを確認できました。本検証では、最大で

約 2.4 倍の性能向上を記録しています。検索範囲が 9GB の場合はバッファ・キャッシュ・ヒット

率がほぼ 100%となり、いずれの構成においても OLTP 処理性能に差はありません。HDD のみの構

成の場合は、検索範囲の拡大に伴って HDD からデータ・ブロックを取得する割合が増加するため

OLTP 処理性能が大きく劣化します。一方、Database Smart Flash Cache を使用した場合は、検索範

囲の拡大に伴う OLTP 処理性能の劣化の推移が非常に緩やかです。

次のグラフ（図 28）は、各構成における HDD 及び SSD の I/O の傾向です。

図 28 HDD及びSSDへのI/O傾向

Database Smart Flash Cache 領域でのキャッシュ・ミスが発生すると、HDD への I/O が行われます。

取得したデータ・ブロックをバッファ・キャッシュに配置するために、アクセス頻度が低いデー

タ・ブロックが Database Smart Flash Cache 領域に書き込まれます。これにより、Database Smart

Flash Cache 領域のサイズを超えて検索範囲が拡大するほど、HDD への I/O の頻度と SSD への書き




35

込みの割合が増加します。そのため、Database Smart Flash Cache の効果（HDD のみの構成との性

能差）は、検索範囲が Database Smart Flash Cache 領域のサイズ付近の時点で最大になると言えます。

次のグラフ（図 29）は、構成毎の平均 CPU 使用率（%usr + %sys）です。

図 29 Database Smart Flash Cacheを使用した場合のCPU使用率

HDD のみの構成の場合は、検索範囲の拡大に伴って HDD の IOPS 性能がボトルネックとなり、

TPS が劣化していくため CPU 使用率も減尐していきます。一方、Database Smart Flash Cache を使

用した場合は、検索範囲の拡大に伴って TPS は僅かに劣化していきますが、CPU 使用率は増加し

ています。検索範囲の拡大が Database Smart Flash Cache 領域のサイズ内に収まっていても、その拡

大に伴いバッファ・キャッシュ・ヒット率が低下し、SSD への I/O の頻度が増加します（図 28）。

OS のカーネルによる I/O システムコールと Database Smart Flash Cache の使用による CPU リソース

の消費が共に増加するため、CPU 使用率が増加していくと考えられます。




36

Database Smart Flash Cache領域のサイズを増加させた場合の性能

前項では、Database Smart Flash Cache 領域のサイズが不足すると、OLTP 処理性能が劣化する傾向

がありました。このような問題に対し、Database Smart Flash Cache 領域のサイズを増加させること

で、高い OLTP 処理性能の向上が期待できます。本検証では、RAID レベルと使用する LU の数を

変更し、Database Smart Flash Cache 領域のサイズを増加しました（図 30）。

RAID構成 LU数

SSD

本数

の合計

総容量

（GB）

ノード毎の

DATABASE SMART

FLASH CACHE

領域サイズ（GB）

構成名

RAID1 (1+1) 1LU 2 90 45 RAID1 (1+1) x 1

RAID1 (1+1) 2LU 4 180 90 RAID1 (1+1) x 2

RAID5 (3+1) 1LU 4 270 135 RAID5 (3+1) x 1

RAID5 (3+1) 2LU 8 540 270 RIAD5 (3+1) x 2

図 30 Database Smart Flash Cache領域のSSD構成とノード毎のサイズ




37

図 31は、構成毎に検索範囲を変更した場合の測定結果です。

図 31 Database Smart Flash Cache領域サイズの増加によるOLTP処理性能向上

Database Smart Flash Cache 領域のサイズを増加させることで、検索範囲の拡大に伴う OLTP 処理性

能の劣化を防げることを確認できました。このことから、検索範囲に合わせて Database Smart Flash

Cache 領域に SSD を追加することで、データ量の増加に対応できると考えられます。

Database Smart Flash Cache を使用した場合は、バッファ・キャッシュ上に管理領域が確保され、そ

のサイズは Database Smart Flash Cache 領域サイズの 2～3％程度です。本検証では、”RAID5 x 2”の

構成において、検索範囲が Database Smart Flash Cache 領域のサイズ内に収まっている場合に、若干

の影響が見られました（図 31）。本環境のバッファ・キャッシュのサイズは 16GB であり、

Database Smart Flash Cache 領域のサイズが 270GB の場合は、その 2～3%である 5～8GB の管理領

域が 16GB のバッファ・キャッシュ上に確保されます。その結果、残りのバッファ・キャッシュの

領域では検索範囲のデータをキャッシュしきれなくなり、TPS が若干減尐しました。

各SSD使用方法の性能比較

本項では、『スキーマ・オブジェクトを選別して SSD 上に配置』の項と『Database Smart Flash

Cache による OLTP システム性能向上』の項での測定結果を比較します。SSD の構成は前者に合わ

せ、Database Smart Flash Cache 領域に SSD を RAID1（1+1）で 2LU 使用し、ノード毎の Database

Smart Flash Cache 領域のサイズを 90GB とします。次のグラフ（図 32）は、その測定結果です。




38

図 32 各SSD使用方法によるOLTP処理性能

本検証では、Database Smart Flash Cache を使用した方が、高い OLTP 処理性能を得ることができま

した。オブジェクトを選別して SSD 上に配置した場合は、依然として HDD の IOPS 性能のボトル

ネックが続いて OLTP 処理性能が頭打ちになっています。これに対し、Database Smart Flash Cache

を使用した場合は、HDD の IOPS 性能のボトルネックを改善し、CPU リソースを活用することが

できています（図 33）。

図 33 各SSD使用方法によるOS統計




39

Database Smart Flash Cacheを使用した場合のまとめ

Database Smart Flash Cache は、SSD を Database のキャッシュとして活用します。Database Smart

Flash Cache 領域には、アクセス頻度が高いにも関わらず、バッファ・キャッシュからキャッシ

ュ・アウトされたデータ・ブロックが自動的に配置されます。その結果、HDD の代替として使用

した場合に実施したような分析、運用を行うことなく、SSD を最大限活用した OLTP システムの

性能向上が可能であることを確認しました。

注意点としては、下記の点が考えられます。

バッファ・キャッシュ上にDatabase Smart Flash Cacheの管理領域が確保される

Database Smart Flash Cacheを使用することによるCPUオーバーヘッド

RAC環境ではノード毎にDatabase Smart Flash Cache領域が必要

総括

ストレージの I/O 性能に課題を持つ OLTP システムが増加する中、高速な I/O が可能である SSD を

使用することで、OLTP システムの性能向上が期待できます。本検証にて、SSD を使用した性能向

上アプローチの特徴を確認できたことにより、OLTP システムが持つ課題に対して、より適切な解

決策を提示することが可能になりました。

SSD を HDD の代替として使用する場合は、IT コスト削減も企業にとっての大きな課題となってい

るため、全てのデータを SSD へ配置することは現実的ではありません。そのため、データベース

を分析し、アクセス頻度やサービスレベルに応じたストレージ構成とデータの配置が必要です。し

かしながら、本検証のように、データを選別して SSD 上に配置したとしても、SSD の性能を最大

限活用できず、期待した性能を得られない可能性があります。

Database Smart Flash Cache を使用する場合は、バッファ・キャッシュの拡張領域として SSD を活

用することで OLTP 処理性能が向上します。SSD 上へのデータの配置は自動化されるため、デー

タベースの分析や、データの再配置等が不要という特長があります。導入、運用コストを抑えつつ、

高い OLTP 処理性能が得られる非常に優位なソリューションであると言えます。

富士通 ETERNUS ストレージシステムでは本検証で使用した DX80 をはじめ、エントリークラス

のモデルから SSD を搭載可能であり、比較的安価に SSD を導入できます。Database Smart Flash

Cache を使用可能である SPARC Enterprise と組み合せることにより、導入コストを抑えた高速なデ

ータベース・システムを構築することが可能になります。




40

Appendix A

Database Smart Flash Cache のチューニング

Database Smart Flash Cache 領域にはアクセス頻度が高いデータ・ブロックが自動的に配置されます

が、ユーザーが優先してキャッシュするデータ及びキャッシュしないデータを指定することも可能

です。以降では、その設定方法とその効果について報告します。

設定方法の例を下記に示します。STORAGE 句で KEEP、NONE、DEFAULT のいずれかをスキー

マ・オブジェクト毎に指定可能です。

スキーマ・オブジェクトを優先的にキャッシュする設定例

スキーマ・オブジェクトをキャッシュしない設定例

デフォルトの設定例

次に、SSD の IOPS 性能がボトルネックとなっている状態に対して、Database Smart Flash Cache の

チューニングを実施します。

『Database Smart Flash Cache による OLTP システム性能向上』の項では、Database Smart Flash

Cache 領域として SSD を RAID1 で 1LU 使用した構成において、検索範囲が 45GB の場合に、最も

高い SSD の IOPS を記録しました（図 28）。この構成に対し、アプリケーションのスレッド数を

200 スレッドから 300 スレッドに増加させることで、SSD の IOPS 性能がボトルネックとなりまし

た。

本検証では、この環境に対して UPDATE 対象表の INVENTORY をキャッシュしない設定をしまし

た。UPDATE が発行されると、Database Smart Flash Cache 領域上の該当するデータ・ブロックが無

効になります。そのため、そのスキーマ・オブジェクトに対してキャッシュしない設定を行うこと

で Database Smart Flash Cache 領域の使用効率が向上すると考えられます。

ALTER TABLE <OBJECT_NAME> STORAGE (FLASH_CACHE DEFAULT);

ALTER TABLE <OBJECT_NAME> STORAGE (FLASH_CACHE NONE);

ALTER TABLE <OBJECT_NAME> STORAGE (FLASH_CACHE KEEP);




41

構成毎の TPS 及びレスポンス・タイムと、HDD 及び SSD の平均応答時間7を下記に示します（図

34、図 35）。

図 34 チューニングによるOLTP処理性能向上

7 データベースの待機イベント”db file sequential read”と”db flash cache single block physical read”1 回

あたりの平均待機時間を使用します。”db file sequential read”は HDD からデータ・ブロックを取得

した際の待機時間を表すため、データベースから見た HDD の応答時間とみなします。”db flash

cache single block physical read”は Database Smart Flash Cache 領域からのデータ・ブロックを取得し

た際の待機時間を表すため、データベースから見た SSD の応答時間とみなします。




42

図 35 SSD応答時間の改善

Database Smart Flash Cache のチューニングを実施することで、SSD の IOPS 性能のボトルネックを

改善し、OLTP 処理性能の向上が可能であることを確認できました。デフォルトの設定の場合、

SSD の応答時間が HDD と比較しても遥かに低速になっています。それに対し、INVENTORY をキ

ャッシュしない設定の場合は、HDD の負荷が僅かに増加してはいますが、SSD の応答時間が劇的

に改善されています。

以上のように、Database Smart Flash Cache にはスキーマ・オブジェクト毎にキャッシュの動作を制

御する機能が備わっています。これにより、ユーザーが I/O の傾向をもとにチューニングを実施す

ることで、SSD 使用効率の向上による OLTP システムの性能向上が期待できます。




43

Appendix B

SPARC Enterprise のご紹介

「SPARC Enterprise」は、SPARC/Solaris アーキテクチャーを継承し、さらなる機能強化と性能向

上を実現した UNIX サーバとして誕生しました。業務特性に合わせて、下記の製品ラインナップを

ご用意しています。

データベースやバッチ処理などの幅広い業務に適用可能な、高性能・高信頼かつ拡張性の高い

サーバ

Webフロント業務、オンライントランザクション処理等に最適なサーバ

詳しくは、下記 WEB ページをご覧下さい。

http://primeserver.fujitsu.com/sparcenterprise/




44

ETERNUS DX series

ETERNUS DX series は、RAID 技術を採用した高信頼・高性能ディスクアレイです。

中小規模の企業や分散システム環境に最適なコンパクトでコストパフォーマンスに優れたエン

トリーディスクアレイ「ETERNUS DX60/DX80/DX90」

コンプライアンス対応などの様々な課題を解決するコストパフォーマンスに優れたミッドレン

ジディスクアレイ「ETERNUS DX400 series」

コンプライアンス対応やシステム統合などの様々な課題を解決するエンタープライズディスク

アレイ「ETERNUS DX8000 series」

をラインナップしています。

ETERNUS DX60/DX80/DX90

基幹 IA/UNIX/PC サーバに対応したエントリーディスクアレイです。コンパクトな筐体に高い拡張

性と信頼性を備え、中小規模システムに最適なソリューションを提供します。なお、ETERNUS

DX90 では、上位機種と同様にリモート・アドバンスト・コピー機能もサポートしています。

* 本容量は1kByte=1,000Byteとして計算した物理容量値（システムディスク、ホットスペアディスクを含む）

2TB ニアラインSASディスクドライブ搭載時

ディスク容量＊：最大 48TB

キャッシュ容量： 2GB

コントローラー数： 2台

ホスト・インターフェース数

- FC(4Gbit/s) ： 2, 4

- iSCSI(1Gbit/s) : 2, 4

- SAS(3Gbit/s) : 2, 4

Entry Disk storage systems





- FC(8Gbit/s, 4Gbit/s) ： 2, 4

- iSCSI(1Gbit/s) : 2, 4

- SAS(3Gbit/s) : 2, 4





- FC(8Gbit/s) ： 8

ETERNUS DX80

ETERNUS DX90

ETERNUS DX60




45

ETERNUS DX400 series

基幹 IA/UNIX/PC サーバに対応したミッドレンジディスクアレイです。豊富なラインナップと、優

れた拡張性により、データの保全、コンプライアンス対応など、情報システムに求められる広範囲

な要件に最適なソリューションを提供します。

ETERNUS DX410 ETERNUS DX440





- FC(8Gbit/s, 4Gbit/s) ： 2～8

- iSCSI(1Gbit/s) ： 2, 4

-






- iSCSI(1Gbit/s) ： 4, 8

* 本容量は1kByte=1,000Byteとして計算した物理容量値（システムディスク、ホットスペアディスクを含む）

2TB ニアラインSATAディスクドライブ搭載時

Midrange Disk storage systems




46

ETERNUS DX8000 series

グローバルサーバから基幹 IA/UNIX/PC サーバまでマルチプラットフォームに対応したエンタープ

ライズディスクアレイです。コンプライアンス対応など、企業を取り巻くさまざまな環境に対応し、

企業レベルでの大規模なシステム統合を実現します。






- iSCSI(1Gbit/s) ： 4～8

- OCLINK ： 4～8

- FCLINK ： 4～8

* 本容量は1kByte=1,000Byteとして計算した物理容量値（ホットスペアディスクを含む）

2TB ニアラインSATAディスクドライブ搭載時

Enterprise Disk storage systems

ETERNUS DX8100

０410

ETERNUS DX8400

０410

ETERNUS DX8700

０410

ディスク容量＊：最大 2,008TB


コントローラー数： 2, 4台




- OCLINK ： 4～32

- FCLINK ： 4～32

ディスク容量＊：最大 5,456TB


コントローラー数： 2, 4, 6, 8台


- FC(8Gbit/s, 4Gbit/s) ： 16～128


- OCLINK ： 4～64

- FCLINK ： 4～64




富士通 SPARC Enterprise上でのDatabase Smart

Flash CacheによるOLTPシステムの性能向上

2010年 4月

富士通株式会社

東京都港区東新橋1-5-2

汐留シティセンター

本書は、Oracle GRID Centerの取組みにて実施された検証結果に関する技術情報を提供するものであり、本書に記載されている内容

は改善のため、予告無く変更することがあります。富士通株式会社は、本書の内容に関して、いかなる保証もいたしません。また、

本書の内容に関連した、いかなる損害についてもその責任は負いません。

UNIXは、米国およびその他の国におけるオープン・グループの登録商標です。

すべての SPARC 商標は、 SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における登

録商標です。SPARC 商標が付いた製品は、Sun Microsystems, Inc. が開発したアーキテクチャーに基づくものです。

SPARC64は、米国SPARC International, Inc.のライセンスを受けて使用している同社の登録商標です。

Sun、Sun Microsystems、Sunロゴ、SolarisおよびすべてのSolarisに関連する商標及びロゴは、米国およびその他の国における米国

Sun Microsystems, Inc.の商標または登録商標であり、同社のライセンスを受けて使用しています。

その他各種製品名は、各社の製品名称、商標または登録商標です。

本資料に記載されているシステム名、製品名等には、必ずしも商標表示（（R）、TM）を付記していません。

著者: 岩本知博

日本オラクル株式会社

東京都港区北青山2-5-8

オラクル青山センター

このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があります。このドキュメントに誤りが無いことの

保証や、商品性又は特定目的への適合性の黙示的な保証や条件を含め明示的又は黙示的な保証や条件は一切無いものとします。日本

オラクル株式会社は、このドキュメントについていかなる責任も負いません。また、このドキュメントによって直接又は間接にいか

なる契約上の義務も負うものではありません。このドキュメントを形式、手段（電子的又は機械的）、目的に関係なく、日本オラク

ル株式会社の書面による事前の承諾なく、複製又は転載することはできません。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名

等は各社の商標または登録商標である場合があります。

Documents

Oracle Database 11g Release 2 富士通 SPARC Enterprise … · 富士通 SPARC Enterprise上でのDatabase Smart Flash CacheによるOLTP ... Database Smart Flash Cache Oracle Database