EMC CLARiXストレージ・システムでのOracleの実装

Transcription

1 EMC CLARiX ストレージ システムでの Oracle の実装 ベスト プラクティスのプランニング US ホワイトペーパー翻訳版 要約 このホワイト ペーパーでは EMC CLARiX CX または CX3 UltraScale シリーズのファイバ チャネル ストレージ システムを使用して Oracle データベースを実装するときに考慮するべき問題について説明します また Oracle の一般的な推奨事項と CLARiX システム特有のパフォーマンス特性を対比させ Oracle で CLARiX ストレージ システムを使用する際の一般的な推奨事項について取り上げています 2008 年 5 月

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

3 目次 T ベスト プラクティスのプランニング... 0 エグゼクティブ サマリー... 5 概要... 5 対象読者...5 用語...5 このホワイト ペーパーについて... 7 Oralce の CLARiX ストレージ認定... 7 CLARiX ストレージに対する Oracle データベース設計に関する考慮事項... 8 魔法の弾丸 シンドロームに対応...8 データベースの論理レイアウトおよびパフォーマンス...8 Oracle OFA および特殊領域とテーブル...9 パフォーマンスへのアプリケーションの種類の影響...10 標準の OLTP アプリケーションの特徴...10 標準 DSS アプリケーションの特徴...11 シーケンシャルまたはランダム I/O...12 I/O プロファイルの決定...12 一時パターンおよびピーク アクティビティ...12 Oracle I/O 構造...13 データ テーブルの I/O...13 REDO ログの I/O...14 アーカイブの I/O...14 データベース ブロック サイズ (DB_BLOCK_SIZE)...14 REDO ログ...15 REDO ログに関する考慮事項...15 インスタンス パラメータ...19 インスタンス パラメータの例...20 データベースのバックアップ...20 コールド バックアップ...21 ホット バックアップ...21 SnapView でのホット バックアップ...22 SnapView での他に影響しないバックアップ...22 パフォーマンスに関するその他の考慮事項 ホスト OS および HBA に関する考慮事項...24 最大 I/O サイズ...24 配置...25 ファイル システムまたは raw パーティション...25 raw パーティション...26 ファイル システム...26 ホスト ベースのスクリプト作成 (Plaid)...27 Oracle の SAME...27 EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 3

4 ホスト ベースのストライピングのガイドライン...27 metalun の使用...28 純粋な metalun およびラウンドロビン ロギング...28 metalun および従来のログ デバイスのハイブリッド使用...29 CLARiX キャッシュ...30 キャッシュ ページ サイズ...30 キャッシュ対象の LUN...30 スピンドルおよびストライプ...30 ストライプ エレメント サイズ...31 RAID レベルとパフォーマンス...31 RAID 6 を使用する状況...31 RAID 5 を使用する状況...32 RAID 1/0 を使用する状況...32 RAID 1 を使用する状況...32 RAID 0 を使用する状況...33 RAID レベルと冗長性...33 ディスク...33 結論 関連資料 付録 A:REDO ログ コンシステンシの必要性...36 パフォーマンスの利用...36 最適化の推進 : バッファ結合...37 付録 B:DB チューニングの基本ステップ EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 4

5 エグゼクティブ サマリー Oracle のパフォーマンスに関する問題は設計フェーズにあります これは アプリケーションおよび論理インフラストラクチャの設計がパフォーマンスにとって非常に重要だからです これらの問題が解決済みと考えられる場合 ストレージ パフォーマンスの最適化において重要視されるのは オブジェクト モデルの競合です オブジェクト レベルで分析するには データベース設計に関する知識が必要です そして 競合しているオブジェクトを ストレージ サブシステム上の別々の物理ディスク ドライブに配置することで 最適化が実現されます Oracle データベースの設計によって REDO ログなど 既知の I/O パターンを備えたコンポーネントがいくつか生成されます これらのパターンを RAID やディスク構成で利用すると 通常は 競合するテーブル上でスピンドルが共有されることがなくなります 所定の Oracle のインスタンス パラメータが EMC CLARiX ストレージの特性と連携して動作するように設定する必要があります 概要 業界トップの RDBMS( リレーショナル データベース管理システム ) である Oracle は 堅牢で かつ可用性に優れたデータ エンジンです 可用性 堅牢性 およびパフォーマンスを実現するために Oracle は データベース テーブルのストレージへの実装に関して 一般的な推奨事項を示しています これらの推奨事項は すべての実装およびストレージ システムに適用されるわけではありません このホワイト ペーパーでは Oracle データベースを CLARiX CX および CX3 UltraScale シリーズのファイバ チャネル ストレージ システムに実装する最適な方法について説明します なお このホワイト ペーパーは Oracle 10g 以降導入された Oracle ASM( 自動ストレージ管理 ) モデルへの展開を計画している方は対象にしていません このホワイト ペーパーは 3 つのセクションに分かれています Oracle の CLARiX ストレージ認定 CLARiX ストレージ向けの Oracle データベース設計に関する考慮事項 パフォーマンスに関するその他の考慮事項 Oracle ASM 導入に関する実装のガイダンスについては ホワイト ペーパー EMC CLARiiON SnapView and MirrorView for Oracle Database 10g Automatic Storage Management Best Practices Planning を参照してください 対象読者 このホワイト ペーパーは CLARiX ストレージを使用した Oracle RDBMS の実装に興味をお持ちのデータベース管理者 (DBA) または CLARiX システム エンジニアを対象にしています また 読者は RDBMS の基本的な機能および用語に関する一般的な知識を持っているほか Oracle 固有の用語とテクノロジーについて精通している必要があります 用語 アトミック : アトミック変更は 1 つの個別の手順で発生します したがって システム障害が発生した場合 状態はまったく変更されないか またはすべてが更新されるかのどちらかです アトミック トランザクションでは部分的に変更された状態はあり得ません 自動ストレージ管理 (ASM):Oracle Database 10g の機能 データベース管理者に すべてのサーバおよびストレージ プラットフォームで一貫したシンプルなストレージ管理インタフェース EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 5

6 を提供します ASM は Oracle データベース ファイル専用の垂直統合型ファイル システムおよびボリューム マネージャとして 非同期 I/O のパフォーマンスにおけるファイル システムの管理を容易にします チェックポイント :RDBMS が 実行されていないすべてのアイテムを REDO ログで処理し 新しいブックマーク ( システム コントロール番号 ) でテーブルを更新するプロセス 結合 : ファイル システム レベルで小さな I/O を大きな I/O にバンドルすること データのローカル性がある場合 ( たとえば ファイル システム内でブロック同士が近接している場合 ) に実行できます エレベータ アルゴリズム : ディスク ドライブが アクセス要求を最も効率よく処理できるように並べ替える方式 OPS(Oracle パラレル サーバ ):Oracle 7 で導入された Oracle クラスタリング テクノロジーの名前 Oracle サーバ エンジン インスタンスは 通常 サーバ ホストから実行し 一連の OS ファイルまたは raw パーティションへのアクセスのみを所有します 拡張および HA サポートの両方を提供するために Oracle RDBMS ソフトウェアは 複数の Oracle エンジン インスタンスが連携し これらの OS ファイルまたは raw パーティション上の一連の同じデータへのアプリケーション アクセスをサポートするよう拡張されました RAC( リアル アプリケーション クラスタ ):Oracle 9i 以降 Real Oracle アプリケーションの拡張と高可用性をサポートする RDBMS テクノロジーを表すために OPS(Oracle パラレル サーバ ) が RAC という名前に変更されました REDO ログ / オンライン ログ / トランザクション ログ :REDO ログは 高パフォーマンスを実現するための Oracle の最も重要なツールです これは 意図された変更をデータベースに記録するためのスクラッチ パッドで Oracle エンジンが次のジョブに移行する間 DBWR の書き込みのキューに配置できます この特殊な領域は シーケンシャル I/O 用に最適化された 高速かつ信頼性の高いストレージに実装する必要があります リザーブキャパシティ : 通常の運用時よりも優れたパフォーマンスを実現できる可能性があるという概念 たとえば レスポンス タイムのターゲットが 10 ミリ秒の場合 通常の運用ではストレージ システムで 8 ミリ秒のレスポンス タイムを実現します したがって 需要がピークに達している期間は システムでは引き続き 10 ミリ秒のパフォーマンスが実現できます ストライプ / ストライプ エレメント :RAID アルゴリズムでは 多数のディスクにストレージのシーケンシャル チャンクを分散させることで速度と信頼性を実現します I/O が次のディスクにジャンプする前に書き込まれたブロック数が ストライプ エレメントのサイズです また グループ ストライプ エレメント サイズ内のディスク数 =RAID ストライプのサイズです ストライプ サイズの方がさまざまな計算でよく使用されますが ストライプ エレメントも同様に重要です SGA( システム グローバル エリア ):Oracle データベース エンジンが存在するメモリ領域 Oracle は 最近使用されたデータに高速にアクセスし レイジー書き込み ( キューにコミットされているがディスクにはまだ書き込まれていない書き込み ) を行うために この領域で DBWR バッファなどのバッファを管理します Oracle では大量のメモリと独自のバッファリングを使用するため OS のチューニングが重要です システム コントロール番号 : 前回のチェックポイント後に行われた変更を特定する際に使用するグローバル ブックマーク ライト アサイド サイズ :512 バイトのブロックで測定される最大サイズ RAID エンジンは このサイズまでの要求に対してキャッシュ I/O を書き込みます このサイズよりも大きな要求は EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 6

