X

A blog about Oracle Technology Network Japan

  • November 23, 2011

津島博士のパフォーマンス講座  第12回 I/O周りについて

Guest Author

津島博士のパフォーマンス講座 Indexページ ▶▶

 


皆さんこんにちは、だいぶ寒くなってきましたが体調はいかがでしょうか。早いもので1月から連載が始まって1年になろうとしていますが(連載も今回で第12回ですね)、これからも頑張りますのでよろしくお願いします。

今回は、I/O周り(OracleデータベースのI/O)について説明しようと思います。これは性能に大きく影響するため大事なことですが、なかなか思うようにできていないのではと思いますので、参考にして下さい。

■1.OracleデータベースのI/Oについて
まずは、OracleデータベースのI/Oについて説明します。OracleデータベースはI/O負荷が高いソフトウェアで、以下に示す代表的なファイル(Oracleデータベースの物理記憶域)に様々なI/Oが発生します。以下に記述されているもの以外にも例えばフラッシュバックリカバリ領域などのファイルはありますが、別の機会とさせていただきます。

  • オンラインREDOログファイル
    これはLGWRプロセスによるログバッファからのシーケンシャル書込みが行われます(サイズは1トランザクションサイズからロブバッファの1/3までになります)。アーカイブログ・モードの時は、ログスイッチのタイミングでアーカイブREDOログファイルへ出力するためにシーケンシャル読込みも行われます。
  • 制御ファイル
    このファイルはデータベースの起動時に物理構造情報として読込みが行われ、物理構造情報の変更が行われた時に(例えば、チェックポイント時にCKPTプロセスによって)書込みが行われますが、非常に小さなファイルですので、あまり気にする必要はないと思います。
  • アーカイブREDOログファイル
    これはアーカイブログ・モードの時にARCHプロセスによるオンラインREDOログファイルからのシーケンシャル書込みを行います。
  • データファイル
    このファイルには、すべてのタイプのI/O(シーケンシャル読込みと書込み、ランダム読込みと書込み)が行われます。1ブロック・サイズによるランダムI/Oとマルチブロック・サイズによるシーケンシャルI/Oがあります。読込みはサーバープロセスによって行われ、書込みはサーバープロセス(ダイレクト・パス・インサート)とDBWRプロセス(バッファキャッシュからの書込み)によって行われます。

 このような様々なI/Oが発生するため、ディスク配置は難しくなります。それでは、「ディスクの配置」と「なぜI/Oは多いか」について説明していきます。

(1)ディスクの配置
ディスクの配置は、様々なI/OのためにできるだけI/O効率が良くなるように時間をかけて検討することになります。一般的には、以下の図のようにディスク毎に同じタイプのI/Oになる(ランダム・アクセスとシーケンシャル・アクセス、読込みと書込みを別ディスクにする)ようにディスク配置をする訳です。これを簡単に行うことができないため(すべてのアクセス・パターンを分析することは難しいから)、もしくは運用しているとアクセス・パターンが変化していくため(その変化にディスク配置を常に合わせるのは難しいから)パフォーマンス問題になったりする訳です。このような従来の方法に対するOracleの解決策として全体最適化を行うようにした訳です。これは、第3回で説明したS.A.M.E(Stripe And Mirror Everything)及びASM(Automatic Storage Management)の考え方です。

img_tsushima_111124_01.png

(2)なぜI/Oは多いか
RDBMSはI/Oが多く発生するものだということを認識しておきましょう。データ量が多いからといえばそれまでですが、それ以外にも可用性を向上するためにI/Oが増えてしまいます。これは最新データがメモリに存在するよりもディスクに存在した方がリカバリする必要がなくなり、リカバリ時間を短縮できるからなので仕方ありません(データベースはデータ損失しないことが非常に重要になるからです)。ですから初期化パラメータFAST_START_MTTR_TARGETの値を小さくすれば(リカバリ時間を短縮するためにダーティ・ブロックを少なくするため)当然ストレージへの書込みは増えてしまう訳です。そのため、このようなことを意識したストレージ性能が必要になることを知っておいて下さい(このようなことがI/Oネックになりやすい要因でもあると思います)。

