1 Oracle Exadata System Softwareの概要

この章では、Oracle Exadata System Softwareの概要について説明します。

1.1 Oracle Exadata System Softwareの概要

Oracle Exadata Storage Serverは、Oracle Databaseデータを格納してそのデータにアクセスするために、Oracle Exadata System Softwareを実行する高度に最適化されたストレージ・サーバーです。

従来型のストレージでは、データはデータベース・サーバーに転送されて処理されていました。これに対し、Oracle Exadata System Softwareでは、SQLや他のデータベース処理をデータベース・サーバーからオフロードする機能など、データベース認識型ストレージ・サービスを利用できます。このサービスは、SQL処理とデータベース・アプリケーションに対して透過的に実行されます。Oracle Exadataストレージ・サーバーは、ストレージ・レベルでデータを処理し、必要な情報のみをデータベース・サーバーに渡します。

Oracle Exadata System Softwareは、ストレージ・サーバーとデータベース・サーバーの両方にインストールされます。Oracle Exadata System Softwareによって、SQL処理がデータベース・サーバーからストレージ・サーバーにオフロードされます。Oracle Exadata System Softwareでは、従来型のデータ移動に加えて、データベース・インスタンスから基礎となるストレージへ機能を移動することが可能です。機能の移動により、データベース・サーバーで必要なデータ処理の量が大幅に軽減されます。データ転送とデータベース・サーバー・ワークロードの削減は、帯域幅によって制約されることが多かった問合せ操作に非常に大きな効果をもたらします。データ転送の削減は、大規模なバッチ処理とレポート処理の操作を実行することが多いオンライン・トランザクション処理(OLTP)システムでもきわめて有効です。

Oracle Exadata Storage Serverのハードウェア・コンポーネントは、高いパフォーマンスの処理に対応できるように慎重に選択されています。Oracle Exadata System Softwareは、ハードウェア・コンポーネントを最大限に活用できるように最適化されています。各ストレージ・サーバーでは、ディスク上の格納データに対する処理で非常に高い帯域幅が提供され、従来の方法よりも数倍優れています。

Oracle Exadataストレージ・サーバーは、サーバーとストレージとの間で最先端のRDMAネットワーク・ファブリック・インターコネクトを使用します。各RDMAネットワーク・ファブリック・リンクは、InfiniBandネットワーク・ファブリックに対して40 Gb/s、RoCEネットワーク・ファブリックに対して100 Gb/sの帯域幅を提供します。さらに、インターコネクト・プロトコルでは、ダイレクト・メモリー・アクセス(DMA)とも呼ばれる直接データ配置を使用して、余分なデータ・コピーを作成せずにデータを回線からデータ・バッファに直接移動することで、CPUのオーバーヘッドを大幅に削減しています。RDMAネットワーク・ファブリックは、LANネットワークの柔軟性とともに、ストレージ・エリア・ネットワーク(SAN)の効率性を備えています。Oracle Exadataでは、RDMAネットワーク・ファブリック・ネットワークを使用することによって、パフォーマンスを低下させる可能性のあるネットワークのボトルネックをなくしています。このRDMAネットワーク・ファブリック・ネットワークでは、Oracle Real Application Clusters (Oracle RAC)サーバー用の高いパフォーマンスのクラスタ・インターコネクトも提供されます。

各ストレージ・サーバーには永続ストレージ・メディアが含まれており、ハード・ディスク・ドライブ(HDD)とフラッシュ・デバイスが混在する場合があります。ストレージ・サーバーには複数の構成があり、それぞれが要件に基づいてストレージの一部の側面を最大化するように構成されています。

各ストレージ・サーバーには永続ストレージ・メディアが含まれており、ハード・ディスク・ドライブ(HDD)とフラッシュ・デバイスが混在する場合があります。高容量(HC)ストレージ・サーバーには、プライマリ・データ・ストレージ用のHDDと、主にキャッシュの目的で使用される高パフォーマンスのフラッシュ・メモリーが含まれています。Extreme Flash (EF)ストレージ・サーバーは、最大のパフォーマンスを目指し、オールフラッシュ・ストレージ構成になっています。拡張(XT)ストレージ・サーバーは、オンライン・データ・アーカイブなどの拡張容量アプリケーションを対象とし、HDDのみが含まれています。HCおよびEFストレージ・サーバーには、Exadata RDMAメモリー・キャッシュ(XRMEMキャッシュ)用の追加メモリーも装備されており、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用した高パフォーマンスのデータ・アクセスをサポートします。

Oracle Exadataアーキテクチャは、パフォーマンスを任意のレベルにスケールアウトします。より高いパフォーマンスとより大きなストレージ容量を達成するには、構成にストレージ・サーバー(セル)を追加します。ストレージ・サーバーの数に比例して容量が増加し、パフォーマンスも向上します。データはストレージ・サーバー間でミラー化されるため、ストレージ・サーバーで障害が発生してもデータや可用性が失われることはありません。スケールアウト・アーキテクチャによってほぼ無限のスケーラビリティが実現し、必要に応じてストレージを増設できるためコスト削減も可能になります。

ノート:

Oracle Exadata System SoftwareOracle Exadataストレージ・サーバーのハードウェアで使用する必要があり、Oracle Exadataデータベース・サーバー上のOracleデータベースのみをサポートしています。情報は次のMy Oracle Support

http://support.oracle.com

また、Oracle Technology Networkの製品ページでも確認できます

http://www.oracle.com/technetwork/index.html

1.2 Oracle Exadata System Softwareの主な機能

この項では、Oracle Exadata System Softwareの主な機能について説明します。

1.2.1 信頼性、モジュール方式、およびコスト効率

Oracle Exadata Storage Serverでは、コスト効率の高いモジュール方式のストレージ・ハードウェアがスケールアウト・アーキテクチャで採用され、高い可用性と信頼性が実現されます。

Oracle Exadata Storage Serverは、データのミラー化、障害分離テクノロジの使用、およびディスクや他のストレージ・ハードウェアの障害からの保護によって、単一障害点がなくなるように設計されています。障害発生時のブラウンアウトも制限または排除されます。

Oracle Exadata Storage Serverのアーキテクチャでは、複数のストレージ・サーバーで、1つ以上のデータベースをサポートする1つのストレージ・プールが提供されます。インテリジェントなソフトウェアでは、データは自動的かつ透過的に、複数のストレージ・サーバーに均等に配分されます。Oracle Exadata Storage Serverでは動的なディスク交換がサポートされており、Oracle Exadata System Softwareではオンラインでの動的なデータ再配分が提供されます。これにより、データベース処理が中断されることなく、ストレージ全体でデータがバランスよく配分されます。Oracle Exadata Storage Serverでは、ディスクおよびストレージ・サーバーの障害に対するデータ保護も提供されます。

1.2.2 Oracle Databaseとの互換性

最低限必要なバージョンが満たされると、Oracle Exadata System SoftwareではOracle Databaseのすべての機能が完全にサポートされます。

Oracle Exadata System Softwareは、Oracle Databaseの単一インスタンスまたはOracle Real Application Clusters (Oracle RAC)デプロイメントで同等に機能します。Oracle Data GuardOracle Recovery Manager (RMAN)Oracle GoldenGateおよび他のデータベース機能は、従来型のストレージと同様にExadataストレージ・セルで管理されます。これにより、データベース管理者は使い慣れたツールをそのまま利用できます。

最低限必要なソフトウェア・バージョンの完全なリストについては、My Oracle SupportのDoc ID 888828.1を参照してください。

1.2.3 スマート・フラッシュ・テクノロジ

Oracle Exadata System SoftwareのExadata Smart Flash Cache機能は、データベース・オブジェクトをフラッシュ・メモリー内に効率的にキャッシュし、ディスクに対する低速で機械的なI/O操作を非常に高速なフラッシュ・メモリー操作に置き換えます。

1.2.3.1 Exadata Smart Flash Cache

Exadata Smart Flash Cacheは、頻繁にアクセスされるデータを高パフォーマンスのフラッシュ・ストレージに格納します。

Exadata Smart Flash Cacheは、自動的にOracle Databaseと連携し、頻繁にアクセスされる値の高いデータを優先して、キャッシュ効率をインテリジェントに最適化します。各データベースI/Oには、データ・アクセスが繰り返される可能性を示すタグが含まれています。この情報は、内部統計およびオブジェクト・サイズやアクセス頻度などのその他の測定値と組み合せて、データをキャッシュするかどうかを決定します。

重要なこととして、Exadata Smart Flash Cacheでは、再利用されない、またはキャッシュに収まらないデータのキャッシュが回避されます。たとえば、バックアップ操作ではデータが繰り返し読み取られないため、バックアップ関連のI/Oはキャッシュされません。

デフォルトでは、キャッシュは自動的に発生し、ユーザーや管理者による作業は必要ありません。

通常は必須ではなくお薦めもしませんが、Oracle Exadata System Softwareでは、管理者がデフォルトのキャッシング・ポリシーをオーバーライドして、特定の表および索引セグメントをキャッシュ内またはキャッシュ外に保持することもできます。

当初、Exadata Smart Flash Cacheはライトスルー・モードでのみ動作していました。ライトスルー・モードでは、データベース書込みは最初にディスクに対して行われ、その後フラッシュ・キャッシュに移入されます。Exadata Smart Flash Cacheがライトスルー・モードで動作している状態でフラッシュ・デバイスに障害が発生した場合、データはすでにディスク上にあるため、データが失われることはありません。

1.2.3.2 Write-Back Flash Cache

Write-Back Flash Cacheを使用すると、Exadata Smart Flash Cacheへの直接書込みI/Oが可能になります。

Exadata Smart Flash Cacheのライトバック・モードでは、データベース書込みは最初にフラッシュ・キャッシュ、その後ディスクに対して行われます。ライトバック・モードは、Oracle Exadata System Softwareリリース11.2.3.2.0で導入されました。

書込み集中型のアプリケーションでは、フラッシュによって提供される高速レイテンシを利用することで、ライトバック・モードから多大なメリットを得ることができます。書込み集中型のアプリケーションで、I/Oレイテンシが長い場合またはfree buffer waitsの待機がかなり多い場合は、Write-Back Flash Cacheの使用を検討する必要があります。

Exadata Smart Flash Cacheをライトバック・モードで使用すると、同じブロックへの複数の書込みが、ディスクへの書込みの前にキャッシュに吸収された場合にも、ディスクI/Oの量が減少します。節約されたI/O帯域幅は、アプリケーションのスループット向上や他のワークロードの処理のために使用できます。

