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

Transcription

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

2 Copyright 2008 EMC Corporation. 不許複製 EMC Corporation は この資料に記載される情報が 発効日時点で正確であるとみなしています この情報は 予告なく変更されることがあります この資料に記載される情報は 現状有姿 の条件で提供されています EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェア ライセンスが必要です 最新の EMC 製品名については EMC.com で EMC Corporation の商標を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 H5967-J Oracle データベースの展開高度なテクノロジー 2

3 目次 エグゼクティブ サマリー...4 概要...5 対象読者... 6 テクノロジーの概要...6 CLARiX CX Oracle データベースとエンタープライズ フラッシュ ドライブ...7 EFD に最も適したデータベース ワークロード... 7 Oracle AWR レポートまたは Statspack レポートの分析... 9 負荷プロファイル セクション... 9 Oracle 待機イベント テーブルスペース I/O 統計 使用例の比較...12 使用例 1: 読み取り集中型ワークロード 使用例 2:Oracle OLTP ワークロードの比較 使用例 4:EFD への部分データベースの移動 EFD の REDO ログか?( あるいは そうではないか ) EFD 上の Oracle 一時テーブルスペース EFD へのオブジェクト強度が高いオブジェクトの移動 EFD と ILM( 情報ライフサイクル管理 ) 戦略...24 結論...25 関連資料...26 Oracle データベースの展開高度なテクノロジー 3

4 エグゼクティブ サマリー 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 を実現できます Oracle データベースの展開高度なテクノロジー 4

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

6 対象読者 このホワイト ペーパーは Oracle データベース環境におけるエンタープライズ フラッシュ ドライブの実装について理解し ビジネス アプリケーションのパフォーマンスを向上させようとしている Oracle データベース管理者 ストレージの設計者 お客様 EMC のフィールド担当者を対象にしています テクノロジーの概要 CLARiX CX4 UltraFlex TM テクノロジーが採用されている EMC CLARiX CX4 シリーズは 新しい画期的なアーキテクチャと広範な技術革新に基づいており どの競合他社の追随も許さないミッドレンジ ストレージを提供します CX4 は第 4 世代の CX シリーズです EMC は お客様が新しいテクノロジーを採用するときに既存のリソースと設備資産を適切に利用できるようにして CLARiX テクノロジーに対するお客様の投資を最大限に生かせるよう引き続き取り組んでいます 図 2に示す新しいCLARiX CX4 システムは ミッドレンジ エンタープライズ ストレージ市場におけるEMCのリーダーシップを強化する次世代 CXシリーズです CX4 は EFD 高パフォーマンスの 4 Gb/s FCドライブ 大容量のSATA IIなど 最新世代のディスク ドライブ テクノロジーに直ちに対応します CLARiX CX4 は この最新世代のディスク ドライブ テクノロジーすべてをサポートできる初の唯一のミッドレンジ ストレージ システムなのです FLARE 最新リリース (R28) が採用されたCLARiX CX4 は パフォーマンスを最大限に高め 階層型ストレージ機能の柔軟性を確保するために最適化されています このホワイト ペーパーでは 一部の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 の読み取り要求はストレージ システムによって直ちに実行されます ディスク アクセスなしでストレージ キャッシュから実行される読み取りが 読み取りヒットと呼ばれます 要求されたデータがストレージ キャッシュで使用できない場合は CLARiX がディスクからそのデータを取得しなければなりません これは 読み取りミスと呼ばれます ショート ストローク ドライブ : レーテンシーの影響が大きいアプリケーションの中には 正規のファイバ チャネル ドライブでこの手法を使用して低レーテンシーを実現するものがあります この手法では スピンドル ヘッドの移動を減らすために 部分的にしか埋まっていない多数のディスクにデータがレイアウトされ 非常に低いレーテンシーで高いレベルの IOPS が実現します CLARiX キャッシュの読み取りヒット率が高いワークロードについては すでにメモリ アクセス速度でサービスが提供されているため フラッシュ ドライブ テクノロジーに展開しても大きなメリットを得られないことがあります CLARiX キャッシュの読み取りヒット率が低いワークロードで ランダム I/O パターンを示しており さらに I/O リクエストのサイズが小さく ( 最大 16 KB) 高いトランザクション スループットが求められている場合は FED の低レーテンシーを最大限に生かせるでしょう データベース マネージャやアプリケーション マネージャは ビジネス トランザクション スループットが増加し サービス レーテンシーが減ったときに 売上増加と生産性向上に直結するミッション クリティカルなアプリケーションを簡単に特定できます こうしたアプリケーションを認識したストレージ管理者は より多くのドライブに対して ショート ストローキング を行い そのドライブでサポートされている最高レベルの I/O サービスを利用できるようにすることがよくあります これらのアプリケーションは 非常に重要な 2 つのメリットを EFD から得ることができます 多数のショート ストローク ドライブの代わりに1つの EFD を使用し 高速トランザクション (IOPS) を提供できます これにより アプリケーションに必要なドライブ数が少なくなり 多数のディスクを回転させ続ける必要がなくなります これにより電力の消費を抑え 結果的にはデータ センターのフロア面積も少なくて済むようになります EFD では非常に低いレーテンシーが実現しています したがって 短いレスポンス タイムを予測できることが非常に重要で 必ずしもすべてのデータをホストまたは CLARiX キャッシュに保持する必要がないアプリケーションは このようなドライブを使用することにより大きなメリットを得られます EFD には回転メディアがないため その転送速度は非常に高速です 多数のショート ストローク ハード ドライブで達成できるベスト レスポンス タイムよりもはるかに速くデータが提供されます Oracle データベースの展開高度なテクノロジー 8