■2.ストレージについて
次に、ストレージについて説明しようと思います。知っている方も多いのかも知れませんが、大事な事なので再確認の意味で行いたいと思います。

Oracleデータベースのデータを格納しているのがストレージです。データベースを格納するストレージには、大量データを高速に、そして高信頼で行うことが求められます。最近は様々なストレージがありますが、基本的な考えは耐障害性と性能をどのようにして最大限に行うかです。ここでは、ストレージのタイプとRAIDについて説明します。

(1)SANとNAS
ストレージには、サーバーに直接接続するDAS(Direct Attached Strage)以外に、ネットワーク・ストレージとしてSAN(Storage Area Network)とNAS(Network Attached Storage)の二種類があり(現在はこちらが主流です)、どれを使用するか悩まれている方も多いのではないでしょうか。SANはブロック・データのアクセスを行うのに対してNASはファイル・レベルでのアクセスを行いますので、ストレージ側にファイル・システムを持つ必要があります。コストからいくとNASは魅力的ですが性能面では多少心配になると思います。つまり、性能重視ではSAN、コスト重視ではNASを使用することになると思います。ただし、NASを使用するときにコスト重視だからといっても性能を無視できるようなシステムはないものです。そのため、OracleはNASに対する性能面の改善もOracle Database 11gから行っています。これはNASストレージのOracleデータベース・ファイルにアクセスするときにOSのNFSクライアント(OS Kernel NFS)機能を使用するのではなく、Oracle Database 11gから提供されているNFSクライアント(ダイレクトNFS)機能を使用して行います。つまり以下の図のようにOracle自身がNFSクライアント機能を備えており、それで直接アクセスすることができるので、オーバーヘッドを削減することができます。

img_tsushima_111124_02.png

(2)ハードウェアRAIDとソフトウェアRAID
どのようなストレージ装置を使用するにせよ性能(I/Oの分散)と可用性(冗長化)、そして管理性(ボリューム容量の拡大)を実現するためにRAID機能は使用すると思います。このRAID機能を実現するために、ディスクアレイ装置などで行うハードウェアRAIDとボリューム・マネージャなどで行うソフトウェアRAIDがあります。皆さんの中には、ディスクアレイ装置を使用するかボリューム・マネジャを使用するか悩まれる方も多いと思います。ただし、高価なストレージ装置は、だいたいがディスクアレイ装置だと思いますので、ストレージの筐体障害に対する可用性を求めない限りはディスクアレイ装置だけで問題ないと思います。高価なストレージはハードウェアRAID、安価なストレージはソフトウェアRAIDで行うことになると思います。ただし、ソフトウェアRAIDはサーバーマシンのCPUを多少使用することは忘れないで下さい。

それから、最近のディスク容量の拡大やボリューム容量の拡大に対応するためにOracle Database 10gからはBIGFILEタイプ表領域を追加して管理を簡略化できるようにしていますので(以前までのものはSMALLFILEタイプ表領域といいます)、できるだけこれを使用すると良いでしょう。

BIGFILEタイプ表領域について
ご存知ない方のために、ここでBIGFILEタイプ表領域について簡単に説明します。

このBIGFILEタイプ表領域は、Oracle Database 10gからの機能で、1つのデータファイルだけを指定できる表領域です。このデータファイルのサイズは、ブロック・サイズ×4GB-1(4,294,967,295)まで作成する事ができるようになります。昔のディスク装置に比べて最近のディスク装置は大規模化してきていて、大きいファイルを確保できる方が効果的になってきています。また、RAID装置などによって論理ボリューム(RAIDグループ、ボリュームグループ)を拡大することができる(動的に拡張可能な論理ボリュームも増えてきている)ので、旧来のデータファイルを追加するという作業は不要になります(当然ASMにとっても良い訳です)。以前は、Oracle側でディスクを分散させるなどを行っていましたが、最近ではRAID機能によって冗長化やI/O分散を行うことができるので、意識する必要がない、このような表領域の方が効率が良い訳です。