7 ディスクに直接書き込まれます 詳細については ホワイト ペーパー EMC CLARiiON Best Practices for Fibre Channel Storage を参照してください このホワイト ペーパーについて このホワイト ペーパーを参照として使用しやすいように 注意が必要な段落には以下のように注記されています 推奨 : 概念については 付録を参照してください また このホワイトペーパーで扱うトピック固有の用語については 用語 セクションで説明しています なお 用語 セクションで定義されている用語は 最初は太字で記されています 付録では 次のトピックについてより詳しく説明します OracleREDO ログ プロセス Oracle の基本的なチューニング手順 パフォーマンスに関するその他の考慮事項 Oralce の CLARiX ストレージ認定 Oracle は Oracle ソフトウェアとストレージ テクノロジーの互換性を保証するために OSCP (Oracle Storage Compatibility Program) というパートナー プログラムを策定しました このプログラムは ネットワーク接続のファイル サーバ リモート ミラーリング テクノロジー およびスナップショット テクノロジーのいずれかのストレージ ソリューションと Oracle の互換性を検証するものです テスト キットを提供するのは Oralce ですが 実際にテストを実施するのはパートナーで そのテスト結果を Oracle が検証します テストには さまざまな障害発生シナリオにおける動作の正確性が重点的に盛り込まれており EMC は 2007 年 1 月までこのプログラムに参加していました Oracle は これらのストレージ システム テクノロジーは業界から受け入れられており ストレージ システム ベンダーにより提供される新世代のシステムにおいてもこれ以上検証の必要がないところまで成熟していると信じています CLARiX 製品ラインは OSCP プログラムによって検証されてきました そのテスト方式は CLARiX の新製品リリース前の CLARiX 検証テストに取り入れられているため 新世代の CLARiX ストレージ システムが新しい要件に対応し続けているということがお客様にも保証されています さらに EMC は CLARiX ストレージ システムをクラスタリング ソリューションおよびバックアップ ツールでの使用を認定しています どちらの使用においても EMC E-Lab によって Oracle 11g Oracle 10g Oracle9i RAC(Real Application Clusters) と OCFS(Oracle クラスタ ファイル システム ) でさまざまなオペレーティング システムの使用が認定されています これらの認定により EMC と Oracle のテクノロジーが確実に連携し お客様側で問題が発生したとしても完全にサポートされることが保証されます EMC には Oracle と緊密に連携するパートナー エンジニア グループがあります EMC エンジニアは 新しいバージョンの Oracle ソフトウェアを CLARiX ストレージ システムに接続されているさまざまな種類のサーバ上でテストします これらのラボでは SnapView や MirrorView などの CLARiX 機能を最新の Oralce ソフトウェアに統合する方法について開発しています EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 7

8 CLARiX ストレージに対する Oracle データベース設計に関する考慮事項 ストレージ システムの Oracle データベース ファイルを設定するには データベースの論理的なデータ レイアウト およびデータの使用パターンについて具体的によく理解する必要があります たとえば 次の点について考えます データベースの論理レイアウトおよびパフォーマンス アプリケーションおよびパフォーマンス Oracle I/O 構造 REDO ログ Oracle インスタンス パラメータ バックアップこのセクションでは これらの考慮事項について順番に説明します 魔法の弾丸 シンドロームに対応 このホワイト ペーパーで取り上げるアプローチについて 非技術系スタッフは次のような疑問を持つ可能性があります このホワイト ペーパーで扱っているのはストレージ システムに関する推奨事項なのに なぜ データベース設計について考えなければならないのか? ストレージ システムは データベースのパフォーマンスの問題を解消する 魔法の弾丸 ( 特効薬 ) として考えられています そうは言っても 結局のところ 重要なのは設計なのです 付録:DBチューニングの基本ステップ には Oracleが推奨するチューニング手順が記載されています 手順 8 では ストレージ システムをチューニングしています ソフトウェア レイヤーのチューニングの重要性に関する疑問はすべて Oracle 独自の推奨事項によって解消されます チューニング プロセスは レスポンス タイムが悪い というユーザーの不満の声があがってから開始するものではありません 通常 最も効果的なチューニング テクノロジーのいくつかは 不満が出てから使用するのでは遅すぎます この時点で アプリケーションの設計を完全に変更するつもりがなければ メモリを割り当て直し I/Oをチューニングしても ほんのわずかしかパフォーマンスは向上しません 1 また ハードウェアを追加してもシステムのパフォーマンスが向上することはありません 設計が不十分なシステムでは ハードウェアをいくら割り当てたとしても パフォーマンスは良くならないのです 2 そこで まず最初に アプリケーション設計がストレージ システムのパフォーマンスにどのような影響を与えるか ということについて説明します データベースの論理レイアウトおよびパフォーマンス 使用率の高いテーブルが I/O 要件を処理できるストレージ上に確実に配置されるようにする必要があります 重要なのはスキーマ つまり どのテーブルが一斉にアクセスされるかを把握することです これにより ディスク上の物理レイアウトが決まるからです 図 1 では 具体例を簡単な形で示しています 4 つのテーブルが一連のスピンドルを共有しており これらすべてのテーブルがサンプル SQL ステートメントで幅広く使用されているため ディスク競合が発生しています 1 Oracle8i Tuning Release パーツ番号 A Oracle9i Database Performance Planning Release 2 (9.2) パーツ番号 A EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 8

9 SQL:SELECT FirstName, LastName, Acctnum, Balance FROM Users INNER JOIN Accounts ON (Users.Acctnum = Accounts.Acctnum) WHERE Balance > 0 ORDER BY Balance 図 1: ディスク競合の例 データベース レイアウトで重要なのは I/O のインタラクションがファイル レベルではなくテーブル レベルであるという点です したがって テーブルとインデックスの関係を理解することが大事です 物理メディアにテーブルを配置する場合 一般的には 同時にアクセスするオブジェクトは別々の物理スピンドルに配置する必要があります 図 1 では 1 つのクエリーが 2 つのテーブルで構成されています 両方のテーブルを同じディスクに置くと 読み取り要求によって ディスク ヘッドがディスク上の 2 か所のロケール間をシークするようになります CLARiX RAID ドライバはディスクのエレベータ アルゴリズムを利用して できるだけ効率的にディスク アクセスを実行できるようにしますが やはり こうした競合は避けることをお勧めします もちろん 例外もあります テーブルおよびインデックスが小さく 頻繁に参照され さらに SGA( システム グローバル エリア ) とサーバ メモリが十分に確保されている場合は インデックスがメモリにキャッシュされるので ディスク アクセスが問題になることはありません 推奨 : 同時にアクセスされるオブジェクトは 異なる物理ドライブに配置されないようにする必要があります ここで説明するオブジェクトには インデックス テーブル TEMP テーブル RBS( ロールバック セグメント ) およびログが含まれます もちろん 例外もあります テーブルおよびインデックスが小さく 頻繁に参照され さらに SGA( システム グローバル エリア ) とサーバ メモリが十分に確保されている場合は インデックスがメモリにキャッシュされ ディスク アクセスが問題になることはありません Oracle OFA および特殊領域とテーブル Oracle には OFA(Optimal Flexible Architecture) というガイドラインがあり これにはできる限り従う必要があります ディスク上の大量のデータを整理する目的は デバイスのボトルネックとパフォーマンスの低下を避けることです OFA では 以下のコンポーネントを切り離すことを推奨しています DATA テーブル INDX テーブル ( インデックス ) DATA に対応 RBS( ロールバック セグメント ) EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 9

10 REDO ログ TEMP SYSTEM SYSAUX(10g の新機能 ) フラッシュ リカバリ領域 (10g の新機能 ) ただし このガイドラインは 使用されているストレージの種類に合わせて調整されます ストライプ構成 ( ホストまたはアレイ ベースのストライピング ) の場合は 次の例外が適用されます ソートの大部分がメモリ内で実行される場合 RBS と TEMP は共存できる (SORT_AREA_SIZE を最適化し ロールバックおよび一時セグメントへの継続的な同時書き込みがないことを確認します ) 環境のほとんどで SYSTEM と RBS または TEMP を共有できる インデックスとテーブルが共存できる場合がある ここでは インデックスとテーブルが ( テーブル スキャン時のように ) 同時にアクセスされると仮定します ただし OLTP 環境では インデックスがメモリ内に保持されない場合 結果としてパフォーマンスが許容範囲外まで低下する可能性があります パフォーマンスへのアプリケーションの種類の影響 アプリケーションは OLTP( オンライン トランザクション処理 ) と DSS( 意思決定支援システム ) の 2 つのカテゴリに大きく分けられます これらのカテゴリによって ストレージに便利にアプローチできるようになりますが 市販の RDBMS には両カテゴリのアプリケーションが含まれています 問題はどちらの I/O タイプに合わせて最適化するか ということです このホワイト ペーパーでは OLTP または DSS のワークロードに基づいた推奨事項を示します ご使用のアプリケーションが どちらの I/O タイプにより適しているかを判断するには 次のガイドラインを参考にしてください 標準の OLTP アプリケーションの特徴ユーザーの観点から見た場合の OLTP アプリケーションの特徴を次に示します トランザクションあたりの読み取り / 更新に対するデータ量 ( テキスト フィールドのページなど ) が少ない トランザクション ( ユーザー トランザクション ) あたりのレスポンス タイムが短い ( 通常は秒単位 ) ユーザー接続数が多い (10~1,000) データベースのデータが最新でなければならない したがって 可用性が重要代表的な OLTP アプリケーションには 受注管理 アカウント更新 保険 行政関連のフォームがあります OLTP I/O の標準のプロファイルストレージ システムの観点から見た場合の OLTP アプリケーションの I/O プロファイルを次に示します I/O サイズが小さい ( 通常は 8 KB 未満 ) I/O アクセス ( データ テーブルおよびインデックス ) がほぼランダム ワークロードにおけるランダム書き込みの割合が 30% を超える EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 10

11 定期チェックポイントによって ディスク上の DB を周期的な書き込みバーストと同期させる REDO ログ デバイスが 集中的なシーケンシャル書き込みのアクティビティによって非常にアクティブになり得る たまに発生するバックアップ ワークロードが ( 通常はシーケンシャルで I/O サイズが大きい ) 実際のアプリケーション プロファイルとまったく異なる パフォーマンスの影響 OLTP ワークロードは 高速アクセス時間 / 低レーテンシーのドライブからメリットを得られます これにより ランダム読み取りだけでなく キャッシュからのランダム書き込みのフラッシュが高速になり ストレージ システムでより多くのロードを処理できます ランダム性が高いため ストライプ RAID ソリューションが必須となります RAID 5 よりも RAID 1/0 の方がディスクに対する書き込みロードが少ないため OLTP に適しています また より迅速にキャッシュからのランダム書き込みをフラッシュできます 読み取りについても ほぼ同じことが言えます (10 ページの シーケンシャルまたはランダム I/O セクションを参照 ) 標準 DSS アプリケーションの特徴エンド ユーザーの観点から見た場合の DSS アプリケーションの特徴を次に示します データの更新がまったく ( またはほとんど ) ない 大量のデータ (10~100 行のレポート ) を取得するためのクエリーが複雑で 多数の異なるタイプやレコードが関連している クエリーの経過時間の単位は複雑さに応じて異なる ( 分 ~ 時間 ) データの古さは時間または日数で測定され 更新はバッチ ジョブとして適用される 出力データには ソートまたはグループ化されたデータ量総計 ( 合計 ) が含まれる 取得データのファイルが大きい ( 地理データベースなど ) ことがある DSS I/O の標準のプロファイルストレージ システムの観点から見た場合の DSS アプリケーションの I/O プロファイルを次に示します I/O サイズが大きい ( 通常は 16~512 KB) データ / インデックスを読み取る複数のシーケンシャル ストリーム クエリーの実行中 重要な書き込みアクティビティが 一時 DB ストレージに対して実行される 定期的なバッチ更新のワークロードが 実際のアプリケーションのワークロードと異なる ログ デバイスおよびチェックポイントはバッチ更新中にのみ関連する パフォーマンスの影響広帯域幅を実現するにはストライプ RAID タイプが必要です ドライブのシーケンシャル アクセスを最大化する必要があるため 同時アクセス テーブルを切り離すことが重要です また 強制フラッシュによって RAID 5 ストライプ (MR3) 書き込みを行えなくなる場合があるため キャッシュ管理も大切です RAID 5 は DSS にとってかなり効果的です ソート アクティビティのため 高速で かつ大きな TEMP 領域 ( ストライプ RAID を使用 ) が必要です EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 11

