エンタープライズ・フラッシュ・ドライブとEMC CLARiX CX4を利用したOracleデータベースの展開

(1)

エンタープライズ・フラッシュ・ドライブと

EMC CLARiX CX4 を利用した

Oracle データベースの展開

高度なテクノロジー

US ホワイト・ペーパー翻訳版要約このホワイト・ペーパーでは、Oracle データベースをエンタープライズ・フラッシュ・ドライブに置いた場合と従来のハード・ディスク・ドライブに置いた場合のパフォーマンスの考慮事項について考察します。また、部分データベース・コンテナをフラッシュ・ドライブに配置するためのベスト・プラクティスについて説明します。 2008 年 12 月

(2)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した Oracle データベースの展開

高度なテクノロジー 2

EMC Corporation は、この資料に記載される情報が、発効日時点で正確であるとみなしています。この情報は、予告なく変更されることがあります。この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。この資料に記載される、いかなる EMC ソフトウェアの使用、複製、頒布も、当該ソフトウェア・ライセンスが必要です。

最新の EMC 製品名については、EMC.com で EMC Corporation の商標を参照してください。

他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。パーツ番号 H5967-J

(3)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した Oracle データベースの展開高度なテクノロジー 3

エグゼクティブ・サマリー... 4

概要... 5

対象読者... 6

テクノロジーの概要... 6

CLARiX CX4 ... 6

Oracleデータベースとエンタープライズ・フラッシュ・ドライブ... 7

EFDに最も適したデータベース・ワークロード ... 7 Oracle AWRレポートまたはStatspackレポートの分析 ... 9 負荷プロファイル・セクション ... 9 Oracle待機イベント ... 10 テーブルスペースI/O統計... 11

使用例の比較 ... 12

使用例 1：読み取り集中型ワークロード... 12 使用例 2：Oracle OLTPワークロードの比較 ... 15 使用例 4：EFDへの部分データベースの移動 ... 19 EFDのREDOログか?（あるいは、そうではないか） ... 19 EFD上のOracle一時テーブルスペース... 20 EFDへのオブジェクト強度が高いオブジェクトの移動 ... 20

EFDとILM（情報ライフサイクル管理）戦略 ... 24

結論... 25

エグゼクティブ・サマリー

CLARiX® CX4 シリーズには、EFD（エンタープライズ・フラッシュ・ドライブ）を利用するための機能が導入されました。EMC® CLARiXは、この新世代のデータ・ストレージ・デバイスを初めてサポートする唯一のミッドレンジ・アレイです。EMCは、この機能を使用して新しい超高性能「階層 0」ストレージを作成しました。このストレージにより、磁気ディスク・ドライブのパフォーマンスの制限がなくなります。EMC®_{テクノロジーで最適化されたエンタープライズ・} クラスのフラッシュ・ドライブと、高度なCLARiX機能を組み合わせることにより、ミッドレンジ・ストレージ・プラットフォームにはなかった新しいストレージ階層が手に入ります。エンタープライズ・フラッシュ・ドライブは、レーテンシーの影響を受けるアプリケーションのパフォーマンスを飛躍的に向上させます。このエンタープライズ・フラッシュ・ドライブは SSD （ソリッド・ステート・ドライブ）とも呼ばれ、可動部がありません。既存の CLARiX 管理ツールには標準的なドライブとして認識されるため、管理者は特殊なプロセスやカスタム・ツールを用意したり、追加のトレーニングを受けたりしなくても階層 0 を管理できます。階層 0 FED は、為替システムや電子商取引システム、リアルタイムのデータ取得や処理など、高速トランザクションを伴うアプリケーションや、最速のデータ取得およびストレージを必要とするアプリケーションに理想的です。また、検索エンジンのデータベースのような読み取り集中型ワークロードに最適であることも分かっています。EFD は、ミリ秒のアプリケーション・レスポンス・タイムと、従来のファイバ・チャネル・ハード・ディスク・ドライブと比べて最大 30 倍の IPOS（1 秒あたりの I/O 動作）を達成できます。さらに、従来のディスク・ドライブと比べて、IOPS あたりの消費電力量がずっと少なくなっています。これにより、データ・センターの消費電力と設置面積がかなり削減されるため、TCO を大幅に下げることができます。データベースのパフォーマンスは長い間 I/O 機能によって制限されてきました。また、HDD のパフォーマンスは、ヘッド・シークによる機械自体の遅延や回転待ち時間による制限を受けてきました。しかし、EFD には可動部がないため、シーク・レーテンシーや回転待ち時間による遅延がありません。これにより、大量の IOPS を処理し続けるための機能が大幅に強化され、全体的なレスポンス・タイムも非常に短くなっています。 5ページの図 1は、従来のHDDの平均シーク時間と平均遅延時間に基づいて実現できる理論上の IOPS速度を、FEDテクノロジーと比べたものです。この 25 年の間に、HDDの回転スピードは 3,600 rpmから 15,000 rpmに向上しました。CPU速度など、他のコンピュータ・テクノロジーについては 2 桁台の伸びを示しているにもかかわらず、IOPSは 4 倍しか速くなっていません。EFDテクノロジーを採用すればパフォーマンスが飛躍的に向上し、従来のHDDテクノロジーと比べて最大 30 倍のIOPSを実現できます。

(5)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した

FLASH Drive vs. HDD IOPS

3600 rpm 5400 rpm 7200 rpm 10K rpm 15K rpm Flash Disk rpm Flash Explosion Up to 30x IOPS HDD 図1：さまざまなドライブ・テクノロジーの IOPS の比較 より高速なトランザクションとレスポンス・タイムに対するニーズはますます高まっています。業界トップのエンタープライズ・フラッシュ・ドライブを EMC CLARiX ミッドレンジ・ストレージ・アレイに導入することで、これらのディスク・アレイを使って、こうしたニーズに応えることができます。レーテンシーに関する要件が厳しい企業でも、最速のファイバ・チャネル・ディスク・ドライブを大量に購入し、非常に要求度の高いランダム・ワークロードの IOPS パフォーマンス要件を満たすためにその容量の一部だけを利用する方法（ショート・ストローキングと呼ばれています）が必要なくなります。リレーショナル・データベースが、ビジネス・アプリケーションの核となっていることはよくあります。ストレージ電力消費量と設置面積を最小限に抑えつつ、このリレーショナル・データベースのパフォーマンスを向上させることで、TCO（総所有コスト）が大幅に削減されます。また、これは、データ・センターの制約を軽減するのにも役立ちます。階層 0 FED を、ファイバ・チャネルおよび SATA ドライブなどの低速で大容量の階層とともに展開すれば、アプリケーション・データ・レイアウトを構築し、ストレージの各階層がホストするアプリケーションの I/O リクエストに対応できます。

概要