(3)RAIDレベル
ここで、それぞれのRAID(Redundant Arrays of Inexpensive Disks)レベルの特長を簡単に説明します。これについての説明は沢山あると思いますので、詳細な説明は省略いたします。RAID0(ストライピング)、RAID1(ミラーリング)、RAID5について簡単に説明しておきます。

  • ストライピングは、複数のディスクに分散させることで性能を向上させることができますが、冗長化されていませんので耐障害性が劣ります。このときストライプ・サイズによって各ディスクへ均等にデータを格納していきます(これはASMではAUサイズまたは128バイトになります)。以下の図のようにストライプ・サイズよりもI/Oサイズが小さければ(左図)1回のI/Oを複数のディスクに分散できるためI/Oサービス時間を短縮できます(ただし、プロセスが増えると競合は発生し易くなります)。また、ストライプ・サイズがI/Oサイズ以上であれば(右図)競合を軽減することができるという特長があります。そのため、ストライピングを行う時はI/Oサイズを知っておくことも大事になります。Oracleデータベースの場合、最大I/Oサイズは1Mバイトになります。そのため、ASMのAUサイズは1Mバイト以上になっています。つまり、ストライプ・サイズにAUサイズを指定すると常に右図のようにすることができます。また、特定のファイル(あまりI/Oが競合しないオンラインREDOファイルなど)のディスク・グループに128Kバイトを指定すると左図のようにすることもできますが、他のファイルと同じディスクグループにすると競合が多発する可能性がありますので注意して下さい(これはS.A.M.Eの考え方からは外れるので、大量のディスクがある場合以外はあまりお奨めしません)。

img_tsushima_111124_03.png

  • ミラーリングは、冗長化のために同じデータを二つのディスクに書込む必要がありますのでディスクが2倍必要になるというコストの問題はあります。ただし、書込み性能はパリティ作成するよりは速く行うことができます(ただし、I/O量は2倍になります)。また、複数のディスクにI/Oを分散させることはできません(基本は2つのディスクだけになります)ので、性能面での限界があります。そのため、これはボリューム容量の増加や性能にはあまり効果がなく、耐障害性を重視したタイプとなります。
  • RAID5(最近はパリティを二重化するRAID6などもあります)は、冗長化のためのパリティ計算が必要なためミラーリングより書込み性能は劣ります。ただし、読込み性能はディスクをストライピングできるので速く行うことができます。これはいくつのディスクでRAIDグループを作成するかで決まってきます(これはパリティ計算のオーバーヘッドも増加しますので注意して下さい。これについては各ストレージ・ベンダー毎に推奨値があると思います)。
  • RAID0+1(RAID1+0は厳密にはRAID0+1と異なりますが、ここでは同じものとして扱います)は、ミラーリングの性能の問題を解決するための方法です。当然ミラーリングと同じように2倍の容量が必要になりますので、コストの問題はあります。ただし、このレベルをサポートしていないものもありますので注意して下さい。

 要件によって、どのRAIDレベルがベストかは一概に言えませんが、以下の表に代表的なOracleファイルに適したレベルをまとめてみました(あくまでも一例です)。耐障害性と性能からRAID0+1がベストだと思いますが、コストの面から書込みが少ないファイルにはRAID5という選択肢もあります。また、耐障害性を重視する場合にはRAID1がベストになると思います。ただし、ストレージ・ベンダーによっては、キャッシュ・アルゴリズムなどの違いによってベストなRAIDレベルが異なる場合がありますので注意して下さい。

  OLTP系 DSS系 解説