12 シーケンシャルまたはランダム I/O データベース アクセス パターンの中には OLTP または DSS にきちんと適応しないものがあります この場合 ストレージ システム パフォーマンスに影響する主な特性は I/O アクセスのランダム性になります ランダム書き込み動作は 特に RAID 5 では シーケンシャル書き込みよりもキャッシュ リソースに対してより大きなストレスをもたらします ランダム読み取りは 各テーブルのスピンドル つまり RAID 1/0 またはより大きな RAID 5 グループからメリットを得られます どちらにおいても 高速ドライブが役に立ちますが ランダム アクセス パターンの方がその効果がはっきり現れます シーケンシャル I/O は ランダム I/O ほどキャッシュに対するストレスは大きくありません ディスク オペレーションを効率よく行うためにシーケンシャル要求を大きな転送にバンドルできるからです 実際のところ シーケンシャル書き込みの処理は RAID 1/0 より RAID 5 の方がうまく行えます シーケンシャル読み取りについては いずれの RAID タイプでも効果的にプリフェッチできます ランダム更新の例を次に示します クライアント アカウント バランスの更新 インベントリ トラッキング アカウンティングシーケンシャル I/O の例を次に示します ユーザーの追加など テーブルへのあらゆるタイプの累積的追加 後の分析で使用するリアルタイム データの追加 ファイルのバックアップアクセス パターンのランダム性によって テーブルにインデックスを設定するかどうかなどの Oracle の設計や テーブルに導入する RAID タイプが決まります I/O プロファイルの決定 DBAが既存のデータベースのデータを新しいシステムに移行する必要があるとします このような場合は 実験に基づいた分析を行うことができます 現在のストレージがCLARiXシステムの場合 I/Oを特徴づけるツールとして最適なのはNavisphere Analyzerです Symmetrix 環境では Workload Analyzerが最適です Oracle 10g よりも前のバージョンでは utlbstat/utlestat スクリプト 3 を使用して 長いテーブル スキャンまたは短いテーブル スキャンがレポートされている report.txt と呼ばれるファイルを出力できます また Oracle 10g 以降では AWR(Automatic Workload Repository) を使って データベース エンジンのより包括的なパフォーマンス統計を収集できます 一時パターンおよびピーク アクティビティ毎日の受領書や週間レポートなど トランザクション バッチ処理を計画します これにより サービスでスパイクを引き起こすことがあります このスパイクは ファイル システム レベルおよびグローバルの両方で発生します したがって データベース バッファやストレージ システム キャッシュなどのグローバル リソースには スパイクに対応するためのリザーブ容量が必要です 3 開始する場合は $ORACLE_HOME/rdbms/admin/utlbstat.sql 終了する場合は utlestat.sql EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 12

13 また ピーク アクティビティも 予期可能なイベントによって引き起こされます 計画対象のイベントには 食事時間 スケジュールされたイベント 金曜日 給料日 祝日など多忙が予想される日などが含まれます Oracle I/O 構造 このホワイト ペーパーで説明するパフォーマンス上のトレードオフについては Oracle の I/O 構造が分かっていればよく理解できます Oracle の構造は データベース エンジンの書き込み先である一連のバッファを使用します これらのバッファは SGA( システム グローバル エリア ) に存在し この SGA はホストの RAM に存在します Oracle は このバッファを頻繁に使用して I/O を最適化します これにより 良好なパフォーマンスを得るには RDBMS ホストに RAM および仮想メモリが大量に必要であるという重要な事実が浮き彫りになっています Oracle のプロセスはこれらのバッファ上で動作し raw パーティションまたはファイル システムのいずれかで実装されているファイルの読み取りおよび書き込みを行います ( 図 2) 図 2:Oracle I/O の構造 Oracle では 分割統治法を使用してストレージのアクセスを並列化します データベースには さまざまな機能に対して メモリ内の個別の SGA バッファ そのバッファをディスクにフラッシュするための個別のプロセス および I/O を行う個別のテーブルまたはファイルが用意されています さらに 各プロセス タイプの複数インスタンスを実装するほか 非同期 I/O を使用することで 同時性を実現できます 最高速度で I/O を実行するためのリソースを Oracle プロセスに必ず確保するようにしてください データ テーブルの I/O データベース上で変更または要求が行われると Oralceは そのバッファを手段として使用し 読み取りおよび書き込みのパフォーマンスを最適化します たとえば 先行読み取りを実行し 必要になるであろうデータをデータ バッファに配置します また メモリ内データ バッファでデータが置かれている場所で ライト バックも使用します トランザクションは継続され EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 13

14 ディスク I/O の完了を待たずに次のトランザクションに進みます 4 DBWR プロセスは バッファで示されている読み取り 書き込み および先行読み取り動作を実行します DBWR I/O の特性 ( 大 / 小ブロック ランダム またはシーケンシャル ) の大部分は アプリケーションによって決まります ( パフォーマンスへのアプリケーションの種類の影響 セクションを参照 ) REDO ログの I/O REDO ログ ( トランザクション ログまたはオンライン ログとも呼ばれます ) は 要するに データベースの更新タスクを実行するために用意されている Oralce の手段で Oracle が行おうとしている変更が記録されます テーブルへの実際の変更は 後から行われます 簡単な変更メモを作成する方が実際に変更を行うよりも速いため 次のタスクに進む前に ログ エントリが作成され そのログはディスクに確実に書き込まれます 変更テーブル ページの書き込みは 後で DBWR がバックグラウンドのバルク ダーティー ページのフラッシュとして行います その際 データベース トランザクションのコミットを妨ぐことはありません REDO ログの I/O はシーケンシャルで かつ同期的です つまり それぞれのオペレーションが 他のオペレーションが開始する前に完了していなければなりません REDO ログは 512 バイトの倍数単位の小さなチャンクで書き込まれます なお このログはデータベースに対する変更をトラッキングするため 読み取り専用のアプリケーションでは REDO ログは使用されません LGWR プロセスは REDO ログ オペレーションを実行します 通常 オンライン REDO ログ ファイルはいっぱいになるまで つまり LGWR が他の REDO ログ ファイルに切り替わるまで書き込まれます ARCHIVELOG モードが設定されている場合 いっぱいになった REDO ログ ファイルは 定義されている場所にアーカイブされます アーカイブされた REDO ログ ファイルは 現在の REDO ログ ファイルがいっぱいになったときに再利用できます ARCHIVELOG モードが設定されていない場合 いっぱいになったこのログ ファイルは再利用可能な状態に設定されます 再利用されたら 前の REDO ログ レコードのコンテンツは上書きされ 失われます 再利用されるのを待機しているログ ファイルには オフラインのタグが設定されます REDO ログ サブシステムのパフォーマンスは そのサブセクションを保証するため重要です ( REDO ログ を参照 ) アーカイブの I/O ARCHプロセスはオプションの機能で 現在オフラインになっているREDOログをバックアップします 前回のデータベース同期以降に書き込まれたREDOログのバックアップ ( チェックポイントとして知られています ) を使用すると 致命的な障害が発生した場合にデータベースを再構築できます これは データベースのリモート コピーまたはオフラインのバックアップを同期する際にも使用できます 詳細については REDOログ セクションを参照してください データベース ブロック サイズ (DB_BLOCK_SIZE) DB_BLOCK_SIZE の値は Oracle I/O の効率性にとっては非常に重要で これにより データベースが行う変更の増分単位が決まります 通常は このパラメータは OLTP アプリケーションの場合は小さな値が DSS アプリケーションの場合はできる限り大きな値が設定されます その目的は 変更が少ない場合は データの交換がほとんど行われないようにすることです 大きなオ 4 Oracle がライト バックを使用してデータベースの整合性を維持する方法については REDO ログ セクションを参照してください EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 14

15 ペレーションの場合は I/O を大きくして数を減らすようにするとより効率的です これにより ストレージ システムに対するより大きな要求に 大きなブロックを結合できます 推奨 :CLARiX のキャッシュ ページ サイズは Oracle の DB_BLOCK_SIZE と同じ値に設定する必要があります Oracle と CLARiX では DB_BLOCK_SIZE をファイル システム ブロック サイズと同じ値にすることを推奨しています OS のページ サイズがファイル システムのブロック サイズよりも小さい場合 またはファイル システムが使用されていない場合 慎重な DBA であれば DB_BLOCK_SIZE を OS のページ サイズに設定するでしょう ファイル システムのブロック サイズが大きいのに対して Oracle のブロック サイズが小さいと データが必要以上に取得されるため ファイル システムのリソースが無駄になります しかし Oracle のブロック サイズが大きすぎると 意図しないプリフェッチが行われてしまう可能性があります このプリフェッチは ファイル システム ( 使用されている場合 ) またはストレージ システム レベルで発生します たとえば データベース ブロック サイズがファイル システム ブロック サイズの 2 倍の場合 このデータベースでは ファイル システムから 2 つの要求が必要となります これにより 不必要なプリフェッチがファイル システムで発生し ストレージ システム リソースが無駄になります REDO ログ 前述したように REDO ログは Oracle のスクラッチ パッドのことで そこでは Oracle が行おうとしている変更が記録されます REDO ログを実装する場合は ログ自体のストレージとアーカイブ ストレージの 2 つの側面から考えていく必要があります REDO ログに関する考慮事項 Oracleではアトミック性を確保する必要があるため REDOログは同期的に書き込まれます つまり 物理メディアへの書き込みオペレーションが完了するまで データベースの処理はどの書き込みからも続行されません これは REDOログのコンテンツがデータベースのリカバリに非常に重要だからです このコンテンツでは 整合性および安全性が確保されていなければなりません ライトスルー ファイル システムファイル システムのライト キャッシュをバイパスできない場合は ファイル システムを使用して REDO ログ ファイルを保持するべきではありません 5 処理を続行するには その前に REDO ログの書き込みを永続的に保存する必要があります ライトスルー ストレージ システム障害発生時におけるライト キャッシュのデータの一貫性がライト キャッシュ スキームによって保証されない限り ストレージ システムではライト キャッシュを使用するべきではありません 障害発生時こそが まさにライト キャッシュ データをディスクに格納する最適な状況です 6 システムによっては 発生した障害が致命的でなくてもログを保護できないことがあります たとえば LSI E シリーズや HP StorageWorks EVA などのシステムでは キャッシュ 5 サーバに致命的な障害が発生した場合 物理メディアにコミットされていると Oracle が見なしたデータが失われることがあります 6 障害が発生した場合 すべての CLARiX および Symmetrix アレイでディスク上にキャッシュが格納されます EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 15