9 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 時間 ( 秒 ): DB CPU( 秒 ): REDO サイズ : 4, ,875.4 論理読み取り : 18, ,443.7 ブロック変更 : 物理読み取り : 17, ,793.6 物理書き込み : ユーザー コール : 解析 : ハード解析 : 処理された W/A MB: 45, ,600.7 ログオン : 実行 : ロールバック : トランザクション : 1.5 AWR レポートによると 読み取り集中型ワークロードでは かなりの数の読み取りが物理的に行われています つまり Oracle キャッシュではなくストレージから読み取りが実行されています このワークロードは 通常 EFD を利用することにより大きなメリットを得られます ただ Oracle データベースの展開高度なテクノロジー 9

10 し EFD の使用を検討する前に データベース キャッシュをチューニングするだけでこれらの IOPS を減らすことができないかどうかを確認することが重要です 問題解決のために EFD を投入するよりも システムのメモリを増やす方がはるかに簡単だからです Oracle パフォーマンス レポートのバッファ プール アドバイザリ セクションは データベース バッファ キャッシュ増加の影響を示しています 現在の例では データベースは 4 GB のバッファ キャッシュを使用するよう構成されていました 表 2 は バッファ プールが 2 倍になっても推定物理読み取りは変わらないことを示しています これは より高速なストレージを導入しないと向上が見込まれない例です したがって この場合は EFD を使用するのが理想的です 表 2: バッファ プール アドバイザリ P 推定用サイズ (M) サイズ係数推定用バッファ推定物理読み取り係数推定物理読み取り D , ,413 D 1, , ,008 D 1, , ,605 D 3, , ,590 D 4, , ,590 D 4, , ,590 D 5, , ,590 D 6, , ,590 D 6, , ,590 D 7, , ,590 データベース キャッシュを 2 倍にしても同じ量の物理読み取りになります Oracle 待機イベントこのセクションは 5 つの主要 Oracle フォアグラウンド待機イベントを示しています データベースをチューニングするとき ほとんどの DBA がこのセクションに注目します このデータによって チューニング時に最大限のメリットを簡単に引き出すことができるからです このセクションで確認する重要な要素は DB ファイルのシーケンシャルな読み取り 待機イベントです この要素の名前はカウンタ直観的で その名前は実際にはその名前が意味するものではなく 実はワークロードのランダム性を示しています このイベントは サンプリング間隔中にデータベースが 1 つのブロック I/O が完了するのを待機しなければならなかった回数と その平均待機時間をトラッキングします 次の例では データベースは約 88% の時間を I/O の完了に費やしていました その平均待機時間は 14 ミリ秒です アプリケーション ユーザーがシステムの応答性が悪いことに不満を持っている場合は このデータベースを EFD に置きます これにより 平均レーテンシーが大きく向上します ここでレーテンシーの値が高くても 必ずしもそれが問題になるとは限りません 結局 ビジネス トランザクション サービス全体のパフォーマンスを許容できるかどうかを決めるのは 実際に操作するユーザーなのです Oracle データベースの展開高度なテクノロジー 10