このホワイト・ペーパーでは、Oracle データベースのワークロードでエンタープライズ・フラッシュ・ドライブを使用する例とそのベスト・プラクティスをいくつか取り上げて説明します。 EFD を適切に使用すると、1 分あたりのトランザクション・レートとトランザクションのレスポンス・タイムの両方において、データベース・アプリケーションのパフォーマンスが、従来のファイバ・チャネル・ドライブと比べて大きく向上します。また、このホワイト・ペーパーでは、 Oracle エンジニアリングの調査結果に合わせて、適切なデータベース・コンポーネントを識別し FED に配置するための推奨事項も紹介しています。 Oracle データベースの展開高度なテクノロジー 5

(6)

対象読者

このホワイト・ペーパーは、Oracle データベース環境におけるエンタープライズ・フラッシュ・ドライブの実装について理解し、ビジネス・アプリケーションのパフォーマンスを向上させようとしている Oracle データベース管理者、ストレージの設計者、お客様、EMC のフィールド担当者を対象にしています。

テクノロジーの概要

CLARiX CX4

UltraFlexTMテクノロジーが採用されているEMC CLARiX CX4 シリーズは、新しい画期的なアーキテクチャと広範な技術革新に基づいており、どの競合他社の追随も許さないミッドレンジ・ストレージを提供します。CX4 は第 4 世代のCXシリーズです。EMCは、お客様が新しいテクノロジーを採用するときに既存のリソースと設備資産を適切に利用できるようにして、CLARiXテクノロジーに対するお客様の投資を最大限に生かせるよう引き続き取り組んでいます。図 2に示す新しいCLARiXCX4 システムは、ミッドレンジ・エンタープライズ・ストレージ市場におけるEMCのリーダーシップを強化する次世代CXシリーズです。CX4 は、EFD、高パフォーマンスの 4 Gb/s FCドライブ、大容量のSATA IIなど、最新世代のディスク・ドライブ・テクノロジーに直ちに対応します。CLARiXCX4 は、この最新世代のディスク・ドライブ・テクノロジーすべてをサポートできる初の唯一のミッドレンジ・ストレージ・システムなのです。FLARE®_最新リリース（R28）が採用されたCLARiXCX4 は、パフォーマンスを最大限に高め、階層型ストレージ機能の柔軟性を確保するために最適化されています。このホワイト・ペーパーでは、一部のCX4 シリーズについては扱っていません。このシリーズの一覧については、21ページの「関連資料」セクションを参照してください。図 2は、CLARiX CX4 シリーズの主な機能をいくつか示しています。ここで示すCLARiX CX4 の 4 つのモデルすべてが、エンタープライズ・フラッシュ・ドライブをサポートします。

CX4-960

最大 960 台のドライブ、32 GB のメモリ

標準：8 ファイバ・チャネル/4 iSCSI

最大：32 フロントエンド・ファイバ・チャネル

/iSCSI

CX4-480

最大 480 台のドライブ、16 GB のメモリ

標準：8 ファイバ・チャネル/4 iSCSI

最大：24 フロントエンド・ファイバ・チャネル

/iSCSI

Oracle データベースの展開高度なテクノロジー 6

(7)

CX4-240

最大 240 台のドライブ、8 GB のメモリ

標準：4 ファイバ・チャネル/4 iSCSI

最大：20 フロントエンド・ファイバ・チャネル

/iSCSI

CX4-120

最大 120 台のドライブ、6 GB のメモリ

標準：4 ファイバ・チャネル/4 iSCSI

最大：16 フロントエンド・ファイバ・チャネル

/iSCSI

図2：CLARiX CX4 モデル CLARiX CX4 がサポートするエンタープライズ・クラスのEMCフラッシュ・ドライブは不揮発性のNAND型半導体フラッシュ･メモリで構築され、既存のCLARiXディスク・ドライブ・アレイ・エンクロージャで使用されている標準の 3.5 インチ・ディスク・フォーム・ファクタにパッケージ化されています。これらのドライブは、一貫して短い読み取り/書き込みレスポンス・タイムを必要とする、レーテンシーの影響を受けるアプリケーションに特に適しています。また、 EFDは、ローカルおよびリモート・レプリケーション、Navisphere® Quality of Service Management、ファイブ・ナインの可用性など、CLARiXが提供する高度な機能からもメリットを得られます。

Oracle データベースとエンタープライズ・フラッシュ・ド

ライブ

EFD に最も適したデータベース・ワークロード

FED に最適なアプリケーションは簡単に識別できるシンプルで確実な規則はありません。しかし、参考になるガイドラインはいくつかあります。まず、アプリケーションを EFD に配置する前に、そのアプリケーションの負荷プロファイルについて理解することが非常に重要です。ほとんどのデータベースのワークロード・プロファイルが 1 日の時間帯によって異なるという事実を認識してください。EFD は、読み取り集中型のアプリケーションやレーテンシーの影響が大きいアプリケーションに適しています。このドライブを不適切なターゲットに対して使用しても、投資に見合う望ましい成果はもたらされないでしょう。EFD が特定のワークロードに適しているかどうかを判断するには、次の用語を理解することが重要です。 • ライト・キャッシュ：ほとんどのストレージ・システムに大きなライト・キャッシュがあります。一般的には、ホストからの書き込み IOPS すべてがキャッシュに書き込まれ、物理ディスク・アクセスによる遅延は発生しません。CLARiX ストレージ・アレイのライト・キャッシュは、コントローラがサポートするディスク数に応じてサイズが変わります。また、必要に応じて、LUN レベルで有効化または無効化されます。 • 読み取りヒット：データベース・ホストからの読み取り要求が、最近の読み取りまたは書き込み、あるいはプリフェッチによって、すでにストレージ・キャッシュに存在する場合、そ Oracle データベースの展開高度なテクノロジー 7

(8)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した Oracle データベースの展開高度なテクノロジー 8 の読み取り要求はストレージ・システムによって直ちに実行されます。ディスク・アクセスなしでストレージ・キャッシュから実行される読み取りが、読み取りヒットと呼ばれます。要求されたデータがストレージ・キャッシュで使用できない場合は、CLARiX がディスクからそのデータを取得しなければなりません。これは、読み取りミスと呼ばれます。 • ショート・ストローク・ドライブ：レーテンシーの影響が大きいアプリケーションの中には、正規のファイバ・チャネル・ドライブでこの手法を使用して低レーテンシーを実現するものがあります。この手法では、スピンドル・ヘッドの移動を減らすために、部分的にしか埋まっていない多数のディスクにデータがレイアウトされ、非常に低いレーテンシーで高いレベルの IOPS が実現します。 CLARiX キャッシュの読み取りヒット率が高いワークロードについては、すでにメモリ・アクセス速度でサービスが提供されているため、フラッシュ・ドライブ・テクノロジーに展開しても大きなメリットを得られないことがあります。CLARiX キャッシュの読み取りヒット率が低いワークロードで、ランダム I/O パターンを示しており、さらに I/O リクエストのサイズが小さく（最大 16 KB）、高いトランザクション・スループットが求められている場合は、FED の低レーテンシーを最大限に生かせるでしょう。データベース・マネージャやアプリケーション・マネージャは、ビジネス・トランザクション・スループットが増加し、サービス・レーテンシーが減ったときに、売上増加と生産性向上に直結するミッション・クリティカルなアプリケーションを簡単に特定できます。こうしたアプリケーションを認識したストレージ管理者は、より多くのドライブに対して「ショート・ストローキング」を行い、そのドライブでサポートされている最高レベルの I/O サービスを利用できるようにすることがよくあります。これらのアプリケーションは、非常に重要な 2 つのメリットを EFD から得ることができます。 • 多数のショート・ストローク・ドライブの代わりに１つの EFD を使用し、高速トランザクション（IOPS）を提供できます。これにより、アプリケーションに必要なドライブ数が少なくなり、多数のディスクを回転させ続ける必要がなくなります。これにより電力の消費を抑え、結果的にはデータ・センターのフロア面積も少なくて済むようになります。 • EFD では非常に低いレーテンシーが実現しています。したがって、短いレスポンス・タイムを予測できることが非常に重要で、必ずしもすべてのデータをホストまたは CLARiX キャッシュに保持する必要がないアプリケーションは、このようなドライブを使用することにより大きなメリットを得られます。EFD には回転メディアがないため、その転送速度は非常に高速です。多数のショート・ストローク・ハード・ドライブで達成できるベスト・レスポンス・タイムよりもはるかに速くデータが提供されます。