16 に対してミラーされていない書き込みを行うことが可能です この場合 LUN トレスパスがデータベース破損につながることがあります OFA および REDO ログのデバイスログ書き込みプロセスでは 512 バイトの倍数のブロック単位でシーケンシャル書き込みが行われるため ログ LUN にとってライト キャッシュは非常に効果的です OFA では 他の I/O で使用されていないドライブにオンライン ログを置くことを提案していますが ストレージ システムが CLARiX ファイバ チャネル システムの場合 これは現実的ではありません なぜでしょう? ライト キャッシュによって ホスト書き込みがディスク アクセスから切り離されます 重要なのは このライト キャッシュはキャッシュが書き込みでいっぱいになるのを防ぐために ログ書き込みをすばやくフラッシュできるという点です ログ書き込みはシーケンシャルです シーケンシャル書き込みでは ライト キャッシュは最適な速度でフラッシュできます したがって 共有 RAID 5 グループでも Oracle LGWR の速度に対応できます ドライブが大きくなるほど Oracle ログ ( 数ギガビット ) のみに使用される 複数のスピンドルを受け入れ可能なユーザーが少なくなります FLARE 24 に導入されたNQM(Navisphere QoS Manager) を使用すると 一連の個別のスピンドルをREDOログのサービスI/O 専用にする必要がなくなります 同じRAIDグループから複数の LUNを作成できるので スピンドルに必要以上の容量があっても無駄にはなりません また NQMによって 指定したサービス レベルをREDOログLUN 上で維持できます これにより 同じRAIDグループ内の他のLUNに他のアプリケーションがアクセスしていても 必要なパフォーマンスのレベルをデータベースから確保できます 共有 RAIDグループのLUNは スピンドルが過負荷にならないように 帯域幅およびスループットの要件が制限されているアプリケーションに割り当てることを推奨します NQMの使用については ホワイト ペーパー Using Navisphere QoS Manager in Oracle Database Deployments を参照してください このホワイト ペーパーはPowerlink から入手できます REDO ログ アーカイブを使用するかどうかは Oralce の {NO}ARCHIVELOG 設定によって決まります 本番環境では 通常は ARCHIVELOG モードが設定されています REDO ログ アーカイブは REDO ログよりもはるかに大きなブロックでシーケンシャルに書き込まれます 大きな I/O サイズは古い (FC シリーズ ) ストレージ システムのファクタで これによりライト キャッシュ帯域幅が制限されます これらの古いシステムで実行されている書き込み集中型データベースは アーカイブ書き込みのライト キャッシュをバイパスすることによってメリットを得られます (CX および CX3 シリーズのシステムは格段に優れた帯域幅を提供しているため この処理は通常は必要ありません ) アーカイブ書き込み用キャッシュをバイパスする CLARiX ライト キャッシュ アーキテクチャの柔軟性を利用することで 通常はアーカイブ ログ アクティビティでいっぱいのキャッシュ ページを解放できます これらの書き込みがキャッシュをバイパスできると より多くのページが本番 I/O 用に解放されます これを制御するには CLARiX のライト アサイド設定を使用します アーカイブ LUN のライト アサイド サイズは ログのバックアップで使用される I/O よりも小さいサイズに設定します 7 たとえば アーカイブ プロセスが 512 KB の書き込みを実行する場合 ライト アサイド サイズは 1,023 ブロック (511.5 KB) に設定します また アーカイブ LUN のライト キャッシュをオフにすることもできます 7 ライト アサイドの詳細については ホワイト ペーパー EMC CLARiiON Best Practices for Fibre Channel Storage を参照してください EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 16

17 オフライン ログがオンラインになる前にログ アーカイブ プロセスを確実に完了させるには キャッシュされていない書き込みが効率的に実行されるようにします この手法には複数の方法でアプローチできます 最初のアプローチでは アーカイブ LUN 上の RAID ストライプに合わせて I/O を割り当てる必要があります この場合 アーカイブ デバイスは 非常に効率的なストライプ書き込み ( 修正 RAID 3 つまり MR3) を実行する RAID 5 になります MR3 の調整および最適化については ホワイト ペーパー EMC CLARiiON Best Practices for Fibre Channel Storage を参照してください 2 番目のアプローチは ファイル システムによって調整済みの書き込みが排除されているか またはアーカイブ プロセスとファイル システムの組み合わせによって十分なサイズの I/O が排除され パリティ ストライプがいっぱいになっていることが前提となっています この場合 アーカイブは ミラーされたストレージ つまり RAID 1 または RAID 1/0 のいずれかに配置されている必要があります ディスク アクティビティは 最適化された RAID 5 のアクティビティよりも大きくなるにもかかわらず 効率的です アーカイブ プロセスに対する I/O が非常に小さい場合は ライト アサイド パラメータでキャッシュをバイパスするよりも ライト キャッシュをオフにする方がよいでしょう 複数ログ デバイスの使用大規模システムの多くが複数のログを使用しています これらのログは 通常 LGWR プロセスからアクセスされた順に番号が付けられており また グループに分けられています ( 図 3) 理想的には ログ グループは アクティブ ログ用および非アクティブ ログ用の 2 つの専用 RAID グループに置かれます なお 非アクティブ ログ用のグループはアーカイブされています 図 3: 複数ログのレイアウト オンライン ログへの書き込み オフライン ログからの読み取り アーカイブへの書き込みの 3 つのログ オペレーションすべてが シーケンシャル I/O であることに注意してください RAID グループをこれらのデバイス専用にすると ディスクの能力を最大限に使用して シーケンシャル I/O が実行されます その結果 ログやアーカイブへの書き込みはキャッシュから即座にフラッシュされるので データベース書き込みの際の余分なオーバーヘッドを回避できます 書き込みの負荷が高いシステムでこの手法を利用すると 書き込みパフォーマンス全体を向上させるのに役立ちます ( 図 4) EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 17

18 図 4:ARCHIVELOG モードがアクティブの場合の Oracle ログ I/O 構成 推奨 : 大規模なシステム (40 を超える数のドライブを使用中 ) で 書き込みの負荷が大きい ( すべてのホスト トラフィックの 30% 以上 ) 場合には オンライン オフライン アーカイブ ログのデバイスは別のドライブ セットに展開する必要があります ディスク グループがストライプ RAID である限り パフォーマンスに重要な影響を与えるような他のデータとアーカイブ ドライブを共有しても問題ありません OFA を小規模システムに適応させる Oracle データベースは サイズも I/O 要件も適度に設定することが可能です ドライブ数が少ないシステムでは REDO ログのデータが 他のファイルと共存しなければならないことがあります この場合 ストレージ システムが REDO ログを効果的にキャッシュできることが重要です REDO ログ書き込みはライト キャッシュにヒットするため REDO ログ オペレーションはキャッシュ速度で実行されます Oracle が小規模展開されている場合 このロードのみがライト キャッシュに負荷をかけているとは考えにくいのですが ストレージ システムが 他の書き込み集中型プロセスと共有されている場合は キャッシュが飽和状態になることを予測できなければなりません キャッシュが飽和状態になると 強制的にフラッシュされ すべての I/O の速度が遅くなるほか REDO ログのパフォーマンスが低下します キャッシュが飽和状態であることを検出するには Navisphere Analyzer でシステムをモニターするのが最適です Oracle を小規模なストレージ システム (20 ドライブ未満 ) で効果的に展開するには できるだけ多くのドライブを RDBMS ファイルで使用できるように ( これにより ファイルを共有する必要が生じても ) ディスク グループを区分化します このケースに適しているのは アクセスが少ないホスト ( 部門ファイル サーバなど ) およびデータベース間でドライブを共有できる metalun です たとえば metalun を使用しなければ 20 のディスクを備えたシステムには 通常 4 つの RAID グループが含まれることになり 通常の展開方式 (5 ディスク グループ ) では LUN がアクセスできるディスク数は最大で 5 つです metalun を使用すると 各ディスク グループが区分化され グループごとに 1 つの LUN がホストの metalun に割り当てられます metalun ではそれぞれ最大 20 のドライブを使用でき I/O バーストに対応します EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 18

19 共有環境で REDO ログをアーカイブするには ストレージ システム キャッシュのダーティー ページをモニターする必要があります ログおよびデータ テーブルがディスクを共有している場合 アーカイブ ログへの書き込みによって強制フラッシュが発生すると ドライブに対する他の要求が影響を受けます 強制フラッシュを行わなくてもアーカイブ プロセスに対応できるだけのドライブがある場合 ホストは これらのドライブにコンカレント I/O を移動できます また アーカイブ デバイスに対してライト アサイドを使用するかライト キャッシュを完全にオフにすると 本番 I/O のキャッシュ ページが解放されます 推奨 : 小規模なシステム ( ドライブの数が 20 より少ない ) の場合 もっともビジーなテーブルをできるだけ多くのドライブに広げて バーストを吸収する必要があります ライト キャッシュはドライブ アクセスをバッファするので データをログ デバイスと共有しても問題ありません metalun を使用して ディスク ドライブを最大限に使用できるようにしてください インスタンス パラメータ Oracle データベース インスタンスには ストレージとの対話を制御するためのパラメータがあります ( 表 1) データベースを設定する場合は ストレージ構成を考慮してください これらのパラメータは ストレージに逆らって動作するのではなく ストレージとともに動作します たとえば 表 2 では 例で使用されている RAID グループのストライプ サイズに合わせてパラメータが調整されています これらのパラメータは 通常は $ORACLE_HOME/dbs/init.ora または init.ora ファイルにあります Oracle インスタンス パラメータが含まれる SQLPLUS プロンプト (8i システムの場合は svrmgr プロンプト ) レポートから show parameters コマンドを使用してください 表 1: 重要な Oracle 設定とデフォルト値 パラメータ 設定単位 標準の デフォ ルト DB_BLOCK_SIZE バイト 2048 説明および推奨事項 ファイル システムのブロック サイズと同じで かつ OS のページ サイズ以上 8 DB_BLOCK_CHECKPOINT _ WRITE_BATCH DB_FILE_MULTIBLOCK_ READ_COUNT DB_BLOCK_SIZE 8 DB_BLOCK_SIZE 8 チェックポイントの書き込みの書き込みチャンク サイズ CLARiX LUNストライプ エレメント サイズからCLARiXストライプ サイズまでの値を設定 ただし OSの最大 I/Oサイズを超えないようにする テーブルおよびインデックス完全スキャン用の読み取りチャンク サイズ CLARiX LUN ストライプ エレメント サイズから CLARiXストライプ サイズまでの値を設定 ただし OSの最大 I/Oサイズを超えないようにする 8 DB_BLOCK_SIZE の詳細については 14 ページの アーカイブの I/O を参照してください EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 19