SYSTEM表領域 RAID1 RAID1 Oracleが稼動するために最も重要なデータを格納している領域ですので、耐障害性を考慮してRAID1にします。
ユーザ表領域、
UNDO表領域
RAID0+1 RAID0+1、RAID5 システム要件とコストに合わせて選択します。性能と信頼性の高いユーザ要件を満たすためにはRAID0+1を使用することをお奨めします。コスト重視のDSS系ではRAID5を使用しても良いです。
一時表領域 RAID0 RAID0 一時データなのでRAID0で問題ないです。
オンライン
REDOログファイル
RAID1、RAID0+1 RAID1 RAID1にします。OLTP系のシステムなどで更新処理が多い場合は、RAID0+1で性能向上が期待できます。
制御ファイル RAID1、RAID5 RAID1、RAID5 非常に小さなファイルなので、通常はOSファイルでRAID1またはRAID5を使用します。
アーカイブ
REDOログファイル
RAID1 RAID1 このファイルはリカバリ用なので耐障害性を最も考慮すべきポイントとなりますのでRAID1にします。

 ここには、各ファイルの耐障害性や必要とする性能要件からベストなRAIDレベルをまとめてみましたが、このように各ファイル毎に設定するのは難しいと思います。そのため、基本はRAID0+1を使用するのがベストということになるではないでしょうか(だから、S.A.M.Eの考え方ができたのだと思います)。

■3.ASMについて
最後に、Oracleが考えるストレージ管理方法であるASM(自動ストレージ管理)について簡単に説明しておきます。

ASMは、S.A.M.E以外にも以下の図のようにボリューム・マネージャからデータファイルまで仮想化させることができます。つまり、別々に管理する必要があったボリューム・マネージャ(RAIDグループ、ディスク配置など)、ファイル・システム(ファイルをプール化することで管理を簡単にする)、データファイル(ファイル名、位置などの管理といくつ作成するか)を一括管理することができ、管理を簡略化することができます。

そして、ファイルの管理などもファイルシステム上でOMF(Oracle Managed Files)を使用している時のように行ってくれるというメリットがあります。これ以外にも様々な機能がありますが、今回はここまでとさせていただきます。

それから、ASMとディスクアレイ装置を使用するような場合は、ストレージ側でミラーリングなどの冗長化を行い、ASMではストライピングだけを行うようにすると良いです。

img_tsushima_111124_04.png

ASMに関しては、以下に多くの情報をまとめてあります。
オラクルエンジニア通信:「Oracle ASMを1から学ぶ - マニュアル、インストール・構築、設定・管理

OMF(Oracle Managed Files)について
ご存知ない方のために、ここでOMFについて簡単に説明します。

Oracle9iから提供されたOMF機能を使用することで、Oracleデータベースのファイル(表領域、制御ファイル、REDOログファイル)の管理(ファイル名と位置の管理)が簡単になります(ただし、ファイルシステム使用時だけです)。OMFを使用する場合は、指定ディレクトリ(初期化パラメータDB_CREATE_FILE_DEST)にファイルを配置したいディレクトリを指定して、まとめてOracleデータベースのファイルを配置することで、DB管理の手間を大幅に省くことができます(初期化パラメータDB_CREATE_ONLINE_LOG_DEST_nで多重化したい制御ファイルとREDOログファイルを指定することもできます)。この設定をすることで、表領域や制御ファイルなどを作成する際にファイル名を指定する必要がなくなります。また、不要になったファイルは自動的に削除されます(例えば、表領域などを削除した際は、データファイルも同時に削除されます)。そのため、不要なファイルが存在するやファイル名を間違えるミス(別のファイルを誤って削除してしまう、他で使用中のファイルを指定してしまうなど)を防止することができる便利な機能です。

■4. おわりに
今回はOracleデータベースのI/Oについて説明しました。また機会があれば他のI/O周りについても説明しようと思います。11/11(金)にOracle DBA & Developer Days 2011で久しぶりに講演をしました。博士として初めて皆さんの前に出て多少恥ずかしかった気がします(キャラクタとのギャップがあるからでしょうか)。聞いてくれた方はありがとうございました。これからも頑張りますのでよろしくお願いします。質問をお待ちしています。

それでは、次回まで、ごきげんよう。


ページトップへ戻る▲ 

 

津島博士のパフォーマンス講座 Indexページ ▶▶

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.