11 表 3:5 つの主要定期フォアグラウンド イベント イベント DB ファイルのシーケンシャルな読み取り DB ファイルの並列読み取り 待機 時間 ( 秒 ) 平均待機 ( ミリ秒 ) DB 時間の割合 待機クラス 1,169,805 16, ユーザー I/O 34,303 1, ユーザー I/O DB CPU ログ ファイルの同期 79, コミット DB ファイルのランダムな読み取り 1, ユーザー 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, ,440,601 1, DATA2 454, , DATA3 425, , INDEX1 265, , INDEX2 188, , 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, ,875.4 論理読み取り : 18, ,443.7 ブロック変更 : 物理読み取り : 17, ,793.6 物理書き込み : ユーザー コール : 実行 : トランザクション : 1.5 インスタンスの効率性 ( 目標 100%) 4 GB バッファ キャッシュ バッファ待機なし率 : I/O の 50% はストレージから提供 REDO 待機なし率 : バッファ ヒット率 : されますが Buffer Pool Advisory インメモリ ソート はバッファ キャッシュの増加に 率 : よるサポートを示しませんライブラリ ヒット率 ソフト解析率 : 解析実行率 : ラッチ ヒット率 : Oracle データベースの展開高度なテクノロジー 12

13 5 つの主要定期イベント イベント DB ファイルのシーケンシャルな読み取り 待機 時間 ( 秒 ) 平均待機 ( ミリ秒 ) 合計コール時間の割合 待機クラス 10,803,192 42, ユーザー I/O DB CPU 1, DB ファイルのランダムな読み取り コントロール ファイルのシーケンシャルな読み取り DB ファイルの並列読み取り 32, ユーザー I/O 25, システム I/O ユーザー 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 EFD によって 論理読 2,727.3 論理読み取り : 57,548.5 み取りと物理読み取り 23,908.0 ブロック変更 : 27.2 は最大 3 倍にまで増加 11.3 物理読み取り : 53,055.7 します これによりディスクの数が 96% 減少 22,041.5 物理書き込み : 3.6 しても より多くのト 1.5 ユーザー コール : ランザクションが可能になります 実行 : トランザクション : 2.4 インスタンスの効率性 ( 目標 100%) Oracle データベースの展開高度なテクノロジー 13