20 HASH_MULTIBLOCK_IO_ COUNT DB_BLOCK_SIZE 8 USE_DIRECT_IO ブール値 N/A ハッシュ結合のI/Oチャンク サイズ CLARiX LUNストライプ エレメント サイズからCLARiXストライプ サイズまでの値を設定 ただし OSの最大 I/Oサイズを超えないようにする ファイル システムをバイパスできる場所 ( 使用できる場合 ) パラメータのサイズ設定 (CLARiX ストライプ エレメント サイズからストライプ サイズまで ) は アプリケーションの種類に多少依存します OLTP の場合は ストライプ エレメント サイズを使用します DSS の場合は ストライプ サイズを使用します また metalun を使用する場合は metalun のストライプ エレメント サイズではなく べース LUN のストライプ エレメント サイズを参考にします インスタンス パラメータの例表 2 は インスタンス パラメータの設定を示しています この表で示すインスタンス パラメータは 次の構成に基づいています Windows 2000 ホストで NTFS ファイル システムにテーブルを展開 ( ファイル システムでは 4 KB ブロック サイズを使用 ) データ LUN の場合は 64 KB(128 ブロック ) ストライプ エレメント サイズ 表 2:OLTP 構成のインスタンス パラメータ パラメータ 値 コメント DB_BLOCK_SIZE 4096 ファイル システムのブロック サイズ DB_BLOCK_CHECKPOINT_ WRITE_BATCH 16 16*4096 = 64 KB べースLUNストライプ エレメント サイズ DB_FILE_MULTIBLOCK_READ_ COUNT 16 16*4096 = 64 KB べースLUNストライプ エレメント サイズ HASH_MULTIBLOCK_IO_COUNT 16 16*4096 = 64 KB べースLUNストライプ エレメント サイズ USE_DIRECT_I/O 未使用 推奨 :Oracle の先行読み取りサイズおよび書き込みクラスタ サイズが 基本の LUN RAID ストライプ サイズまたはストライプ エレメント サイズと必ず対応ようにしてください データベースのバックアップ データベースのバックアップは 2 通りの方法で実行できます 1 つはコールド バックアップといい データベースをシャットダウンしてバックアップを行います もう 1 つはホット バックアップで データベースを実行したままバックアップ モードでバックアップを行います 両オペレーションともストレージ サブシステムの設計に影響するので重要です したがって この両方について検討していきます システムを設計する場合は バックアップによって発生する時間および I/O ロードを考慮し ホット バックアップ中に十分なパフォーマンスが確保されるようにします EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 20

21 Oracle バックアップの詳細については Oracle ドキュメント User-Managed Backup and Recovery Guide を参照してください コールド バックアップ コールド バックアップでは データベースがシャットダウンされます これと並行して データベースを構成する Oracle データベース ファイルをバックアップ メディアにコピーできます Oracle RMAN は使用できません Oracle RMAN では データベースを実行しておく必要があるからです データベースが停止するため パフォーマンスの要件を予測することができます たとえば バックアップ対象の LUN の数に気をつけたり 読み取りアクセス用の総帯域幅を計算したりします この総帯域幅をストレージ システム自体 バックアップ ホスト およびメディアの最大帯域幅と比較して どこがボトルネックになっているかを特定します 読み取りアクセスのブロックは大きくなければなりません また このアクセスはシーケンシャルに実行される必要があります ホット バックアップ DBAは I/Oを停止せずにデータベースをバックアップする方法を見つけることが重要です Oracleでは ホット バックアップ モードを使用できます このホット バックアップの詳細については 関連資料 セクションで紹介するホワイト ペーパー Oracle 9i with SnapView in SAN Environments または Oracle 10g with SnapView in SAN Environments を参照してください 以下にその特徴を簡単に示します データベースはログ可能モードで動作している必要がある ホット バックアップ モードが開始される データベースにチェックポイントが設定され SCN(System Change Number) が凍結される データベースへの変更が許可されている間にバックアップが完了し REDO ログのレコードが変更される バックアップが完了すると データベースはホット バックアップ モードでなくなり REDO ログが通常のログ モードに戻る SCN の凍結が解除され コミットされた変更すべてがデータベースに正しく反映される ホット バックアップ期間中に生成された REDO ログが データベース バックアップ ファイルとともに収集 アーカイブ および保存される また 制御ファイルのバックアップ コピーが REDO ログのアーカイブの完了後に作成される バックアップ期間中は データベースのこの部分に対するブックキーピングがさらに必要となるため データベースに対するアクティビティが多くなると REDO ログが急速に拡大します データベースがホット バックアップ モードのままの場合 トランザクションのレスポンス タイムに悪影響を与えます データベースによる I/O オペレーションはホット バックアップ中も行われています したがって コールド バックアップに比べると パフォーマンス要件を予測することが難しくなっています バックアップ プロセスにおける読み取りのシーケンシャル処理はデータベース アクティビティによって分割され 本番アプリケーションとバックアップ プロセスの両方の I/O が影響を受けます データベースを設計するときはパフォーマンス ヘッドルームを十分に考慮する必要があります または ホット バックアップは それほど処理が多くないときに実行するようにします EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 21

22 SnapView でのホット バックアップ CLARiX SnapView ソフトウェアの長所は ホット バックアップを実行する際のデータベース システムへの影響を抑えることができるという点です データベースをホット バックアップ モードにすると システムのオーバーヘッドに影響しますが このモードにする必要があるのは SnapView セッションを開始するのに必要な実行時間だけです また この処理はスクリプトに対応しており 非常に迅速に行われます ( この手順の詳細については 関連資料 セクションで紹介するホワイト ペーパー Oracle 9i with SnapView in SAN Environments または Oracle 10g with SnapView in SAN Environments を参照してください ) したがって ロックされているスキーマによるデータベース トランザクション レートへの影響を最小限に抑えられます スナップされたバックアップによるパフォーマンスへの影響 SnapView ではデータベース LUN のイメージが瞬時に作成され これらの LUN のコンテンツがバックアップされます データベースが変更されると スナップされたデータがいくつか COFW (copy on first write) と呼ばれるオペレーションで SnapView の保存先 LUN に移行します COFW オペレーションはチャンク単位で行われるため 本番ボリュームへの小さな書き込み (4 KB) が 結果的にはスナップ キャッシュ LUN への大きな書き込み ( 通常は 64 KB) となります ただし 本番ディスクのチャンク エリアをさらに変更した場合は この変更をコピーする必要はありません REDO ログおよびアーカイブのロードは SnapView 以外のホット バックアップよりも大幅に少なくなっています バックアップ プロセスのシーケンシャル処理は 引き続きディスク ドライブで競合するアプリケーション I/O の影響を受け ( データ読み取りのほとんどがスナップ保存先 LUN ではなく 本番 LUN から行われています ) これがバックアップのスピードに影響を及ぼします このため システムを設計するときは パフォーマンスのオーバーヘッドを考慮する必要があります あるいは 負荷の少ないときにバックアップを実行するようにします 本番システムと同時に実行される SnapView のオーバーヘッドは データベース テーブルへの書き込みボリュームによって決まります CLARiX パフォーマンス エンジニアリングからの予備データは 本番データの SnapView イメージの維持による影響は 5~15% であることを示しています この値は ディスクの競合がなく キャッシュが飽和状態になっていないことを前提としています 通常の本番ロードで CLARiX キャッシュが飽和状態に近い場合 COFW オペレーションで追加のロードが発生すると キャッシュ競合を引き起こし 進行中のオペレーションに影響を与える可能性があります 書き込み対象のテーブルに対する更新のローカル性は このロードに大きく 注意 :SnapView の保存領域に使用されるドライブは 本番データと共有されないようにしてください 影響します SnapView は COFW をチャンク単位で実行し そのチャンクに対する以降の書き込みでは 本番 LUN または SnapView 保存先 LUN に対する I/O を必要としません ビジー期間にバックアップを行う必要があり 本番 I/O への影響を最小限に抑えることが求められている場合は 他に影響しないバックアップについて検討します SnapView での他に影響しないバックアップ 他に影響しないバックアップの戦略は SnapView のクローンを考慮して設計できます クローン関係は SnapView のスナップショット関係とは異なります クローンが受け取るのは ホスト ボリュームへの書き込みのミラーです たとえば 本番ボリュームが 4 KB の書き込みを受け取ると クローンも同じように受け取ります 本番ボリュームがその 4 KB ブロックに書き込むと その書き込みはクローンにミラーされます COFW とは異なり すべての書き込みにクロ EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 22