ただし、ライトバック・モードの使用中にフラッシュ・デバイスで障害が発生した場合、ディスクにまだ永続化されていないデータは失われるため、ミラー・コピーからリカバリする必要があります。このため、データベース・ファイルを保護するために高冗長性(3方向ミラー化)とともにライトバック・モードを使用することをお薦めします。

Write-Back Flash Cacheの内容は再起動後も保持されるため、キャッシュへの移入に必要なウォームアップ時間が不要になります。

1.2.3.3 Exadata Smart Flash Log

Exadata Smart Flash Logは、パフォーマンスが重要となるログ書込み操作を高速化することで、トランザクションのレスポンス時間を改善し、I/O集中型ワークロードのデータベース全体のスループットを向上させます。

ユーザー・トランザクションをコミットする時間は、ログ書込み操作のレイテンシの影響を大きく受けます。また、領域管理や索引分割などのパフォーマンス・クリティカルな多くのデータベース・アルゴリズムも、ログ書込みのレイテンシにより大きな影響を受けます。

ディスク・コントローラには、高速の書込みに対応した大きいバッテリ・バックアップDRAMキャッシュが備えられていますが、それでも、ビジーな期間にはディスクに書き込まれていないブロックでディスク・コントローラ・キャッシュが時々いっぱいになり、ディスクに対する一部の書込み操作が低速になることがあります。低速のREDOログ書込み操作が比較的少ない場合でも、顕著なパフォーマンスの問題が発生することがあります。

Exadata Smart Flash Logにより、パフォーマンスに依存するREDOログ書込みI/O操作の平均レイテンシが短縮されるため、低速のREDOログ書込みが原因で発生する可能性のあるパフォーマンスのボトルネックが解消されます。Exadata Smart Flash Logでは、2つのメディア・デバイスへのREDOログ書込みを同時に実行することで、レイテンシ・スパイクを排除します。いずれかのメディア・デバイスへのFirst Writesが完了するとすぐにREDO書込みが確認されます。

Oracle Exadata System Softwareリリース20.1より前は、Exadata Smart Flash Logではディスクおよびフラッシュ・ストレージへの同時書込みを実行していました。この構成では、Exadata Smart Flash Logによって平均ログ書込みレイテンシが改善され、データベース全体のスループットが向上します。ただし、すべてのログ書込みは最終的にディスクに永続化される必要があるため、この構成はディスク全体のスループットによって制限され、ディスクのスループットで制約されるアプリケーションにはほとんど役立ちません。

Oracle Exadata System Softwareリリース20.1では、ディスク記憶域ではなくExadata Smart Flash Cacheをライトバック・モードで使用する、Smart Flash Log Write-Backと呼ばれる最適化がさらに追加されています。この構成では、Exadata Smart Flash Logによって平均ログ書込みレイテンシおよびログ書込み全体のスループットが向上し、要求の厳しいスループット集中型アプリケーションのロギングのボトルネックが排除されます。

1.2.4 永続メモリー・アクセラレータおよびRDMA

永続メモリー(PMEM)アクセラレータを使用すると、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用して永続メモリーに直接アクセスできできることで、レスポンス時間が速くなり、読取りレイテンシが短縮されます。

ノート:

PMEMは、高容量(HC)またはExtreme Flash (EF)ストレージを搭載したExadata X8M-2およびX9M-2ストレージ・サーバー・モデルでのみ使用できます。

Oracle Exadata System Softwareリリース19.3.0以降では、株式取引、IOTデバイスなどの極端に短いレスポンス時間を必要とするワークロードで、PMEMキャッシュとPMEMログの形式でPMEMとRDMAを利用できます。

データベース・クライアントがPMEMキャッシュから読み取ると、クライアント・ソフトウェアはキャッシュされたデータのRDMA読取りを実行します。これにより、ストレージ・サーバー・ソフトウェアがバイパスされ、結果がExadata Smart Flash Cacheよりもはるかに高速に配信されます。

PMEMキャッシュは、Exadata Smart Flash Cacheと連携します。次の表では、PMEMキャッシュの構成時にサポートされるキャッシュ・モードの組合せについて説明します。

PMEMキャッシュ・モード フラッシュ・キャッシュ・モード サポートされている構成は次のとおりです。
ライトスルー ライトスルー

はい。

これは、標準冗長性の高容量(HC)サーバーのデフォルト構成です。

ライトスルー ライトバック

はい。

これは、高冗長性のHCサーバーのデフォルト構成です。これは、Extreme Flash (EF)サーバーのデフォルト構成でもあります。

ライトバック ライトバック

はい。

ただし、ベスト・プラクティスの推奨事項は、ライトスルー・モードでPMEMキャッシュを構成することです。この構成によって、最高のパフォーマンスと可用性が提供されます。

ノート: Oracle Exadata System Softwareリリース23.1.0以降、PMEMキャッシュはライトスルー・モードでのみ動作します。

ライトバック ライトスルー

いいえ。

Write-Back Flash Cacheで補わないと、書込み集中型のワークロードによってライトバック・モードのPMEMキャッシュが過負荷になる可能性があります。

PMEMキャッシュが構成されていない場合、Exadata Smart Flash Cacheはライトバック・モードとライトスルー・モードの両方でサポートされます。

REDOログの書込みは重要なデータベース操作であり、負荷の急増や停止を防ぐために適切なタイミングで完了する必要があります。Exadata Smart Flash Logは、REDO書込みレイテンシの外れ値を抑制するように設計されています。PMEMログは、PMEMおよびRDMAを使用することで、REDOログ書込みレイテンシをさらに短縮するために役立ちます。

PMEMログを使用すると、データベース・クライアントはRDMAを使用してREDOログI/Oバッファをストレージ・サーバーのPMEMに直接送信するため、転送レイテンシが短縮されます。その後、セル・サーバー(cellsrv)はREDOをExadata Smart Flash Log(有効な場合)およびディスクに書き込みます。

REDOログの書込みレイテンシが短縮されるとOLTPのパフォーマンスが向上し、トランザクションのスループットが向上します。PMEM Logがバイパスされる場合でも、Exadata Smart Flash Logを使用できます。

1.2.5 Exadata RDMAメモリー

Oracle Exadata System Softwareリリース23.1.0では、Exadata RDMAメモリー(XRMEM)が導入されています。XRMEMには、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用したストレージ・サーバー・メモリーへの直接アクセスを提供するすべてのExadata機能が組み込まれており、レスポンス時間の短縮と読取りレイテンシの削減を実現します。

XRMEMには、以前のExadataデータと、Exadata X8MおよびX9Mストレージ・サーバー・モデルでのみ使用可能な永続メモリー(PMEM)に基づくコミット・アクセラレータが含まれています。Exadata X10M以降、XRMEMは、特殊な永続メモリーを必要とせずにRDMAのメリットが得られ、メモリーおよびストレージ・ハードウェアの開発を利用する準備が整っています。

Exadata X10Mシステムでは、株式取引やIOTデバイスなど、非常に短いレスポンス時間を必要とするワークロードには、XRMEMキャッシュを利用できます。データベース・クライアントがXRMEMキャッシュから読み取る場合、クライアント・ソフトウェアはキャッシュされたデータのRDMA読取りを実行します。これにより、ストレージ・サーバーのソフトウェアおよびネットワーク・レイヤーがバイパスされ、高価なCPU割込みおよびコンテキスト・スイッチが排除され、Exadata Smart Flash Cacheよりもはるかに高速に結果が提供されます。この場合、XRMEMキャッシュはライトスルー・モードでのみ動作し、データベース書込みは永続ストレージに保存されます。

Exadata X10Mでは、高パフォーマンスの動的ランダム・アクセス・メモリー(DRAM)を利用する、高容量(HC)およびExtreme Flash (EF) Exadata X10Mストレージ・サーバーでXRMEMキャッシュを使用できます。この環境では、XRMEMキャッシュは自動的に機能するため、個別の構成や継続的な管理は必要ありません。

Oracle Exadata System Softwareリリースが23.1.0の既存のExadata X8MおよびX9Mシステムでは、永続メモリー・データ・アクセラレータPMEMキャッシュ(またはPMEMCACHE)はXRMEMキャッシュ(またはXRMEMCACHE)と呼ばれるようになりました。同様に、永続メモリー・コミット・アクセラレータ(PMEMログ(またはPMEMLOG)とも呼ばれる)もXRMEMログ(またはXRMEMLOG)になりました。ただし、PMEMCACHEおよびPMEMLOGリソースを管理するためのCellCLIコマンドは、下位互換性のために引き続き使用できます。

Oracle Exadata System Softwareリリース23.1.0では、Exadata X10MシステムにはXRMEMLOGは実装されません。

1.2.6 集中型ストレージ

Oracle Exadataを使用すると、ストレージ要件を、複数のデータベースで使用可能な中央のプールに統合できます。

Oracle Exadataでは、Exadataストレージ・サーバーの使用可能ディスク間で、すべてのデータベースのデータおよびI/O負荷が均等に配分されます。利用可能なすべてのディスクをすべてのデータベースで使用できるため、優れたI/Oレートが実現します。Oracle Exadataでは、低コストで高い効率とパフォーマンスを実現できるだけでなく、ストレージ管理のオーバーヘッドも低減できます。

1.2.7 I/Oリソース管理(IORM)

I/Oリソース管理(IORM)およびOracle Database Resource Managerでは、複数のデータベースおよびプラガブル・データベース間で同じストレージを共有できるのみならず、様々なデータベースにI/Oリソースを割り当てることができます。

Oracle Exadata System Softwareは、IORMおよびOracle Database Resource Managerと連動することにより、複数のデータベース間で同じストレージ・サーバーのセットを共有する場合でも、顧客定義のポリシーを満たすことができます。その結果、1つのデータベースでI/O帯域幅を占有して他のデータベースのパフォーマンスが低下することがなくなります。

IORMでは、管理者が設定した共有および優先順位のレベルに従って、すべてのデータベースの複数のアプリケーションおよびユーザー間で、ストレージ・セルのI/Oリソースを管理できます。これにより、スループットに依存するバッチ・アプリケーションよりもレイテンシに依存するオンライン・トランザクション処理(OLTP)アプリケーションにディスクおよびフラッシュI/O帯域幅を多く割り当てることができるため、OLTPとレポート処理のワークロードのバランスが改善します。Oracle Database Resource Managerを使用することにより、管理者はデータベース・ホストでのプロセッサの使用率をアプリケーション単位で制御できます。IORMOracle Database Resource Managerを組み合せることにより、管理者はより正確なポリシーを設定できます。