14 バッファ待機なし率 : REDO 待機なし率 : バッファ ヒット率 : インメモリ ソート率 : ライブラリ ヒット率 ソフト解析率 : 解析実行率 : ラッチ ヒット率 : つの主要定期イベント イベント DB ファイルのシーケンシャルな読み取り 待機 時間 ( 秒 ) 平均待機 ( ミリ秒 ) 合計コール時間の割合 待機クラス 33,689,960 40, ユーザー I/O DB CPU 5, DB ファイルのランダムな 30, 応答時間はディスクの数を ユーザー I/O 読み取り 96% 減少しても 4 ミリ秒か コントロール ファイルのシーケンシャルな読み取り 25,993 6 ら 1 ミリ秒に減ります システム I/O ラッチ フリー 6, その他 このテストは 少数の 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 Flash Tx/min HDD Tx/min :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 図 3:EFD と HDD の 1 分あたりのトランザクション数の比較 図 3 は このテストの構成では EFD が平均 19,000 TPM(1 分あたりのトランザクション数 ) を実現する一方で ファイバ チャネル ドライブでは約 2,400 TPM しか維持されていないことを示しています つまり EFD の TPM は ファイバ チャネル ドライブの約 8 倍になっています さらに EFD のレスポンス タイムがファイバ チャネル ドライブの 7 分の 1 になっているのも興味深いところです Oracle データベースの展開高度なテクノロジー 15

16 この使用例は 構成内のディスクのみを変更することで 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 FCD 6 EFD 図 4:6 台の EFD と 75 台の FC ドライブの 1 分あたりのトランザクション数の比較 Oracle データベースの展開高度なテクノロジー 16

17 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) 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) 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 ワークロード ランダム読み取り B ツリー リーフ アクセス テーブルの ROWID 検索 異なる種類の LOB へのアクセス オーバーフロー行へのアクセス クラスタ化されていないテーブルに対するインデックス スキャン 圧縮 :I/O 負荷増加 (IOPS/GB) シリアル読み取り ランダム書き込み PK による行の更新 インデックスのメンテナンス チェックポイント間隔の削減 一時ファイル : ソート エリアと中間テーブル シーケンシャルな読み取りおよび書き込み ただしI/Oは 1 MB 単位で実行 : シークを償却するには不十分 低レーテンシー : 取り込み 取り出し EFD で良好なコスト パフォーマンスを得られない REDO ログ ファイル シーケンシャルな読み取りと書き込み また ストレージ コントローラのキャッシュによってすでに処理されているレーテンシーのコミット UNDO テーブル スペース シーケンシャルな書き込み FlashBack によるランダム読み取り ただし 読み取りは バッファ キャッシュにまだ存在すると思われる最近書き込まれたデータ用 大きなテーブルのスキャン 書き込みが多いバッファ プール 低レーテンシー読み取りの後に更新を行うと ダーティー ページでプールがいっぱいになる可能性がある フラッシュ デバイス書き込みは読み取りよりも 2~4 倍遅いため排出に時間がかかる 読者に対して フリー バッファ待機 が発生する可能性がある EFD の REDO ログか?( あるいは そうではないか ) Oracle オンライン REDO ログを EFD に移動するとそのログがメリットを得られる とよく誤解されていますが テストのデータはすべて これとは反対のことを示しています テストは EFD に REDO ログを移動しても 大きな改善は見られないことを示しています こうした REDO ログは EFD に移動するよりも ファイバ チャネル ドライブを支える書き込みキャッシュに残したままにして EFD は データベースの他の読み取り集中部分 ( インデックスやデータなど ) に対して使用することをお勧めします Oracle データベースの展開高度なテクノロジー 19

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, ,440,601 1, TABLE2 454, , TABLE3 425, , TABLE4 265, , INDEX1 188, , INDEX2 222, , 表 12 は これらのオブジェクトすべてのオブジェクト強度を示しています このオブジェクト強度を示す表をよく見ると TABLE4 が受け取る GB あたりの相対的な IOPS 数が TABLE1 と比べてかなり多いことが分かります オブジェクト強度が高いこれらのオブジェクトを EFD に移動すると そのオブジェクトに対して同等のセカンダリ キャッシュが作成されるため アクセス Oracle データベースの展開高度なテクノロジー 20