23 ーンがコピーされます この処理は CMW(Clone Mirrored Write) と呼ばれます CMW によりライト キャッシュ上のロードが増え 最大 8 つのクローンを本番 LUN ごと および CMW ヒット ライト キャッシュごとに維持できます ただし バックアップが必要な場合は 本番運用中のロード追加が効果をもたらします 次の 2 通りの方法を使用して 他に影響しないバックアップを実行できます クローンをフラクチャして バックアップ先として使用する SnapView を使用して クローンのスナップショットを作成する以下のセクションでは これらの方法について説明します クローンをフラクチャして バックアップ先として使用するこの場合 データベースがホット バックアップ モードになり クローン ( バックアップ対象の各本番 LUN のクローン ) がフラクチャされます その後 データベースが通常の運用に戻ります SnapView スナップショット バックアップと比べると このアプローチにより バックアップ中の本番 LUN のロードが軽減されます まず BCV がフラクチャされるとすぐに CMW オペレーションが停止します 次に バックアップ読み取りが 本番スピンドルとは異なるスピンドルに対して実行されます ( クローンのベスト プラクティスでは クローンはミラー対象の LUN とは異なるディスクに配置されます ) バックアップ中 ライト キャッシュまたは本番ディスクへの影響はありません この方法の欠点は バックアップの完了時にクローンを再同期する必要があるという点です 再同期が完了するまで クローン上のデータベース イメージは一貫性のない状態です ただし 最大 8 つのクローンを LUN に関連づけることができるため 一貫性のあるオンライン ミラーを常に必要とするユーザーにも対応できます また これと似た方法として バックアップが行われるまで クローンをフラクチャしたままにしておくというものがあります クローンの再同期は バックアップ準備フェーズの一環として行われます クローンの再同期が完了したら データベースがホット バックアップ モードになり クローンがフラクチャされます このクローンは 次のバックアップまでフラクチャされたままです SnapView を使用して クローンのスナップショットを作成するこの場合 バックアップ対象のすべての LUN に対してクローン関係が存在します ただし バックアップのためにクローンがフラクチャされることはありません データベースがホット バックアップ モードになると SnapView によってクローンのスナップショットが作成されます その後 データベースが通常の運用に戻ります バックアップは このスナップショットに対して実行されます バックアップ読み取りアクティビティが影響を及ぼすのは クローンと SnapView キャッシュ ディスクだけなので 本番データに対してバックアップ関連の競合が発生することはありません ただし CMW アクティビティが本番およびクローン ディスク間に発生するため CMW とバックアップ読み取りの間でクローン ディスクの競合が発生します クローン ディスクの I/O ロードが大きくなると バックアップが本番データの応答性に影響を及ぼすことがあります クローンに対する CMW がライト キャッシュにヒットしますが クローン ディスク上のロードが余計にかかることで これらのディスクへのライト キャッシュのフラッシュが遅くなる可能性があります これにより Watermak または強制キャッシュ フラッシュが発生し システム パフォーマンス全体に影響を及ぼす場合があります この方法の長所は クローンの再同期が必要なく 有効なデータベース イメージが常にクローンに含まれるという点です EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 23

24 推奨 :RDBMS のパフォーマンスへの影響を最小限に抑えるには SnapView のクローンをバックアップ ソースとして使用してください パフォーマンスに関するその他の考慮事項 このセクションでは Oracle RDBMS を実装する際の考慮事項を ホストからストレージ システムに至るまで説明します ホスト OS に関する考慮事項 ファイル システムまたは raw パーティション ホスト ベースのスクリプト作成 (Plaid) MetaLUN CLARiX キャッシュ LU 配布 スピンドルおよびストライプ RAID レベルとパフォーマンス ディスク ホスト OS および HBA に関する考慮事項 このセクションでは Oracle データベースが ストレージ システムのパフォーマンス特性を活用できるようにチューニングする方法について 簡単に説明します 最大 I/O サイズ ほとんどのシステムに設定されているデフォルトの最大 I/O サイズは 64~128 KB です OLTP アプリケーションについてはこのサイズで十分ですが それでも このサイズが大きければ データベースのバックアップおよび REDO ログ アーカイブはそれなりのメリットを得られます CLARiX ストレージ システムにおける現実的な I/O サイズの目標値は 1 MB です DSS アプリケーションも I/O サイズが大きいと便利です ファイル システムの I/O サイズを増やすには 次の例に従ってパラメータを変更します Solaris ファイル システムの設定 : maxphys バイト単位で設定 maxcontig ブロック単位で設定 maxphys と同じ容量に設定 per-hdisk レベルでの AIX 設定 chdev を使用 : max_transfer バイト単位で設定 max_coalesce バイト単位で設定 VERITAS VXFS: vxio:vol maxio は 512 バイト単位で設定 2,048(1 MB) に設定する EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 24

25 推奨 :RAID 5 でのベスト パフォーマンスを得るには ファイル システムの最大 I/O サイズを 物理ボリュームおよび CLARiX LUN で使用するストライプ サイズと同じ値 またはその倍数に設定してください TEMP データベースファイル システムの最大物理サイズが増加すると TEMP データベースへの書き込みの帯域幅は 反直感的な動きをします 普通は 帯域幅が増えることを期待するでしょう しかし 最大物理サイズが CLARiX のライト アサイド サイズよりも大きい場合 TEMP への書き込みが大きいと キャッシュがバイパスされます シーケンシャル書き込みがファイル システムによって 1 つの大きな I/O に結合されると その書き込みはライト アサイド サイズに達することがあります その結果 TEMP への書き込み速度が遅くなります ライト アサイドがキャッシュをバイパスし ディスク I/O は キャッシュされた I/O よりも常に遅いからです さらに TEMP が再度読み取られるときに ファイル システムのバッファに要求されているデータがないと そのファイル システムは CLARiX ストレージ システムからデータを要求します ライト アサイドが使用されていると キャッシュにデータがないため 読み取り要求はディスクに移動してデータを取得しなければなりません すると データが CLARiX ライト キャッシュにある場合よりも読み取りが遅くなります その影響は実に顕著に現れます これを回避する手段は オペレーティング システムの柔軟性に応じて数通りあります TEMP ファイル システムを作成し 最大物理または最大連続設定を低く設定する LUN のライト アサイド サイズを増やして TEMP を持つファイル システムの最大連続サイズよりも大きくする raw デバイス上に TEMP データベースを作成する 配置ファイル システムがストライプ RAID LUN(RAID 0 RAID 1/0 RAID 5 RAID 3) に展開されている場合 RAID アルゴリズムを最大限に活用するには ファイル システムの書き込みを確実に配置します これにより レーテンシーを増加させる原因となる ディスクおよびストライプの境界部分を横切る処理が少なくなります ディスクおよびストライプの境界を横切る処理は RAID 5 などのパリティ RAID タイプでは特にコストがかかります たとえば 256 KB の CLARiX RAID 5 ストライプに書き込むとき 512 KB の I/O が誤って配置されていると 2 つの部分的なストライプ オペレーションが発生し パリティ読み取りおよび書き込みが必要になります 配置が適切だと 512 KB の I/O によって 2 つのストライプが満たされ RAID 5 ストライプをより効率的にディスクに書き込むことができます ( パリティ オペレーションは発生しません ) 配置 および配置に関する問題への対処方法の詳細については ホワイト ペーパー EMC CLARiiON Best Practices for Fibre Channel Storage を参照してください ファイル システムまたは raw パーティション Oracle の DBA には テーブルを raw パーティションまたはファイル システムのいずれかに実装できます ここでは それぞれの利点を紹介します EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 25

26 raw パーティション raw デバイスには パフォーマンスに関してファイル システムよりも優れた点が多数あります これらの理由から 本番データベースの多くが raw パーティションで実装されています raw パーティションの長所を以下に示します ファイル システムのキャッシュを回避する ファイル システムをキャッシュすると ホスト上の CPU サイクルに負担がかかり I/O が二重でバッファリングされるため無駄が多くなります Oracle SGA 専用のメモリをより多く使用して Oracle 独自のバッファ管理を行うとより効果的です ファイル システムのロックを回避する ファイル システムはファイルごとに書き込みを 1 つロックします これにより Oracle が独自のテーブルおよび行レベルのロックを使用して同時に処理できる I/O が遂次化されます ファイル システムのブロック サイズがない DB_BLOCK_SIZE で raw デバイスに書き込むことができます ファイル システムの多くに I/O サイズの上限があるのに対し raw パーティションには大きな I/O サイズを定義できる スナップが簡単で (SnapView 機能を使用 ) 一貫性のある状態を保つことができる これを実現するのに必要なのは データベースをホット バックアップ モードにするだけです ファイル システムを同期させる必要はありません raw パーティションの短所を以下に示します ファイル システム レベルの管理が用意されていない テーブルをバックアップ マシンに再ロードするには テーブルが配置されているパーティションのデバイスの状況や権限が 本番サーバ上のものとまったく同じである必要があり 同じでない場合 データベース エンジンがテーブルをロードできない ファイル システムファイル システムには OS レベルのキャッシュでのメリットがいくつかあります OS キャッシュからのブロックの再読み取りは非常に高速で ストレージ システムにかかるリード キャッシュの負荷を軽減します これは インデックスおよびテーブル全体をファイル システムにロードできる大量の (8 GB を超える )RAM でシステムが構成されている場合に便利です ファイル システムの長所を以下に示します 書き込みを結合できる これは シーケンシャル アクセス オペレーションで帯域幅を最大限にする際に便利です バックアップおよびバックアップ ホストからのマウントが容易 raw パーティションよりも管理が簡単で 分析ツールも豊富 ライト キャッシュをバイパスできない場合は OracleREDO ログでファイル システムを使用するべきではありません たとえば Solaris では Oracle は D_SYNC を使って REDO ログ ファイルを開き 物理メディアへのライトスルーを強制的に行います ファイル システムの短所を以下に示します 不必要な間接的な論理レイヤーがある ファイル システムのバッファリングでは バックアップを開始する前にファイル システムの同期を完了する必要がある EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 26

27 高度なファイル システム一部のファイル システムには パフォーマンスを向上させるためのアドバンス機能が用意されています XFS JFS VxFS などの高度なファイル システムは UFS ファイル システムよりも好まれています これらの高度なファイル システムでは 二重バッファリングが排除され ジャーナル処理およびパフォーマンスが向上しています 高度なファイル システムのダイレクト オプション一部の高度なファイル システムには ダイレクト I/O 機能が用意されています この機能を使用すると ファイル システム キャッシュがバイパスされます これにより 5 レベルのロックによる制限はあるものの パフォーマンスが向上します 一方 ダイレクト I/O オプションのファイル システムの長所 (Oracle メタデータのテーブルに対する 5 レベルの間接処理など ) については そのまま維持されます なお ダイレクト I/O を使用するときは Oralce システムの非同期 I/O を無効にする必要があります それには init.ora ファイルを次のように設定します disk_asynch_io=false 一部のサード パーティのファイル システムでは raw デバイス パフォーマンスの向上を目指し ファイル レベルでのロック排除と効率的な I/O モデルの両方が実現していることが主張されています ホスト ベースのスクリプト作成 (Plaid) 大規模なファイル システムを作成し 突発的に増加するランダム I/O を多数のドライブに分散させるには 多数の LUN から大きなファイル システムを作成する戦術が効果的です ただし やり過ぎはお勧めできません このアプローチによって 大きな I/O のパフォーマンスが低下することがあるからです (1 つの I/O が多数のドライブにわたる場合 ) Plaid に関する利点や問題点については ホワイト ペーパー EMC CLARiiON Best Practices for Fibre Channel Storage を参照してください Oracle の SAME ストレージを実装する際のエイジング哲学 SAME(Striping And Mirroring Everywhere) は CLARiX ストレージについて言えば コスト パフォーマンスに優れているとはいえません SAME の根底をなす基本的な主張は Oracle データベース ファイルに対する I/O をできるだけ多くの物理リソース ( ディスク I/O チャネルなど ) に均等に分散させ リソース アクセスの競合を最小限に抑えるというものです 最新の大容量ストレージ システムが使用されるようになり この概念は OFA に取って代わられました ホスト ベースのストライピングのガイドライン 1 つの RAID グループではサイズ的にファイル システムに対応できないとき あるいはランダム I/O パフォーマンスによって I/O を多数のドライブまたは両方のストレージ プロセッサに分散させる必要があるときは Plaid をお勧めします 適切な深さでストライプ Oracle では ホスト ベースのストライピングでのストライプの深さを 16 KB に抑えることを推奨していますが これはストレージ システムのキャッシュ機能を考慮していないため お勧めできません ホスト レベルのストライプの深さ ( ストライプ エレメント サイズ ) は CLARiX ストライプ サイズと同じか そのサイズの倍数にするようにします このアプローチは RAID 1/0 よりも RAID 5 ストライプの最適化において より多くのメリットをもたらしますが どちらの RAID タイプにも適用できます EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 27