(9)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した StatspackまたはAWRレポートと呼ばれるOracleツールを使って取得したOracleワークロードの負 荷プロファイルは、データベース全体を配置するのか、またはFEDにそのデータベースの一部を配置するのかを判断する際に使用できます。この 2 つのツールは、根本的には、Oracleレベルのパフォーマンス・カウンタを監視する 1 つの測定手法に基づいています。AWRはOracleデータベースの新しいバージョン（10gおよび 11g）でサポートされており、一方StatspackはOracle 8iから存在しています。このツールは両方ともデルタ・ベースのツールで、2 つの異なる時間間隔で Oracleパフォーマンス・カウンタからサンプルを収集し、サンプル間の合計経過時間に基づいて平均パフォーマンス値を計算します。サンプルを収集する間隔が長くなるとこの平均値の信頼性が薄くなります。したがって、ツールはデータベース・アプリケーションの最も忙しい時間に短時間（通常は 30 分で十分です）実行するようにします。経験豊かなDBAの中には、これらのツールを使用せずに、そのツールで使用されている基盤となるOracle V$ビューを直接使用して、動的かつリアルタイムにパフォーマンス値を取得する人もいるでしょう。

Oracle AWR レポートまたは Statspack レポートの分析

パフォーマンス・レポートのさまざまなセクションを使用して、ワークロード・プロファイルを識別できます。ここでは、重要な領域について 1 つずつ取り上げ、これらの領域で注目すべき内容について説明します。

負荷プロファイル・セクション

このセクションでは、サンプリング間隔中のワークロード・プロファイル全体を定義します。ここで確認する重要な要素は、論理読み取り、物理読み取り、物理書き込みです。 表1：ワークロードのプロファイル 1 秒あたり トランザクションあたり 実行あたり コールあたり DB 時間（秒）： 68.8 46.4 0.22 0.23 DB CPU（秒）： 2.5 1.7 0.01 0.01 REDO サイズ： 4,256.8 2,875.4 Oracle データベースの展開高度なテクノロジー 9 論理読み取り： 18,421.9 12,443.7 ブロック変更： 13.5 9.1 物理読み取り： 17,459.4 11,793.6 物理書き込み： 2.1 1.4 ユーザー・コール： 302.3 204.2 解析： 5.7 3.8 ハード解析： 0.3 0.2 処理された W/A MB： 45,301.9 30,600.7 ログオン： 0.2 0.1 実行： 307.3 207.6 ロールバック： 0.0 0.0 トランザクション： 1.5 AWR レポートによると、読み取り集中型ワークロードでは、かなりの数の読み取りが物理的に行われています。つまり、Oracle キャッシュではなくストレージから読み取りが実行されています。このワークロードは、通常、EFD を利用することにより大きなメリットを得られます。ただ

(10)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用したし、EFD の使用を検討する前に、データベース・キャッシュをチューニングするだけでこれらの IOPS を減らすことができないかどうかを確認することが重要です。問題解決のために EFD を投入するよりも、システムのメモリを増やす方がはるかに簡単だからです。 Oracleパフォーマンス・レポートのバッファ・プール・アドバイザリ・セクションは、データベース・バッファ・キャッシュ増加の影響を示しています。現在の例では、データベースは、4 GB のバッファ・キャッシュを使用するよう構成されていました。表 2は、バッファ・プールが 2 倍になっても推定物理読み取りは変わらないことを示しています。これは、より高速なストレージを導入しないと向上が見込まれない例です。したがって、この場合はEFDを使用するのが理想的です。 表2：バッファ・プール・アドバイザリ P 推定用サイズ （M） サイズ係数 推定用バッファ 推定物理読み取り係数 推定物理読み取り D 384 0.09 47,340 1.49 897,413 D 1,152 0.28 142,020 1.06 635,008 D 1,920 0.47 236,700 1.01 603,605 Oracle データベースの展開高度なテクノロジー 10 D 3,456 0.84 426,060 1.00 600,590 D 4,096 1.00 504,960 1.00 600,590 D 4,608 1.13 568,080 1.00 600,590 D 5,376 1.31 662,760 1.00 600,590 D 6,144 1.50 757,440 1.00 600,590 D 6,912 1.69 852,120 1.00 600,590 D 7,680 1.88 946,800 1.00 600,590 データベース・キャッシュを 2 倍にして も同じ量の物理読み取りになります

Oracle 待機イベント

このセクションは、5 つの主要 Oracle フォアグラウンド待機イベントを示しています。データベースをチューニングするとき、ほとんどの DBA がこのセクションに注目します。このデータによって、チューニング時に最大限のメリットを簡単に引き出すことができるからです。このセクションで確認する重要な要素は「DB ファイルのシーケンシャルな読み取り」待機イベントです。この要素の名前はカウンタ直観的で、その名前は実際にはその名前が意味するものではなく、実はワークロードのランダム性を示しています。このイベントは、サンプリング間隔中にデータベースが 1 つのブロック I/O が完了するのを待機しなければならなかった回数と、その平均待機時間をトラッキングします。次の例では、データベースは約 88%の時間を I/O の完了に費やしていました。その平均待機時間は 14 ミリ秒です。アプリケーション・ユーザーがシステムの応答性が悪いことに不満を持っている場合は、このデータベースを EFD に置きます。これにより、平均レーテンシーが大きく向上します。ここでレーテンシーの値が高くても、必ずしもそれが問題になるとは限りません。結局、ビジネス・トランザクション・サービス全体のパフォーマンスを許容できるかどうかを決めるのは、実際に操作するユーザーなのです。

(11)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した 表3：5 つの主要定期フォアグラウンド・イベント イベント待機時間 （秒） 平均待機 （ミリ秒） DB 時間の 割合 待機クラス DB ファイルのシーケ ンシャルな読み取り 1,169,805 16,171 14 87.92 ユーザーI/O DB ファイルの並列読み取り 34,303 1,819 53 9.89 ユーザーI/O DB CPU 290 1.58 ログ・ファイルの同期 79,538 54 1 0.29 コミット DB ファイルのランダムな読み取り 1,997 27 14 0.15 ユーザーI/O