21 速度が上がります この表の上位 3 つのアイテムを移動することで得られる相対的なメリットを 他のデータ コンテナとも比較してみます 重要なのは 表 12 の上位 3 つのエントリが占める割合がデータベースの 2% にもなっていないということです 表 12:OI 率 テーブルスペース 平均読み取り / 秒 平均書き込み / 秒 合計 I/O オブジェクト サイズ (GB) OI 率 TABLE INDEX INDEX TABLE1 4,727 1,539 6, TABLE TABLE 思想的な階層型 Oracle 展開では オブジェクト強度がかなり高いオブジェクトは EFD に 中程度の強度を持つオブジェクトはファイバ チャネル ドライブに そして オブジェクト強度の値が一番低いオブジェクトは SATA ドライブに配置します 図 7 は 部分データベースを EFD に移動することによって得られるパフォーマンス上のメリットを示しています ここでは 45 x 15k rpm のファイバ チャネル スピンドルに展開されている 1 TB OLTP データベースからさまざまな部分を 6 つの EFD に作成された ASM ディスク グループに順番に移動しました Relative transactions per minute 30% data with 70% I/O moved to EFD Moving logs - minimal improvement Just 2% data moved to EFD All on FC Logs on EFD High OI on EFD Top TS on EFD OI Object Intensity TS Tablespace 図 7: 部分データベースの移動により得られるパフォーマンス上のメリット Oracle データベースの展開高度なテクノロジー 21

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

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 ミリ秒 ) しか向上しないのはこのためです Overall Transaction response time before and after deploying Flash drives (Entire database is moved to Flash) Before 1m 1m 1m 2m Total= 35ms Storage=30m 15m 6m 9m After 1m 1m 1m 2m 1m 0.5m 0.5m Total = 7ms Storage= 2ms Legend Time spent processing data Waiting for I/O on FC drive to finish Waiting for I/O on Flash drive to finish アプリケーションはストレージが 15 倍 (30 / 2) になっても 5 倍 (35 / 7) 図 8: データベース全体を移動することで実現するトランザクション レスポンス タイムの向上 部分データベースの移行の場合にEFDに移動するデータの量によっては EFD 対象のI/Oオペレーションの一部のみが高速になりますが それでもトランザクションは 低速なファイバ チャネル ドライブ上の他のオペレーションが完了するのを待機しなければなりません そのせいで トランザクション レスポンス タイム全体の改善幅が小さくなる場合があります 図 9は このシナリオについて説明しています このシナリオでは EFDベースのI/Oが大幅に改善されたにもかかわらず ファイバ チャネル ドライブに残されたデータのI/Oオペレーションを完了させるのにまだ 6 ミリ秒を必要としています その結果 トランザクション レスポンス タイム全体の改善幅が小さくなっています Oracle データベースの展開高度なテクノロジー 23

24 Overall Transaction response time before & after deploying Flash drives (Only pa rts of database moved to Flash) Before 1m 1m 1m 2m Total= 35ms Storage=30ms 15m 6m 9m Legend After 1m 1m 1m 2m Total = 12.5ms Storage= 7.5ms Time spent processing data Waiting for I/O on FC drive to finish 1m 6m 0.5m Waiting for I/O on Flash drive to finish アプリケーションはフラッシュ ドライブ上の I/O が 1/16(24/1.5 = 16) で終了しても 2.4 倍しか全体的に向上しません 全体のトランザクションの応答時間は ファイバ チャネル ドライブに一部のデ 図 9: 部分データベースを移動することで実現するトランザクション レスポンス タイムの向上 EFD と ILM( 情報ライフサイクル管理 ) 戦略 エンタープライズ アプリケーション データは 実際 ほとんどが一時的なものです 最新のデータへのアクセス頻度は古いデータよりも高く このようなアクセス頻度が高いデータをより高速なストレージに移動し アクセス頻度が低いデータを SATA のような安価なストレージへ移動するという処理は 極めて一般的に行われています ILM( 情報ライフサイクル管理 ) 戦略は まず このようにデータを分類することから始まります コスト パフォーマンスに優れたストレージ階層をアプリケーションで実現し そのアプリケーションのワークロードのニーズを満たすには データを分類することが重要です これは各アプリケーションを最適なストレージ階層に配置することで実現できますが 同じアプリケーション内にある複数のストレージ階層を使用して達成することも可能です 一般的には 1 つのデータベースを ファイルの種類ごとに複数の階層にわたって展開します たとえば アーカイブ ログとバックアップ イメージには SATA ドライブを REDO ログとデータ ファイルにはファイバ チャネル HDD を使用できます EFD によって 階層 0 と呼ばれるパフォーマンスに優れた階層が追加されているため 前に説明したように レーテンシーが重要なデータ ファイル インデックス 一時ファイルをこの階層に配置できるようになりました ただし データベースが大きいときは ドライブ リソースを最適に使用できるように 頻繁にアクセスされ レーテンシーに関する要件が最も厳しいデータのみを EFD に置くことをお勧めします データベースの多くは テーブルのパーティションを設定することによってこれを行います このホワイト ペーパーで紹介した分析手法を使用すれば EFD の機能を生かせる最もアクティブなテーブルスペースとファイルをお客様が判断できます こうしたテーブルスペースの LUN を EFD に置けば大きなメリットを得られます データベース全体を EFD に移動する必要はありません また テーブルのパーティション設定により そのテーブルのサブセットが作成されます 通常 サブセットは日付範囲ごとに作成され さまざまなデータ ファイルに配置できます こうした Oracle データベースの展開高度なテクノロジー 24