IORMでは、Exadata Smart Flash CacheおよびExadata RDMAメモリー・キャッシュ(XRMEMキャッシュ)の領域使用率も管理されます。クリティカルなOLTPワークロードには、Exadata Smart Flash CacheまたはXRMEMキャッシュ内の領域を保証することで、安定したパフォーマンスを提供できます。

データベース用のIORMまたはプラガブル・データベース(PDB)は、Oracle Database Resource Managerから実装および管理されます。データベース・インスタンスのOracle Database Resource Managerは、ストレージ・セル内のIORMソフトウェアと通信して、ユーザー定義のサービス・レベルのターゲットを管理します。データベース・リソース・プランはデータベースから管理されますが、データベース間のプランはストレージ・セル上で管理されます。

1.2.8 Exadata Hybrid Columnar Compression

Exadata Hybrid Columnar Compressionでは、列編成を使用してデータを格納し、類似した値を近接させることで圧縮率を高めています。

Exadata Hybrid Columnar Compressionを使用すると、データは圧縮ユニットと呼ばれる行のセットに編成されます。圧縮ユニット内では、データは列ごとに編成されてから圧縮されます。各行は圧縮ユニット内で自己完結しています。

データベース操作は圧縮オブジェクトに対して透過的に実行されるため、アプリケーションを変更する必要はありません。データベースでは、任意のSQL操作によって処理されるデータを圧縮しますが、ダイレクト・パス・ロードでは圧縮レベルがより高くなります。

ユーザーの要件に応じて、次のタイプのExadata Hybrid Columnar Compressionを指定できます。

  • ウェアハウス圧縮: このタイプの圧縮は、問合せパフォーマンス用に最適化されており、データ・ウェアハウス・アプリケーション向けです。
  • アーカイブ圧縮: このタイプの圧縮は、最大の圧縮レベル用に最適化されており、履歴データおよび変更されないデータ向けです。

たとえば、Exadata Hybrid Columnar Compressiondaily_sales表に適用するとします。1日の終わりに、品目と販売数が表に移入され、品目IDと日付がコンポジット主キーになります。次の表に、行サブセットを示します。

表1-1 サンプル表daily_sales

Item_ID Date Num_Sold Shipped_From Restock

1000

01-JUN-07

2

WAREHOUSE1

Y

1001

01-JUN-07

0

WAREHOUSE3

N

1002

01-JUN-07

1

WAREHOUSE3

N

1003

01-JUN-07

0

WAREHOUSE2

N

1004

01-JUN-07

2

WAREHOUSE1

N

1005

01-JUN-07

1

WAREHOUSE2

N

データベースでは、圧縮ユニットと呼ばれる内部構造に行のセットを格納します。たとえば、前述の表の行が1つのユニットに格納されるとします。Exadata Hybrid Columnar Compressionでは、値を行にマップするメタデータとともに、列4の一意の値をそれぞれ格納します。概念上は、圧縮値は次のように表現されます。

WAREHOUSE1WAREHOUSE3WAREHOUSE2

次に、データベースでは、この値で繰り返されているWAREHOUSEという語を圧縮するために、この語を1回だけ格納し、その各出現箇所を参照で置き換えます。参照のサイズが元の語より小さければ、データベースは圧縮に成功したことになります。圧縮の利点は、一意の値が1つのみ含まれるDate列で特に明らかです。

次の図に示すように、各圧縮ユニットは、複数のデータ・ブロックにまたがることができます。特定の列の値は、複数のブロックにまたがる場合とまたがらない場合があります。

Exadata Hybrid Columnar Compressionでは、暗黙的に行がロックされます。非圧縮のデータ・ブロックで行の更新が発生した場合、更新される行のみがロックされます。これに対して、更新が圧縮ユニットのいずれかの行で発生した場合、データベースではそのユニットのすべての行をロックする必要があります。Exadata Hybrid Columnar Compressionを使用して行を更新すると、ROWIDが変更されます。

ノート:

表でExadata Hybrid Columnar Compressionを使用する場合、Oracle DMLでは、比較的大きなデータ・ブロック(圧縮ユニット)がロックされるため、同時実行性が低下する可能性があります。

Oracle Databaseでは、表の圧縮で4つの方法がサポートされます。

表1-2 表の圧縮方法

表の圧縮方法 圧縮レベル CPUオーバーヘッド アプリケーション

基本圧縮

高い

最小

DSS

OLTP圧縮

高い

最小

OLTP、DSS

ウェアハウス圧縮

より高い(圧縮レベルは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します)

より高い(CPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します)

DSS

アーカイブ圧縮

最高(圧縮レベルは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します)

最高(CPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します)

アーカイブ

ウェアハウス圧縮とアーカイブ圧縮では、Exadata Hybrid Columnar Compressionテクノロジが使用されるため、最高の圧縮レベルが実現します。Exadata Hybrid Columnar Compressionテクノロジでは、行優先ストレージではなく、修正された形式の列指向ストレージが使用されます。これにより、データベースでは、同様のデータをまとめて格納できるため、圧縮アルゴリズムの効率性が向上します。Exadata Hybrid Columnar Compressionでは、DMLでCPUオーバーヘッドが多く必要とされるため、更新頻度の低いデータにのみこの圧縮機能を使用してください。

より高い圧縮レベルのExadata Hybrid Columnar Compressionは、ダイレクト・パス・インサートが行われるデータでのみ実現されます。従来の挿入および更新もサポートされますが、その場合はより低い圧縮形式となり、圧縮レベルも低下します。

次の表は、表の各圧縮方法の特徴を示しています。

表1-3 表の圧縮の特徴

表の圧縮方法 CREATE/ALTER TABLEの構文 ダイレクト・パス・インサート DML

基本圧縮

COMPRESS [BASIC]

COMPRESSCOMPRESS BASICは同等です

ノート: 挿入および更新された行は圧縮されません。

OLTP圧縮

COMPRESS FOR OLTP

ウェアハウス圧縮

COMPRESS FOR QUERY [LOW|HIGH]

CPUオーバーヘッドが高くなります。

ノート: 挿入および更新された行は、より低い圧縮形式でブロックに配置されるため、圧縮レベルは低下します。

アーカイブ圧縮

COMPRESS FOR ARCHIVE [LOW|HIGH]

ノート: 挿入および更新された行は圧縮されません。挿入および更新された行は、より低い圧縮形式でブロックに配置されるため、圧縮レベルは低下します。

COMPRESS FOR QUERY HIGHオプションは、デフォルトのデータ・ウェアハウス圧縮モードです。これにより、適切な圧縮およびパフォーマンスが実現します。COMPRESS FOR QUERY LOWオプションは、ロード・パフォーマンスが非常に重要な環境で使用する必要があります。このオプションでは、COMPRESS FOR QUERY HIGHオプションで圧縮されたデータより高速にロードが行われます。

COMPRESS FOR ARCHIVE LOWオプションは、デフォルトのアーカイブ圧縮モードです。これにより、高い圧縮レベルと適切な問合せパフォーマンスが実現します。このオプションは、アクセス頻度の低いデータに適しています。めったにアクセスされないデータに対しては、COMPRESS FOR ARCHIVE HIGHオプションを使用する必要があります。

DBMS_COMPRESSIONパッケージで提供される圧縮アドバイザを使用すると、特定の表に特定の圧縮方法を適用したときに予想される圧縮レベルを確認できます。

表の圧縮は、CREATE TABLEコマンドのCOMPRESS句で指定します。既存の表で圧縮を有効にするには、ALTER TABLE文でこれらの句を使用します。この場合、圧縮の有効後に挿入または更新されたデータのみが圧縮されます。同様に、既存の圧縮表で表の圧縮を無効にするには、ALTER TABLE...NOCOMPRESSコマンドを使用します。この場合、すでに圧縮されているすべてのデータは圧縮されたままですが、新規データは圧縮されずに挿入されます。

1.2.9 インメモリー列形式のサポート

Oracle Exadata環境では、データをインメモリー列形式でフラッシュ・キャッシュに格納することでパフォーマンスが向上する場合は、自動的にそのようになります。

Oracle Exadataでは、必要な圧縮列のみへのアクセス、SIMDベクター処理、ストレージ索引などのすべてのインメモリー最適化がサポートされます。

INMEMORY_SIZEデータベース初期化パラメータをゼロ以外の値に設定すると(Oracle Database In-Memoryオプションが必要)、スマート・スキャンを使用してアクセスされたオブジェクトはフラッシュ・キャッシュに挿入され、インメモリー列形式に自動的に変換されます。データは最初は列キャッシュ形式に変換されますが、この形式はOracle Database In-Memoryの列形式とは異なります。データは、バックグラウンドでOracle Database In-Memory列形式に書き換えられます。結果的に、データに対するその後のすべてのアクセスで、そのデータがフラッシュ・キャッシュから取得されるときにインメモリー最適化のすべてからメリットを得られます。



インメモリー表への書込みでは、その表の列キャッシュ全体は無効になりません。これにより無効になるのは、ブロックが存在するディスク・リージョンの列キャッシュ単位のみです。表の更新後の後続のスキャンでは、表の大部分はまだ列キャッシュ内にあります。スキャンでは列キャッシュを引き続き使用できます(書込みが行われた単位は除く)。このような単位の場合、問合せでは元のブロック・バージョンを使用してデータが取得されます。十分な数のスキャンの後、無効化された列キャッシュ単位は列形式で自動的に再移入されます。

また、インメモリー列形式を使用してどのオブジェクトをフラッシュに移入しないようにするか、およびどのタイプの圧縮を使用するかの制御に役立つ、新しいセグメント・レベルの属性CELLMEMORYも導入されました。INMEMORY属性と同様に、CELLMEMORY属性に対するサブラベルとして異なる圧縮レベルを指定できます。ただし、すべてのINMEMORY圧縮レベルが使用できるわけではありません。MEMCOMPRESS FOR QUERY LOWおよびMEMCOMPRESS FOR CAPACITY LOW (デフォルト)のみです。CELLMEMORY属性は、次のようなSQLコマンドを使用して指定します。

ALTER TABLE trades CELLMEMORY MEMCOMPRESS FOR QUERY LOW

Oracle Database In-Memoryで使用可能なPRIORTY副句は、Oracle Exadataでは使用できません。これは、Exadataストレージ・サーバーのフラッシュ・キャッシュを移入するプロセスがOracle Databaseサーバーのインメモリー列ストアへのDRAMの移入と異なるためです。

1.2.10 データ検索およびデータ取得処理のオフロード

Exadataスマート・スキャンにより、検索および取得の処理をストレージ・サーバーにオフロードします。