テーブル・スペース I/O 統計

レポートの終わりの部分にある 2 つのセクションは、データ・コンテナ・レベルでの I/O の統計を示しています。このデータを使用すると、EFD への正しい移行先を識別できます。最初のセクションは「テーブル・スペース I/O 統計」、2 番目のセクションは「ファイル I/O 統計」と呼ばれています。これらのテーブルの最上部に示されているエントリは I/O レートが最も高くなっており、これは、EFD への移行により最大限のメリットを得られることを示しています。平均レスポンス・タイムが高い値を示しているデータ・コンテナを EFD に移行してもよいでしょう。たとえば、データ・ファイル、インデックス、一時ファイルなどがあります。これは、データベース全体を EFD に移動する代わりのアプローチです。この報告された数値は平均値であるという点を覚えておいてください。サンプリング間隔中に特定の期間だけ急激に値を上昇させる可能性のある、テーブルスペースにおける I/O アクティビティの突発的増加が反映されているとは限りません。 表4：テーブルスペース I/O 統計 テーブルス ペース 読み取り平均読み取 り/秒 平均読み取り（ミ リ秒） 平均ブロッ ク/読み取 り書き込み平均書き込 み/秒 バッファ待機平均バッファ待機（ミリ秒） DATA1 _4,464,451 _4,730 _19.11 _{1.00 1,440,601} _1,526 ₃₄₇ _47.20 DATA2 _454,647 ₄₈₂ _11.05 _1.03 _288,654 ₃₀₆ ₁₄₂ _10.35 DATA3 _425,990 ₄₅₁ _17.80 _1.00 _186,795 ₁₉₈ ₄₈ _2.71 INDEX1 _265,040 ₂₈₁ _10.30 _1.09 _234,963 ₂₄₉ ₁₄ _10.00 INDEX2 _188,572 ₂₀₀ _15.07 _1.03 _168,047 ₁₇₈ ₃ _3.33 Oracle データベースの展開高度なテクノロジー 11

(12)

使用例の比較

ここでは、EMCのエンジニアリングによってテストされたさまざまな使用例のシナリオを取り上げ、EFDを適切に利用することで、これらの典型的なビジネス環境からどのようにメリットを得られるのかを紹介します。このホワイト・ペーパーで紹介するテストはすべて、73GB EFDと 300 GB 15k rpm FCドライブを比較しています。また、FLAREリリース28が実行されている CLARiX CX4-960で行われました。

使用例 1：読み取り集中型ワークロード

次の使用例は、EFD によって読み取り集中型のアプリケーションやレーテンシーの影響を受けるアプリケーションがどのように向上するかを示しています。このようなアプリケーションを膨大なショート・ストローク・ファイバ・チャネルのスピンドルに展開することは、珍しくありません。この特別なアプリケーションは、非常に低いレーテンシー要件を満たすために 150 のファイバ・チャネル・スピンドルに展開されていましたが、それでも 4 ミリ秒のレーテンシーしか達成できませんでした。この使用例は、そのアプリケーションをより少ない EFD に展開することで、より多くのトランザクションを処理し、レーテンシーを向上させる方法を示しています。次の表は AWR レポートの最初の部分です（10 分のサンプル）。アプリケーションは、Oracle

11g/ASM/Oracle Enterprise Linux と CLARiX CX4-960 で実行されています。 表5：使用例 1 の結果 キャッシュ・サイズ 開始終了バッファ・キャッシュ： 4,096M 4,096M 標準ブロック・サイズ： 8K 共有プール・サイズ： 640M 640M ログ・バッファ： 41,488K 負荷プロファイル 1 秒あたり トランザクションあたり REDO サイズ： 4,256.8 2,875.4 論理読み取り： 18,421.9 12,443.7 ブロック変更： 13.5 9.1 物理読み取り： 17,459.4 11,793.6 物理書き込み： 2.1 1.4 ユーザー・コール： 302.3 204.2 実行： 307.3 207.6 トランザクション： 1.5 インスタンスの効率性（目標 100%） バッファ待機なし率： 100.00 REDO 待機なし率： 100.00 バッファ・ヒット率： 50.88 インメモリ・ソート率： 100.00 ライブラリ・ヒット率 86.13 ソフト解析率： 95.64 解析実行率： 98.16 ラッチ・ヒット率： 99.99 I/Oの50%はストレージから提供されますが、Buffer Pool Advisory はバッファ・キャッシュの増加によるサポートを示しません

4 GB バッファ・キャッシュ

Oracle データベースの展開

(13)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した 5 つの主要定期イベント イベント 待機時間（秒）平均待機（ミ リ秒） 合計コール時間の割合 待機クラス DB ファイルのシーケンシャルな読み取り 10,803,192 42,450 4 95.92 ユーザーI/O DB CPU 1,575 3.56 DB ファイルのランダムな読み取り 32,266 219 7 0.50 ユーザーI/O コントロール・ファイルのシーケンシャルな読み取り 25,993 7 0 0.02 システム I/O DB ファイルの並列読み取り 704 5 7 0.01 ユーザーI/O 最上位の待機イベント（96%）は応答時間が 4 ミリ秒によるランダム読み取りです。こ のアプリケーションはレーテンシーの影響を受け、膨大なファイバ・チャネル・ドライブを必要とします。フラッシュ・ドライブを使用すると、大きなメリットを得ることが できます。 次の表は、データをわずか 6 台の EFD に移動した後の Oracle ワークロード・プロファイルを示しています。 表6：データベースを 6 台の EFD へ移動した後の使用例 1 の結果 キャッシュ・サイズ 開始終了バッファ・キャッシュ： 4,096M 4,096M 標準ブロック・サイズ： 8K 共有プール・サイズ： 640M 640M ログ・バッファ： 41,488K 負荷プロファイル 1 秒あたり トランザクションあたり REDO サイズ： 6,564.8 2,727.3 論理読み取り： 57,548.5 23,908.0 ブロック変更： 27.2 11.3 物理読み取り： 53,055.7 22,041.5 物理書き込み： 3.6 1.5 ユーザー・コール： 937.8 389.6 実行： 944.3 392.3 トランザクション： 2.4 EFDによって、論理読み取りと物理読み取りは最大3倍にまで増加します。これによりディスクの数が96%減少 しても、より多くのトランザクションが可能になります。 インスタンスの効率性（目標 100%） Oracle データベースの展開高度なテクノロジー 13