28 たとえば 4 つの 4+1 RAID 5 LU があり ストライプ サイズが 256 KB であるとします ストライプの深さ (1 MB/4 LU= 256 KB) は各 CLARiX LU のストライプ サイズと一致するので Oracle のストライプ サイズは 1 MB になります metalun の使用 EMC CLARiiON Best Practices for Fibre Channel Storage ホワイト ペーパーで説明しているように metalun は 多数のディスク ドライブにわたる I/O バーストを分散させるのに効果的なツールです metalun を実装する場合は その前にパフォーマンスおよびデータ拡張の目標を考慮する必要があります たとえば 広帯域幅の DSS システムのパフォーマンスは 従来の RAID グループ ベースの LUN によって向上します テーブル間のディスク アクセスのフェンシングによりデバイスを効率的に動作させることができるからです metalun は さまざまなテーブルへのアクセスが突発的に増加したり予測不能だったりする場合のパフォーマンス維持に役立ちます たとえば Oralce データベース上の SAP などの大規模アプリケーションでは 展開前にビジーなテーブルやデータのやり取りが行われているテーブルを特定するのが非常に困難です この場合は metalun( ホスト Plaid) を使用するとよいでしょう これにより すべてのディスクが確実に均等にロードされるようになります Oracle などの RDBMS の設計に関する考慮事項を次に示します ディスク プーリング : 一連の RAID グループを 一連の共通 metalun をホストするセットに関連づけます データ フェンシング ログ デバイスの場所 metalun および従来の LUN は連携して Oracle データベースを効率よく展開できます たとえば ストレージ システムにクライアントが 1 つである 単一データベース サーバまたはクラスタに対するアプローチとして可能性があるのは 純粋な metalun データ ストレージに対するハイブリッド metalun およびログに対する従来の LUN です 純粋な metalun およびラウンドロビン ロギングこの設計では 少なくとも 3 つのディスク グループが作成され それぞれのディスク グループに データ テーブル RBS テーブル および TEMP テーブルのサブセットと 次のログのいずれかが含まれています オンライン ログ オフライン ログ アーカイブ ログ 1 つのディスク グループが常にログ書き込みを行う一方で 他の 2 つはアーカイブ読み込みとアーカイブ書き込みを行います 総アクティビティまたはアーカイブ アクティビティがディスク ドライブ全体に均等に分散され すべてのディスクがデータ (DBWR)I/O にかかわっています ( 図 5) EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 28

29 図 5: 純粋な metalun Oracle 実装の例 3 つのグループでは ディスク間のデータ I/O フェンシングが可能です テーブルとインデックス間の相互関係が分かっている場合は テーブルおよびインデックスは異なる metalun に配置する必要があります また 前の例には 異なる RAID タイプの RAID グループ セットが含まれています もちろん 複数の RAID タイプを使用するかどうかは任意ですが これを使用することで 複数 RAID セット設計の柔軟性が示されます metalun および従来のログ デバイスのハイブリッド使用 最大規模の書き込み集中型データベース以外では ログを個別のスピンドル上にデータから切り離して実装する必要はありません ライト キャッシュが LGWR プロセスをディスク フラッシュのレーテンシーから切り離します また これらのドライブのランダム I/O が膨大であっても プリフェッチによって アーカイブ プロセスがオフライン ログを効率よく読み取ることができます ただし ログ デバイスを個別のスピンドル上にデータから切り離して実装するべきであると考えているデータベース マネージャは CLARiX metalun 設計の柔軟性を有効に利用します このアプローチは一部の 仮想 RAID スキームでは困難ですが CLARiX では簡単です また クライアントがログに対して違和感なく大容量のキャパシティを費やすことできるのであれば このアプローチには本当に欠点がありません 図 6 は 専用ログ スピンドル アプローチを示しています このアプローチでは ログ デバイスごとに RAID 1 セットを使用しています なお この例で RAID 1 が使用されているのは 冗長ボリュームを実装するのに必要なディスクが一番少ないというだけの理由です EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 29

30 図 6: ハイブリッド metalun Oracle 実装の例 CLARiX キャッシュ CLARiX ストレージ システムのキャッシュは Oracle に良好なレスポンス タイムとスループットを提供するための重要な要素です キャッシュ ページ サイズ CLARiX ストレージ システムを使用すると キャッシュ ページ サイズを設定できます これはグローバル設定のため すべての LUN に影響します キャッシュ ページ サイズは または 16 KB のいずれかで Oracle の DB_BLOCK_SIZE に設定する必要があります キャッシュ対象の LUN 警告 : データベースを格納するファイル システムが異なるブロック サイズに設定されている場合 データベースは ファイル システム ブロック サイズをバックエンドで効果的に使用します そのため この場合は ファイル システム ブロック サイズをキャッシュ ページ サイズとして使用します データベース ブロック サイズをファイル システム ブロック サイズと一致させることで ベスト プラクティスを実現できます すべてのテーブルがリード キャッシュから また 非静的テーブルがライト キャッシュからメリットを得られます REDO ログ デバイスではライト キャッシュおよびリード キャッシュを有効にする必要があります 以下に示す LUN については ライト キャッシュを無効にすることを検討する必要があります REDO ログ アーカイブ ライト キャッシュの REDO ログ アーカイブのアクティビティを保持するため 静的テーブル ( 書き込みなし ) 詳細については 13ページの REDOログ セクションを参照してください スピンドルおよびストライプ 期待する I/O プロファイルが分かっていれば RDBMS ファイル システム専用のスピンドル数を計算することは難しくありません ただし 期待する I/O ロードを計算するのは非常に困難で EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 30

31 す ホスト ベースのツールの対象範囲は制限されているため I/O プロファイルを DBA が知らないことは珍しくありません 最も正確な予測は実験データに基づいています 本番運用中に Workload Analyzer または Navisphere Analyzer が実行され ロードが記録されます 最適なパフォーマンスを実現するには ワークロード (DSS OLTP アーカイブ ) ごとに適切な数のスピンドルを確保することが重要です 最新のディスク ドライブの密度が高い場合は同じスピンドルで複数のアプリケーションを共有する傾向が強くなるため 特にこのことを考慮します この共有によりスピンドルの競合が発生し パフォーマンス重視のアプリケーションに影響を及ぼします ディスク競合を最小限に抑えるためのガイダンスについては ホワイト ペーパー EMC CLARiiON Fibre Channel Storage Fundamentals を参照してください ストライプ エレメント サイズ CLARiX パフォーマンス エンジニアリングが提案するストライプ エレメント サイズは 64 KB(128 ブロック ) です 標準の RAID ストライプのストライプ サイズを表 3 に示します 表 3: ストライプ セグメントとストライプ サイズ RAIDタイプとサイズ ストライプ サイズ 64 KB エレメント サイズ 5ディスクRAID KB 8ディスクRAID 1/0 256 KB 9ディスクRAID KB 16ディスクRAID 1/0 512 KB 広帯域幅のオペレーションでは これらの値を使用して ファイル システム上の最大結合値および期待最大 I/O サイズと調和させます 目標としては ホスト I/O を CLARiX ストライプ またはその偶数の倍数と等しい値にします および 8+8 ストライプ セットがよく使用されるのは これが理由です 有効なディスク数が 2 の累乗の場合は 容易に CLARiX RAID ストライプをホスト I/O サイズに合わせられます RAID レベルとパフォーマンス EMC CLARiiON Best Practices for Fibre Channel Storage で RAID 5 および RAID 1/0 の関連パフォーマンス および CLARiX RAID 5 の最適化について詳しく説明しています RAID 6 を使用する状況 FLARE 26 に新しく導入されたのがRAID 6 です このRAID 6 では パリティRAIDにおける二重のドライブ障害に対する保護が強化されています パフォーマンスの点では RAID 6 はRAID 5 と肩を並べますが 追加のパリティを計算する必要があります ランダム ワークロードの読み取り処理のパフォーマンスは RAID 6 と RAID 5 に違いはありません RAID 6 のバックエンド アクティビティの書き込みについては 追加のパリティ ドライブが原因となり 50% 増加する可能性があります 強制フラッシュせずにワークロードをデステージできる場合 ホストのレスポンス タイムの点から見れば RAID 5 と RAID 6 は同じように動作します シーケンシャル ワークロードの読み取りパフォーマンスについては RAID 5 と RAID 6 はほぼ同じです RAID 6 のダブル パリティ保護のため シーケンシャル書き込みのパフォーマンスは 10% 低下します したがって 信頼性を強化する必要性が追加パリティ ドライブのオーバー EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 31

