1 Oracle Exadata System Softwareの概要
この章では、Oracle Exadata System Softwareの概要について説明します。
- Oracle Exadata System Softwareの概要
Oracle Exadata Storage Serverは、Oracle Databaseデータを格納してそのデータにアクセスするために、Oracle Exadata System Softwareを実行する高度に最適化されたストレージ・サーバーです。 - Oracle Exadata System Softwareの主な機能
この項では、Oracle Exadata System Softwareの主な機能について説明します。 - 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 Database Machineのストレージ・サーバーは、ストレージ・レベルでデータを処理し、データベース・サーバーに必要な内容のみを渡します。
Oracle Exadata System Softwareは、ストレージ・サーバーとデータベース・サーバーの両方にインストールされます。Oracle Exadata System Softwareによって、SQL処理がデータベース・サーバーからストレージ・サーバーにオフロードされます。Oracle Exadata System Softwareでは、従来型のデータ移動に加えて、データベース・インスタンスから基礎となるストレージへ機能を移動することが可能です。機能の移動により、データベース・サーバーで必要なデータ処理の量が大幅に軽減されます。データ転送とデータベース・サーバー・ワークロードの削減は、帯域幅によって制約されることが多かった問合せ操作に非常に大きな効果をもたらします。データ転送の削減は、大規模なバッチ処理とレポート処理の操作を実行することが多いオンライン・トランザクション処理(OLTP)システムでもきわめて有効です。
Oracle Exadata Storage Serverのハードウェア・コンポーネントは、高いパフォーマンスの処理に対応できるように慎重に選択されています。Oracle Exadata System Softwareは、ハードウェア・コンポーネントを最大限に活用できるように最適化されています。各ストレージ・サーバーでは、ディスク上の格納データに対する処理で非常に高い帯域幅が提供され、従来の方法よりも数倍優れています。
Oracle Exadata Database Machineストレージ・サーバーは、サーバーとストレージとの間で最先端のRDMAネットワーク・ファブリック・インターコネクトを使用します。各RDMAネットワーク・ファブリック・リンクは、InfiniBandネットワーク・ファブリックに対して40 GB、RoCEネットワーク・ファブリックに対して100 GBの帯域幅を提供します。さらに、インターコネクト・プロトコルでは、ダイレクト・メモリー・アクセス(DMA)とも呼ばれる直接データ配置を使用して、余分なデータ・コピーを作成せずにデータを回線からデータ・バッファに直接移動することで、CPUのオーバーヘッドを大幅に削減しています。RDMAネットワーク・ファブリックは、LANネットワークの柔軟性とともに、ストレージ・エリア・ネットワーク(SAN)の効率性を備えています。Oracle Exadata Database Machineでは、RDMAネットワーク・ファブリック・ネットワークを使用することによって、パフォーマンスを低下させる可能性のあるネットワークのボトルネックをなくしています。このRDMAネットワーク・ファブリック・ネットワークでは、Oracle Real Application Clusters (Oracle RAC)サーバー用の高いパフォーマンスのクラスタ・インターコネクトも提供されます。
各ストレージ・サーバーには、ディスク(回転)ストレージがあります。ストレージ・サーバーには複数の構成があり、それぞれが要件に基づいてストレージの一部の側面を最大化するように構成されています。ストレージ・サーバーは、インストール済のExadataスマート・フラッシュ・キャッシュまたはオプションとして使用可能なExadataスマート・フラッシュ・キャッシュを使用して指定できます。一部のストレージ・サーバーには永続メモリー(PMEM)キャッシュもあります。各キャッシュ構成ではRDMAを使用して最大転送速度を提供します。
Oracle Exadata Database Machineアーキテクチャは、パフォーマンスを任意のレベルにスケールアウトします。より高いパフォーマンスとより大きなストレージ容量を達成するには、構成にストレージ・サーバー(セル)を追加します。ストレージ・サーバーの数に比例して容量が増加し、パフォーマンスも向上します。データはストレージ・サーバー間でミラー化されるため、ストレージ・サーバーで障害が発生してもデータや可用性が失われることはありません。スケールアウト・アーキテクチャによってほぼ無限のスケーラビリティが実現し、必要に応じてストレージを増設できるためコスト削減も可能になります。
ノート:
Oracle Exadata System SoftwareはOracle Exadata Database Machineストレージ・サーバーのハードウェアと併用する必要があり、Oracle Exadata Database Machineのデータベース・サーバー上のOracleデータベースのみをサポートしています。情報は次のMy Oracle Support、
また、Oracle Technology Networkの製品ページでも確認できます
1.2 Oracle Exadata System Softwareの主な機能
この項では、Oracle Exadata System Softwareの主な機能について説明します。
- 信頼性、モジュール方式、およびコスト効率
Oracle Exadata System Softwareでは、コスト効率の高いモジュール方式のストレージ・ハードウェアをスケールアウト・アーキテクチャで使用できるため、高いレベルの可用性と信頼性が実現します。 - Oracle Databaseとの互換性
最低限必要なバージョンが満たされると、Oracle Exadata System SoftwareではOracle Databaseのすべての機能が完全にサポートされます。 - スマート・フラッシュ・テクノロジ
Oracle Exadata System SoftwareのExadataスマート・フラッシュ・キャッシュ機能は、データベース・オブジェクトをフラッシュ・メモリー内に効率的にキャッシュし、ディスクに対する低速で機械的なI/O操作を非常に高速なフラッシュ・メモリー操作に置き換えます。 - 永続メモリー・アクセラレータおよびRDMA
永続メモリー(PMEM)アクセラレータを使用すると、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用して永続メモリーに直接アクセスできることで、レスポンス時間が速くなり、読取りレイテンシが短縮されます。 - 集中型ストレージ
Oracle Exadata Storage Serverを使用すると、複数のデータベースで使用可能な中央のプールに各自のストレージ要件を統合できます。 - I/Oリソース管理(IORM)
I/Oリソース管理(IORM)およびOracle Database Resource Managerでは、複数のデータベースおよびプラガブル・データベース間で同じストレージを共有できるのみならず、様々なデータベースにI/Oリソースを割り当てることができます。 - Exadataハイブリッド列圧縮
Exadataハイブリッド列圧縮では、列編成を使用してデータを格納し、類似した値を近接させることで圧縮率を高めています。 - インメモリー列形式のサポート
Oracle Exadata Database Machine環境では、データをインメモリー列形式でフラッシュ・キャッシュに格納することでパフォーマンスが向上する場合は、自動的にそうされます。 - データ検索およびデータ取得処理のオフロード
Oracle Exadata System Softwareの最も強力な機能の1つは、データ検索および取得処理をストレージ・サーバーにオフロードする機能です。 - 増分バックアップ処理のオフロード
増分バックアップのパフォーマンスを最適化するために、ブロックのフィルタ処理をデータベースからOracle Exadata Storage Serverにオフロードできます。 - 検疫による障害分離
Oracle Exadata System Softwareには、過去のイベントから学習して潜在的な致命的エラーを回避する機能があります。 - データ破損の防止
データ破損が起こるのは非常にまれですが、発生した場合は、データベース、さらには業務に壊滅的な影響を与える可能性があります。 - 高速ファイル作成
ファイル作成操作はOracle Exadata Storage Serverにオフロードされます。 - ストレージ索引
Oracle Exadata Storage Serverはディスク上のデータ分散のサマリーを含むストレージ索引を管理します。
1.2.1 信頼性、モジュール方式、およびコスト効率
Oracle Exadata System Softwareでは、コスト効率の高いモジュール方式のストレージ・ハードウェアをスケールアウト・アーキテクチャで使用できるため、高いレベルの可用性と信頼性が実現します。
Oracle Exadata Storage Serverのアーキテクチャでは、データのミラー化、障害分離テクノロジ、およびディスクや他のストレージ・ハードウェアの障害からの保護により、すべてのシングル・ポイント障害が排除されます。障害発生時のブラウンアウトも制限または排除されます。
Oracle Exadata Storage Serverのアーキテクチャでは、1つ以上のストレージ・セルで1つ以上のデータベースをサポートできます。データの配置は、データベース・ユーザーとアプリケーションに対して透過的に実行されます。ストレージ・セルでは、Oracle Automatic Storage Management(Oracle ASM)を使用してデータをセル間で均等に配分します。Oracle Exadata Storage Serverでは、動的なディスク挿入および削除をサポートしているため、Oracle ASMのオンライン動的データ再配分機能により、データベース処理を中断することなく、新規追加されたディスクまたは既存のディスク間でデータを適切に配分できます。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 Guard、Oracle Recovery Manager (RMAN)、Oracle GoldenGateおよび他のデータベース機能は、従来型のストレージと同様にExadataストレージ・セルで管理されます。これにより、データベース管理者は使い慣れたツールをそのまま利用できます。
最低限必要なソフトウェア・バージョンの完全なリストについては、My Oracle SupportのDoc ID 888828.1を参照してください。
1.2.3 スマート・フラッシュ・テクノロジ
Oracle Exadata System SoftwareのExadataスマート・フラッシュ・キャッシュ機能は、データベース・オブジェクトをフラッシュ・メモリー内に効率的にキャッシュし、ディスクに対する低速で機械的なI/O操作を非常に高速なフラッシュ・メモリー操作に置き換えます。
- Exadataスマート・フラッシュ・キャッシュ
Exadataスマート・フラッシュ・キャッシュでは、アクセス頻度の高いデータが高パフォーマンスのフラッシュ・ストレージに保持される一方、ほとんどのデータはコスト効率に優れたディスク・ストレージに保持されます。 - ライトバック・フラッシュ・キャッシュ
ライトバック・フラッシュ・キャッシュを使用すると、Exadataスマート・フラッシュ・キャッシュへの直接書込みI/Oが可能になります。 - Exadataスマート・フラッシュ・ログ
Exadataスマート・フラッシュ・ログは、パフォーマンスが重要となるログ書込み操作を高速化することで、トランザクションのレスポンス時間を改善し、I/O集中型ワークロードのデータベース全体のスループットを向上させます。
1.2.3.1 Exadataスマート・フラッシュキャッシュ
Exadataスマート・フラッシュ・キャッシュでは、アクセス頻度の高いデータが高パフォーマンスのフラッシュ・ストレージに保持される一方、ほとんどのデータはコスト効率に優れたディスク・ストレージに保持されます。
キャッシングは自動的に発生し、ユーザーや管理者による作業は必要ありません。
Exadataスマート・フラッシュ・キャッシュでは、データの使用状況、アクセス・パターンおよびアクセスされるデータのタイプを示すデータベースからのヒントに基づいて、キャッシュすることが最も有益なデータをインテリジェントに決定します。また、再利用されないデータやキャッシュに収まらないデータのキャッシュを回避します。
通常は必須ではなくお薦めもしませんが、Oracle Exadata System Softwareでは、管理者がデフォルトのキャッシング・ポリシーをオーバーライドして、特定の表および索引セグメントをキャッシュ内またはキャッシュ外に保持することもできます。
当初、Exadataスマート・フラッシュ・キャッシュはライトスルー・モードでのみ動作していました。ライトスルー・モードでは、データベース書込みは最初にディスクに対して行われ、その後フラッシュ・キャッシュに対して行われます。Exadataスマート・フラッシュ・キャッシュがライトスルー・モードで動作している状態でフラッシュ・デバイスに障害が発生した場合、データはすでにディスク上にあるため、データが失われることはありません。
親トピック: スマート・フラッシュテクノロジ
1.2.3.2 ライトバック・フラッシュ・キャッシュ
ライトバック・フラッシュ・キャッシュを使用すると、Exadataスマート・フラッシュ・キャッシュへの直接書込みI/Oが可能になります。
Exadataスマート・フラッシュ・キャッシュのライトバック・モードでは、データベース書込みは最初にフラッシュ・キャッシュ、その後ディスクに対して行われます。ライトバック・モードは、Oracle Exadata System Softwareリリース11.2.3.2.0で導入されました。
書込み集中型のアプリケーションでは、フラッシュによって提供される高速レイテンシを利用することで、ライトバック・モードから多大なメリットを得ることができます。書込み集中型のアプリケーションで、I/Oレイテンシが長い場合またはfree buffer waits
の待機がかなり多い場合は、ライトバック・フラッシュ・キャッシュの使用を検討する必要があります。
Exadataスマート・フラッシュ・キャッシュをライトバック・モードで使用すると、同じブロックへの複数の書込みが、ディスクへの書込みの前にキャッシュに吸収された場合にも、ディスクI/Oの量が減少します。節約されたI/O帯域幅は、アプリケーションのスループット向上や他のワークロードの処理のために使用できます。
ただし、ライトバック・モードの使用中にフラッシュ・デバイスで障害が発生した場合、ディスクにまだ永続化されていないデータは失われるため、ミラー・コピーからリカバリする必要があります。このため、ライトバック・モードは、高冗長性のASMディスク・グループと組み合せて使用することをお薦めします。
ライトバック・フラッシュ・キャッシュの内容は再起動後も保持されるため、キャッシュへの移入に必要なウォームアップ時間が不要になります。
親トピック: スマート・フラッシュテクノロジ
1.2.3.3 Exadataスマート・フラッシュ・ログ
Exadataスマート・フラッシュ・ログは、パフォーマンスが重要となるログ書込み操作を高速化することで、トランザクションのレスポンス時間を改善し、I/O集中型ワークロードのデータベース全体のスループットを向上させます。
ユーザー・トランザクションをコミットする時間は、ログ書込み操作のレイテンシの影響を大きく受けます。また、領域管理や索引分割などのパフォーマンス・クリティカルな多くのデータベース・アルゴリズムも、ログ書込みのレイテンシにより大きな影響を受けます。
ディスク・コントローラには、高速の書込みに対応した大きいバッテリ・バックアップDRAMキャッシュが備えられていますが、それでも、ビジーな期間にはディスクに書き込まれていないブロックでディスク・コントローラ・キャッシュが時々いっぱいになり、ディスクに対する一部の書込み操作が低速になることがあります。低速のREDOログ書込み操作が比較的少ない場合でも、顕著なパフォーマンスの問題が発生することがあります。
Exadataスマート・フラッシュ・ログにより、パフォーマンスに依存するREDOログ書込みI/O操作の平均レイテンシが短縮されるため、低速のREDOログ書込みが原因で発生する可能性のあるパフォーマンスのボトルネックが解消されます。Exadataスマート・フラッシュ・ログでは、2つのメディア・デバイスへのREDOログ書込みを同時に実行することで、レイテンシ・スパイクを排除します。いずれかのメディア・デバイスへの最初の書込みが完了するとすぐにREDO書込みが確認されます。
Oracle Exadata System Softwareリリース20.1より前は、Exadataスマート・フラッシュ・ログではディスクおよびフラッシュ・ストレージへの同時書込みを実行していました。この構成では、Exadataスマート・フラッシュ・ログによって平均ログ書込みレイテンシが改善され、データベース全体のスループットが向上します。ただし、すべてのログ書込みは最終的にディスクに永続化される必要があるため、この構成はディスク全体のスループットによって制限され、ディスクのスループットで制約されるアプリケーションにはほとんど役立ちません。
Oracle Exadata System Softwareリリース20.1では、ディスク記憶域ではなくExadataスマート・フラッシュ・キャッシュをライトバック・モードで使用する、スマート・フラッシュ・ログ・ライトバックと呼ばれる最適化がさらに追加されています。この構成では、Exadataスマート・フラッシュ・ログによって平均ログ書込みレイテンシおよびログ書込み全体のスループットが向上し、要求の厳しいスループット集中型アプリケーションのロギングのボトルネックが排除されます。
親トピック: スマート・フラッシュテクノロジ
1.2.4 永続メモリー・アクセラレータおよびRDMA
永続メモリー(PMEM)アクセラレータを使用すると、リモート・ダイレクト・メモリー・アクセス(RDMA)を使用して永続メモリーに直接アクセスできできることで、レスポンス時間が速くなり、読取りレイテンシが短縮されます。
Oracle Exadata System Softwareリリース19.3.0以降では、株式取引、IOTデバイスなどの極端に短いレスポンス時間を必要とするワークロードで、PMEMキャッシュとPMEMログの形式でPMEMとRDMAを利用できます。
PMEMは、Exadata X8Mで最初にリリースされた新しいストレージ層です。データベース・クライアントがPMEMキャッシュから読み取ると、クライアント・ソフトウェアはキャッシュされたデータのRDMA読取りを実行します。これにより、ストレージ・サーバー・ソフトウェアがバイパスされ、結果がExadataスマート・フラッシュ・キャッシュよりもはるかに高速に配信されます。
PMEMキャッシュは、Exadataスマート・フラッシュ・キャッシュと連携します。次の表では、PMEMキャッシュの構成時にサポートされるキャッシュ・モードの組合せについて説明します。
PMEMキャッシュ・モード | フラッシュ・キャッシュ・モード | サポートされている構成は次のとおりです。 |
---|---|---|
ライトスルー | ライトスルー | はい。これは、標準冗長性の高容量(HC)サーバーのデフォルト構成です。 |
ライトスルー | ライトバック | はい。これは、高冗長性のHCサーバーのデフォルト構成です。これは、Extreme Flash (EF)サーバーのデフォルト構成でもあります。 |
ライトバック | ライトバック | はい。 |
ライトバック | ライトスルー | いいえ。ライトバック・フラッシュ・キャッシュで補わないと、書込み集中型のワークロードによってライトバック・モードのPMEMキャッシュが過負荷になる可能性があります。 |
PMEMキャッシュが構成されていない場合、Exadataスマート・フラッシュ・キャッシュはライトバック・モードとライトスルー・モードの両方でサポートされます。
REDOログの書込みは重要なデータベース操作であり、負荷の急増や停止を防ぐために適切なタイミングで完了する必要があります。Exadataスマート・フラッシュ・ログは、REDO書込みレイテンシの外れ値を抑制するように設計されています。PMEMログは、PMEMおよびRDMAを使用することで、REDOログ書込みレイテンシをさらに短縮するために役立ちます。
PMEMログを使用すると、データベース・クライアントはRDMAを使用してREDOログI/Oバッファをストレージ・サーバーのPMEMに直接送信するため、転送レイテンシが短縮されます。その後、セル・サーバー(cellsrv
)はREDOをExadataスマート・フラッシュ・ログ(有効な場合)およびディスクに書き込みます。
REDOログの書込みレイテンシが短縮されるとOLTPのパフォーマンスが向上し、トランザクションのスループットが向上します。PMEMログがバイパスされる場合でも、Exadataスマート・フラッシュ・ログを使用できます。
1.2.5 集中型ストレージ
Oracle Exadata Storage Serverを使用すると、複数のデータベースで使用可能な中央のプールに各自のストレージ要件を統合できます。
Oracle Exadata System SoftwareとOracle Automatic Storage Management (Oracle ASM)を併用することにより、ストレージ・プールで利用可能なディスク間で、すべてのデータベースのデータおよびI/O負荷を均等に配分できます。利用可能なすべてのディスクをすべてのデータベースで使用できるため、優れたI/Oレートが実現します。Oracle Exadata Storage Serverでは、低コストで高い効率とパフォーマンスを実現できるだけでなく、ストレージ管理のオーバーヘッドも低減できます。
1.2.6 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を使用することにより、管理者はデータベース・ホストでのプロセッサの使用率をアプリケーション単位で制御できます。IORMとOracle Database Resource Managerを組み合せることにより、管理者はより正確なポリシーを設定できます。
IORMではまた、Exadataスマート・フラッシュ・キャッシュおよびPMEMキャッシュの領域使用率も管理されます。クリティカルなOLTPワークロードには、Exadataスマート・フラッシュ・キャッシュまたはPMEMキャッシュ内の領域を保証することで、安定したパフォーマンスを提供できます。
データベース用のIORMまたはプラガブル・データベース(PDB)は、Oracle Database Resource Managerから実装および管理されます。データベース・インスタンスのOracle Database Resource Managerは、ストレージ・セル内のIORMソフトウェアと通信して、ユーザー定義のサービス・レベルのターゲットを管理します。データベース・リソース・プランはデータベースから管理されますが、データベース間のプランはストレージ・セル上で管理されます。
関連項目
1.2.7 Exadataハイブリッド・コラム圧縮
Exadataハイブリッド列圧縮では、列編成を使用してデータを格納し、類似した値を近接させることで圧縮率を高めています。
Exadataハイブリッド列圧縮を使用すると、データは圧縮ユニットと呼ばれる行のセットに編成されます。圧縮ユニット内では、データは列ごとに編成されてから圧縮されます。各行は圧縮ユニット内で自己完結しています。
データベース操作は圧縮オブジェクトに対して透過的に実行されるため、アプリケーションを変更する必要はありません。データベースでは、任意のSQL操作によって処理されるデータを圧縮しますが、ダイレクト・パス・ロードでは圧縮レベルがより高くなります。
ユーザーの要件に応じて、次のタイプのExadataハイブリッド列圧縮を指定できます。
- ウェアハウス圧縮: このタイプの圧縮は、問合せパフォーマンス用に最適化されており、データ・ウェアハウス・アプリケーション向けです。
- アーカイブ圧縮: このタイプの圧縮は、最大の圧縮レベル用に最適化されており、履歴データおよび変更されないデータ向けです。
たとえば、Exadataハイブリッド列圧縮をdaily_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ハイブリッド列圧縮では、値を行にマップするメタデータとともに、列4の一意の値をそれぞれ格納します。概念上は、圧縮値は次のように表現されます。
WAREHOUSE1WAREHOUSE3WAREHOUSE2
次に、データベースでは、この値で繰り返されているWAREHOUSE
という語を圧縮するために、この語を1回だけ格納し、その各出現箇所を参照で置き換えます。参照のサイズが元の語より小さければ、データベースは圧縮に成功したことになります。圧縮の利点は、一意の値が1つのみ含まれるDate
列で特に明らかです。
次の図に示すように、各圧縮ユニットは、複数のデータ・ブロックにまたがることができます。特定の列の値は、複数のブロックにまたがる場合とまたがらない場合があります。
Exadataハイブリッド列圧縮では、暗黙的に行がロックされます。非圧縮のデータ・ブロックで行の更新が発生した場合、更新される行のみがロックされます。これに対して、更新が圧縮ユニットのいずれかの行で発生した場合、データベースではそのユニットのすべての行をロックする必要があります。Exadataハイブリッド列圧縮を使用して行を更新すると、ROWIDが変更されます。
ノート:
表でExadataハイブリッド列圧縮を使用する場合、Oracle DMLでは、比較的大きなデータ・ブロック(圧縮ユニット)がロックされるため、同時実行性が低下する可能性があります。Oracle Databaseでは、表の圧縮で4つの方法がサポートされます。
表1-2 表の圧縮方法
表の圧縮方法 | 圧縮レベル | CPUオーバーヘッド | アプリケーション |
---|---|---|---|
基本圧縮 |
高い |
最小 |
DSS |
OLTP圧縮 |
高い |
最小 |
OLTP、DSS |
ウェアハウス圧縮 |
より高い(圧縮レベルは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します) |
より高い(CPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します) |
DSS |
アーカイブ圧縮 |
最高(圧縮レベルは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します) |
最高(CPUオーバーヘッドは、指定された圧縮レベル(LOWまたはHIGH)に応じて変化します) |
アーカイブ |
ウェアハウス圧縮とアーカイブ圧縮では、Exadataハイブリッド列圧縮テクノロジが使用されるため、最高の圧縮レベルが実現します。Exadataハイブリッド列圧縮テクノロジでは、行優先ストレージではなく、修正された形式の列指向ストレージが使用されます。これにより、データベースでは、同様のデータをまとめて格納できるため、圧縮アルゴリズムの効率性が向上します。Exadataハイブリッド列圧縮では、DMLでCPUオーバーヘッドが多く必要とされるため、更新頻度の低いデータにのみこの圧縮機能を使用してください。
より高い圧縮レベルのExadataハイブリッド列圧縮は、ダイレクト・パス・インサートが行われるデータでのみ実現されます。従来の挿入および更新もサポートされますが、その場合はより低い圧縮形式となり、圧縮レベルも低下します。
次の表は、表の各圧縮方法の特徴を示しています。
表1-3 表の圧縮の特徴
表の圧縮方法 | CREATE/ALTER TABLEの構文 | ダイレクト・パス・インサート | DML |
---|---|---|---|
基本圧縮 |
|
可 |
可 ノート: 挿入および更新された行は圧縮されません。 |
OLTP圧縮 |
|
可 |
可 |
ウェアハウス圧縮 |
|
可 |
可 CPUオーバーヘッドが高くなります。 ノート: 挿入および更新された行は、より低い圧縮形式でブロックに配置されるため、圧縮レベルは低下します。 |
アーカイブ圧縮 |
|
可 |
可 ノート: 挿入および更新された行は圧縮されません。挿入および更新された行は、より低い圧縮形式でブロックに配置されるため、圧縮レベルは低下します。 |
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.8 インメモリー列形式のサポート
Oracle Exadata Database Machine環境では、データをインメモリー列形式でフラッシュ・キャッシュに格納することでパフォーマンスが向上する場合は、自動的にそうされます。
Oracle Exadata Database Machineでは、必要な圧縮列のみへのアクセス、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 Database Machineでは使用できません。これは、Exadataストレージ・サーバーのフラッシュ・キャッシュを移入するプロセスがOracle Databaseサーバーのインメモリー列ストアへのDRAMの移入と異なるためです。
1.2.9 データ検索およびデータ取得処理のオフロード
Oracle Exadata System Softwareの最も強力な機能の1つは、データ検索および取得処理をストレージ・サーバーにオフロードする機能です。
Exadataスマート・スキャンのオフロード(または単にスマート・スキャン)の主な利点の1つとして、ストレージ・サーバーのCPUを使用してデータベース・サーバーをIOから解放し、さらに圧縮形式で格納されたデータの解凍を含むことをあげることができます。スマート・スキャンでは、条件のフィルタ処理を実行することでデータベース・サーバーでの処理がさらに削減されます。条件のフィルタ処理では、データベース条件の評価を実行して、一括データ処理の特定のクラスのパフォーマンスを最適化します。
Oracle Databaseでは、全表スキャン、高速全索引スキャンおよび全ビットマップ索引スキャンを実行して、Oracle Exadata Storage Serverの選択条件を評価する問合せのパフォーマンスを最適化できます。これらの問合せは、データベース評価式をストレージ・セルに送信することにより、データベースで高速に実行できます。これらの式には、amount > 200
などの単純なSQLコマンド条件や、SELECT customer_name
などの列条件があります。次に例を示します。
SQL> SELECT customer_name FROM calls WHERE amount > 200;
この例では、条件を満たす行および指定された列のみがデータベース・サーバーに返されるため、データベース・サーバーに対する不要なデータ転送が削減されます。
Oracle Exadata System Softwareでは、表および索引スキャンの条件評価操作を簡略化してストレージ・セルに転送するストレージ側の条件評価を使用します。これにより、表スキャンがディスクの近くで実行されるため帯域幅が効率化し、一致しない行をホストに送信する必要がなくなります。
1.2.10 増分バックアップ処理のオフロード
増分バックアップのパフォーマンスを最適化するために、ブロックのフィルタ処理をデータベースからOracle Exadata Storage Serverにオフロードできます。
この最適化は、Oracle Recovery Manager(RMAN)を使用してバックアップを実行する場合にのみ可能です。オフロード処理は、ユーザー操作なしで透過的に実行されます。オフロード処理では、実行中の増分バックアップで不要なブロックがOracle Exadata System Softwareによってフィルタ処理されます。このため、バックアップに必要なブロックのみがデータベースに送信されるため、バックアップ時間が大幅に短縮します。
1.2.11 検疫による障害分離
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オフロード: 詳細は、「Cell-to-Cellオフロード操作に対する隔離マネージャのサポート」を参照してください。
検疫が作成されると、何が検疫され、検疫が作成された理由、検疫を手動で削除できるタイミングと方法、検疫が自動で削除されるタイミングが管理者にアラートで通知されます。セルにパッチが適用またはアップグレードされると、検疫はすべて自動的に削除されます。
CellCLIコマンドは手動で検疫を処理する場合に使用します。たとえば、管理者は検疫を手動で作成、削除、検疫の属性を変更、検疫を表示できます。
1.2.11.1 Cell-to-Cellオフロード操作に対する隔離マネージャのサポート
Exadataの最小ソフトウェア要件: 12.2.1.1.0
隔離マネージャのサポートは、Cell-to-Cellオフロード操作のリバランスおよび高スループット書込みで有効です。これらの操作中にExadataがクラッシュを検出すると、問題のある操作が隔離され、Exadataはオフロードされていない操作を使用する方法に戻ります。
これらのタイプの隔離は、互換性のないバージョンのCELLSRVが原因である可能性があります。ご使用のシステムでこのような隔離が発生した場合は、Oracleサポート・サービスに連絡してください。
リバランス操作の場合、隔離はASMクラスタIDに基づいています。リバランスは、より低速のフォールバック・パスを使用して続行されます。
データベースから発生した高スループット書込みの場合、隔離は、ASMクラスタIDとデータベースIDの組合せに基づいています。
CDBまたはPDBから発生した高スループット書込みの場合、隔離は、ASMクラスタIDとコンテナ・データベースIDの組合せに基づいています。
これらのタイプの隔離を識別するには、LIST QUARANTINE DETAIL
コマンドを実行し、quarantineType
属性の値を確認します。これらの隔離に対するこの属性の値は、ASM_OFFLOAD_REBALANCE
およびHIGH_THROUGHPUT_WRITE
です。HIGH_THROUGHPUT_WRITE
タイプの場合、データベースのケースとCDBのケースがあります。
LIST QUARANTINE
文によって生成される出力は次のようになります。
リバランスの場合:
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.12 データ破損の防止
データ破損が起こるのは非常にまれですが、発生した場合は、データベース、さらには業務に壊滅的な影響を与える可能性があります。
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.13 高速ファイル作成
ファイル作成操作はOracle Exadata Storage Serverにオフロードされます。
ファイル作成のオフロードにより、1つ以上のファイル作成を可能にするCREATE TABLESPACE
などの操作が大幅に高速化します。
ファイルのサイズ変更操作もストレージ・サーバーにオフロードされます。これは自動拡張可能ファイルで重要です。
1.2.14 ストレージ索引
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ハイブリッド列圧縮によって圧縮されたブロックまたは暗号化された表領域への書込み操作は、領域索引と特定の領域のストレージ索引のみを無効化します。Exadataハイブリッド列圧縮用のストレージ索引は、後続のスキャンで再構築されます。
例1-1 ストレージ索引を使用したディスクI/Oの回避
次の図は、表および領域索引を示しています。表内の値の範囲は1から8までです。一方の領域索引には最小値として1、最大値として5が格納されています。もう一方の領域索引には、最小値として3、最大値として8が格納されています。
SELECT * FROM TABLE WHERE B<2
などの問合せの場合、最初の行セットのみが一致します。2番目の行セットの最小値と最大値は問合せのWHERE
句と一致しないため、ディスクI/Oが回避されます。
例1-2 ストレージ索引から得られるパーティション・プルーニングのような効果
次の図には、Order_Number
、Order_Date
、Ship_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_Date
とOrder_Number
はOrder_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コンポーネントのサマリーを示します。
- Oracle Exadata System Softwareについて
Oracle Exadata System Softwareのユニークなソフトウェア・アルゴリズムは、ストレージでのデータベース・インテリジェンス、PCIベースのフラッシュおよびRDMAネットワーク・ファブリック・ネットワークを実装して、他のプラットフォームよりも低コストで高パフォーマンスと大容量を実現します。 - Oracle Automatic Storage Managementについて
Oracle Automatic Storage Management (Oracle ASM)は、Oracle Exadata Storage Serverのリソース管理に使用されるクラスタ・ボリューム・マネージャおよびファイル・システムです。 - グリッドRAIDについて
グリッドのRedundant Array of Independent Disks(RAID)構成では、Oracle ASMミラー化機能を使用します。 - ストレージ・サーバーのセキュリティについて
Exadata Storage Serverのセキュリティは、ストレージ・サーバーおよびグリッド・ディスクにアクセスできるクライアントを特定することによって実現されます。 - iDBプロトコルについて
iDBプロトコルは、Oracle ASM、データベース・インスタンスおよびストレージ・セル間の通信プロトコルとして機能するOracle固有のデータ転送プロトコルです。 - Oracle Exadata System Softwareプロセスについて
Oracle Exadata System Softwareには、次のソフトウェア・プロセスが含まれます。 - セル管理について
Oracle Exadata Storage Serverグリッドの各セルは、セル・コントロール・コマンドライン・インタフェース(CellCLI)で個別に管理されます。 - データベース・サーバー・ソフトウェアについて
Oracleソフトウェアは、Exadata Database Serverにインストールされます。 - Oracle Enterprise Manager for Oracle Exadata Database Machineについて
Oracle Enterprise Managerには、構成やパフォーマンスを含む、Oracle Exadata Database Machineをグラフィカル・ユーザー・インタフェース(GUI)で監視できる完全なターゲットが用意されています。
1.3.1 Oracle Exadata System Softwareについて
Oracle Exadata System Softwareのユニークなソフトウェア・アルゴリズムは、ストレージでのデータベース・インテリジェンス、PCIベースのフラッシュおよびRDMAネットワーク・ファブリック・ネットワークを実装して、他のプラットフォームよりも低コストで高パフォーマンスと大容量を実現します。
Oracle Exadata Storage Serverは、Oracle Exadata System Softwareをインストールしたネットワーク・アクセス可能なストレージ・デバイスです。このソフトウェアは、専用のiDBプロトコルを使用してデータベースと通信し、ブロック指向の読取りおよび書込みなどの単純なI/O機能と、条件のオフロードやI/Oリソース管理(IORM)などの高度なI/O機能の両方を提供します。各ストレージ・サーバーには、物理ディスクが含まれます。物理ディスクは、単一のディスク・ドライブ・スピンドルを構成するストレージ・サーバー内の実際のデバイスです。
ストレージ・サーバー内では、論理ユニット番号(LUN)は論理ストレージ・リソースを定義し、そこから単一のセル・ディスクを作成できます。LUNは、基礎となるハードウェアによって上位のソフトウェア・レイヤーに提示されるストレージ・リソースのアクセス・ポイントを示します。LUNの正確な属性は構成に固有です。たとえば、LUNはストライプ化、ミラー化、またはストライプ化とミラー化の両方が可能です。
セル・ディスクは、Oracle Exadata System Softwareを抽象化したもので、LUN上に構築されます。セル・ディスクは、LUNから作成された後にOracle Exadata System Softwareによって管理され、グリッド・ディスクにさらに分割できます。グリッド・ディスクは、データベースおよびOracle Automatic Storage Management (Oracle ASM)インスタンスに直接公開されます。各グリッド・ディスクは、Oracle ASMに直接公開されるセル・ディスクのパーティションで、Oracle ASMディスク・グループの作成および拡張に使用されます。グリッド・ディスクは不連続なパーティションになる場合があります。
このようなレベルの仮想化により、複数のOracle ASMクラスタおよびデータベース間で同じ物理ディスクを共有できます。この共有により、ディスク容量および帯域幅を最適に使用できます。セル・ディスクのレベルで収集される様々なメトリックと統計により、ストレージ・サーバーのパフォーマンスと容量を評価できます。IORMでは、ユーザー定義のポリシーに従ってセル・ディスクのアクセスをスケジュール管理します。
次の図は、ストレージ・サーバー(セルとも呼ばれる)のコンポーネントとグリッド・ディスクの関係を示しています。
- LUNは、物理ディスクから作成されます。
- セル・ディスクは、LUNで作成されます。セル・ディスク・ストレージのセグメントは、セル・システム領域と呼ばれるOracle Exadata System Softwareシステムで使用されます。
- 複数のグリッド・ディスクを1つのセル・ディスク上に作成できます。
次の図は、Oracle Exadata Storage Server環境のソフトウェア・コンポーネントを示しています。
図1-4 Oracle Exadata Database Machine環境のソフトウェア・コンポーネント
「図1-4 Oracle Exadata Database Machine環境のソフトウェア・コンポーネント」の説明
この図に示されている環境は、次のとおりです。
-
単一インスタンスまたはOracle RACデータベースでは、iDBプロトコルを使用し、RDMAネットワーク・ファブリック・ネットワークを介してストレージ・サーバーにアクセスします。各データベース・サーバーでは、Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアが実行されます。リソースは、Oracle Database Resource Manager (DBRMと表示されています)によってデータベース・インスタンスごとに管理されます。
-
データベース・サーバーには、管理サーバー(MS)、コマンドライン・インタフェース(DBMCLI)、OSベースのExaWatcherなどのOracle Exadata System Softwareの機能が含まれています。
-
ストレージ・サーバーには、次のようなOracle Exadata System Softwareのセルベースのユーティリティおよびプロセスが含まれています。
-
セル・サーバー(CELLSRV) - ストレージ・サーバーで実行されるOracle Exadata System Softwareのプライマリ・コンポーネントであり、ストレージ・サーバー・サービスの大部分を提供します。CELLSRVは、データベース・リクエストのディスクI/Oを処理し、SQLの負荷を軽減する高度な機能を提供します。CELLSRVは、I/Oリソース管理(IORM)機能を実装し、ストレージ・サーバー上でI/Oコールを発行する様々なデータベースおよびコンシューマ・グループに、I/Oの帯域幅を供給します。
-
オフロード・サーバー(CELLOFLSRV <version>) - 特定のデータベース・バージョンからのオフロード・リクエストを処理するセル・サーバーのヘルパー・プロセスです。これらのプロセスにより、ストレージ・サーバーは、同じまたは複数のデータベース・サーバーに存在する複数のデータベース・バージョンからのリクエストに応答できます。
-
管理サーバー(MS) - ストレージ・サーバーのステータスの管理および問合せを行うためのプライマリ・インタフェース。セル・コントロール・コマンドライン・インタフェース(CellCLI)と連係して動作し、CellCLIのほとんどのコマンドを処理します。
-
再起動サーバー(RS) - MSプロセスおよびCELLSRVプロセスを使用してハートビートを監視し、許容できるハートビート期間内にサーバーが応答できなかった場合は、サーバーを再起動します。
-
-
ストレージ・セルは、ネットワーク上で構成され、Oracle Exadata System SoftwareのCellCLIユーティリティで管理されます。
-
各ストレージ・サーバーには、データベース・サーバーのデータベース・インスタンスのデータを格納するための複数のディスクが含まれています。データは、Oracle ASMによって管理されるディスクに格納されます。
1.3.2 Oracle Automatic Storage Managementについて
Oracle Automatic Storage Management (Oracle ASM)は、Oracle Exadata Storage Serverのリソース管理に使用されるクラスタ・ボリューム・マネージャおよびファイル・システムです。
Oracle ASMでは、次の処理を実行してストレージ管理を拡張します。
- 最適なパフォーマンスが得られるように、利用可能なすべてのストレージ・セルおよびディスク間でデータベース・ファイルを均等にストライプ化。
- ミラー化および障害グループを使用してシングル・ポイント障害を回避。
- 動的追加および削除機能により、セルおよびディスクの割当て、割当て解除および再割当てを透過的に実行。
- 複数のデータベース間でストレージ・セルおよびディスクを共有。
次の各トピックでは、Oracle ASMの簡単な概要について説明します。
- Oracle ASMディスク・グループ
Oracle Automatic Storage Management (Oracle ASM)ディスク・グループは、Oracle ASM内で抽象化されたプライマリ・ストレージで、1つ以上のグリッド・ディスクで構成されます。 - Oracle ASMの障害グループ
Oracle ASM障害グループは、同じハードウェアを共有するために同時に停止する可能性があるOracle ASMディスク・グループのディスクのサブセットです。 - Oracle ASMの最大可用性
高冗長性のOracle ASMディスク・グループと、Oracle Exadata Deployment Assistantを使用して自動的にデプロイ可能なファイルの配置構成をお薦めします。
1.3.2.1 Oracle ASMディスク・グループ
Oracle Automatic Storage Management (Oracle ASM)ディスク・グループは、Oracle ASM内で抽象化されたプライマリ・ストレージで、1つ以上のグリッド・ディスクで構成されます。
Oracle Exadata Storage Serverのグリッド・ディスクは、Oracle ASMディスク・グループのメンバーシップに使用可能な個々のディスクとして、Oracle ASMに認識されます。グリッド・ディスク名とOracle ASMディスク・グループ名は、Oracle ASMとOracle Exadata System Software間で問題が発生した場合に容易に診断できるように、できるだけ関連性のある名前にすることをお薦めします。
通常、Oracle Exadata Database Machineは、次の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.2.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.2.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スマート・ライトバック・フラッシュ・キャッシュに与える影響はごくわずかです。
次の表では、冗長性オプション、その他のオプション、および相対的な高可用性のトレードオフについて説明します。次の表は、投票ディスクが高冗長性ディスク・グループに含まれていることを前提としています。既存の高冗長性ディスク・グループ構成の高冗長性グループに投票ディスクを移行するには、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。
冗長性のオプション | 可用性の意味 | 推奨事項 |
---|---|---|
すべて(DATAおよびRECO)を高冗長性にする |
投票ディスクが高冗長性ディスク・グループに存在している場合、前述のストレージ停止のシナリオでは、アプリケーションのダウンタイムおよびデータ損失はゼロです。 現在投票ディスクが標準冗長性ディスク・グループに含まれている場合、それらを高冗長性ディスク・グループに移行するには『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。 |
ミッション・クリティカルなアプリケーションのための最高のストレージ保護および運用の簡素化のために、このオプションを使用します。冗長性を高めるには、より多くの領域が必要です。 |
DATAのみを高冗長性にする |
前述のストレージ停止のシナリオでは、アプリケーションのダウンタイムおよびデータ損失はゼロです。このオプションでは、別のアーカイブ先が必要です。 |
運用の複雑性が若干高いDATAのための最高のストレージ保護には、このオプションを使用します。すべてを高冗長化する場合よりも使用可能な領域が増えます。 詳細は、My Oracle Supportノート2059780.1を参照してください。 |
RECOのみを高冗長性にする |
前述のストレージ停止のシナリオでは、データ損失はゼロです。 |
前述のストレージ停止のシナリオで長時間のリカバリが許容される場合は、このオプションを使用します。リカバリ・オプションは次のとおりです。
|
すべて(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.3 グリッドRAIDについて
グリッドのRedundant Array of Independent Disks(RAID)構成では、Oracle ASMミラー化機能を使用します。
グリッドRAIDを使用するには、「標準」または「高」の冗長性レベルでグリッド・ディスクをOracle ASMディスク・グループに配置し、すべてのグリッド・ディスクを同じセルに設定して、同じOracle ASM障害グループにします。これにより、Oracle ASMがセル内のディスクを使用してデータ・エクステントをミラー化することがなくなります。様々なセルからディスクを使用するため、個々のセルで障害が発生してもデータが利用できなくなることはありません。
グリッドRAIDでは、セル・ディスクを簡単に作成することもできます。Oracleソフトウェアでは必要なLUNが自動的に作成されるため、グリッドRAIDを使用することにより、利用可能な物理ディスクからLUNが自動的に作成されます。
1.3.4 ストレージ・サーバーのセキュリティについて
Exadata Storage Serverのセキュリティは、ストレージ・サーバーおよびグリッド・ディスクにアクセスできるクライアントを特定することによって実現されます。
クライアントには、Oracle ASMインスタンス、データベース・インスタンスおよびクラスタがあります。グリッド・ディスクを作成または変更する場合は、グリッド・ディスクの使用権限を設定したOracle ASM所有者およびデータベース・クライアントを構成できます。
1.3.5 iDBプロトコルについて
iDBプロトコルは、Oracle ASM、データベース・インスタンスおよびストレージ・セル間の通信プロトコルとして機能するOracle固有のデータ転送プロトコルです。
汎用のデータ転送プロトコルは、下位レベルのディスク・ブロックでのみ動作します。これに対し、iDBプロトコルは、Oracleの内部データ表現を認識し、条件処理のオフロードなど、Exadataストレージ・サーバー固有の機能に必要な補助機能です。
また、iDBプロトコルでは、インターコネクト帯域幅の集約とフェイルオーバーを提供します。
1.3.6 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>)は、特定のデータベース・バージョンからのオフロード・リクエストを処理するCELLSRVのヘルパー・プロセスです。オフロード・サーバーを使用すると、各ストレージ・サーバーで複数のデータベース・バージョンからのすべてのオフロード操作をサポートできます。オフロード・サーバーはCELLSRVとともに自動的に実行されるため、追加の構成やメンテナンスは必要ありません。
-
管理サーバー(MS)は、スタンドアロンのOracle Exadata System Software管理および構成機能を提供します。MSはアラートの送信も行い、CELLSRVによって収集された統計に加えていくつかの統計を収集します。
-
再起動サーバー(RS)はCELLSRV、オフロード・サーバーおよびMSプロセスを監視し、必要に応じて再起動します。
1.3.7 セル管理について
Oracle Exadata Storage Serverグリッドの各セルは、セル・コントロール・コマンドライン・インタフェース(CellCLI)で個別に管理されます。
CellCLIユーティリティには、セルの初期構成、セル・ディスクおよびグリッド・ディスクの作成、パフォーマンスの監視など、セル管理機能のためのコマンドライン・インタフェースが用意されています。CellCLIユーティリティはセル上で実行され、ストレージ・セルにネットワーク・アクセスするクライアント・コンピュータまたは直接セルに接続されるクライアント・コンピュータからアクセスできます。CellCLIユーティリティは、管理サーバーと通信してストレージ・セルを管理します。
セルにアクセスするには、Secure Shell(SSH)アクセス、またはKVMスイッチ(キーボード、ビデオ、視覚的表示装置、マウス用スイッチ)などを介したローカル・アクセスのいずれかを使用する必要があります。SSHではリモート・アクセスが可能ですが、セルがネットワークにまだ構成されていない場合は、初期構成でローカル・アクセスが必要になる場合があります。ローカル・アクセスを使用すると、セルのオペレーティング・システムのシェル・プロンプトにアクセスできるため、CellCLIユーティリティなどの各種ツールを使用してセルを管理できます。
dcliユーティリティを使用すると、複数のセルで同じCellCLIコマンドをリモートで実行できます。
セルを計算ノードからリモートで管理するために、ExaCLIユーティリティを使用できます。ExaCLIにより、ほとんどのCellCLIコマンドをセルで実行できます。これが必要になるのは、セルに直接アクセスしてCellCLIを実行できない場合、またはセルでSSHサービスが無効になっている場合です。複数のセルでリモートでコマンドを実行するために、exadcli
ユーティリティを使用できます。
関連項目:
-
セルをリモートで管理する方法の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』のExaCLIユーティリティの使用に関する項を参照してください
-
複数のセルをリモートで管理する方法の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』のexadcliユーティリティの使用に関する項を参照してください
1.3.8 データベース・サーバー・ソフトウェアについて
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.9 Oracle Enterprise Manager for Oracle Exadata Database Machineについて
Oracle Enterprise Managerには、構成やパフォーマンスを含む、Oracle Exadata Database Machineをグラフィカル・ユーザー・インタフェース(GUI)で監視できる完全なターゲットが用意されています。
次の図は、Exadata Storage Serverグリッド・ホームページを示しています。このページを表示すると、ストレージ・サーバーの状態、ストレージの主要なパフォーマンス特性、およびストレージのリソース使用率をデータベース別に迅速に表示できます。
図1-5 Oracle Enterprise ManagerのExadata Storage Serverグリッド・ホームページ
「図1-5 Oracle Enterprise ManagerのExadata Storage Serverグリッド・ホームページ」の説明
Oracle Enterprise Managerでは、レポートに加えて、アラートのメトリックしきい値を設定したり、Exadataシステムの状態を判断するためのメトリック値を監視することもできます。