(14)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用したバッファ待機なし率： 100.00 REDO 待機なし率： 100.00 バッファ・ヒット率： 75.53 インメモリ・ソート率： 100.00 ライブラリ・ヒット率 88.20 ソフト解析率： 96.58 解析実行率： 99.21 ラッチ・ヒット率： 99.97 5 つの主要定期イベント イベント 待機時間（秒）平均待機（ミ リ秒） 合計コール時間の割合 待機クラス DB ファイルのシーケンシャルな読み取り 33,689,960 40,945 1 87.76 ユーザーI/O DB CPU 5,631 12.07 DB ファイルのランダムな読み取り 30,079 60 2 0.13 ユーザーI/O コントロール・ファイルのシーケンシャルな読み取り 25,993 6 0 0.01 システム I/O ラッチ・フリー 6,621 5 1 0.01 その他応答時間はディスクの数を 96%減少しても4ミリ秒から1ミリ秒に減ります。このテストは、少数の EFD によってエンタープライズ・アプリケーションが大きく向上することを明確に示してします。EFD に移動することでパフォーマンスが向上するうえに、電力量やスペースを節約できるのです!この例では、スピンドル数は 25 倍違います。また、全体的なトランザクション・スループットについては 3 倍以上も向上しています。これを考えると、EFD によって全体的に 30 倍以上の改善が約束されることになります。 表7：使用例 1 での FC ドライブ上の EFD メトリック 150 台の FC ドライブ 6 台の EFD 物理読み取り 17,459 53,055 読み取りレーテンシー 4 ミリ秒 1 ミリ秒インターネット時代における管理ビジネス情報の急増により、蓄積された膨大なビジネス・データを効率的に処理できる強力な検索エンジンに対する需要が新しく生まれています。エンタープライズ・フラッシュ・ドライブは、その特性からこの市場分野にも適しています。 Oracle データベースの展開高度なテクノロジー 14

(15)

使用例 2：Oracle OLTP ワークロードの比較

EFD は、読み取り集中型のアプリケーションに非常に適しています。また、書き込み優先の読み取り/書き込み混合のアプリケーションでキャッシュされていない RAID 5 を使用していても、素晴らしい性能を発揮します。さらに、いずれの場合も、EFD により電力コストが大幅に削減され、レーテンシーやパフォーマンスが大きく向上するため、TCO（総所有コスト）を削減できます。標準の OLTP Oracle アプリケーションでは、更新や挿入などの DML オペレーションにより書き込みオペレーションが発生します。 OLAP 環境のハード・ディスク・ドライブで EFD のパフォーマンスを比較するために、まったく同じ 2 つの Oracle 11g/ASM データベースをそれぞれ、6 x 73 GB EFD と 6 x 300 GB 15k rpm ファイバ・チャネル・ドライブに展開しました。これらのドライブは 1 つの RAID5（5+1）グループにあります。6 対 4 の割合で読み取りと書き込みが行われている OLTP ワークロードを使用して、 64 ビットの Oracle Enterprise Linux サーバでこの両方のデータベースに対して同じワークロードを生成し、アクティビティを推進しています。より現実に近い状態でテストするためにストレージ・コントローラ・レベルの読み取りキャッシュはオフにしました。このテストでは、より小さなデータベースが使用されるからです。このテストで使用する読み取りと書き込みの割合は、最悪の OLTP シナリオを想定しています。実際、ほとんどの OLTP データベースでは、読み取りと書き込みが 9 対 1 の割合で発生します。

Transactions per min - Flash vs. HDD

0 5000 10000 15000 20000 25000 0:00 1:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00 6:30 7:00 Time

Flash Tx/min HDD Tx/min

図3：EFD と HDD の 1 分あたりのトランザクション数の比較 図 3は、このテストの構成では、EFDが平均 19,000 TPM（1 分あたりのトランザクション数）を実現する一方で、ファイバ・チャネル・ドライブでは約 2,400 TPMしか維持されていないことを示しています。つまり、EFDのTPMは、ファイバ・チャネル・ドライブの約 8 倍になっています。さらに、EFDのレスポンス・タイムがファイバ・チャネル・ドライブの 7 分の 1 になっているのも興味深いところです。 Oracle データベースの展開高度なテクノロジー 15

(16)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用したこの使用例は、構成内のディスクのみを変更することで、IOPS とレスポンス・タイムを大幅に向上させることができるという重要な事実を示しています。ただし、チューニング時には、アプリケーションに関する実際の問題を理解することがとても大切です。X という要因に注目して I/O だけを向上させても、システム・レスポンス全体が何倍も向上するとは限りません。ストレージ・ボトルネックを何も考えずに解消すると、どこか別の場所で違うボトルネックが発生することがよくあります。アプリケーションを全体的に向上させるには、FED に移行することにより解消されたストレージ・ボトルネックの影響がどの程度深刻であるかを考慮します。

使用例 3：ショート・ストロークOracle OLTPワークロード

使用例 2 は、同一条件のシナリオでの FED のパフォーマンス上のメリットを示していますが、 DBA およびストレージの設計者が、ファイバ・チャネル・ドライブを同じ台数の FED で置き換えられないことはよくあります。さらに、使用例 2 は、ストレージ・アレイ全体が 1 つのワークロードのみを実行し、標準以外のキャッシュ設定を使用しているという最も理想的な条件に基づいています。本番環境では、極めて一般的に、ストレージ・アレイが複数の異なるアプリケーションで共有されています。ここでは、実際の環境における FED のパフォーマンスについて理解するために、バックグラウンド負荷をテストに追加しました。これにより、ストレージ・プロセッサの使用率は常に 40～50%に、そしてキャッシュは常に飽和状態になります。負荷がかかっているこのシステムでは 6 対 4 の割合で読み取り/書き込みが行われている OLTP ワークロードが、ショート・ストローク 75 X 300 GB ファイバ・チャネル・ドライブと 6 X 73 GB EFD の 2 つのセットに対して実行されています。使用されているキャッシュ設定を次に示します。これはデフォルトのキャッシュ設定です。 表8：キャッシュ設定（デフォルト） SP読み取りキャッシュ SP書き込みキャッシュ LUN読み取りキャッシュ LUN書き込みキャッシュ 75 FC ON ON ON ON

6 EFD ON ON OFF OFF

Relative Transactions per minute

1.00 0.65 0.00 0.20 0.40 0.60 0.80 1.00 1.20 75 FCD 6 EFD 図4：6 台の EFD と 75 台の FC ドライブの 1 分あたりのトランザクション数の比較 Oracle データベースの展開高度なテクノロジー 16

(17)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した EFD の全体的な効率性を計算するには、スピンドル数が実行ごとに変化するため次の式を使用します。 全体的な効率性 = ディスク削減係数 x パフォーマンス向上係数 全体的な効率性 = （75/6） x 0.65 ~=

8 倍