スマート・スキャンでは、選択したOracle Database関数がOracle Exadata Storage Server内で実行されます。この機能により、データベース・サーバーのI/Oの量が最小限に抑えられて、データベース・サーバーとストレージ・サーバーの間のI/O関連の通信量が減少するため、問合せのパフォーマンスが向上します。さらに、スマート・スキャンによって節約されたデータベース・サーバーのCPUを使用して、システム・スループット全体を向上させることができます。

スマート・スキャンでは、ダイレクト・パス読取りメカニズム(つまり並列操作および大規模な順次スキャン)を使用する、全表スキャン、高速全索引スキャンおよび高速全ビットマップ索引スキャンが自動的に最適化されます。Oracle Exadata Storage Server内でスマート・スキャンによって実行される主な機能を次に示します。

  • 条件のフィルタ処理

    スマート・スキャンの条件フィルタ処理では、条件評価のためにすべての行がデータベース・サーバーに転送されるのではなく、問合せ基準に一致する行のみがデータベース・サーバーに送られるようになります。サポートされている条件演算子としては、=!=<><=>=IS [NOT] NULLLIKE[NOT] BETWEEN[NOT] INEXISTSIS OF typeNOTANDおよびORがあります。また、Exadata Storage Serverによって、条件のフィルタ処理の間に、最も一般的なSQLファンクションが評価されます。

  • 列のフィルタ処理

    スマート・スキャンの列フィルタ処理では、すべての行がデータベース・サーバーに転送されるのではなく、要求された列のみがデータベース・サーバーに送られるようになります。列が多い表や、列にLOBが含まれている表の場合は、列のフィルタ処理によって節約されるI/O帯域幅が非常に大きくなる可能性があります。

たとえば、次の単純な問合せについて考えてみましょう。

SQL> SELECT customer_name FROM calls WHERE amount > 200;

この場合、スマート・スキャンによって、条件のフィルタ処理(WHERE amount > 200)および列のフィルタ処理(SELECT customer_name)がExadataストレージ・サーバーにオフロードされます。この効果は、表のサイズ、構造および内容によっては非常に大きくなります。たとえば、表に1 TBのデータが含まれているが問合せ結果が2 MBのみの場合は、2 MBのデータのみがストレージ・サーバーおよびデータベース・サーバーから転送されまです。

次の図では、ストレージ・サーバーとデータベース・サーバーの間の不要なデータ転送がスマート・スキャンによってどのように回避されるかを示します。

図1-2 データ検索および取得のオフロード

図1-2の説明が続きます。
「図1-2 データ検索および取得のオフロード」の説明

スマート・スキャンでは、条件のフィルタ処理および列のフィルタ処理のオフロードの他に、次のことが可能です。

  • スター・スキーマ用の最適化された結合処理(大きい表と小さい参照表との結合)。これは、ブルーム・フィルタを使用して実装され、要素がセットのメンバーであるかどうかを判断するための非常に効率的な確率論的手法を提供します。

  • 暗号化された表領域および暗号化された列に対する最適化されたスキャン。暗号化された表領域の場合は、Exadata Storage Serverで、ブロックを復号化してその復号化したブロックをOracle Databaseに返すことや、暗号化されたデータに対して行および列のフィルタ処理を実行できます。CPUの負荷が高い復号化処理をExadataセルにオフロードすることで、データベース・サーバー内のCPUを大幅に節約します。

  • 圧縮データに対する最適化されたスキャン。スマート・スキャンはハイブリッド列圧縮と連携することで、列射影、行のフィルタ処理および圧縮解除をExadata Storage Serverで実行してデータベース・サーバーでのCPUサイクルを節約します。

  • データ・マイニング・モデル用のスコアリング関数(PREDICTION_PROBABILITYなど)のオフロード。これによって、分析の処理速度が速くなると同時に、データベース・サーバーのCPUの消費と、データベース・サーバーとストレージ・サーバーの間のI/O負荷が減少します。

1.2.11 増分バックアップ処理のオフロード

増分バックアップのパフォーマンスを最適化するために、ブロックのフィルタ処理をデータベースからOracle Exadata Storage Serverにオフロードできます。

この最適化は、Oracle Recovery Manager(RMAN)を使用してバックアップを実行する場合にのみ可能です。オフロード処理は、ユーザー操作なしで透過的に実行されます。オフロード処理では、実行中の増分バックアップで不要なブロックがOracle Exadata System Softwareによってフィルタ処理されます。このため、バックアップに必要なブロックのみがデータベースに送信されるため、バックアップ時間が大幅に短縮します。

1.2.12 検疫による障害分離

Oracle Exadata System Softwareには、過去のイベントから学習してエラーを回避する機能があります。

過去に不完全なSQL文によってサーバーがクラッシュした場合、Oracle Exadata System SoftwareはSQL文を検疫し、再度不完全なSQL文が発生した場合は、SQL文がスマート・スキャンを実行できないようにします。これによって、サーバー・ソフトウェアがクラッシュする可能性が減り、ストレージ機能が改善されます。使用できる検疫タイプは、次のとおりです。

  • SQLプラン: SQL文にスマート・スキャンを実行中にOracle Exadata System Softwareがクラッシュすると作成されます。その結果、SQL文のSQLプランが検疫され、SQL文のスマート・スキャンは無効化されます。

  • ディスク領域: ディスク領域のスマート・スキャンを実行中にOracle Exadata System Softwareがクラッシュすると作成されます。その結果、1 MBのディスク領域が検疫され、ディスク領域のスマート・スキャンは無効化されます。

  • データベース: Oracle Exadata System Softwareが特定のデータベースがセルの不安定性を引き起こしていることを検出すると作成されます。不安定性検出は、データベースのSQLプラン検疫数に基づきます。データベースのスマート・スキャンは無効化されます。

  • セル・オフロード: Oracle Exadata System Softwareが一部のオフロード機能がセルの不安定性を引き起こしたことを検出すると作成されます。不安定性検出はセルのデータベース検疫数に基づきます。すべてのデータベースのスマート・スキャンは無効化されます。

  • データベース内プラン: データベース内リソース・プランの処理中にOracle Exadata System Softwareがクラッシュすると作成されます。これにより、データベース内リソース・プランは隔離され、適用されません。同じデータベース内の他のデータベース内リソース・プランは引き続き適用されます。他のデータベース内のデータベース内リソース・プランは、影響を受けません。

  • データベース間プラン: データベース間リソース・プランの処理中にOracle Exadata System Softwareがクラッシュすると作成されます。これにより、データベース間リソース・プランは隔離され、適用されません。他のデータベース間リソース・プランが引き続き適用されます。

  • I/Oリソース管理(IORM): I/O処理コード・パスでOracle Exadata System Softwareがクラッシュすると作成されます。IORMの目標をbasicに設定すると、IORMが効果的に無効化され、すべてのリソース・プランが無視されます。

  • Cell-to-Cell Offload: 詳細は、「 Cell-to-Cell Offload操作に対する隔離マネージャのサポート」を参照してください。

検疫が作成されると、何が検疫され、検疫が作成された理由、検疫を手動で削除できるタイミングと方法、検疫が自動で削除されるタイミングが管理者にアラートで通知されます。セルにパッチが適用またはアップグレードされると、検疫はすべて自動的に削除されます。

CellCLIコマンドは手動で検疫を処理する場合に使用します。たとえば、管理者は検疫を手動で作成、削除、検疫の属性を変更、検疫を表示できます。

1.2.12.1 Cell-to-Cell Offload操作に対する隔離マネージャのサポート

Oracle Exadata System Software 12.2.1.1.0以降では、ASMリバランスおよび高スループット書込みをサポートするCell-to-Cellオフロード操作に対して、隔離マネージャのサポートが提供されます。これらの操作の間にExadataでクラッシュが検出されると、問題のある操作が隔離され、Exadataで、オフロードされない操作が使用されるようになります。

これらのタイプの隔離は、互換性のないバージョンのCELLSRVが原因である可能性があります。ご使用のシステムでこのような隔離が発生した場合は、Oracleサポート・サービスに連絡してください。

これらのタイプの隔離を識別するには、LIST QUARANTINE DETAILコマンドを実行し、quarantineType属性の値を確認します。これらの隔離に関連付けられている値は、ASM_OFFLOAD_REBALANCEHIGH_THROUGHPUT_WRITEです。

次に、LIST QUARANTINEコマンドによって生成される出力の例を示します。

ASMリバランスの場合:

CellCLI> list quarantine detail
 name:                   2
 asmClusterId:           b6063030c0ffef8dffcc99bd18b91a62
 cellsrvChecksum:        9f98483ef351a1352d567ebb1ca8aeab
 clientPID:              10308
 comment:                None
 crashReason:            ORA-600[CacheGet::process:C2C_OFFLOAD_CACHEGET_CRASH]
 creationTime:           2016-06-23T22:33:30-07:00
 dbUniqueID:             0
 dbUniqueName:           UnknownDBName
 incidentID:             1
 quarantineMode:         "FULL Quarantine"
 quarantinePlan:         SYSTEM
 quarantineReason:       Crash
 quarantineType:         ASM_OFFLOAD_REBALANCE
 remoteHostName:         slc10vwt
 rpmVersion:             OSS_MAIN_LINUX.X64_160623

非コンテナ・データベースから発生した高スループット書込みの場合:

CellCLI> list quarantine detail
 name:                   10
 asmClusterId:           b6063030c0ffef8dffcc99bd18b91a62
 cellsrvChecksum:        9f98483ef351a1352d567ebb1ca8aeab
 clientPID:              8377
 comment:                None
 crashReason:            ORA-600[CacheGet::process:C2C_OFFLOAD_CACHEGET_CRASH]
 creationTime:           2016-06-23T23:47:01-07:00
 conDbUniqueID:          0
 conDbUniqueName:        UnknownDBName
 dbUniqueID:             4263312973
 dbUniqueName:           WRITES
 incidentID:             25
 quarantineMode:         "FULL Quarantine"
 quarantinePlan:         SYSTEM
 quarantineReason:       Crash
 quarantineType:         HIGH_THROUGHPUT_WRITE
 remoteHostName:         slc10vwt
 rpmVersion:             OSS_MAIN_LINUX.X64_160623

コンテナ・データベース(CDB)から発生した高スループット書込みの場合:

