| Oracle® Database VLDBおよびパーティショニング・ガイド 11g リリース2 (11.2) B56316-03 |
|
 前 |
 次 |
データ・ウェアハウス環境の記憶域のパフォーマンスは、多くの場合、I/Oスループット(MB/s)に換算されます。オンライン・トランザクション処理(OLTP)システムでは、1秒当たりのI/Oリクエスト数(IOPS)がパフォーマンスの重要な尺度です。
この章では、VLDB環境のみに関してデータベース・ファイルの記憶域管理を説明します。Oracle Databaseソフトウェアなどデータベース以外のファイルについては、管理方法がVLDB以外の環境と変わらないためここでは扱いません。このため、VLDB環境の記憶域システムの高可用性、パフォーマンスおよび管理性の側面を中心に説明します。
この章では次の項について説明します。
|
注意: Oracle Databaseでは、RAWデバイスやファイルシステム上のデータベース・ファイルを使用できます。また、RAWデバイスまたは論理ボリューム上でのOracle自動ストレージ管理(Oracle ASM)の使用もできます。可能であればOracle ASMを使用することが推奨されます。 |
高可用性は、記憶域の冗長性を実装することで達成できます。これを記憶域の用語ではミラー化技法と呼びます。データベース環境でのミラー化には次の3つの方法があります。
ハードウェアベースのミラー化
Oracle ASMを使用したミラー化
ソフトウェアベースのミラー化(AOracle ASMは使用しない)
Oracle ASMを使用しないソフトウェアベースのミラー化はお薦めしません。
この項の内容は次のとおりです。
|
注意: クラスタ構成では、使用するソフトウェアがクラスタ機能をサポートする必要があります。Oracle ASMは、Oracle Databaseファイル用のクラスタ・ファイルシステムです。 |
ほとんどの外部ストレージ・デバイスでは、様々なRAID (Redundant Array of Independent Disks)レベルがサポートされています。VLDB環境で最もよく使用される高可用性ハードウェアRAIDレベルは、RAID 1およびRAID 5です。VLDB環境ではそれほど一般的ではありませんが、他の高可用性RAIDレベルも使用できます。
この項の内容は次のとおりです。
RAID 1は基本的なミラー化技術です。記憶域に書き込まれるすべての記憶域ブロックは、RAID設定で定義されたように異なる2つの物理デバイスに格納されます。RAID 1ではフォルト・トレランスが提供されます。つまり、1台のデバイスで障害が発生すると、もう1台のミラー化されたデバイスがデータのリクエストに応答できます。RAID 1設定での2つの書込みは記憶域レベルで生成されます。RAID 1が有効に機能するには少なくとも2つの物理ディスクが必要です。
ストレージ・デバイスには、通常、リクエストが届いたときにプライマリとミラーのいずれかを読み取る機能があります。これにより、高可用性対応に設計された他のRAID構成に比べて高いパフォーマンスが得られます。RAID 1は、最も単純なハードウェア高可用性実装ですが、データを格納するために必要な記憶域が2倍になります。多くの場合、RAID 1はRAID 0 (ストライプ化)と組み合せてRAID 0+1構成で使用されます。最も単純なRAID 0+1構成では、個々のストライプが2台の物理デバイス間でミラー化されます。
RAID 5には、少なくとも3台のストレージ・デバイスが必要です。通常は4～6台のデバイスが1つのRAID 5グループで使用されます。RAID 5を使用すると、デバイスに書き込まれるデータ・ブロックごとにパリティが計算されて、別のデバイスに格納されます。読取り操作時にパリティがチェックされます。パリティ計算は記憶域レイヤーで行われます。RAID 5でデバイス障害に対する高可用性が得られるのは、別のデバイスに格納されているパリティに基づいてデバイスの内容を再構築できるためです。
RAID 5では優れた読取りパフォーマンスも提供されます。書込みのパフォーマンスは、記憶域レイヤーでのパリティ計算のために遅くなることがあります。RAID 5では、グループ内のデバイス数によって異なりますが、必要な記憶域容量は2倍よりは少なくなります。RAID 5は比較的複雑なため、ストレージ・デバイスによってはRAID 5設定がサポートされないものもあります。
Oracle自動ストレージ管理(Oracle ASM)は、ソフトウェアベースのミラー化機能を提供します。Oracle ASMでは、通常の冗長性(ミラー化)と高い冗長性(トリプル・ミラー化)がサポートされます。また、Oracle ASMでは、外部冗長性の使用もサポートされます。この場合、Oracle ASMでさらにミラー化が実行されることはありません。Oracle ASMの通常の冗長性は、RAID 1ハードウェア・ミラー化と同等です。
Oracle ASMによるミラー化では、ミラーはデータベース・サーバーによって作成されます。このため、Oracle ASMミラー化を使用すると、ハードウェアベースのミラー化に比べて、書込み操作時にさらにI/Oスループットが必要になります。構成やハードウェアRAIDコントローラの速度によって異なりますが、Oracle ASMによるミラー化またはハードウェアRAIDではデータ・ロードのボトルネックが発生することがあります。
Oracle ASMでは、障害グループの定義により冗長性が有効になります。Oracle ASMによって障害グループの境界を超えてデータがミラー化されるためです。たとえば、VLDB環境では、1つのディスク配列ごとに1つの障害グループを定義できます。この場合、Oracle ASMによって、ミラー化されたデータは必ず別のディスク配列に格納されます。このようにして、1つのディスク配列の1つのディスクの障害を切り抜けるだけではなく、ディスク配列全体の障害やディスク配列のすべてのチャネルの障害も乗り越えることができます。通常、ハードウェアRAID構成ではこのようなフォルト・トレランスはサポートされません。
通常の冗長性を使用するOracle ASMでは、データを格納するために必要なディスク領域が2倍になります。高い冗長性では3倍のディスク領域が必要です。
|
関連項目: Oracle自動ストレージ管理の管理者ガイド |
ストレージ・デバイスの最適なスループットを実現するには、複数のディスクをパラレルで作動させる必要があります。これは、ストライプ化という技法を使用して行いますが、このとき、複数のデバイスにある同じサイズのスライス(ストライプ)にデータ・ブロックを格納します。ストライプ化により、優れたパフォーマンスとスループットを得るための記憶域構成が可能になります。
ストレージ・デバイスの最適なパフォーマンスは、シーク・タイムと、ディスク上の連続ブロックへのアクセスのトレードオフで決まります。VLDB環境では、OLTPシステムとデータ・ウェアハウス・システムの両方において、ストライプ・サイズを1MBにすると、最適なパフォーマンスとスループットを実現するための適切なバランスを得られます。データベース環境でのストライプ化には次の3つの方法があります。
ハードウェアベースのストライプ化
ソフトウェアベースのストライプ化(Oracle ASMを使用する)
ソフトウェアベースのストライプ化(Oracle ASMを使用しない)
ストライプ化技法を組み合せて使用することが可能ですが、ストライプ化によってパフォーマンスを向上させるためには、ストライプを異なるデバイスに物理的に格納することを確認してください。概念の面では、Oracle ASMを使用しないソフトウェアベースのストライプ化はハードウェアベースのストライプ化と大変よく似ています。
この項の内容は次のとおりです。
|
注意: クラスタ構成では、使用するソフトウェアがクラスタ機能をサポートする必要があります。Oracle ASMは、Oracle Databaseファイル用のクラスタ・ファイルシステムです。 |
一番外側にあるストレージ・デバイスがストライプ化機能を提供します。記憶域のパフォーマンスを向上するために最もよく使用されるストライプ化技法は、RAID 0およびRAID 5です。
この項の内容は次のとおりです。
RAID 0では少なくとも2台のデバイスを実装する必要があります。デバイスに書き込まれるデータ・ブロックは、ストライプ・サイズに分割され、複数のデバイスに交互に格納されます。この技法により、複数デバイスと、デバイスの複数チャネルの使用が可能になります。
RAID 0には、RAIDという名前が付いていますが冗長性はありません。RAID 0構成でデバイスに障害が発生すると、データは損失されます。重要な環境では必ずなんらかの冗長性と組み合せる必要があります。RAID 0を使用するデータベース実装は、多くの場合、RAID 1 (基本のミラー化)と組み合せてRAID 0+1構成で使用されます。
Oracle自動ストレージ管理(Oracle ASM)は、ディスク・グループとして認識されるすべてのデバイスに対して常にストライプ化を行います。ディスク・グループは、データファイルを作成するための論理的な記憶域プールです。デフォルトのOracle ASMストライプ・サイズは1MBです。これはVLDBに適したストライプ・サイズです。
|
関連項目: Oracle ASM構成の詳細は、Oracle自動ストレージ管理の管理者ガイドを参照してください。 |
ディスク・グループ内ではパフォーマンス特性が同じディスクを使用してください。また、データを最適に分散して最適なパフォーマンスとスループットを得るには、ディスク・グループのすべてのディスクを同じサイズにする必要があります。最高のパフォーマンスを実現するために、ディスク・グループはできるだけ多くの物理スピンドルを含むようにしてください。VLDB用のディスク・グループ構成を、VLDB以外のディスク・グループ構成と変える必要はありません。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle ASMは、すでにストライプ化されたストレージ・デバイスで使用できます。そのような構成を使用する場合は、論理デバイスにまたがるディスク・グループを定義してホットスポットを生成しないようにしてください。それらの論理デバイスが、他の使用可能なリソースではなく同一のリソース(ディスク、コントローラ、またはディスクのチャネル)を物理的に使用していることがあるためです。Oracle ASMストライプがすべての物理デバイスに常に均等に分散されるようにします。
情報ライフサイクル管理(ILM)環境では、すべてのデバイスに対するストライプ化は、すべてのデータがすべての記憶域プールに分散されるため使用できません。ILM環境では、通常、記憶域プールごとにパフォーマンス特性が異なります。このため、表領域が記憶域プールにまたがらないようにしてください。つまり、同じ表領域のデータファイルを複数の記憶域プールに格納しないでください。
ILM環境の記憶域は、1つの記憶域プールのすべてのデバイスに対するストライプ化を使用するように構成する必要があります。Oracle ASMを使用する場合は、記憶域プールごとに別のディスク・グループを作成します。この方法では、表領域のデータファイルが異なるディスク・グループに格納されることはありません。データはオンラインのまま表領域間で移動できます。パーティション表にはパーティション移動操作を使用し、表がパーティション化されていない場合はDBMS_REDEFINITIONパッケージを使用します。
情報ライフサイクル管理環境の詳細は、第5章「情報ライフサイクル管理のためのパーティション化の使用」を参照してください。
使用可能なすべてのデバイスに対してストライプ化し、使用可能なすべてのリソースに負荷を分散する場合、パーティション配置は問題になりません。使用可能なすべてのデバイスにデータファイルをストライプ化できない場合は、使用可能なすべてのハードウェア・リソース(物理ディスク・スピンドル、ディスク・コントローラ、およびディスクのチャネル)の使用状況を最適化するためにパーティション配置を検討します。
I/O集中型の問合せまたはDML操作では、使用可能なすべてのリソースを最適に活用する必要があります。データベース・オブジェクト・パーティションを特定の表領域に格納し、各表領域が異なるハードウェア・リソースのセットを使用する場合、1つのパーティション・データベース・オブジェクトに対する操作ですべてのリソースを使用できるようになります。適切なパーティション化技法を使用して、I/O集中型の操作がすべてのリソースを使用できるようにしてください。
パーティション配置を使用してI/Oリソース使用率を最適化する場合、ワークロードをできるだけ均等に分散するただ1つの方法としては、ハッシュ・パーティション数を2の累乗とした、一意またはほぼ一意の列(または一連の列)に対するハッシュ・パーティション化とハッシュ・サブパーティション化があります。その他のパーティション化およびサブパーティション化の技法でも、アプリケーションによっては同様の効果が得られる場合があります。
Oracle Databaseではビッグファイル表領域を作成できます。ビッグファイル表領域は、最大128TBの1つのデータファイルまたは一時ファイルで構成されます。ビッグファイル表領域を使用すると、データベースのデータファイル数を大幅に削減できます。Oracle Database 11gでは、1つのデータファイルに対してRMANのバックアップとリストアをパラレルで実行できます。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
結果として、ビッグファイル表領域の使用にデメリットはありません。データファイルや一時ファイルの数を大幅に削減するために、ビッグファイル表領域の使用を選択できます。
ファイルの割当てはシリアル・プロセスで行われます。表および自動拡張可能データファイルの自動割当てを使用すると、ビッグファイル表領域を使用するかどうかにかかわらず、ファイルの拡張に時間がかかるため大きなデータのロードが影響を受けることがあります。ただし、データファイルを事前に割り当てて、複数データファイルを使用する場合は、複数のプロセスを生成してデータファイルを同時に追加することができます。
Oracle Database File System(DBFS)は、ファイルを格納するデータベースの利点と、リレーショナル・データを効率的に管理するデータベースの強みを活用して、データベースに格納されたファイルに対する標準のファイルシステム・インタフェースを実装します。このインタフェースを使用すると、BLOBおよびCLOBプログラム・インタフェースを使用するために特別に記述されたプログラムに制限されずに、データベースにファイルを格納できるようになります。これで、ファイルに作用する任意のオペレーティング・システム(OS)プログラムを使用して、データベース内のファイルに透過的にアクセスできるようになります。
Oracle Database File System(DBFS)は、データベース表に格納されたファイルおよびディレクトリの上部に標準ファイルシステム・インタフェースを作成します。DBFSでは、サーバーはOracle Databaseです。ファイルは、Oracle SecureFiles LOBとしてデータベース表に格納されます。PL/SQLプロシージャのセットにより、ディレクトリの作成、オープン、読取り、書込み、リストなどのファイル・システム・アクセスのプリミティブが実装されます。データベース内のファイルシステムの実装は、DBFSコンテンツ・ストア│DBFS Content Storeと呼ばれます。DBFSコンテンツ・ストア│DBFS Content Storeにより、すべてのデータベース・ユーザーは、クライアントによってマウント可能な1つ以上のファイルシステムを作成できます。それぞれのファイルシステムには、ファイルシステム・コンテンツを保持する専用の表があります。
|
関連項目: Oracle SecureFiles LOB、ストアおよびOracle Database File Systemの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 |
VLDBのきわめて重要な特性はサイズが大きいことです。記憶域のスケーラビリティと管理性は、VLDB環境の重要な要素です。サイズが大きいために次の課題があります。
VLDBでは使用されるコンポーネントが多いため、単純な統計により、記憶域コンポーネントで障害が発生する可能性が高いことが示されます。
VLDBでの小規模な相対成長は、大規模な絶対成長に相当することがあり、多くのデバイスの追加につながる場合があります。
サイズの大きさにかかわらず、パフォーマンスおよび可用性の要件は小規模システムと変わりません。
これらの課題に対処できる記憶域構成を選択する必要があります。記憶域の追加や削除を計画的に行うか状況に応じて行うかにかかわらず、システムはパフォーマンスと高可用性の観点で最適な状態を保つ必要があります。
この項の内容は次のとおりです。
SAME(Stripe and Mirror Everything)方式は、長い間オラクル社によって推奨されている、高可用性、パフォーマンスおよび管理性を最適化する方法です。構成をさらに単純化するために、SAME方式では、OLTPシステムとデータ・ウェアハウス・システムの両方での適切な開始値として1MBの固定ストライプ・サイズが推奨されます。Oracle ASMではSAME方式が実装され、さらに自動化も行われます。
最大のパフォーマンスを実現するため、SAME方式では、できるだけ多くの物理デバイスに対するストライプ化が提案されます。これはOracle ASMなしでも達成できます。ただし、デバイスの追加または削除などにより記憶域構成が変わると、デバイス上のデータベース・ファイルのレイアウトも変える必要があります。Oracle ASMではこのタスクがバックグラウンドで自動的に実行されます。Oracle ASM以外の環境のほとんどでは再ストライプ化が主要な作業であり、多くの場合は手動の処理が必要です。
ILM環境では、すべての記憶域プールにSAME方式を適用します。
VLDB用のOracle自動ストレージ管理の構成は、VLDB以外のOracle ASMの構成とほとんど変わりません。Oracle ASMインスタンスへのメモリー割当てなど特定のパラメータ値では、値を高くする必要があります。
|
関連項目: 詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle Database 11gでは、Oracle ASMの変数割当て単位が導入されています。大きな変数割当て単位は、大きな順次I/O処理を使用する環境で利点があります。一般的にVLDB、特に大規模データ・ウェアハウスは、大きな割当て単位を活用するのに適した環境です。割当て単位は、1MBから64MBの範囲で2の累乗に設定できます(1、2、4、8、16、32および64)。大きな表をスキャンする問合せが多数ワークロードに含まれている場合は、大きなOracle ASM割当て単位を使用する必要があります。非常に大規模なデータ・ウェアハウス・システムでは64MBを使用してください。また、大きな割当て単位を使用すると、Oracle ASMのメモリー要件が減少し、Oracle ASMの起動時間が短縮されます。
|
関連項目: Oracle ASMの設定および構成方法の詳細は、Oracle自動ストレージ管理の管理者ガイドを参照してください。 |
Oracle Enterprise Manager(Enterprise Manager)の「パフォーマンス」ページには、I/Oパフォーマンスの概要が示されます。このページは、記憶域構成のパフォーマンスとスループットを監視するために役立ちます。I/Oパフォーマンスのデータは、Enterprise Managerの「パフォーマンス」ページからアクセスできます。I/Oグラフには、すべてのデータベース・クライアントとデータベースのホストの基礎となるシステムから収集したI/O統計が表示されます。データベース・プロセスのI/O待機時間は、保留中のI/O処理が完了していた場合に、プロセスが有益な作業を行うことができた時間を表します。Oracle Databaseは、あらゆるOracle DatabaseプロセスによるすべてのI/O待機がI/O統計から推測されるように、すべての重要なI/OコンポーネントのI/O待機時間を同様に取得します。
3つのグラフに次のI/Oパフォーマンス・データが表示されます。
単一ブロックI/O待機時間
本番システムでは、待機時間が10ミリ秒を超えないようにしてください。待機時間が長い場合は、記憶域構成に潜在的なボトルネックがあり、ホットスポットがある可能性も高いことを意味します。
I/O MB(1秒当たり)
このメトリックはI/Oスループットを示します。I/Oスループットは、データ・ウェアハウスのパフォーマンスの重要な目安です。
1秒当たりのI/O
このメトリックは通常はIOPSと示され、OLTPアプリケーションで重要です。同時実行ユーザー数が多い大規模OLTPアプリケーションでは、IOPS値が高くなります。
I/Oブレークダウンの選択内容によっては、その他のグラフも使用できます。
インスタンス・レベル
関数ごとのI/Oの監視
タイプごとのI/Oの監視
コンシューマ・グループごとのI/Oの監視
ホスト・レベル
「合計ディスクI/O秒」ページが表示されます。
最長I/Oサービス時間
データベースはディスク・セットに存在するため、I/Oサブシステムのパフォーマンスはデータベースのパフォーマンスにとって非常に重要です。重要なディスク統計には、1秒当たりのディスクI/O処理やサービス時間の長さがあります。これらの統計は、ディスクが最適に実行されている場合、またはディスクがオーバーワークになっている場合に表示されます。
|
関連項目: インスタンスやホストのアクティビティ、リアルタイム・データベース・パフォーマンスおよびディスクI/O使用率の監視の詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。 |
