ダウンロードはこちら - EMC.com

EMC CLARiX ストレージ・システムでの
Oracle の実装
ベスト・プラクティスのプランニング
US ホワイトペーパー翻訳版
要約
このホワイト・ペーパーでは、EMC® CLARiX® CXまたはCX3 UltraScale™シリーズのファイバ・チ
ャネル・ストレージ・システムを使用してOracleデータベースを実装するときに考慮するべき問題に
ついて説明します。また、Oracleの一般的な推奨事項とCLARiXシステム特有のパフォーマンス特性
を対比させ、OracleでCLARiXストレージ・システムを使用する際の一般的な推奨事項について取り
上げています。
2008 年 5 月
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
目次
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
パフォーマンスに関するその他の考慮事項..................................................... 24
ホストOSおよびHBAに関する考慮事項 ............................................................................... 24
最大I/Oサイズ.................................................................................................................. 24
配置 ................................................................................................................................ 25
ファイル・システムまたはrawパーティション .................................................................... 25
rawパーティション .......................................................................................................... 26
ファイル・システム ........................................................................................................ 26
ホスト・ベースのスクリプト作成（Plaid） ......................................................................... 27
OracleのSAME ................................................................................................................. 27
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
3
ホスト・ベースのストライピングのガイドライン ............................................................ 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
結論 .............................................................................................................. 33
関連資料........................................................................................................ 35
付録A：REDOログ ........................................................................................ 36
コンシステンシの必要性 ..................................................................................................... 36
パフォーマンスの利用 ........................................................................................................ 36
最適化の推進：バッファ結合 ........................................................................................... 37
付録B：DBチューニングの基本ステップ ....................................................... 38
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
4
エグゼクティブ・サマリー
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
を提供します。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
ディスクに直接書き込まれます。詳細については、ホワイト・ペーパー「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 のテクノロジーが確実に連携し、お客様側で問題が発生し
たとしても完全にサポートされることが保証されます。
http://www.emc.com/products/interoperability/index.htm
EMCには、Oracleと緊密に連携するパートナー・エンジニア・グループがあります。EMCエンジ
ニアは、新しいバージョンのOracleソフトウェアを、CLARiXストレージ・システムに接続され
ているさまざまな種類のサーバ上でテストします。これらのラボでは、SnapView™や
MirrorView®などのCLARiX機能を最新のOralceソフトウェアに統合する方法について開発してい
ます。
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
7
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 8.1.5、パーツ番号A67775-01。
2 Oracle9i Database Performance Planning Release 2 (9.2)、パーツ番号A96532-01。
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
8
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
•
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
•
•
•
定期チェックポイントによって、ディスク上の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
シーケンシャルまたはランダム 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
また、ピーク・アクティビティも、予期可能なイベントによって引き起こされます。計画対象の
イベントには、食事時間、スケジュールされたイベント、金曜日、給料日、祝日など多忙が予想
される日などが含まれます。
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
ディスク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
ペレーションの場合は、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
に対してミラーされていない書き込みを行うことが可能です。この場合、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
オフライン・ログがオンラインになる前にログ・アーカイブ・プロセスを確実に完了させるには、
キャッシュされていない書き込みが効率的に実行されるようにします。この手法には複数の方法
でアプローチできます。
最初のアプローチでは、アーカイブ 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
図 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
共有環境で 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
DB_BLOCK_CHECKPOINT
_ WRITE_BATCH
DB_BLOCK_SIZE
8
DB_FILE_MULTIBLOCK_
READ_COUNT
DB_BLOCK_SIZE
8
説明および推奨事項
ファイル・システムのブロック・サイズと同
8
じで、かつOSのページ・サイズ以上。
チェックポイントの書き込みの書き込みチャ
ンク・サイズ。CLARiX LUNストライプ・エ
レメント・サイズからCLARiXストライプ・
サイズまでの値を設定。ただし、OSの最大
I/Oサイズを超えないようにする。
テーブルおよびインデックス完全スキャン用
の読み取りチャンク・サイズ。CLARiX LUN
ストライプ・エレメント・サイズから
CLARiXストライプ・サイズまでの値を設
定。ただし、OSの最大I/Oサイズを超えない
ようにする。
8 DB_BLOCK_SIZEの詳細については、14ページの「アーカイブのI/O」を参照してください。
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
19
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
DB_BLOCK_CHECKPOINT_
WRITE_BATCH
4096
16
DB_FILE_MULTIBLOCK_READ_
COUNT
16
HASH_MULTIBLOCK_IO_COUNT
16
ファイル・システムのブロック・サイズ。
16*4096 = 64 KB、べースLUNストライプ・エレメン
ト・サイズ。
16*4096 = 64 KB、べースLUNストライプ・エレメン
ト・サイズ。
16*4096 = 64 KB、べースLUNストライプ・エレメン
ト・サイズ。
USE_DIRECT_I/O
未使用
推奨：Oracle の先行読み取りサイズおよび書き込みクラスタ・サイズが、基本の LUN RAID
ストライプ・サイズまたはストライプ・エレメント・サイズと必ず対応ようにしてくださ
い。
データベースのバックアップ
データベースのバックアップは 2 通りの方法で実行できます。1 つはコールド・バックアップと
いい、データベースをシャットダウンしてバックアップを行います。もう 1 つはホット・バック
アップで、データベースを実行したままバックアップ・モードでバックアップを行います。両オ
ペレーションともストレージ・サブシステムの設計に影響するので重要です。したがって、この
両方について検討していきます。システムを設計する場合は、バックアップによって発生する時
間および I/O ロードを考慮し、ホット・バックアップ中に十分なパフォーマンスが確保されるよ
うにします。
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
20
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
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
ーンがコピーされます。この処理は、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
推奨：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
推奨：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
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
高度なファイル・システム
一部のファイル・システムには、パフォーマンスを向上させるためのアドバンス機能が用意され
ています。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
たとえば、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
図 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
図 6：ハイブリッド metaLUN Oracle 実装の例
CLARiX キャッシュ
CLARiX ストレージ・システムのキャッシュは、Oracle に良好なレスポンス・タイムとスループ
ットを提供するための重要な要素です。
キャッシュ・ページ・サイズ
CLARiX ストレージ・システムを使用すると、キャッシュ・ページ・サイズを設定できます。こ
れはグローバル設定のため、すべての LUN に影響します。キャッシュ・ページ・サイズは 2、4、
8、または 16 KB のいずれかで、Oracle の DB_BLOCK_SIZE に設定する必要があります。
キャッシュ対象の LUN
警告：データベースを格納するファイル・システムが異なるブロック・サイズに設定されている場合、データベースは、ファイル・
システム・ブロック･サイズをバックエンドで効果的に使用します。そのため、この場合は、ファイル・システム・ブロック･サイズを
キャッシュ・ページ・サイズとして使用します。データベース・ブロック・サイズをファイル・システム・ブロック・サイズと一致させるこ
とで、ベスト・プラクティスを実現できます。
すべてのテーブルがリード・キャッシュから、また、非静的テーブルがライト・キャッシュから
メリットを得られます。REDO ログ・デバイスではライト・キャッシュおよびリード・キャッシ
ュを有効にする必要があります。以下に示す LUN については、ライト・キャッシュを無効にす
ることを検討する必要があります。
•
REDO ログ・アーカイブ。ライト・キャッシュの REDO ログ・アーカイブのアクティビティ
を保持するため
•
静的テーブル（書き込みなし）
詳細については、13ページの「REDOログ」セクションを参照してください。
スピンドルおよびストライプ
期待する I/O プロファイルが分かっていれば、RDBMS ファイル・システム専用のスピンドル数
を計算することは難しくありません。ただし、期待する I/O ロードを計算するのは非常に困難で
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
30
す。ホスト・ベースのツールの対象範囲は制限されているため、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 5
8ディスクRAID 1/0
9ディスクRAID 5
16ディスクRAID 1/0
256 KB
256 KB
512 KB
512 KB
広帯域幅のオペレーションでは、これらの値を使用して、ファイル・システム上の最大結合値お
よび期待最大 I/O サイズと調和させます。目標としては、ホスト I/O を CLARiX ストライプ、ま
たはその偶数の倍数と等しい値にします。4+1、4+4、8+1、および 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
ヘッドを上回っている場合は、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
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
Oracleの推奨手順を参照するようクライアントに勧めてください（「付録B：DBチューニングの
基本ステップ」を参照）。
アプリケーションが適切に設計されている場合は、相互関係を持つオブジェクトの展開は、異な
る物理スピンドルで行われるようにします。OLTP データベースの場合は、15k RPM ドライブの
RAID1/0 が推奨されます。また、容量に関するクライアントのニーズに適した最小容量のドライ
ブを使用する必要があります。DSS アプリケーションは、RAID 5 によって適切に機能します。
これは、より大きな 10k RPM ドライブです。
信頼性は、CLARiX CX および CX3 UltraScale シリーズのストレージ・システムが誇る強みです。
データベースの重要な部分については、コンポーネント障害の影響が少ない RAID 1/0 を使用す
ることを検討してください。
実装前のプランニングには十分に時間を費やす価値があります。
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
34
関連資料
次の技術的な内容に関するホワイト・ペーパーは、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
付録 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
図 7：トランザクションの例
図 7 の手順 3 を実行したら、データベースは次のオペレーションを実行できます。つまり、
DBWR プロセスが REG2 および CENTRAL に対して非同期書き込みを実行できます。REDO ログ
の場合と同様に、障害発生時にデータベースで必要になるのは、行を移動することだけです。
最初のテーブル・オペレーションは REG2 に対する行の追加です。つまり、追加処理であるため、
障害が発生した場合にデータベースの整合性を確保するには、CENTRAL の古い行を削除する必
要があります。データ消失はなく、データベースの整合性も確保できます。
最適化の推進：バッファ結合
書き込み対象のデータが DBWR メモリ・バッファに保持されることで、パフォーマンスがさら
に向上します。DBWR プロセスは、テーブル更新の複数インスタンスのバッファをスキャンで
きます。これにより、テーブルに対する複数の変更を数回のオペレーションでバンドルする機会
が発生し、I/O ロード、ディスク競合、およびレーテンシーが軽減されます。たとえば、200 フ
ィールドを持つレコードに個別の要求があり、その要求によって 20 フィールドで変更が発生す
るとします。これらの変更はすべて、テーブルに対する 1 つの書き込みに結合されます。
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
37
付録 B：DB チューニングの基本ステップ
Oracle では、次の手順に従ってデータベースをチューニングすることを推奨しています。
1.
ビジネス・ルールをチューニングします。
2.
データ設計をチューニングします。
3.
アプリケーション設計をチューニングします。
4.
データベースの論理構造をチューニングします。
5.
データベース・オペレーションをチューニングします。
6.
アクセス・パスをチューニングします。
7.
メモリ割り当てをチューニングします。
8.
I/O および物理構造をチューニングします。
9.
リソース競合をチューニングします。
10. 基盤となるプラットフォームをチューニングします。
EMC CLARiX ストレージ・システムでの Oracle の実装
ベスト・プラクティスのプランニング
38

Download Report