32 ヘッドを上回っている場合は RAID 5 の代わりに RAID 6 を使用できます RAID 5 に最適なワークロードの種類については RAID 5 を使用する状況 セクションを参照してください RAID 5 を使用する状況 RAID 5 は 非常に大きな I/O サイズ ワークロードで最適に動作します シーケンシャル I/O の場合 Oracle 実装では最適なオプションと考えられており DBA が効率よく 先行読み取り ライト バック およびベクタ書き込みを実装できます ホスト OS および HBA が 64 KB を上回る転送を行える場合も RAID 5 は非常に魅力的です 効率よくという言葉に注意してください 大規模データ構造のランダム I/O は Oracle データベースが行おうとしているデータ結合を使用しません このパフォーマンス プロファイルからメリットを得られるアプリケーションを以下に示します レコード サイズが 64 KB より大きく アクセスがランダムに行われるテーブル スペース ( 写真 地理データベースなどのバイナリ データを含む人事レコードなど ) アクセスがシーケンシャルに行なわれる DSS データベース ( 売上記録に基づいて統計分析を実行する場合など ) コストのほうがパフォーマンスより重要なシナリオ RAID 1/0 を使用する状況 RAID 1/0 を使用では RAID 5 に比べると 指定された任意のストレージ システムや有効容量に対して より多くのランダムな書き込み I/O が可能です したがって 書き込み I/O の負荷が高い環境で RAID 5 ではなく RAID 1/0 を使用すると 次の 2 つの効果があります ライト キャッシュが飽和状態になる前に システムがより多くのランダム書き込みを維持できる ディスクの負荷が少なくなり ランダム読み取りレスポンス タイム短縮に役立つその他の面では 同じ容量であれば 2 つの RAID タイプのランダム読み取りパフォーマンスは非常に似ています 小さなランダム I/O ワークロードの例を次に示します 頻繁に更新される小さなレコード ( 利用残高など ) が格納されたデータ テーブル データベースが何回もソートを行う TEMP スペース ( 構造化レポートを備えた DSS) SAP や Oracle ソリューションなどの大規模アプリケーション セットは アプリケーション サーバでデータ バッファリングを使用します この手法により 初期化時にテーブルが頻繁にスキャンされるようになりますが アプリケーション実行中は非常にランダムにアクセスが行われます RAID 1 を使用する状況ログ デバイス用などの専用 RAID グループが必要だが ストレージの必要性が小さいため RAID 1/0 LU を作成するとコストがかかりすぎる場合は RAID 1 を使用します RAID 1 は シーケンシャル I/O を適切に処理します ただし RAID 1 はストライピングを提供しないため 注意が必要です RAID 1 ボリュームは I/O サイズが 128 KB を上回ると不利な状況に置かれます EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 32

33 RAID 0 を使用する状況 RAID 0 はストライプを提供しますが データ保護は提供しません TEMP テーブルでのみ使用するようにします この役割においてのパフォーマンスは非常に良好です しかし 障害ドライブのコストは絶対に無視できません 保護されていない TEMP スペースでドライブ障害が発生した場合 データベースを再起動する必要があります RAID レベルと冗長性プランニング プロセスで コンポーネント障害によるサービス停止に対するトレランスを評価する必要があります パフォーマンスやコストには関係なく データベースにとって非常に重要なテーブルによって どの RAID タイプを選択するかが決まることがあります たとえば RAID 5 グループにおける障害ドライブのコスト つまり再構築までのコストは ミラーされたペアまたはミラーされたストライプよりも高くなっています また 再構築中 RAID 5 LU のパフォーマンスは ミラーされたデバイスよりも低下します RAID タイプに関連する冗長性の詳細については EMC CLARiiON Fibre Channel Storage Fundamentals を参照してください 使用頻度が常時多いテーブルや 頻繁に更新されるテーブルについては RAID 1/0 グループのコストを増加して 導入されているドライブの容量を増やせば 障害発生時にはそのコストに見合う効果を得られるでしょう RAID 5 グループと比較した場合の RAID 1/0 グループの特徴を以下に示します 再構築中のホスト パフォーマンスへの影響が少なくなる 再構築がより高速 マルチディスク障害が発生する可能性がある (RAID 1/0 グループは 最大でそのディスクの半分が停止しても機能する ) ディスク RPM( 回転スピード ) が同じディスク間のパフォーマンスの違いはごくわずかです しかし Oracle のパフォーマンスは 使用されているドライブの数に大きく依存しています パフォーマンスを最大限に高めるには 最も小さいドライブを使用する必要があります これにより ギガバイトあたりのパフォーマンスが向上し ドライブあたり約 100 IOPS(I/O 合計値 ) になります また ドライブの RPM が高い (15k RPM) とランダム I/O におけるパフォーマンスが大幅に向上します ( 最大 30%) したがって このようなドライブは トランザクション レートが高い OLTP アプリケーションに適しています シーケンシャル I/O については あまりメリットがありません 詳細については ホワイト ペーパー EMC CLARiiON Best Practices for Fibre Channel Storage を参照してください 結論 Oracle データベースのストレージを選択する場合は 主に 容量 パフォーマンス および信頼性を考慮します パフォーマンスのプランニングでは データベース設計 ホストのメモリ構成 およびストレージ システムのパフォーマンス特性を慎重に分析する必要があります パフォーマンスで大切なのは まず アプリケーションを適切に設計することです そのうえで ホスト チューニングを行います ストレージ システムは ホストの要求する以上の速度でデータを配信することはできません パフォーマンスに問題がある場合は パフォーマンス チューニングに関する EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 33

34 Oracle の推奨手順を参照するようクライアントに勧めてください ( 付録 B:DB チューニングの基本ステップ を参照 ) アプリケーションが適切に設計されている場合は 相互関係を持つオブジェクトの展開は 異なる物理スピンドルで行われるようにします OLTP データベースの場合は 15k RPM ドライブの RAID1/0 が推奨されます また 容量に関するクライアントのニーズに適した最小容量のドライブを使用する必要があります DSS アプリケーションは RAID 5 によって適切に機能します これは より大きな 10k RPM ドライブです 信頼性は CLARiX CX および CX3 UltraScale シリーズのストレージ システムが誇る強みです データベースの重要な部分については コンポーネント障害の影響が少ない RAID 1/0 を使用することを検討してください 実装前のプランニングには十分に時間を費やす価値があります EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 34

35 関連資料 次の技術的な内容に関するホワイト ペーパーは Powerlink から入手できます EMC CLARiiON Fibre Channel Storage Fundamentals EMC CLARiiON Best Practices for Fibre Channel Storage EMC CLARiiON Data Replication Options for Oracle Deployments Technology Concepts and Business Considerations EMC CLARiiON SnapView and MirrorView for Oracle Database 10g Automatic Storage Management Best Practices Planning EMC CLARiiON Database Storage Solutions:Oracle 10g with SnapView in SAN Environments EMC CLARiiON Database Storage Solutions:Oracle 9i with SnapView in SAN Environments Oracle TechNet から入手できる重要なドキュメントを以下に示します Oracle9i User-Managed Backup and Recovery Guide Oracle Database Backup and Recovery Basics 10g Release 2 The Oracle Database Administrator's Guides for Oracle 9i, 10g, or 11g EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 35

36 付録 A:REDO ログ Oracle では 次の場合に REDO ログに書き込まれます COMMIT がデータベースに対して実行された場合 ログ バッファの 1/3 が埋まった場合 DBWR によってデータベース ファイルが書き込まれた場合 REDO ログの設計は 複雑性の面では明らかにコストがかかります では なぜ REDO ログを使用するのでしょう? コンシステンシの必要性 REDO ログの当初の目的は 多重トランザクションをアトミックに記録することでした これにより 致命的な障害が発生してもデータベースを Consistent( コンシステント ) 状態にすることができました たとえば 2 つのテーブルを 1 回の操作で更新する必要があり その更新が互いに依存している場合 ( たとえば 一方のテーブルが実行され もう一方のテーブルが実行されない場合 データベースが非同期になる場合 ) 両方の変更の意図を 1 回のオペレーションで記録する方法として アトミックに書き込まれる 1 つの REDO ログ エントリを使用します テーブル内のデータは 後で更新されます 致命的な障害が発生した場合は REDO ログのコンテンツと データベース内のブックマークを使用して ログされているが完了していないトランザクションの実行を終了します パフォーマンスの利用 REDO ログは Oracle のトランザクション処理のパフォーマンスにとって重要です 初期のデータベース設計者は 基本的には複数の書き込みを 1 回のオペレーションにバンドルすることで REDO ログによるパフォーマンスの向上が実現する ということが分かっていました 複雑なビジネス トランザクションに さまざまなテーブルのデータに対する変更がいくつも含まれていることはよくあります 複数テーブルの書き込みでは コストが増加します 複数ファイルや 複数ファイルシステムへの書き込みなど 裏で複数のストレージ ハードウェアが動作している場合は 複雑なトランザクションを実行時のレーテンシーと同様のコストがかかります しかし 変更されたデータが 恒久的なストレージに適切に書き込まれない限り システムがクラッシュしたときに コミットされたトランザクションを失うリスクは本来備え持っています 最近のデータベースでは ロギング データのみがパーシステント ストレージに同期的にフラッシュされます ダーティー データベース ページの I/O パフォーマンス全体が向上する 1 つの理由は 同じページに対する複数の変更が 1 つの物理 I/O のみで効果的に書き込まれるからです また 複数のダーティー ページを DBWR プロセスがバッチとしてバックグラウンドで非同期的に実行できるからという理由もあります ( 図 7) EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 36

37 図 7: トランザクションの例 図 7 の手順 3 を実行したら データベースは次のオペレーションを実行できます つまり DBWR プロセスが REG2 および CENTRAL に対して非同期書き込みを実行できます REDO ログの場合と同様に 障害発生時にデータベースで必要になるのは 行を移動することだけです 最初のテーブル オペレーションは REG2 に対する行の追加です つまり 追加処理であるため 障害が発生した場合にデータベースの整合性を確保するには CENTRAL の古い行を削除する必要があります データ消失はなく データベースの整合性も確保できます 最適化の推進 : バッファ結合 書き込み対象のデータが DBWR メモリ バッファに保持されることで パフォーマンスがさらに向上します DBWR プロセスは テーブル更新の複数インスタンスのバッファをスキャンできます これにより テーブルに対する複数の変更を数回のオペレーションでバンドルする機会が発生し I/O ロード ディスク競合 およびレーテンシーが軽減されます たとえば 200 フィールドを持つレコードに個別の要求があり その要求によって 20 フィールドで変更が発生するとします これらの変更はすべて テーブルに対する 1 つの書き込みに結合されます EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 37

38 付録 B:DB チューニングの基本ステップ Oracle では 次の手順に従ってデータベースをチューニングすることを推奨しています 1. ビジネス ルールをチューニングします 2. データ設計をチューニングします 3. アプリケーション設計をチューニングします 4. データベースの論理構造をチューニングします 5. データベース オペレーションをチューニングします 6. アクセス パスをチューニングします 7. メモリ割り当てをチューニングします 8. I/O および物理構造をチューニングします 9. リソース競合をチューニングします 10. 基盤となるプラットフォームをチューニングします EMC CLARiX ストレージ システムでの Oracle の実装ベスト プラクティスのプランニング 38