図 4は、こうした極端な状況でも、EFDによって全体的な効率性が 8 倍向上することを示しています。つまり、EFDはデータ・センターの電力や設置面積の節約という形で大きなメリットをもたらしています。この実行によるパフォーマンス・データを詳細に分析すると、キャッシュされていないEFD LUNが不必要なOracle「ログ・ファイル同期」待機イベントの原因となっており、これがトランザクション数をかなり減らし、EFDの使用率を低下させていたことが分かります。 REDOログ・ファイルの配置に関するOracleの推奨事項に従って、これらのファイルは次の実行で個別のファイバ・チャネル・スピンドル・セットに戻されていました。図 5は、個別のファイバ・チャネル・ドライブ上にあるREDOログによって、EFDが全体的な効率性を 12 倍も向上させたことを示しています。このテストも、EFDへのREDOファイルの移動に関するOracleの推奨事項に従っています（これについては、次のセクションで説明します）。 Oracle REDOログ・ファイルは、EFDに移動するよりも、ファイバ・チャネル・ドライブを支えるキャッシュに残したままにすることをお勧めします。 全体的な効率性 = （75/6） x 0.98 ~=

12 倍

Relative Transactions per minute (w ith logs on separate FC drives)

1.00 _0.98 0.00 0.20 0.40 0.60 0.80 1.00 1.20 75 FCD 6 EFD 図5：6 台の EFD と 75 台の FC ドライブの 1 分あたりのトランザクション数の比較 パフォーマンスは、EFD LUN の書き込みキャッシュをオンにすることでさらに向上させることができます。これは標準の設定とは異なります。EFD LUN の書き込みキャッシュと読み取りキャッシュは、次の 2 つの理由により通常はオフにすることをお勧めします。 Oracle データベースの展開高度なテクノロジー 17

(18)

• EFD は非常に高速であるため、EFD の LUN に対して読み取りキャッシュが有効になっていると、読み取りキャッシュ・ヒットがそれほど求められていないアプリケーション・プロファイルでも、読み取りリクエストごとに読み取りキャッシュ照合が行われ、FC ドライブに比べてはるかに大きなオーバーヘッドが発生します。この場合は、EFD から直接ブロックを読み取る方が高速です。 • 実際のシナリオで、CX4 が複数のアプリケーションで共有され、特にそれが低速な SATA ドライブとともに展開されている場合は、書き込みキャッシュが飽和状態になる可能性があり、 EFD が強制フラッシュ状態に置かれます。これによりレーテンシーが増加します。この状況では、ストレージ・システムの書き込みキャッシュではなく EFD に直接ブロックを書き込むことをお勧めします。

通常は、EFD の LUN に対してキャッシュを有効にすることは推奨しませんが、DBA とストレージの管理者がその影響を認識していれば、有効にしても構いません。これにより、環境によっては（ストレージ・システムが多数のアプリケーションで共有されていない環境など）、EFD から最大限のメリットを引き出せることがあります。デフォルトとは違った設定を採用する場合は、分析とベンチマークを十分に行うことを強くお勧めします。図 6は、データベース全体（REDOログを含む）をEFDに展開し、書き込みキャッシュを有効にした場合に、システムの効率性が約 17 倍向上することを示しています。テストで使用されたキャッシュ設定を次に示します。 表9：キャッシュ設定 SP読み取りキャッシュ SP書き込みキャッシュ LUN読み取りキャッシュ LUN書き込みキャッシュ 75 FC ON ON ON ON 6 EFD ON ON OFF ON

Relative Transaction per minute (w ith w rite cache on for EFD LUNS)

1.00 1.35 0.00 0.20 0.40 0.60 0.80 1.00 1.20 1.40 1.60 75 FCD 6 EFD 図6：6 台の EFD と 75 台の FC ドライブの 1 分あたりのトランザクション数の比較 全体的な効率性 = （75/6） x 1.35 ~=

17 倍

Oracle データベースの展開高度なテクノロジー 18

(19)

使用例 4：EFD への部分データベースの移動

可能であれば、データベース全体を EFD に移動するのに越したことはありませんが、データベース・サイズなどの制約により、経済的にデータベース全体を移動できないことがあります。このセクションでは、データベースの一部を移動するときに、どの部分を移動するのが最も効果的であるかを識別する方法について説明します。次の Oracle ガイドラインは、データ移動に関する決定を行う際に役立ちます。 表10：EFD に適したワークロード EFD に適した DB ワークロード EFD で良好なコスト・パフォーマンスを得られない ランダム読み取り • B ツリー・リーフ・アクセス • テーブルの ROWID 検索 • 異なる種類の LOB へのアクセス • オーバーフロー行へのアクセス • クラスタ化されていないテーブルに対するインデックス・スキャン • 圧縮：I/O 負荷増加（IOPS/GB

）

シリアル読み取り ランダム書き込み • PK による行の更新 • インデックスのメンテナンス • チェックポイント間隔の削減一時ファイル：ソート・エリアと中間テーブル • シーケンシャルな読み取りおよび書き込み、ただしI/Oは 1 MB単位で実行：シークを償却するには不十分 • 低レーテンシー：取り込み、取り出し REDO ログ・ファイル • シーケンシャルな読み取りと書き込み、また、ストレージ・コントローラのキャッシュによってすでに処理されているレーテンシーのコミット UNDO テーブル・スペース • シーケンシャルな書き込み、FlashBack によるランダム読み取り。ただし、読み取りは、バッファ・キャッシュにまだ存在すると思われる最近書き込まれたデータ用 大きなテーブルのスキャン 書き込みが多いバッファ・プール • 低レーテンシー読み取りの後に更新を行うと、ダーティー・ページでプールがいっぱいになる可能性がある。フラッシュ・デバイス書き込みは読み取りよりも 2～4 倍遅いため排出に時間がかかる • 読者に対して「フリー・バッファ待機」が発生する可能性がある

EFD の REDO ログか?（あるいは、そうではないか）

Oracle オンライン REDO ログを EFD に移動するとそのログがメリットを得られる、とよく誤解されていますが、テストのデータはすべて、これとは反対のことを示しています。テストは、 EFD に REDO ログを移動しても、大きな改善は見られないことを示しています。こうした REDO ログは、EFD に移動するよりも、ファイバ・チャネル・ドライブを支える書き込みキャッシュに残したままにして、EFD は、データベースの他の読み取り集中部分（インデックスやデータなど）に対して使用することをお勧めします。

(20)

EFD 上の Oracle 一時テーブルスペース

Oracle は、このスペースを主にデータ統合およびソートで使用します。データベース・エンジンがメモリ内でソートを行い切れない場合、そのソートはディスクに流れ、そこに中間結果が格納されます。ユーザーが 1 人の場合、Oracle は通常これらのテーブルスペースに対して大きなシーケンシャル I/O を処理します。複数のユーザーがこれらのテーブルスペースに対してコンカレント・ソートを行っていると、I/O は大きなランダム I/O になります。EFD は、大きなランダム I/O に対しては、小さなランダム・オペレーションほど大きなメリットをもたらしませんが、それでも標準の回転ファイバ・チャネル・ドライブに比べれば EFD の方がはるかに優れた性能を発揮します。EFD 上のスペースの可用性によっては、一時テーブルスペースを EFD に移動することで Oracle アプリケーションがメリットを得られます。この一時テーブルスペース・ファイルの移動処理は、I/O が集中している部分を EFD に移動した後に行う必要があります。

EFD へのオブジェクト強度が高いオブジェクトの移動