CellCLI> list quarantine detail
 name:                   10
 asmClusterId:           eff096e82317ff87bfb2ee163731f7f7
 cellsrvChecksum:        9f98483ef351a1352d567ebb1ca8aeab
 clientPID:              17206
 comment:                None
 crashReason:            ORA-600[CacheGet::process:C2C_OFFLOAD_CACHEGET_CRASH]
 creationTime:           2016-06-24T12:59:06-07:00
 conDbUniqueID:          4263312973 
 conDbUniqueName:        WRITES 
 dbUniqueID:             0 
 dbUniqueName:           UnknownDBName 
 incidentID:             25
 quarantineMode:         "FULL Quarantine"
 quarantinePlan:         SYSTEM
 quarantineReason:       Crash
 quarantineType:         HIGH_THROUGHPUT_WRITE
 remoteHostName:         slc10vwt
 rpmVersion:             OSS_MAIN_LINUX.X64_160623

1.2.13 データ破損の防止

データ破損が起こるのは非常にまれですが、発生した場合は、データベース、さらには業務に壊滅的な影響を与える可能性があります。

Oracle Exadata System Softwareでは、物理ビットだけでなくビジネス・データも保護することにより、高いレベルのデータ保護を実現します。

破損データを検出および防止するための主な方法は、ストレージ・サブシステムがOracleブロック・コンテンツを検証するブロック・チェックです。Oracle Databaseでは、データベース・ブロックを検証して保護情報を追加しますが、Oracle Exadata System Softwareでは、データベースおよびストレージ間のI/Oパスに送信される破損データを検出します。ストレージ・サーバーは破損データがディスクに書き込まれないように阻止します。これにより、従来型のデータベース製品では防止できなかった大規模な障害を回避できます。

他の破損チェックの実装と異なり、Oracle Exadata System Softwareによるチェックは、完全に透過的に動作します。データベースやストレージ層にパラメータを設定する必要はありません。これらのチェックでは、Oracle Automatic Storage Management (Oracle ASM)ディスク・リバランス操作やディスク障害など、すべてのケースを透過的に処理します。

1.2.14 高速ファイル作成

ファイル作成操作はOracle Exadata Storage Serverにオフロードされます。

ファイル作成のオフロードにより、1つ以上のファイル作成を可能にするCREATE TABLESPACEなどの操作が大幅に高速化します。

ファイルのサイズ変更操作もストレージ・サーバーにオフロードされます。これは自動拡張可能ファイルで重要です。

1.2.15 ストレージ索引

Oracle Exadata Storage Serverはディスク上のデータ分散のサマリーを含むストレージ索引を管理します。

ストレージ索引は自動的に管理され、Oracle Databaseに対して透過的です。これはメモリー内領域の索引を収集したもので、Exadata 12.2.1.1.0より前は、領域索引ごとに最大8列のサマリーが格納されていましたが、Exadata 12.2.1.1.0からは、領域索引ごとに最大24列のサマリーを格納できます。セット・サマリーを使用する場合は、最大数の24に達しないことがあります。ディスク上の各1MBの領域に領域索引が1つあります。ストレージ索引は、すべての非言語データ型で動作し、非言語索引に似た言語データ型でも動作します。

各領域索引では、表の列の最小値および最大値を管理します。最小値および最大値は、不要なI/Oの回避に使用されます。これは、I/Oフィルタリングとも呼ばれます。V$SYS_STATビューおよびV$SESSTATビューにあるCell physical IO bytes saved by storage index統計には、ストレージ索引を使用して保存されたI/Oのバイト数が表示されます。1つの領域索引に格納されているコンテンツは、その他の領域索引とは無関係です。これにより高スケーラブルとなり、ラッチの競合が回避されます。

次の比較を使用した問合せは、ストレージ索引によって改善されています。

  • 等価(=)

  • 不等価(<、!=、>)

  • 以下(<=)

  • 以上(>=)

  • IS NULL

  • IS NOT NULL

Oracle Exadata System Softwareでは、領域内の列の最大値よりも大きいか、最小値よりも小さいという比較述語が指定された問合せの後、ストレージ索引が存在していれば効果があるとみなされる場合に、自動的にストレージ索引を作成します。Oracle Exadata System Softwareでは、どのストレージ索引が問合せに効果があったかを自動的に学習し、その情報に基づいてストレージ索引を自動的に作成するため、似たような問合せを今後受け取った場合に効果的です。

Oracle Exadata System Softwareリリース12.2.1.1.0以降では、インメモリー形式の列指向キャッシュを使用してデータが格納されている場合、Oracle Exadata Database Machineは、ディクショナリ・エンコーディングを使用して圧縮されたこれらの列を格納します。固有値が200個より少ない列の場合、ストレージ索引は、ディクショナリの非常にコンパクトなインメモリー表現を作成し、このコンパクトな表現を使用して等価条件に基づいてディスク読取りをフィルタ処理します。この機能は、セット・メンバーシップと呼ばれます。より制限されたフィルタ処理機能が、固有値400個まで拡張されています。

たとえば、ディスクの1リージョンで米国およびカナダの顧客のリストを保持しているとします。メキシコの顧客を検索する問合せを実行する場合は、Oracle Exadata Storage Serverで、新しいセット・メンバーシップ機能を使用して、メキシコからの顧客を含まないディスク・リージョンを除外することで、問合せのパフォーマンスを向上させることができます。セット・メンバーシップ機能がない、12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、通常のストレージ索引でこれらのディスク・リージョンをフィルタ処理できません。

ノート:

問合せのWHERE句に頻繁に出現する列に基づいて行を順序付けると、ストレージ索引の効果が上がります。

ノート:

ストレージ索引は、圧縮されていないブロックおよびOLTPの圧縮されたブロックへの書込み操作中に管理されます。Exadata Hybrid Columnar Compressionによって圧縮されたブロックまたは暗号化された表領域への書込み操作は、領域索引と特定の領域のストレージ索引のみを無効化します。Exadata Hybrid Columnar Compression用のストレージ索引は、後続のスキャンで再構築されます。

例1-1 ストレージ索引を使用したディスクI/Oの回避

次の図は、表および領域索引を示しています。表内の値の範囲は1から8までです。一方の領域索引には最小値として1、最大値として5が格納されています。もう一方の領域索引には、最小値として3、最大値として8が格納されています。

SELECT * FROM TABLE WHERE B<2などの問合せの場合、最初の行セットのみが一致します。2番目の行セットの最小値と最大値は問合せのWHERE句と一致しないため、ディスクI/Oが回避されます。

例1-2 ストレージ索引から得られるパーティション・プルーニングのような効果

次の図には、Order_NumberOrder_DateShip_DateおよびOrder_Item列があるOrdersという表があります。表はOrder_Date列によってレンジ・パーティションされています。

次の問合せは2015年1月1日以降のオーダーを検索します。

SELECT count (*) FROM Orders WHERE Order_Date >= to_date ('2015-01-01', \
'YYY-MM-DD')

表はOrder_Date列でパーティション化されているため、この問合せは表の不要なパーティションのスキャンを回避します。Order_Dateのパーティション化はShip_Dateに対する問合せに効果があるわけではありませんが、Ship_DateOrder_NumberOrder_Dateと密に相関しています。ストレージ索引では、パーティション化またはソート・ロードによって作成された順序付けを利用し、それを表内の他の列で使用できます。これにより、Ship_Date列およびOrder_Number列に対する問合せでパーティション・プルーニングのようなパフォーマンスが実現されます。

例1-3 ストレージ索引による結合パフォーマンスの向上

ストレージ索引を使用すると、表の結合で不要なI/O操作をスキップできます。たとえば、次の問合せでは、I/O操作を実行し、ファクト表の最初のブロックにのみブルーム・フィルタを適用しています。

SELECT count(*) FROM fact, dim WHERE fact.m=dim.m AND dim.product="Hard drive"

ファクト表の2番目のブロックに対するI/Oは、最小値/最大値の範囲(5,8)がブルーム・フィルタに存在しないため、ストレージ索引によって完全に回避されます。

1.3 Oracle Exadata System Softwareのコンポーネント

この項では、次のOracle Exadata System Softwareコンポーネントのサマリーを示します。

1.3.1 Oracle Exadata System Softwareについて

Oracle Exadata System Softwareのユニークなソフトウェア・アルゴリズムは、ストレージでのデータベース・インテリジェンス、PCIベースのフラッシュおよびRDMAネットワーク・ファブリック・ネットワークを実装して、他のプラットフォームよりも低コストで高パフォーマンスと大容量を実現します。

Oracle Exadata Storage Serverは、Oracle Exadata System Softwareを含むネットワーク・アクセス可能なストレージ・デバイスです。Exadataソフトウェアは、専用のiDBプロトコルを使用してOracle Databaseと通信し、ブロック指向の読取りおよび書込みなどの標準I/O機能と、条件のオフロードやI/Oリソース管理(IORM)などの高度なI/O機能の両方を提供します。

各ストレージ・サーバーには、物理ディスクが含まれます。物理ディスクは、ハード・ディスク・ドライブ(HDD)またはフラッシュ・デバイスを構成するストレージ・サーバー内の実際のデバイスです。各物理ディスクには、オペレーティング・システム(OS)内に論理ユニット番号(LUN)と呼ばれる論理表現があります。通常、すべてのExadata Storage Serverモデルには、物理ディスクとLUNの間に1対1の関係があります。ただし、Exadata X10M Extreme Flash (EF)ストレージ・サーバーの場合のみ、30.72 TBの4つの容量最適化フラッシュ・デバイスのそれぞれに2つのLUNが構成されるため、Exadata X10M EFストレージ・サーバーではLUNが8つになります。

セル・ディスクは、Oracle Exadata System Softwareを抽象化したもので、LUN上に構築されます。セル・ディスクは、LUNから作成された後はOracle Exadata System Softwareによって管理され、複数のグリッド・ディスクにさらに分割できます。

各グリッド・ディスクは、Oracle ASMに直接公開されて、Oracle ASMディスク・グループで使用されます。このようなレベルの仮想化により、複数のOracle ASMクラスタおよびデータベース間で同じ物理ディスクを共有できます。この共有により、ディスク容量および帯域幅を最適に使用できます。

セル・ディスクのレベルで収集される様々なメトリックと統計により、ストレージ・サーバーのパフォーマンスと容量を評価できます。IORMでは、ユーザー定義のポリシーに従ってセル・ディスクのアクセスをスケジュール管理します。

次の図は、ストレージ・サーバー(セルとも呼ばれる)の主なデータ・ストレージ・コンポーネントを示しています。

  • Oracle Exadata Storage Serverには、物理ディスクとしてハード・ディスク・ドライブ(HDD)またはフラッシュ・デバイスが含まれます。
  • 各物理ディスクは、通常は、セルOSでLUNとして表されます(ただし、容量最適化フラッシュ・デバイスそれぞれに2つのLUNが含まれているExadata X10M EFストレージ・サーバーは除きます)。
  • セル・ディスクは、Oracle Exadata System Softwareによって管理される各LUNのデータ・ストレージ領域を表す、より高いレベルの抽象概念です。LUNにはセル・ディスクを1つのみ含めることができます。
  • 各セル・ディスクには、Oracle ASMで直接使用できる複数のグリッド・ディスクを含めることができます。