25 データ ファイルはそれぞれが特定のストレージ階層に属しています テーブルのパーティション設定は 一般的には データ ウェアハウスで使用され インデックスおよびデータ スキャンを強化します ただし ILM 戦略を考慮しているお客様は OLTP アプリケーションでテーブルのパーティション設定を使用する利点を考慮する必要があります パーティションを設定すると複数のストレージ階層にわたってデータを分散させることができますが これは階層間でのデータ移動には対応していません ストレージ階層間でのデータ移行については このホワイト ペーパーでは扱いません このスペースの問題を解決するには CLARiX 仮想 LUN テクノロジーである Oracle オンライン再定義機能 またはホスト ボリューム管理機能を使用します CLARiX 仮想 LUN テクノロジーを使用すると ホストやそのホストで実行されているアプリケーションを中断せずに データベースの一部を EFD にシームレスに移行できます 図 10 は テーブルのパーティション設定の使用例を示しています 図 10: 階層型ストレージ レベルを使用したパーティション テーブル 結論 CLARiX CX4 にエンタープライズ フラッシュ ドライブを組み込むことにより 非常に低いレーテンシーで高い I/O パフォーマンスを実現できる新しい階層 0 ストレージ レイヤーが提供され OLTP スループットが飛躍的に向上し 非常に短いレスポンス タイムを維持できます 階層 0 では信頼性とシームレスな相互運用性を確保するために包括的な検証とテストが行われ データ レプリケーションやリモート保護など すべての主要 CLARiX ソフトウェア アプリケーションでサポートされています 磁気ディスク ドライブ テクノロジーは もはやミッション クリティカルなストレージ環境のパフォーマンス境界を定義しません 十分に使用されない大量のディスク ドライブに作業負荷を分散するという 高コストなアプローチは不要になりました CLARiX は今日 フラッシュ ドライブ テクノロジーのパフォーマンスと電力効率を 従来のディスク ドライブ テクノロジーと 1 つのアレイ ( 単一ソフトウェア ツールで管理される ) で組み合わせることで 最先端の機能と超高性能を実現し ストレージ階層オプションを拡張します Oracle データベースの展開高度なテクノロジー 25

26 関連資料 スペック シート : EMC CLARiiON CX4 Model 960 Networked Storage System EMC CLARiiON CX4 Series Ordering Information and Configuration Guidelines ( 対象読者制限あり ) Introduction to the EMC CLARiiON CX4 Series Featuring UltraFlex Technology ホワイト ペーパー Oracle データベースの展開高度なテクノロジー 26