Oracle は、OI「オブジェクト強度」と呼ばれるパラメータを定義します。このパラメータは、 EFD に移動するデータベース・オブジェクトを識別する際に役立ちます。これらのオブジェクトには、Oracle テーブルスペース、データ・ファイル、インデックスなどがあります。このパラメータは、指定したオブジェクトが受信する IOPS を、そのオブジェクトのサイズと比較して相対的に定義します。これらのオブジェクトを EFD にすることは理にかなっています。これにより、頻繁にアクセスされるようになるため、レーテンシーが大きく向上するからです。 OI（オブジェクト強度） = オブジェクト IOPS / オブジェクト GB ここでは、オブジェクト強度が高いデータ・コンテナを移動した場合のパフォーマンスへの影響を確認するために、さらに大きな 1 TB のデータベースを 45 x 15k rpm ファイバ・チャネル・スピンドルに作成しました。EFD に移行する候補オブジェクトは、ベースライン実行後にオブジェクト・インスタンス分析を行うことで識別されています。最初に、テーブルスペース I/O 統計を示す表を見てみましょう。この表は、TABLE1 を EFD に移動すれば、最大のメリットを得られることを示しています。このテーブルスペースは、データベース・サイズの 30%を占め、I/O の 70%を受け取っています。 表11：テーブルスペース I/O 統計 テーブルス ペース 読み取り平均読み取 り/秒 平均読み取り（ミ リ秒） 平均ブロッ ク/読み取 り書き込み平均書き込 み/秒 バッファ待機平均バッファ待機（ミリ秒） TABLE1 4,464,451 4,730 19.11 1.00 1,440,601 1,526 347 47.20 TABLE2 454,647 482 11.05 1.03 288,654 306 142 10.35 TABLE3 425,990 451 17.80 1.00 186,795 198 48 2.71 TABLE4 265,040 281 10.30 1.09 234,963 249 14 10.00 INDEX1 188,572 200 15.07 1.03 168,047 178 3 3.33 INDEX2 222,456 236 10.85 1.00 128,160 136 1 20.00 表 12は、これらのオブジェクトすべてのオブジェクト強度を示しています。このオブジェクト強度を示す表をよく見ると、TABLE4 が受け取るGBあたりの相対的なIOPS数が、TABLE1 と比べてかなり多いことが分かります。オブジェクト強度が高いこれらのオブジェクトをEFDに移動すると、そのオブジェクトに対して同等のセカンダリ・キャッシュが作成されるため、アクセス Oracle データベースの展開高度なテクノロジー 20

(21)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した速度が上がります。この表の上位 3 つのアイテムを移動することで得られる相対的なメリットを、他のデータ・コンテナとも比較してみます。重要なのは、表 12の上位 3 つのエントリが占める割合がデータベースの 2％にもなっていないということです。 Oracle データベースの展開高度なテクノロジー 21 表12：OI 率 テーブルスペース平均読み取 り/秒 平均書き込 み/秒 合計 I/O オブジェクト・ サイズ（GB） OI 率 TABLE4 258 196 454 0.343 752.19 INDEX2 238 123 361 1.75 136.00 INDEX1 203 180 383 3.35 60.60 TABLE1 4,727 1,539 6,266 109 43.37 TABLE2 494 314 808 52 9.50 TABLE3 463 208 671 91 5.09 思想的な階層型 Oracle 展開では、オブジェクト強度がかなり高いオブジェクトは EFD に、中程度の強度を持つオブジェクトはファイバ・チャネル・ドライブに、そして、オブジェクト強度の値が一番低いオブジェクトは SATA ドライブに配置します。 図 7は、部分データベースをEFDに移動することによって得られるパフォーマンス上のメリット を示しています。ここでは、45 x 15k rpmのファイバ・チャネル・スピンドルに展開されている 1 TB OLTPデータベースからさまざまな部分を、6 つのEFDに作成されたASMディスク・グループに順番に移動しました。

Relative transactions per minute

1.00 1.01

1.18

2.13

2.50

All on FC Logs on EFD High OI on EFD Top TS on EFD Just 2% data moved to EFD 30% data with 70% I/O moved to EFD Moving logs - minimal improvement 0.00 1.00 2.00 1.50 0.50 OI – Object Intensity TS – Tablespace 図7：部分データベースの移動により得られるパフォーマンス上のメリット

(22)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した Oracle データベースの展開高度なテクノロジー 22 図 7のデータを見ると、REDOログ・ファイルに関するOracleの推奨事項が分かります。EFDにロ グを移動しても、わずか 1%の向上しか見られません。つまり、ログはファイバ・チャネル・ドライブに安全に残しつつ、データベースでレーテンシーの影響を受ける部分をEFDに移動することで、最大限のメリットを引き出すことができます。オブジェクト強度が高いオブジェクトを EFD に移動すれば、相対的なパフォーマンス上のメリットを必ず得られます。このテストでは、わずか 2%のデータ（オブジェクト強度の高い上位 3 つのオブジェクト）を EFD に移動するだけで、パフォーマンスが 18%向上しました。スペース制限により限られたデータベース・オブジェクトしか移動できない場合、DBA やストレージ管理者は、オブジェクト強度を考慮しながら移動するオブジェクトを選択し、最大限のメリットを引き出せるようにします。 I/O の 70%を受け取るテーブルスペースを移動すれば、予想どおり 2.13 倍以上のパフォーマンス向上が実現します。ここで重要なのは、パフォーマンスを 2.13 倍向上させるために合計 30%のデータが移動されたという点です。つまり、データベース・サイズのわずか 2%を移動するだけでパフォーマンスが向上する高強度のオブジェクトに比べると、相対的なメリットがかなり低いということです。

(23)

Oracle データベースを EFD に移動しても、EFD のパフォーマンス機能ではなく、次のようなアプリケーション関連の問題により、期待どおりにアプリケーションのパフォーマンスが向上しない場合があります。通常、データベース・トランザクションは、次の要因により非常に複雑です。 • さまざまなサイズおよび種類の I/O オペレーションが複数存在する • ストレージ・システムから取得したデータを処理する CPU 集約型オペレーションが複数存在する • 標準の逐次化機能をサポートする可能性があるデータベースが、変更ベクタをトランザクション・ログにコミットしてから処理しなければならないインデックス・ブロックがフェッチされるまでデータ・ブロック読み取りが発生できない • トランザクションの速度がそのトランザクションのどのサブオペレーションよりも遅い 図 8は、データベース全体をEFDに移動しても、アプリケーションのパフォーマンスがそれほど 大きく向上しない理由を示しています。データベースがファイバ・チャネル・ドライブに展開されている場合に、完了するまでに 35 ミリ秒がかかるトランザクションについて考えてみます。このトランザクションは、3 つの異なるデータ・コンテナを対象にした 3 つのI/Oオペレーションで構成されており、それぞれに 15 ミリ秒、6 ミリ秒、9 ミリ秒が費やされています。また、データを処理するためのCPU集約型オペレーションもトランザクションに含まれています。データベースをEFDに移動するとトランザクションのI/O部分だけが最適化され、CPU集約型オペレーションに関する部分は何も変わりません。I/Oオペレーションの時間は 15 分の 1 に短縮されるのに（30 ミリ秒から 2 ミリ秒）、全体的なパフォーマンスは 5 倍（35 ミリ秒から 7 ミリ秒）しか向上しないのはこのためです。 1m 15m 1m 1m 9m 2m 6m Total= 35ms Storage=30m Before 1m 1m 1m 1m 2m 0.5m Total = 7ms Storage=2ms 0.5m After