図1-3 Oracle Exadataのデータ・ストレージ・コンポーネント

図1-3の説明が続きます
「図1-3 Oracle Exadataのデータ・ストレージ・コンポーネント」の説明

次の図は、Oracle Exadataの主要なソフトウェア・コンポーネントを示しています。

図1-4 Oracle Exadataのソフトウェア・コンポーネント

図1-4の説明が続きます
「図1-4 Oracle Exadataのソフトウェア・コンポーネント」の説明

この図に示されている環境は、次のとおりです。

  • 単一インスタンスまたはOracle RACデータベースは、RDMAネットワーク・ファブリックを使用してOracle Exadata Storage Serverにアクセスします。各データベース・サーバーでは、Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアが実行されます。リソースは、Oracle Database Resource Manager (DBRM)によって各データベース・インスタンス内で管理されます。

  • データベース・サーバーには、管理サーバー(MS)、コマンドライン管理インタフェース(DBMCLI)などのOracle Exadata System Softwareコンポーネントも含まれています。

  • ストレージ・サーバーには、物理データ・ストレージ・デバイスと、次のようなOracle Exadata System Softwareのセルベースのユーティリティおよびプロセスが含まれています。

    • セル・サーバー(CELLSRV)はExadataストレージ・サーバー・ソフトウェアのプライマリ・コンポーネントで、Exadataストレージ・サービスの大部分を提供します。データベース・バッファ・キャッシュ読取りなどの単純なブロック・リクエストを処理し、投影およびフィルタを使用した表スキャンなどのスマート・スキャン・リクエストを容易にします。CELLSRVは、Oracle Databaseリソース管理と連携してI/Oを発行している様々なデータベースおよびコンシューマ・グループへのI/O帯域幅を計測する、Exadata I/Oリソース管理(IORM)を実装します。CELLSRVは、その操作に関連する多数の統計も収集します。CELLSRVはマルチスレッド・サーバーであり、通常、ストレージ・サーバー上のCPUリソースの最大部分を使用します。

    • オフロード・サーバー(CELLOFLSRV <version>)は、特定のOracle Databaseバージョンからのオフロード・リクエストを処理するCELLSRVのヘルパー・プロセスです。オフロード・サーバーを使用すると、ストレージ・サーバーで複数のOracle Databaseバージョンからのすべてのオフロード操作をサポートできます。オフロード・サーバーはCELLSRVとともに自動的に実行されるため、追加の構成やメンテナンスは必要ありません。

    • 管理サーバー(MS)は、スタンドアロンのOracle Exadata System Software管理および構成機能を提供します。MSは、セル制御コマンドライン・インタフェース(CellCLI)と連携して動作し、そのコマンドのほとんどを処理します。CellCLIはサーバー・ステータスを管理、管理、および問合せするための主要なユーザー・インタフェースです。また、MSはアラートの送信を行い、CELLSRVによって収集された統計に加えていくつかの統計を収集します。

    • 再起動サーバー(RS)CELLSRV、オフロード・サーバーおよびMSプロセスを監視し、必要に応じて再起動します。

  • CellCLIユーティリティは各ストレージ・サーバー上のOracle Exadata System Softwareのプライマリ管理インタフェースであり、各データベース・サーバーにはDBMCLIという同様のユーティリティが含まれています。dcliユーティリティを使用すると、管理者は複数のサーバーにわたって管理操作を実行できます。さらに、ExaCLIおよびexadcliにより、個別またはグループとしてExadataサーバーのリモート管理が容易になります。

1.3.2 セル管理について

Oracle Exadata Storage Serverグリッドの各セルは、セル・コントロール・コマンドライン・インタフェース(CellCLI)で個別に管理されます。

CellCLIユーティリティには、セルの初期構成、セル・ディスクおよびグリッド・ディスクの作成、パフォーマンスの監視など、セル管理機能のためのコマンドライン・インタフェースが用意されています。CellCLIユーティリティはセル上で実行され、ストレージ・セルにネットワーク・アクセスするクライアント・コンピュータまたは直接セルに接続されるクライアント・コンピュータからアクセスできます。CellCLIユーティリティは、管理サーバーと通信してストレージ・セルを管理します。

セルにアクセスするには、Secure Shell(SSH)アクセス、またはKVM (キーボード、ビデオ、視覚的表示装置、マウス用)スイッチなどを介したローカル・アクセスのいずれかを使用する必要があります。SSHではリモート・アクセスが可能ですが、セルがネットワークにまだ構成されていない場合は、初期構成でローカル・アクセスが必要になる場合があります。ローカル・アクセスを使用すると、セルのオペレーティング・システムのシェル・プロンプトにアクセスできるため、CellCLIユーティリティなどの各種ツールを使用してセルを管理できます。

dcliユーティリティを使用すると、複数のセルで同じCellCLIコマンドをリモートで実行できます。

セルを計算ノードからリモートで管理するために、ExaCLIユーティリティを使用できます。ExaCLIにより、ほとんどのCellCLIコマンドをセルで実行できます。これが必要になるのは、セルに直接アクセスしてCellCLIを実行できない場合、またはセルでSSHサービスが無効になっている場合です。複数のセルでリモートでコマンドを実行するために、exadcliユーティリティを使用できます。

関連項目:

1.3.3 ストレージ・サーバーのセキュリティについて

Exadata Storage Serverのセキュリティは、ストレージ・サーバーおよびグリッド・ディスクにアクセスできるクライアントを特定することによって実現されます。

クライアントには、Oracle ASMインスタンス、データベース・インスタンスおよびクラスタがあります。グリッド・ディスクを作成または変更する場合は、グリッド・ディスクの使用権限を設定したOracle ASM所有者およびデータベース・クライアントを構成できます。

1.3.4 Oracle Automatic Storage Managementについて

Oracle Automatic Storage Management (Oracle ASM)は、Oracle Exadata Storage Serverのリソース管理に使用されるクラスタ・ボリューム・マネージャおよびファイル・システムです。

Oracle ASMでは、次の処理を実行してストレージ管理を拡張します。

  • 最適なパフォーマンスが得られるように、利用可能なすべてのストレージ・セルおよびディスク間でデータベース・ファイルを均等にストライプ化。
  • ミラー化および障害グループを使用してシングル・ポイント障害を回避。
  • 動的追加および削除機能により、セルおよびディスクの割当て、割当て解除および再割当てを透過的に実行。
  • 複数のデータベース間でストレージ・セルおよびディスクを共有。

次の各トピックでは、Oracle ASMの簡単な概要について説明します。

1.3.4.1 Oracle ASMディスク・グループ

Oracle Automatic Storage Management (Oracle ASM)ディスク・グループは、Oracle ASM内で抽象化されたプライマリ・ストレージで、1つ以上のグリッド・ディスクで構成されます。

Oracle Exadata Storage Serverのグリッド・ディスクは、Oracle ASMディスク・グループのメンバーシップに使用可能な個々のディスクとして、Oracle ASMに認識されます。グリッド・ディスク名とOracle ASMディスク・グループ名は、Oracle ASMOracle Exadata System Software間で問題が発生した場合に容易に診断できるように、できるだけ関連性のある名前にすることをお薦めします。

通常、Oracle Exadataは、次のOracle ASMディスク・グループで構成されます。

  • DATAは、プライマリ・データ・ディスク・グループです。

  • RECOは、プライマリ・リカバリ・ディスク・グループです。Oracle Database高速リカバリ領域(FRA)が収容されます。

  • SPARSEは、オプション構成のスパース・ディスク・グループです。Exadataスナップショットのサポートに必要です。

  • XTNDは、Exadata XT (拡張)ストレージ・サーバーからストレージを収集するために使用するディスク・グループのデフォルト名です。

  • DBFSは、システム・ディスク・グループです。通常、Exadata X7より前のシステムで構成されます。DBFSディスク・グループは、共有Oracle Clusterwareファイル(Oracle Cluster Registryおよび投票ディスク)を格納することと、Oracle Database File System (DBFS)をホストするための領域を確保することを主な目的として使用します。このディスク・グループは、Exadata X7以降のシステムでは構成されません。

条件処理のオフロードなどのOracle Exadata System Softwareの機能を利用するには、ディスク・グループにOracle Exadata Storage Serverのグリッド・ディスクのみが含まれていること、表がこれらのディスク・グループ内に完全に収まっていること、およびグループのcell.smart_scan_capable属性がTRUEに設定されていることが必要です。

ノート:

スパース・グリッド・ディスクを使用する場合は、Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアはリリース12.1.0.2.0 BP3以上である必要があります。

1.3.4.2 Oracle ASMの障害グループ

Oracle ASM障害グループは、同じハードウェアを共有するために同時に停止する可能性があるOracle ASMディスク・グループのディスクのサブセットです。

Oracle ASMでは、冗長性について決定する場合に障害グループを考慮します。

Oracle Exadata Storage Serverでは、ストレージ・セルに障害が発生すると、Oracle ASMディスク・グループのメンバーおよび候補で構成されるすべてのグリッド・ディスクが同時に停止する可能性があります。このようなシナリオのため、ストレージ・セルが関連するすべてのOracle ASMグリッド・ディスクには、そのセルを表す障害グループを1つ割り当てる必要があります。

たとえば、2つのストレージ・セル(AおよびB)が関連するすべてのグリッド・ディスクが「標準」の冗長性で1つのOracle ASMディスク・グループに追加されている場合、ストレージ・セルAのすべてのグリッド・ディスクとストレージ・セルBのすべてのグリッド・ディスクには、それぞれ別の障害グループが指定されます。これにより、いずれかのストレージ・セルで障害が発生しても、Oracle Exadata System SoftwareおよびOracle ASMでフォルト・トレランスが実行されるようになります。

Oracle Exadata Storage Serverのグリッド・ディスクの障害グループは、単一のセル上のディスクが同じ障害グループに属するようにデフォルトで設定されているため、Oracle Exadata Storage Serverに関する正しい障害グループ構成は簡単になっています。

Oracle ASMディスク・グループの冗長性レベルは、ディスク・グループの作成時に定義できます。Oracle ASMディスク・グループは、「標準」または「高」の冗長性で指定できます。「標準」の冗長性では、エクステントを二重にミラー化し、「高」の冗長性では、エクステントを三重にミラー化します。Oracle ASMの「標準」の冗長性では、1つのセルまたはそのセル内のディスク・セットに障害が発生した場合にフォルト・トレランスが実行されます。Oracle ASMの「高」の冗長性では、2つのセルまたはそのセル内のディスク・セットに障害が発生した場合にフォルト・トレランスが実行されます。冗長性の設定基準は、必要とする保護レベルです。冗長性レベルを選択する場合は、障害後のI/O容量が冗長性の要件およびパフォーマンス・サービス・レベルを十分に満たすようにします。「標準」の冗長性で3つのセルを使用することをお薦めします。これにより、セルに障害が発生しても完全な冗長性でリストアが可能になります。次の点を考慮してください。

  • セルまたはディスクに障害が発生した場合、セルまたはディスクの内容はOracle ASMによってディスク・グループの残りのディスクに自動的に再配分されます(データを格納する十分な領域があることが条件)。Oracle ASMの冗長性を使用する既存のディスク・グループでは、V$ASM_DISGKROUPビューのUSABLE_FILE_MB列に使用可能領域の容量が表示され、REQUIRED_FREE_MIRROR_MB列に冗長性のための領域の容量が表示されます。

  • セルまたはディスクに障害が発生した場合は、パフォーマンス・サービス・レベル合意を満たすために必要なIOPSを残りのディスクで生成できるようにしてください。

ディスク・グループを作成した後は、ディスク・グループの冗長性レベルを変更することはできません。ディスク・グループの冗長性を変更するには、別のディスク・グループを作成して冗長性を指定し、ファイルを移動する必要があります。

各Exadataセルは、障害グループです。標準冗長性のディスク・グループには、少なくとも2つの障害グループが含まれる必要があります。Oracle ASMでは、異なる障害グループに配置されたミラー化されたエクステントを使用して、ファイル・エクステントの2つのコピーを自動的に格納します。高い冗長性のディスク・グループには3つ以上の障害グループが含まれている必要があります。Oracle ASMでは、個別の障害グループの各ファイル・エクステントを使用して、ファイル・エクステントの3つのコピーを自動的に格納します。

使用環境における障害グループの数が十分でない場合、システムの信頼性が損われる可能性があります。障害グループの数が少ない場合や、障害グループの容量が均等でない場合は、利用可能なすべてのストレージを十分に活用できない割当ての問題につながる場合があります。

1.3.4.3 Oracle ASMの最大可用性

高冗長性のOracle ASMディスク・グループと、Oracle Exadata Deployment Assistantを使用して自動的にデプロイ可能なファイルの配置構成をお薦めします。

少なくともストレージ・セルが3つあるDATA、RECOまたは他の任意のOracle ASMディスク・グループに対して高冗長性を構成できます。Exadata Softwareリリース12.1.2.3.0以降では、投票ディスクを高冗長性ディスク・グループに含め、Exadataストレージ・セルが5つ未満の場合にはquorumディスクを(実質的に投票ディスクと同じ)をデータベース・サーバーに追加できます。

最大可用性アーキテクチャ(MAA)のベスト・プラクティスでは、DATAとRECOの2つの主要なOracle ASMディスク・グループを使用します。ディスク・グループは次のように編成されています。

  • I/O帯域幅とパフォーマンスを最大化し、管理を簡素化するため、ディスク・グループはすべてのディスクおよびOracle Exadata Storage Server全体でストライプ化されます。
  • DATAおよびRECOディスク・グループは、高(3方向)冗長性で構成されます。

高い冗長性のディスク・グループの利点については、次の停止シナリオに示します。

  • 二重パートナ・ディスク障害: ディスク障害に続く、2番目のパートナ・ディスクの障害による、データベースおよびOracle ASMディスク・グループの損失防止。
  • Oracle Exadata Storage Serverのオフライン時のディスク障害: ストレージ・サーバーがオフラインであり、そのいずれかのストレージ・サーバーのパートナ・ディスク障害が発生した場合の、データベースおよびOracle ASMディスク・グループの損失防止。ストレージ・サーバーは、Exadataローリング・ストレージ・サーバーのパッチ適用など、Exadataストレージの計画メンテナンスによってオフラインになる場合があります。
  • ディスクのセクター破損によるディスク障害: 潜在的なディスク・セクター破損が存在し、計画メンテナンスまたはディスク障害のいずれかが原因でパートナ・ストレージ・ディスクを使用できない場合の、データの損失およびI/Oエラーの防止。

デフォルトのExadata高冗長性デプロイメントの一部である高冗長性ディスク・グループに投票ディスクが含まれている場合、前述の障害シナリオでもクラスタおよびデータベースの可用性は失われません。投票ディスクが標準冗長性ディスク・グループに含まれている場合は、データベース・クラスタで障害が発生します。データベースを再起動する必要があります。このようなリスクは、投票ディスクを高冗長性ディスク・グループに移動し、データベース・サーバーに追加のquorumディスクを作成することで排除できます。

ストレージ障害に対する最大のアプリケーション可用性を提供し、ストレージ停止時の運用を簡素化するために、すべて(DATAおよびRECO)を高冗長性ディスク・グループにすることをお薦めします。対照的に、すべてのディスク・グループが標準冗長性で構成されている場合に2つのパートナ・ディスクで障害が発生すると、Exadata上のすべてのクラスタとデータベースで障害が発生し、すべてのデータが失われます(標準冗長性では二重パートナ・ディスク障害は許容されません)。ストレージ保護が向上する以外に、高冗長性と標準冗長性との主な違いは、使用可能なストレージ容量と書込みI/Oにあります。高冗長性ではより多くの領域が必要で、2つではなく3つの書込みI/Oが発生します。追加で発生する書込みI/OがExadataスマート・Write-Back Flash Cacheに与える影響はごくわずかです。

次の表では、冗長性オプション、その他のオプション、および相対的な高可用性のトレードオフについて説明します。次の表は、投票ディスクが高冗長性ディスク・グループに含まれていることを前提としています。既存の高冗長性ディスク・グループ構成の高冗長性グループに投票ディスクを移行するには、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

冗長性のオプション 可用性の意味 推奨事項

すべて(DATAおよびRECO)を高冗長性にする

投票ディスクが高冗長性ディスク・グループに存在している場合、前述のストレージ停止のシナリオでは、アプリケーションのダウンタイムおよびデータ損失はゼロです。

現在投票ディスクが標準冗長性ディスク・グループに含まれている場合、それらを高冗長性ディスク・グループに移行するには『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

ミッション・クリティカルなアプリケーションのための最高のストレージ保護および運用の簡素化のために、このオプションを使用します。冗長性を高めるには、より多くの領域が必要です。

DATAのみを高冗長性にする

前述のストレージ停止のシナリオでは、アプリケーションのダウンタイムおよびデータ損失はゼロです。このオプションでは、別のアーカイブ先が必要です。

運用の複雑性が若干高いDATAのための最高のストレージ保護には、このオプションを使用します。すべてを高冗長化する場合よりも使用可能な領域が増えます。

詳細は、My Oracle Supportノート2059780.1を参照してください。

RECOのみを高冗長性にする

前述のストレージ停止のシナリオでは、データ損失はゼロです。

前述のストレージ停止のシナリオで長時間のリカバリが許容される場合は、このオプションを使用します。リカバリ・オプションは次のとおりです。

  • リストアとリカバリ:

    - DATAディスク・グループの再作成

    - RECOからのリストアおよびテープ・ベースのバックアップ(必要な場合)

    - データベースのリカバリ

  • スイッチとリカバリ:

    - RMANスイッチを使用してコピー

    データベースのリカバリ

すべて(DATAおよびRECO)を標準冗長性にする

ノート: ASMディスク・グループのコンテンツ・タイプを使用したディスク間ミラー分離では、物理ディスクとストレージ・サーバーを共有する標準冗長性グループの2つのディスク・パートナが失われたとき、1つのディスク・グループに停止が制限されます。

前述のストレージ停止のシナリオでは、すべてのOracle ASMディスク・グループに障害が発生しました。ただし、ディスク間ミラー分離を使用すると、停止対象は1つのディスク・グループに制限されます。

ノート: このオプションは、エイスまたはクオータ・ラックには使用できません。

最低でもDATAのみは高冗長性にすることをお薦めします。

すべてを標準冗長性にするオプションは、別のOracle Exadata Database MachineにデプロイされたOracle Data Guardのスタンバイ・データベースによってプライマリ・データベースが保護されているか、Oracle Exadata Database Machineが開発またはテスト・データベースにのみサービスを提供している場合に使用します。Oracle Data Guardでは、ストレージ障害に対してリアルタイムのデータ保護および高速のフェイルオーバーを提供します。

Oracle Data Guardが使用できず、DATAまたはRECOディスク・グループが失われている場合は、My Oracle Supportノート1339373.1に記載されているリカバリ・オプションを利用してください。

MAAの設定のための最適なファイル配置は次のとおりです。

  • Oracle Databaseファイル — DATAディスク・グループ
  • フラッシュバック・ログ・ファイル、アーカイブREDOファイルおよびバックアップ・ファイル — RECOディスク・グループ
  • REDOログ・ファイル — 最初の高冗長性ディスク・グループ。高冗長性のディスク・グループが存在しない場合は、REDOログファイルがDATAおよびRECOディスク・グループ間に配置されます。
  • 制御ファイル — 最初の高冗長性ディスク・グループ。高冗長性のディスク・グループが存在しない場合は、DATAディスク・グループで1つの制御ファイルを使用します。バックアップ制御ファイルがRECOディスク・グループ内に存在するようにし、RMAN CONFIGURE CONTROLFILE AUTOBACKUP ONを設定する必要があります。
  • サーバー・パラメータ・ファイル(SPFILE) — 最初の高冗長性ディスク・グループ。高冗長性のディスク・グループが存在しない場合は、SPFILEがDATAディスク・グループ内に存在するようにします。SPFILEバックアップがRECOディスク・グループ内に存在するようにします。
  • Oracle Exadata Database Machineフル・ラックおよびOracle Exadata Database Machineハーフ・ラック用のOracle Cluster Registry (OCR)および投票ディスク— 最初の高冗長性ディスク・グループ。高冗長性のディスク・グループが存在しない場合は、ファイルがDATAディスク・グループ内に存在するようにします。
  • Oracle Exadata Database Machineクオータ・ラックまたはエイス・ラックの投票ディスク — 最初の高冗長性ディスク・グループ'(そうでなければ、標準冗長性ディスク・グループ)。高冗長性ディスク・グループのExadataストレージ・セルが5つ未満である場合は、OEDAデプロイメント中にquorumディスクをExadataデータベース・サーバーに追加できます。既存の高冗長性ディスク・グループ構成の高冗長性グループに投票ディスクを移行するには、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
  • 一時ファイル — 最初の高冗長性ディスク・グループ。すべてを高冗長性にするオプションを使用する場合は、最初の高冗長性ディスク・グループを使用します。
  • ステージングおよび非データベース・ファイル — DBFSディスク・グループまたはACFSボリューム
  • Oracleソフトウェア(監査および診断先を含む) — OEDAデプロイメント中に構成されたExadataデータベース・サーバーのローカル・ファイル・システムの場所