Overall Transaction response time before and after deploying Flash drives (Entire database is moved to Flash)

Time spent processing data Waiting for I/O on FC drive to finish Legend

Waiting for I/O on Flash drive to finish

アプリケーションはストレージが

15

倍（

30 / 2

）になっても、

5

倍（

35 / 7

）

図8：データベース全体を移動することで実現するトランザクション・レスポンス・タイムの向 上 Oracle データベースの展開高度なテクノロジー 23 させるのにまだ 6 ミリ秒を必要としています。その結果、トランザクション・レスポンス・タイム全体の改善幅が小さくなっています。部分データベースの移行の場合にEFDに移動するデータの量によっては、EFD対象のI/Oオペレーションの一部のみが高速になりますが、それでもトランザクションは、低速なファイバ・チャネル・ドライブ上の他のオペレーションが完了するのを待機しなければなりません。そのせいで、 トランザクション・レスポンス・タイム全体の改善幅が小さくなる場合があります。図 9は、こ のシナリオについて説明しています。このシナリオでは、EFDベースのI/Oが大幅に改善されたにもかかわらず、ファイバ・チャネル・ドライブに残されたデータのI/Oオペレーションを完了

(24)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した Oracle データベースの展開高度なテクノロジー 24 図9：部分データベースを移動することで実現するトランザクション・レスポンス・タイムの向 上

EFD と ILM（情報ライフサイクル管理）戦略

エンタープライズ・アプリケーション・データは、実際、ほとんどが一時的なものです。最新のデータへのアクセス頻度は古いデータよりも高く、このようなアクセス頻度が高いデータをより高速なストレージに移動し、アクセス頻度が低いデータを SATA のような安価なストレージへ移動するという処理は、極めて一般的に行われています。ILM（情報ライフサイクル管理）戦略は、まず、このようにデータを分類することから始まります。コスト・パフォーマンスに優れたストレージ階層をアプリケーションで実現し、そのアプリケーションのワークロードのニーズを満たすには、データを分類することが重要です。これは各アプリケーションを最適なストレージ階層に配置することで実現できますが、同じアプリケーション内にある複数のストレージ階層を使用して達成することも可能です。一般的には、1 つのデータベースを、ファイルの種類ごとに複数の階層にわたって展開します。たとえば、アーカイブ・ログとバックアップ・イメージには SATA ドライブを、REDO ログとデータ・ファイルにはファイバ・チャネル HDD を使用できます。EFD によって「階層 0」と呼ばれるパフォーマンスに優れた階層が追加されているため、前に説明したように、レーテンシーが重要なデータ・ファイル、インデックス、一時ファイルをこの階層に配置できるようになりました。ただし、データベースが大きいときは、ドライブ・リソースを最適に使用できるように、頻繁にアクセスされ、レーテンシーに関する要件が最も厳しいデータのみを EFD に置くことをお勧めします。データベースの多くは、テーブルのパーティションを設定することによってこれを行います。このホワイト・ペーパーで紹介した分析手法を使用すれば、EFD の機能を生かせる最もアクティブなテーブルスペースとファイルをお客様が判断できます。こうしたテーブルスペースの LUN を EFD に置けば大きなメリットを得られます。データベース全体を EFD に移動する必要はありません。また、テーブルのパーティション設定により、そのテーブルのサブセットが作成されます。通常、サブセットは日付範囲ごとに作成され、さまざまなデータ・ファイルに配置できます。こうした Total= 35ms Storage=30ms 1m 15m 1m 1m 9m 2m 6m Before

nse time before & after deploying Flash drives rts

Overall Transaction respo

(Only pa of database moved to Flash)

Time spent processing data Waiting for I/O on FC drive to finish Legend

Waiting for I/O on Flash drive to finish 1m 1m 1m 1m 2m 6m Total = 12.5ms Storage=7.5ms 0.5m After アプリケーションはフラッシュ・ドライブ上の I/O が 1/16（24/1.5 = 16）で終了しても、2.4 倍しか全体的に向上しません。全体のトラン ザクションの応答時間は、ファイバ・チャネル・ドライブに一部のデ

(25)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用したデータ・ファイルはそれぞれが特定のストレージ階層に属しています。テーブルのパーティション設定は、一般的には、データ・ウェアハウスで使用され、インデックスおよびデータ・スキャンを強化します。ただし、ILM戦略を考慮しているお客様は、OLTPアプリケーションでテーブルのパーティション設定を使用する利点を考慮する必要があります。パーティションを設定すると複数のストレージ階層にわたってデータを分散させることができますが、これは階層間でのデータ移動には対応していません。ストレージ階層間でのデータ移行については、このホワイト・ペーパーでは扱いません。このスペースの問題を解決するには、CLARiX仮想LUNテクノロジーであるOracleオンライン再定義機能、またはホスト・ボリューム管理機能を使用します。 CLARiX仮想LUNテクノロジーを使用すると、ホストやそのホストで実行されているアプリケーションを中断せずに、データベースの一部をEFDにシームレスに移行できます。図 10は、テーブルのパーティション設定の使用例を示しています。 図10：階層型ストレージ・レベルを使用したパーティション・テーブル

結論

CLARiX CX4 にエンタープライズ・フラッシュ・ドライブを組み込むことにより、非常に低いレーテンシーで高い I/O パフォーマンスを実現できる新しい階層 0 ストレージ・レイヤーが提供さォーマンス境界を定義しません。十分に使用されない大量のディスク・ドライブに作業負わせることで、最先端の機能と超高性能を実現し、ストレージ階層オプションを拡張しれ、OLTP スループットが飛躍的に向上し、非常に短いレスポンス・タイムを維持できます。階層 0 では信頼性とシームレスな相互運用性を確保するために包括的な検証とテストが行われ、データ・レプリケーションやリモート保護など、すべての主要 CLARiX ソフトウェア・アプリケーションでサポートされています。磁気ディスク・ドライブ・テクノロジーは、もはやミッション・クリティカルなストレージ環境のパフ荷を分散するという、高コストなアプローチは不要になりました。 CLARiX は今日、フラッシュ・ドライブ・テクノロジーのパフォーマンスと電力効率を、従来のディスク・ドライブ・テクノロジーと 1 つのアレイ（単一ソフトウェア・ツールで管理される）で組み合ます。 Oracle データベースの展開高度なテクノロジー 25

(26)

エンタープライズ・フラッシュ・ドライブと EMC CLARiX CX4 を利用した Oracle データベースの展開

高度なテクノロジー 26

エンタープライズ・フラッシュ・ドライブとEMC CLARiX CX4を利用したOracleデータベースの展開