1.3.5 ストレージの中断時の高いパフォーマンスの維持

Exadataは、複数のストレージ層およびキャッシュにわたってデータをインテリジェントに管理することで、高いパフォーマンスを実現するように設計されています。初期のExadataモデルは、パフォーマンスが高くレイテンシが短いフラッシュ・ストレージを備えています。その後のモデルは、永続メモリー(PMEM)またはExadata RDMAメモリー(XRMEM)を追加することで、さらに高いパフォーマンスと非常に短いレイテンシを実現します。通常の運用中、Exadataはストレージ層をインテリジェントに管理し、最も関連性の高いデータが、最も高いパフォーマンスと最も低いレイテンシでストレージの場所を使用するようにします。ただし、特別な機能により、イベントが計画的か計画外かに関係なく、ストレージの中断が発生した場合でも高パフォーマンスおよび低I/Oレイテンシを維持することもできます。

計画外のストレージ・イベントの最も一般的なタイプの1つは、フラッシュ・デバイスまたはハード・ディスクの障害です。これらの障害は、完全なハードウェア障害、障害予兆、制限など、様々な形で発生する可能性があります。その他の計画外ストレージ・イベントは、セルの再起動が発生するオペレーティング・システムのカーネル・クラッシュなど、様々なハードウェアまたはソフトウェア・コンポーネントの障害から発生する可能性があります。計画的なストレージ・イベントの最も一般的なタイプは、ストレージ・サーバー・ソフトウェアの更新です。ストレージ・サーバー・ソフトウェアの更新はローリング方式で実行され、1つのセルが更新されて再同期された後、次のセルに移動します。

どのようなストレージの中断であるとしても、I/Oレイテンシは主に次の2つの要因の影響を受けます。

  • 中断への対処に必要なシステム上の追加のI/O負荷。

  • 中断によって発生したキャッシュ・ミス。

Exadataは、次のような一連の測定を使用してこれらの影響に対処します。

ストレージの中断に関連付けられたI/O負荷の管理

  • ストレージ・イベントが発生すると、Exadataは適切なレスポンスを自動的にオーケストレーションして、データの冗長性を効率的に維持またはリストアします。Exadataでは、状況ごとに適切なアプローチを使用して、冗長性を維持するために必要なI/O負荷の影響を最小限に抑えます。

    • ハード・ドライブに障害が発生すると、ExadataはOracle ASMからディスクを自動的に削除します。このアクションにより、ASMリバランス操作が自動的にトリガーされ、ASMディスク・グループに冗長性がリストアされます。フラッシュ・ドライブに存在するASMディスクに障害が影響する場合も同様です。

    • ハード・ドライブのパフォーマンスの低下、または障害予兆の状態になった場合、Exadataには、ドライブを交換する前にディスクを事前に削除してリバランスを実行し、冗長性を維持するオプションが用意されています。

    • Exadata Smart Flash Cacheをライトバック・モードで使用している場合、Exadataでは、キャッシュの内容を記述するメタデータが自動的に維持されます。フラッシュ・ドライブの障害がキャッシュに影響を与えると、デバイスの交換後にExadataによってキャッシュが自動的に再移入されます。このプロセスは再同期化と呼ばれ、RDMAネットワーク・ファブリックを介した非常に効率的なセル間の直接データ転送を使用して、生存しているミラーから読み取ることでキャッシュが再移入されます。

    • ストレージが短期的な中断後にオンラインに戻ると、冗長性をリストアするための再同期操作を実行するように、ExadataがASMに自動的に指示します。再同期操作では、ストレージ・エクステントの変更を追跡するビットマップが使用されます。ソフトウェア更新やセルの再起動などの短期的な中断の場合、再同期は、変更されたデータのみをコピーして冗長性をリストアする非常に効率的な方法です。

  • ASMは、リバランスや再同期などの非同期操作に関連するI/Oに対して、ASM能力制限と呼ばれる抑制を提供します。ASM能力制限が高すぎる場合、ASM I/Oによってハード・ディスクが過負荷になり、I/Oレイテンシが長くなる可能性があります。高い制限では、ASMエクステント・ロックが増加し、データベースI/Oに影響する可能性があります。ただし、Exadataでは、デフォルト(および推奨)のASM能力制限設定が非常に低く、アプリケーションのI/Oレイテンシへの影響は最小限に抑えられます。この設定はEXAchkでも監視され、変動がEXAchkレポートに記載されます。

  • Exadata I/Oリソース管理(IORM)では、システムI/OとアプリケーションI/Oが区別され、アプリケーションI/Oにインテリジェントに優先順位が付けられます。たとえば、アプリケーションI/OはExadataキャッシュに優先的にアクセスしますが、ASMリバランスではハード・ディスクおよび未使用のキャッシュ領域にのみアクセスできます。

キャッシュ・ミスの最小化

  • 通常の操作の過程で、データベース・バッファ・キャッシュに読み取られたデータは、プライマリ・データ・コピーを含むセルのExadataキャッシュ(可用性に応じてフラッシュ・キャッシュ、PMEMキャッシュまたはXRMEMキャッシュのいずれか)にもロードされます。また、データは常にプライマリ・コピーから読み取られます(使用可能な場合)。

    ただし、プライマリ・コピーを使用できない場合は、セカンダリ・コピーを使用する必要があります。この可能性に備えるために、Exadataは、プライマリ・キャッシュの管理の一環として、セカンダリ・セルのフラッシュ・キャッシュにもデータをロードします。Exadataは、セカンダリ・キャッシュを事前にロードすることで、プライマリ・コピーが使用できずにセカンダリ・コピーを使用する必要がある場合に、最も重要なデータが引き続きキャッシュされているようにします。

    セカンダリ・データ・コピーも使用できず、データが高い冗長性(3方向ミラー化)で保護されている場合は、最後の手段として第3のデータ・コピーが使用されます。これは、二重障害の同時発生を必要とするまれなシナリオです。したがって、Exadataには、第3のデータ・コピーの事前キャッシュは用意されていません。

  • Exadataでは、セル間でデータを移動するときにキャッシュのコンテンツが保持されます。たとえば、セル1の一部のデータがフラッシュ・キャッシュにロードされ、そのデータがセル2に移動されると、データはセル2のフラッシュ・キャッシュにもロードされます。これにより、リバランス操作によって移動されたデータが移動前と同じ方法でキャッシュされます。

  • Exadataは、障害後のフラッシュ・キャッシュ・リカバリを迅速に処理します。プロセス障害の場合、Exadataはフラッシュ・キャッシュを再接続し、以前に移入されたデータで続行できます。システム障害後にフラッシュ・キャッシュを迅速に再構築するために、Exadataは、Oracle Exadata X7以降のシステムにあるM.2ソリッド・ステート・ドライブ(SSD)にフラッシュ・キャッシュ・メタデータを保持します。

  • たとえば、フラッシュ・ドライブやハード・ドライブの交換後など、新しいストレージ・デバイスが検出されると、Exadataは、新しいストレージを完全に有効にする前に、フラッシュ・キャッシュが適切にウォームアップされていることを確認します。これには、新しいストレージに関連付けられたフラッシュ・キャッシュ・ヒット率がシステムの他の部分と同様であることを確認するための広範なヘルス・チェックが含まれます。

1.3.6 データベース・サーバー・ソフトウェアについて

Oracleソフトウェアは、Exadata Database Serverにインストールされます。

Oracle Exadata System Softwareは、Oracle Databaseとシームレスに連携します。データベース・サーバー上のソフトウェアは次のとおりです。

  • Oracle Databaseインスタンス。格納データ上で動作するOracle Databaseバックグラウンド・プロセスおよびそのプロセスで使用される共有割当てメモリーのセットが含まれます。データベース・サーバー・ソフトウェアには、データベースの管理、パフォーマンス管理およびサポート用のユーティリティも含まれています。

  • Oracle Automatic Storage Management (Oracle ASM)は、データベースおよびOracle Exadata Storage Server用に最適化されたストレージ管理を提供するクラスタ化されたファイル・システムおよびボリューム・マネージャです。Oracle ASMは、Oracle Grid Infrastructureに含まれます。Oracle Grid Infrastructureソフトウェアには、すべてのExadataサーバーのクラスタ・コヒーレンスを維持するために不可欠な機能が用意されています。また、Oracle Grid Infrastructureソフトウェアは、データベース・サーバーとストレージ・サーバーの両方の正常性と稼働状態を監視し、計画済および計画外のストレージ停止が発生した場合にデータベース高可用性を確保します。

    Oracle ASMインスタンスでは、ディスク上のデータ・ファイルの配置を処理し、メタデータ・マネージャとして動作します。Oracle ASMインスタンスがアクティブになるのは、主にファイルの作成および拡張中、または構成変更後のディスクのリバランス中です。ランタイムI/O操作は、Oracle ASMインスタンスを介して渡されずに、データベースからストレージ・セルに直接送信されます。

  • Oracle Database Resource Manager。I/Oリソースがデータベース内で適切に割り当てられるようにします。

  • iDBプロトコル。セルとの通信にデータベース・インスタンスで使用され、データベース・サーバーに静的に関連付けられるOracle提供のライブラリに実装されます。

1.3.7 Oracle Enterprise Manager for Oracle Exadataについて

Oracle Enterprise Managerには、構成やパフォーマンスを含む、Oracle Exadataをグラフィカル・ユーザー・インタフェース(GUI)で監視できる完全なターゲットが用意されています。

次の図は、Exadata Storage Serverグリッド・ホームページを示しています。このページを表示すると、ストレージ・サーバーの状態、ストレージの主要なパフォーマンス特性、およびストレージのリソース使用率をデータベース別に迅速に表示できます。

図1-5 Oracle Enterprise ManagerのExadata Storage Serverグリッド・ホームページ

図1-5の説明が続きます
「図1-5 Oracle Enterprise ManagerのExadata Storage Serverグリッド・ホームページ」の説明

Oracle Enterprise Managerでは、レポートに加えて、アラートのメトリックしきい値を設定したり、Exadataシステムの状態を判断するためのメトリック値を監視することもできます。