A Oracle Exadata Database Machineの新機能

この付録では、Oracle Exadata Database MachineおよびOracle Exadata System Softwareの新機能について説明します。

A.1 Oracle Exadata Database Machine 19.1.0の新機能

Oracle Exadata System Software 19.1.0の新機能は次のとおりです。

A.1.1 Oracle Linux 7.5へのOracle Linuxのアップグレード

Oracle Exadata System Softwareリリース19.1.0では、データベース・サーバーおよびストレージ・サーバーで使用されるオペレーティング・システムがOracle Linux 7.5に更新されました。以前のリリースで使用されていたOracle LinuxカーネルUEK4は、引き続き同じままです。

Oracle Linux 7の詳細は、Oracle Linux 7のドキュメントを参照してください。

A.1.1.1 Oracle Databaseソフトウェアの最小必須バージョン

次のOracle DatabaseおよびOracle Grid Infrastructureソフトウェア・リリースは、Oracle Exadata System Softwareリリース19.1.0およびOracle Linux 7.5でサポートされています。

Oracle Exadata System Software 19.1.0以降では、次のOracle Databaseソフトウェア・リリースがサポートされています。

  • Oracle DatabaseおよびOracle Grid Infrastructure 19c
  • Oracle DatabaseおよびOracle Grid Infrastructure 18c
    • 最低バージョン 18.3.0.0.180717
  • Oracle DatabaseおよびOracle Grid Infrastructure 12cリリース2 (12.2.0.1.0)
    • 最低バージョン 12.2.0.1.180717
  • Oracle DatabaseおよびOracle Grid Infrastructure 12cリリース1 (12.1.0.2.0)
    • 最低バージョン 12.1.0.2.180831
  • Oracle Database 11gリリース2(11.2.0.4.0)
    • 最低バージョン 11.2.0.4.180717
    • Oracle Grid Infrastructure release 12.1.0.2.180831以上が必要です
  • Oracle Database 11gリリース2(11.2.0.3.0)
    • 最低バージョン 11.2.0.3.28
    • Oracle Grid Infrastructure release 12.1.0.2.180831以上が必要です
    • Oracle Databaseソフトウェアのインストールは、このリリースでは手動タスクであり、OEDAでは処理されません。

      注意:

      Oracle Database 11gリリース2 (11.2.0.3.0)に、これ以上バンドル・パッチはありません。このリリースのパッチ適用終了日は、2015年8月27日でした。

Oracle Linux 7リリースの詳細は、Oracle Linux 7リリース・ノート新機能および変更点を参照してください。

A.1.2 クラウド・スケール・パフォーマンスの自動監視

Oracle Exadata System Softwareリリース19.1.0以降Exadata Database Machineは、CPU、メモリー、ファイル・システム、IO、ネットワークなど、幅広いサブシステムを対象に、自動化されたクラウド・スケール・パフォーマンス監視を提供します。この機能では、人工知能、長年にわたる現実世界でのパフォーマンス・トリアージの経験、およびベスト・プラクティスを組み合わせています。

Oracle Exadata System Softwareは、パフォーマンスの問題を自動検出し、人間の介入なしに根本原因を特定できます。この機能の動作例を次に示します。

  • 回転プロセスがシステム上のすべてのリソースを占有し、データベースのパフォーマンスに影響を与える場合、Oracle Exadata System SoftwareはCPUスピンを自動的に検出し、スピンの原因であるプロセスを正確に特定してアラートを生成します。
  • Oracle Databaseが、ベスト・プラクティス推奨に従って大規模なページに正しく構成されていない場合、Oracle Exadata System Softwareは正しく構成されていないことを自動的に検出し、影響を受けるデータベース・インスタンスについてアラートを生成します。

この機能に構成は必要ありません。アラートを受信するには、通知メカニズムを構成する必要があります。Oracle Exadata Storage Serverのリクエストとアラートの監視、およびALTER DBSERVERを参照してください。

この機能の一部として、ストレージ・サーバー、データベース・サーバー(ベア・メタル構成)および管理ドメイン(dom0)に加えて、ユーザー・ドメイン(domU)で管理サーバー(MS)が有効になります。

最小要件:

  • Oracle Exadata System Software 19.1.0

A.1.3 列レベルのチェックサムを使用したスマート・スキャンの高速化

チェックサムの計算および検証は、データの格納または取得中に発生する可能性のあるエラーを検出するのに役立ちます。チェックサムは、データがExadataフラッシュ・キャッシュに書き込まれるときに計算され、後続の読取り時に検証されます。

Oracle Exadata System Softwareリリース19.1.0より前では、読取り後にフラッシュ上のブロックでチェックサムが計算されていました。通常、このブロックには複数の列が含まれますが、典型的なデータ・ウェアハウス問合せは表の一部の列にしかアクセスしません。Oracle Exadata System Softwareリリース19.1.0では、チェックサム計算の単位が1列に減っています。チェックサムは列ごとに計算され、列圧縮単位(CU)ヘッダーに格納されます。この最適化は、Exadataスマート・フラッシュ・キャッシュのインメモリー列形式でのみ有効です。

列レベル・チェックサムのアプローチの主な利点は、次のとおりです。

  • 選択的なチェックサム計算: 対象となる列を含むフラッシュ・ブロックがスマート・スキャンによって読み取られるとき、キャッシュ行に他の列が多数存在する場合でも、チェックサム検証は特定の列CUに対してのみ実行されます。そのため、チェックサムが実行されるデータ量が減り、CPU使用率が低くなります。たとえば、A < 5 and Z < 10という述語について考えてみます。列Aが存在するフラッシュ・ブロックには、列B、CおよびDを含まれる可能性があります。ただし、B、CおよびDは問合せで参照されていないため、B、CおよびDに対してチェックサムは実行されません。

  • Just in timeのチェックサム計算: チェックサムは列が処理される場合にのみ実行されます。たとえば、A < 5 and Z < 10という述語について考えてみます。チェックサムは列Aの列CUで計算され、述語が評価されます。述語A < 5を満たす行がない場合、Z < 10を評価する理由はありません。列Zの列CUに対してチェックサム計算は実行されません。そのため、チェックサムが実行されるデータ量が大幅に減り、CPU使用率が低くなります。

この機能は、INMEMORY_SIZEデータベース初期化パラメータを構成し、Oracle Exadata System Softwareリリース19.1.0にアップグレードするときに自動的に有効になります。この新機能を使用するために、これ以上の構成は必要ありません。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドデータ検索および取得処理のオフロードを参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
  • Exadataスマート・フラッシュキャッシュ
  • INMEMORY_SIZEデータベース初期化パラメータ

A.1.4 セルの停止およびフラッシュ障害時のOLTP高可用性の拡張

Oracle Exadata System Softwareリリース19.1.0では、セルの停止およびフラッシュ障害に起因するOLTP高可用性をさらに拡張する新機能が導入されています。この機能で、複数のストレージ・サーバーのフラッシュ・キャッシュのホット・データを部分的に複製することによって、フラッシュ・デバイスまたはストレージ・サーバーの障害後にアプリケーション・パフォーマンスが向上します。

セルがオフラインになるかフラッシュ・デバイスが失敗した場合、停止のためにプライマリ・ミラーが使用できないため、データベースは、読取り操作用のセカンダリ・ミラーを使用するようにIOをリダイレクトします。ただし、セカンダリ・ミラーは各セルのフラッシュ・キャッシュにないため、データベースはハード・ディスクからデータを読み取る必要があります。フラッシュ・キャッシュ・ミスが原因で、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。

この新機能を使用すると、Oracle Exadata System Softwareは、フラッシュ・キャッシュに最も頻繁にアクセスされるOLTPデータのセカンダリ・ミラーをプリフェッチします。このプリフェッチはバックグラウンド・タスクとして実行されます。Oracle Exadata System Softwareは、フラッシュ・キャッシュ内のセカンダリ・ミラーを最適な方法で自動的に管理し、新しいアクティブなセカンダリ・ミラーがキャッシュ内のコールド・データを置換します。また、フラッシュ・デバイスを交換すると、この機能によって、新しいフラッシュ・デバイスにデータベースの読取り操作を行う前に、新しく交換されたフラッシュ・デバイスがより新しい(堅牢な)ものになります。したがって、この機能により、セルまたはフラッシュ・デバイスの障害時とフラッシュ・デバイスの交換時に、セカンダリ・ミラー・フラッシュ・キャッシュミスが著しく減少するるため、アプリケーション・パフォーマンスの高可用性が向上します。

この機能はOLTPワークロードにのみ有効です。Oracle Exadata System Softwareは、スキャン・データのセカンダリ・ミラーをキャッシュしません。また、この機能はライトバック・フラッシュ・キャッシュに対してのみ有効になります。ライトスルー・フラッシュ・キャッシュでは、セカンダリ・ミラー・キャッシュは実行されません。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
  • 大容量ストレージ・サーバー上のExadataライトバック・フラッシュ・キャッシュ
  • Exadata Database Machine X6以上(フラッシュ・キャッシュ・サイズの要件のため)

A.1.5 個別ネットワーク上のホストおよびILOMのサポート

以前は、Oracle Exadata System Softwareでのアラート通知など特定の機能を使用するために、ExadataサーバーおよびIntegrated Lights Out Manager (ILOM)が同じ管理ネットワークを使用する必要がありました。Oracle Exadata System Softwareリリース19.1.0以降では、以前サポートされていたすべての機能を維持したまま、このネットワーク依存関係がなくなります。

この機能を利用してILOM用に別のネットワークを構成すれば、ExadataサーバーおよびILOMが相互に完全に分離されるため、セキュリティが向上します。

Oracle Exadata Database Machineインストレーションおよび構成ガイドILOM用の個別ネットワークの構成に関する項を参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0

A.1.6 DB_UNIQUE_NAMEでExadataストレージを共有する複数クラスタをサポート

同じストレージを共有するデータベースに対して、同じDB_UNIQUE_NAME値を使用できるようになりました。この機能により、同じストレージ・セルを共有するOracle Multitenantクラスタ・データベースが同じDB_UNIQUE_NAMEを持つことができます。

以前のリリースでは、複数のクラスタがExadataストレージを共有できるのは、各インスタンスのDB_UNIQUE_NAME値がすべてのクラスタでグローバルに一意である場合にだけでした。Oracle Exadata System Softwareリリース19.1.0では、各クラスタに独自のDB_UNIQUE_NAMEネームスペースを設定できます。つまり、異なるクラスタ間で同じDB_UNIQUE_NAME値を使用できるということです。たとえば、以前のリリースでは、cluster1およびcluster2は、DB_UNIQUE_NAMEパラメータをdb1に設定したデータベースを1つ(cluster1またはcluster2)しか持てませんでした。このリリースでは、各クラスタでASMスコープのセキュリティを構成すれば、DB_UNIQUE_NAMEパラメータをdb1に設定したデータベースを両方のクラスタが持つことができます。

この機能により、Exadataストレージを共有する異なるクラスタが、DB_UNIQUE_NAME割当てを調整して名前の競合を回避する必要がなくなります。各クラスタでは、クラスタごとにASMスコープのセキュリティを構成しているかぎり、他のクラスタと調整することなく、任意のDB_UNIQUE_NAME値を選択できます。

ASMスコープのセキュリティが構成されている場合、ASMクラスタ名を使用して、ストレージ・サーバーにアクセスする際のDB_UNIQUE_NAMEを修飾します。各データベースについて収集されるメトリックと統計は、I/Oリソース管理(IORM)、フラッシュ・キャッシュ、セルのオフロードなど様々な領域で、asmcluster.database名修飾も使用します。

警告:

同じDB_UNIQUE_NAMEを持つように複数のデータベースを構成する場合、そのデータベースをOracle Zero Data Loss Recovery Applianceにバックアップできません。各データベース・インスタンスのDB_UNIQUE_NAMEは、Oracle Zero Data Loss Recovery Applianceのスコープ内で一意である必要があります。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
  • DB_UNIQUE_NAMEが等しい各データベースは、異なるOracle ASMクラスタに存在する必要があります。
  • Oracle ASMクラスタごとに構成されたASMスコープのセキュリティ

A.1.7 Secure Eraserの更新

Oracle Exadata System Softwareリリース19.1.0では、Secure Eraserが様々な点で改善されました。

A.1.7.1 マルチパス・ディスク消去からSecure Eraserへの自動アップグレード

1パス、3パスまたは7パスのメソッドを使用してディスクを消去するように指定した場合、Oracle Exadata System Softwareは、基礎となるハードウェアでサポートされていれば自動的に最適なSecure Eraserメソッドを使用します。

ディスクが大きくなればなるほど、従来のマルチパス上書きメソッド(1パス、3パス、7パスなど)は、Secure Eraserで使用される消去メソッドよりも完了までに時間がかかるようになります。たとえば10TBのハード・ドライブになると、7パス消去に4日以上かかることもありますが、Secure Eraserを使用すれば、わずか1分です。サポートされているハードウェアと推定消去時間については、データベース・サーバーおよびストレージ・サーバーの安全な消去を参照してください。

ディスクでサポートされていれば、Secure Eraserを使用する方が高速で安全です。DROP CELLおよびDROP CELLDISKで使用されるSecure Eraserメソッドは、Secure Eraser機能のものと同じであり、NIST SP-800-88r1標準に準拠しています。

詳細は、DROP CELLおよびDROP CELLDISKを参照してください。

最小要件:

  • Oracle Exadata System Software 19.1.0
  • Oracle Exadata Database Machine X5-2以上
A.1.7.2 イメージ化の一部として自動実行されるSecure Eraser

Oracle Exadataラックを転用する際は通常、最初にOracle Exadata System Softwareリリース12.2.1.1.0で導入されたSecure Eraser機能を使用してデータを消去し、その後必要なOracle Exadata Database Machineイメージでラックを再イメージ化するという2つの部分からなるプロセスです。

Oracle Exadata System Softwareリリース19.1.0以降、ハードウェアがSecure Eraserをサポートしている場合、Secure Eraserは再イメージ化中に自動的に起動されます。これにより、パフォーマンスを維持しながら再イメージ化する手順が大幅に簡略化されます。ラックを転用する場合は、ラックをイメージ化するだけで、プロセスの一環として安全なデータ消去が透過的に行われます。

詳細は、Oracle Exadata Database Machineセキュリティ・ガイド安全な消去の概要を参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0

  • Oracle Exadata Database Machine X5-2以上

A.1.7.3 Secure Eraserの改善および新機能
このリリースでは、次の新機能およびコマンド・オプションがSecure Eraserに追加されました。
  • 証明書のタイムスタンプにタイムゾーンが含まれるようになりました
  • データ・ディスクのみを消去し、システム・ディスクを除外するオプション(--erase_data_only)
  • 個々のデバイスの消去をサポート(--devices_to_erase)

詳細は、Oracle Exadata Database Machineセキュリティ・ガイドSecureEraser構文を参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
  • Oracle Exadata Database Machine X5-2以上(暗号消去用)

A.1.8 サーバー時刻同期化でchronyを使用

Oracle Exadata System Softwareリリース19.1.0以降、Oracle Linux 7を実行しているExadataデータベース・サーバーおよびストレージ・サーバーはntpdを使用できなくなりました。かわりに、chronyを使用してサーバーのシステム・クロックをNTPサーバーと同期します。chronyは通常、ntpdより高速かつ高精度でシステム・クロックを同期できます。

Oracle Linux 6からOracle Linux 7にアップグレードすると、NTPサーバー設定がchronyに移行されます。

Oracle Linux 7で動作保証されているOracle Grid InfrastructureおよびOracle Databaseリリースもすべて、chronyをサポートしています。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0

A.1.9 Quorumディスク・マネージャ・サービスの変更

Oracle Linux 7を実行しているOracle Exadata Database Machineデータベース・サーバーおよびストレージ・サーバーは、Exadata Quorumディスク・マネージャtgtdサービスのかわりにtargetサービスを使用します。

Oracle Linux 6からOracle Linux 7へのアップグレード中に、Quorumディスク・マネージャを使用するOracle Exadata Database Machineデータベース・サーバーは、基礎となる新しいtargetサービスを使用するよう移行されます。移行はローリング方式で実行できます。Quorumディスク・マネージャの管理インタフェースは同じままで、Oracle Linux 7へのアップグレード後に変更が必要な場合に使用できます。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0

A.1.10 監査ルール・ファイル

Exadataデータベース・サーバー上のOracle Linux 6からOracle Linux 7へのアップグレード中に、Oracle Linux 6監査設定が移行され、監査ファイル01-exadata_audit.rulesに移動されます。Oracle Exadata Database Machineに固有でないルールは、アップグレード中に移行されません。これらのルールは個別に再構成する必要があります。Oracle Exadata Database Machineに固有でないルールのカスタム監査ルール・ファイルを作成して確保しておくことをお薦めします。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドOracle Exadata Storage Serverでのオペレーティング・システム・アクティビティの監視に関する項を参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0

A.1.11 カスタマイズ可能なSYSLOGフォーマット

新しいセルおよびデータベース・サーバー属性syslogFormatを使用して、標準のsyslogフォーマットを任意のフォーマットに変更できます。

この属性を設定すると、管理サーバー(MS)は、指定されたフォーマット文字列を含むように/etc/rsyslog.confファイルを変更し、syslogデーモンを再起動します。syslogFormatを空の文字列に設定すると、フォーマット変更が削除され、デフォルト・フォーマットがリストアされます。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドALTER CELL、またはOracle Exadata Database Machineメンテナンス・ガイドALTER DBSERVERを参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0

A.1.12 セキュリティの改善

Oracle Exadata System Softwareリリース19.1.0では、様々なセキュリティ改善が導入されました。

A.1.12.1 RESTfulサービスのアクセス制御

Oracle Exadata System Softwareリリース19.1.0以上では、Exadata RESTfulサービスへのHTTPsアクセスでユーザーがアクセス制御リストを構成できる新しい機能が導入されています。ユーザーは、IPアドレスまたはIPサブネット・マスクのリストを指定して、HTTPsを介してRESTfulサービスにアクセスできるユーザーを制御できます。または、RESTfulサービスが使用されていない場合、ノードへのHTTPsアクセスの無効化を選択できます。この機能は、Oracle Exadata Database ServerOracle Exadata Storage Serverの両方に適用されます。

詳細は次のトピックを参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
A.1.12.2 リモート・ユーザーのパスワードの有効期限

Exadata RESTfulサービスへのアクセスまたはExaCLIを使用するリモート・ユーザーのパスワード有効期限を構成できるようになりました。Exadataサーバーでは、パスワード有効期限を構成し、失効したユーザーがパスワードをリモートで変更できるかどうかを構成する属性を設定できます。追加属性を設定すると、パスワードが期限切れになる前の警告期間の長さと、ユーザー・アカウントがロックされる期限切れまでの時間を指定できます。

注意:

この機能はリモート・ユーザーにのみ適用され、celladminoracleなどのオペレーティング・システム・ユーザーには適用されません。

これらの属性がサーバーで設定されている場合、ユーザーが有効期限の切れたパスワードでアカウントに接続しようとすると、次の2つのいずれかが発生します。

  • サーバーがリモートでのパスワード変更を許可するように構成されている場合、ユーザーはただちにパスワードを変更するよう求められます。
  • サーバーがリモートでパスワードを変更できない場合、パスワードが期限切れであることを示すエラーが表示され、パスワードを変更するには支援が必要になります。

詳細は次のトピックを参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
A.1.12.3 Advanced Intrusion Detection Environment (AIDE)

Oracle Exadata System Softwareリリース19.1.0では、Exadataシステム上のファイルへの不正アクセスを防止するために、Advanced Intrusion Detection Environment (AIDE)のサポートが追加されました。AIDEは、システムに対する悪質な改変または計画外の変更をレポートするセキュリティ機能です。AIDEは、システム上にファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確認してシステム侵入を検出します。

詳細は次のトピックを参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
  • Oracle Linux 7
A.1.12.4 セキュリティ向上のための最小権限の原則の実装

セキュリティのベスト・プラクティスでは、タスクの実行に必要な最小限の権限で各プロセスを実行する必要があります。次のプロセスは、権限のないユーザーとして実行されるようになりました。

  • Smart Scanプロセス

    rootユーザー権限を使用して実行するために使用されるOracle Exadata Storage Serverでスマート・スキャンを実行するプロセス。条件評価の実行にroot権限は必要ありません。Oracle Exadata System Softwareリリース19.1.0以降、これらのスマート・スキャン・プロセスはcelloflと呼ばれる新しいオペレーティング・システム・ユーザーによって所有されます。Oracle Exadata System Softwareリリース19.1.0へのソフトウェア更新を実行すると、ユーザーcelloflおよびグループcelltraceが自動的に作成されます。

  • ExaWatcher プロセスの選択

    ExaWatcherインフラストラクチャは、Oracle Exadata Database ServerOracle Exadata Storage Serverの両方でシステム統計を収集およびアーカイブします。iostatnetstatpstopなどの情報を収集するコマンドの一部は、rootユーザー権限なしで実行できるように変更されました。Oracle Exadata Storage ServerおよびOracle Exadata Database Serverと、Oracle Exadata Database Serverで実行されている仮想マシンでソフトウェア・アップデートを実行すると、新しいオペレーティング・システム・ユーザーexawatchおよびグループexawatchが自動的に作成されます。

これらの変更の結果、rootユーザーとして実行されるプロセスの数が著しく減少するため、Oracle Exadataサーバーのセキュリティが向上します。

この機能は、Oracle Exadata System Softwareリリース19.1.0へのソフトウェア更新を実行すると自動的に有効になります。追加の構成は不要です。

詳細は次のトピックを参照してください。

A.1.12.5 ストレージ・サーバー・プロセスのセキュリティの向上

Oracle Linuxカーネルでのセキュアなコンピューティング(seccomp)機能を使用すると、プロセスから実行できるシステム・コールを制限できます。

Oracle Linuxカーネルには数百のシステム・コールがありますが、ほとんどのプロセスでは必要ありません。seccompフィルタは、システム・コールが許可されるか制限されるかを定義します。seccompフィルタがセル・サーバーにインストールされ、アップグレード時にはセル・オフロード・サーバー・プロセスが自動的にインストールされます。ホワイトリストに設定されたシステム・コールは、セル・サーバーおよびセル・オフロード・サーバーから実行できます。ホワイトリストされた特定のシステム・コールの場合、seccompフィルタは引数の追加検証を実行します。

seccompフィルタを使用すると、セル・プロセスのセキュリティ・レベルが向上します。この機能は、Oracle Exadata System Softwareリリース19.1.0で自動的に有効になります。

A.1.12.6 SSHD ClientAliveIntervalを600秒に変更

ClientAliveIntervalパラメータを使用すると、非アクティブな期間(秒単位で指定)の経過後にSSHクライアントが自動的にタイムアウトします。指定された時間制限に達したときに、クライアントからデータが受信されなかった場合、SSHDは暗号化されたチャネルを介してメッセージを送信し、クライアントからのレスポンスをリクエストします。サーバー側からレスポンスが受信されない場合、接続は破棄されます。以前のClientAliveIntervalはストレージ・サーバーで2時間、データベース・サーバーでは24時間に設定されていました。patchmgrから行われたdcliコールがタイムアウトしないように、これらには大きい値が必要でした。

patchmgrユーティリティも変更されています。patchmgrから行われたdcliコールは、実行時パラメータを使用してタイムアウト制限を延長します。こうすると、サーバーから10分以上通信がない場合でも、コールはタイムアウトしなくなります。

A.1.12.7 パスワード要件の強化

データベース・サーバーおよびストレージ・サーバーでオペレーティング・システム・ユーザーを作成する場合、新しいExadataデフォルト・パスワード・ポリシー・ルールは次のとおりです。

  • 文字の最小数: 8
  • 数字の最小数: 1
  • 小文字の最小数: 1
  • 大文字の最小数: 1
  • 特殊文字の最小数: 1
  • 連続繰返し文字の最大数:3
  • 同じクラスの連続繰返し文字の最小数:4
  • 異なる数字の最小数: 8
  • パスワード変更の最小日数:1
  • パスワード変更の最大日数:60
  • 辞書の単語が無効または受け入れられません。
  • 直前に使った10個までのパスワードは再使用できません

注意:

Oracle Exadata System Softwareリリース19.1.0に新しい制限が追加される前に作成されたパスワードは、問題なく機能します。SSH等価を使用する場合、違いはありません。

詳細は次のトピックを参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース19.1.0
A.1.12.8 HTTPsを使用してDIAGPACKをOracle ASRマネージャにアップロード

セキュリティを強化するために、HTTPsを使用して診断パッケージをアップロードするために、管理サーバー(MS)およびOracle ASRマネージャを構成できます。

A.1.13 Oracle Exadata System Softwareリリース19.1.0で非推奨となった機能

次の機能は、このリリースでは非推奨であり、将来のリリースではサポートされなくなる可能性があります。

A.1.13.1 インターリーブ・グリッド・ディスクが非推奨に

グリッド・ディスクのインターリーブ・オプションは非推奨になりました。インターリーブ・グリッド・ディスクを作成しようとすると、自動的に通常のグリッド・ディスク作成に変換されます。

Oracle Exadata System Softwareリリース19.1.0より前に作成したインターリーブ・グリッド・ディスクは、以前のリリースと同様に機能します。

A.1.13.2 nfsimgイメージが非推奨に

Oracle Exadata System Softwareリリース19.1.0以降、Oracle Exadata Database Machineサーバーをイメージ化または再イメージ化する場合、NFSイメージは非推奨になりました。かわりにPXEおよびISOイメージングを使用する必要があります。

Secure Eraserパッケージ(secureeraser_label.zip)には、Oracle Exadata System Softwareリリース19.1.0以降、NFSイメージではなくISOイメージも含まれています。

この変更を反映するために、ドキュメントの該当セクションが更新されています。

A.1.14 Oracle Exadata System Softwareリリース19.1.0で非推奨となった機能

Oracle Exadata V2は、Oracle Exadata System Softwareリリース19.1.0以降、動作保証されなくなりました。現在の動作保証情報は、Exadata System Softwareの動作保証(My Oracle SupportDoc ID2075007.1)にあります

A.2 Oracle Exadata Database Machine 18c (18.1.0)の新機能

次に、Oracle Exadata System Software 18c (18.1.0)の新機能を示します。

A.2.1 インメモリーOLTPおよび統合アクセラレーション

Oracle Exadata Storage Serverは、フラッシュ・メモリーの前に新しいメモリー・キャッシュを追加します。これは、ハード・ディスクの前にある現在のフラッシュ・キャッシュと同様です。この機能は、100マイクロ秒(µs)のオンライン・トランザクション処理(OLTP)の読取りIOレイテンシを提供しており、250μsのフラッシュOLTPの読取りIOレイテンシよりも2.5倍低い値です。この機能を利用するために、既存のメモリー・アップグレード・キットを使用してメモリーをストレージ・サーバーに追加できます。

セルRAMキャッシュはストレージ・サーバーのフラッシュ・キャッシュの前にあるキャッシュで、データベース・キャッシュを拡張したものです。フラッシュ・キャッシュよりも高速ですが、容量は小さくなっています。バッファがデータベース・バッファ・キャッシュの有効期限を過ぎている場合、キャッシュ・ポリシーに従ってセルRAMキャッシュにこれらのバッファを移入できるように、データベースがセルに通知します。これらのバッファはセルRAMキャッシュに排他的にキャッシュされます。データ・ブロックをデータベース・バッファバッファ・キャッシュに戻す必要がある場合、バッファ(存在する場合)はセルRAMキャッシュから削除されます。セルRAMキャッシュは排他的なキャッシュです。データ・ブロックはセルRAMキャッシュまたはデータベース・バッファ・キャッシュのみに存在しますが、両方には存在しません。

読取り操作時にデータ・ブロックがデータベース・バッファ・キャッシュに見つからない場合(キャッシュ・ミス)、データベースはセルからのデータ・ブロックの読取りを指示します。CELLSRVはRAMキャッシュをチェックしてから、IOスタックのより低い層(フラッシュ・メモリーまたはハード・ディスク)にアクセスします。

  • データ・ブロックがRAMキャッシュに見つかった場合、データ・ブロックはデータベースに同期的に返されます。データ・ブロックがデータベース・バッファ・キャッシュにキャッシュされる場合、ストレージ・サーバーはRAMキャッシュからデータ・ブロックを削除します。

  • データ・ブロックがRAMキャッシュに見つからない場合、ストレージ・サーバーはフラッシュ・キャッシュを検索します。データ・ブロックがフラッシュ・キャッシュに見つからない場合、データ・ブロックはディスクから読み取られます。データ・ブロックはデータベースに返されますが、RAMキャッシュに追加されません。

書込み操作時に、データベースはデータ・ブロックの書込みをストレージ・サーバーに指示します。Cell Server (CELLSRV)はRAMキャッシュをチェックしてから、IOスタックのより低い層(フラッシュ・キャッシュまたはハード・ディスク)にアクセスします。

  • データ・ブロックがRAMキャッシュに見つかった場合、CELLSRVではRAMキャッシュの対応するキャッシュ行を無効にし、ディスクに書き込むためにデータ・ブロックをより低い層に送信します。RAMキャッシュには移入されません。

  • データ・ブロックがRAMキャッシュに見つからない場合、ストレージ・サーバーはディスクに書き込むためにデータ・ブロックをより低い層に送信します。RAMキャッシュには移入されません。

フラッシュ・キャッシュとは異なり、ストレージ・サーバー上のRAMキャッシュは排他的なキャッシュです。格納されるデータ・ブロックはRAMキャッシュまたはデータベースのバッファ・キャッシュのいずれかに存在しますが、両方には存在しません。データベースはバッファ・キャッシュからデータ・ブロックを削除した場合、RAMキャッシュにデータ・ブロックを移入するようにCELLSRVに指示します。CELLSRVはRAMキャッシュに非同期的に移入します。

プライマリ・ミラー上でストレージ・サーバーが失敗した場合、データベースでは、RAMキャッシュへの移入をセカンダリ・ミラーに送信します。これにより、ブロックはセカンダリ・ミラーのRAMキャッシュにキャッシュされます。プライマリ・ミラーがオンライン状態に戻ると、ブロックはプライマリ・ミラーのRAMキャッシュに戻されます。

新規メモリー・キャッシュ・セクションが、RAMキャッシュのステータスおよびアクティビティの監視用AWRレポートで使用可能です。

最小要件:

  • Oracle Exadata System Software 18c (18.1.0)

  • Oracle Exadata Storage Server X6またはX7

  • Oracle Databaseバージョン12.2.0.1 2018年4月のDBRUまたは18.1以降

A.2.2 ストレージ・サーバーでのインメモリー列指向キャッシング

Oracle Exadata System Softwareリリース12.2.1.1.0では、Exadata Hybrid Columnar Compression表用にOracle Exadata Storage Server上でインメモリー列指向キャッシングのサポートを導入しました。Oracle Exadata System Software 18c (18.1.0)では、特に圧縮されていない表およびOLTP圧縮表などの表タイプを追加するために、ストレージ・サーバー上でインメモリー列指向のサポートを拡張しました。

圧縮されていない表およびOLTP圧縮表のためにDatabase In-Memory形式を拡張すると、追加した表タイプに関するSmart Scan問合せに、ストレージ・フラッシュ・キャッシュに格納されたデータに対する高速ベクトル処理インメモリー・アルゴリズムが役立ちます。この形式では、結合や集計など、ほとんどのインメモリー・パフォーマンス拡張がSmart Scanでサポートされています。Database In-Memory形式は領域効率に優れており、通常、非圧縮形式またはOLTP圧縮形式よりも少ない領域を使用します。Database In-memory形式でデータを格納すると、ストレージ・フラッシュ・キャッシュで領域がより適切に使用されます。

従来の非圧縮形式またはOLTP圧縮形式からDatabase In-Memory形式への再書込みは、非常にCPU負荷が高くなります。Oracle Exadata System Softwareには、頻繁に変更されないリージョンに対してDatabase In-Memory形式でデータをキャッシュするための組込みのインテリジェンスがあります。

標準表領域(暗号化されていない)および暗号化表領域からのデータを、インメモリー列指向キャッシュ形式でキャッシュできます。

Oracle Database In-Memoryを使用する場合と同様に、新しいDatabase In-Memory形式は、問合せのパフォーマンスに悪影響を及ぼさないようバックグラウンド・プロセスで作成されます。

INMEMORY_SIZEデータベース初期化パラメータを構成した場合、この機能はデフォルトで有効になっており、この新機能を使用するために追加の構成は必要ありません。INMEMORY_SIZEが構成されていない場合、非圧縮表およびOLTP圧縮表のデータは、ネイティブ形式でフラッシュ・キャッシュにキャッシュされ、Database In-Memory列指向形式ではキャッシュされません。

この機能を無効にする必要がある場合、ALTER TABLEコマンドとともに新しいDDLキーワードCELLMEMORYを使用できます。『Oracle Exadata System Softwareユーザーズ・ガイド』ストレージ・サーバーでのインメモリー列指向キャッシングの有効化または無効化に関する項を参照してください。

最小要件:

  • Oracle Exadata System Software 18c (18.1.0)

  • Oracle Database 12cリリース1 (12.1.0.2)バージョン12.1.0.2.161018DBBPまたはOracle Database 12cリリース2 (12.2.0.1)

  • Oracle Database 12cリリース1 (12.1.0.2)を使用している場合、バグ24521608のパッチ

  • (推奨)バグ26261327のパッチ(複雑な問合せ用のより適切な逆オフロード機能を有効化)

A.2.3 Oracle Exadata Storage Serverのクラウド・スケールのソフトウェア更新

Oracle Exadata Storage Serverのクラウド・スケールのソフトウェア更新機能では、ストレージ・サーバー用に新しいクラウド・スケールのソフトウェア更新プロセスを導入しました。ストレージ・サーバーをソフトウェア・ストアにポイントします。ストレージ・サーバーは、バックグラウンドで新しいソフトウェアをダウンロードします。ソフトウェア更新に優先される時間をスケジュールできます。ストレージ・サーバーでは、データベースをオンラインのまま、自動的にOracle Exadata System Softwareをローリング方式でアップグレードします。1つのソフトウェア・リポジトリを、多数のストレージ・サーバーに使用できます。この機能は、クラウドおよびオンプレミス・ユーザーにより単純で高速なソフトウェア更新を提供しています。

各ストレージ・サーバーはソフトウェアをアクティブなパーティションにダウンロードし、その後、ソフトウェアをパッシブなパーティションにロードします。ストレージ・サーバーは、指定されたスケジュールに従って新しいバージョンを再起動します。

この機能は、専用のpatchmgrセッションなしでストレージ・サーバーが更新できるようにすることで、ソフトウェア更新のスケーラビリティを改善します。多数のストレージ・サーバーを更新する場合、管理者はdcliを使用してALTER SOFTWAREUPDATEコマンドを発行し、すべてのストレージ・サーバーに対するソフトウェアの場所と時間パラメータを設定します。非常に大きなデプロイメントで競合を削減するために、複数のソフトウェアの場所を使用できます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドストレージ・サーバーの自動更新のスケジュールを参照してください。

最小要件:

  • Oracle Exadata System Software 18c (18.1.0)この機能を使用して、後続のソフトウェア更新をインストールできます。

A.2.4 高速なOracle Exadata Database Serverのソフトウェア更新

Oracle Exadata Database Serverのソフトウェア更新は以前よりも大幅に処理時間が削減され、以前のリリースと比較すると、最大40%速くなりました。これにより、データベース・サーバーのソフトウェア更新に必要なコストと労力が削減されます。

最小要件:

  • Oracle Exadata System Software 18c (18.1.0)

A.2.5 Oracle VMでのイーサネット・パフォーマンスの改善

Oracle Exadata System Software 18c (18.1.0)では、仮想化を使用して、システムのイーサネット・パケットの送受信を最適化しました。この最適化により、ネットワーク・レイテンシを抑えてネットワーク・パフォーマンスが大きく改善され、管理ドメイン (dom0)およびユーザー・ドメイン (domU)のCPU使用率が改善されました。

最小要件:

  • Oracle Exadata System Software 18c (18.1.0)

A.2.6 ディスクのオンライン完了後のパフォーマンス改善

以前のリリースでは、Oracle ASMの再同期操作時に、キャッシュ行がターゲット・ストレージ・サーバーにキャッシュされていても、ソース・ストレージ・サーバーにキャッシュされない場合、Oracle Exadata System Softwareでは、ターゲット・ストレージ・サーバーのフラッシュ・キャッシュからこれらを削除していました。これにより、プライマリ・ミラーが影響を受ける場合があり、キャッシュ・ミスが発生したり、パフォーマンスが低下しました。

このリリース以降、Oracle Exadata System Softwareでは、すでにフラッシュ・キャッシュに存在するOracle ASM再同期チャンク・リージョン内のキャッシュ行が保持されるようになり、無効化されなくなりました。これにより、キャッシュ・ミスを防止できます。この機能により、前のバージョン・リリースと比較すると、Oracle ASM再同期操作時のパフォーマンスが大幅に向上しました。

最小要件:

  • Oracle Exadata System Software 18c (18.1.0)

A.2.7 フラッシュの障害後の高可用性改善

フラッシュの障害後のシステム全体のパフォーマンスが改善されました。以前は、フラッシュの障害後、フラッシュの復元が完了すると、Oracle ASMは影響を受けたOracle Exadata Storage Serverでディスクから読取りを開始していました。しかしながら、ストレージ・サーバーは通常よりもフラッシュ・デバイスの数が少なく、そのため、そのストレージ・サーバー上でのパフォーマンスに影響がありました。Oracle Exadata System Software 18c (18.1.0)以降、Oracle ASMでは、障害が起きたすべてのフラッシュ・デバイスがそのストレージ・サーバー上で交換されて初めて、ディスクから読取りを開始します。

必要な最小ソフトウェア:

  • Oracle Exadata System Software 18c (18.1.0)

A.2.8 IORMの最大使用率制限をフラッシュ・デバイスに適用

Oracle Exadata System Softwareリリース18c (18.1.0)以上では、データベース内リソース・プラン・ディレクティブのI/Oリソース管理(IORM)プラン・ディレクティブまたはmax_utilization_limitLIMITを使用すると、フラッシュ・デバイスおよびハード・ディスク上のデータベースのI/O使用率が制限されます。

最大使用率制限(LIMIT)の概念はIORMでサポートされています。リソース割当て値の指定に加えて、特定のデータベースに対して最大使用率制限も指定できます。このディレクティブにより、指定した制限を超えるI/Oリソースがデータベースで利用されなくなります。たとえば、本番とテスト環境用のデータベースがExadataセルを共有している場合、テスト用データベースにLIMITを指定し、テスト用データベースのI/O使用率を制限することができます。

最大使用率制限が指定されている場合、データベースが過剰な容量を使用することはありません。最大使用率制限を指定すると、ディスクをフル容量未満で実行できます。

ALTER IORMPLANまたはI/Oリソース管理の理解を参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata System Software 18c (18.1.0)

A.2.9 OEDAコマンドライン・インタフェース

Oracle Exadata Deployment Assistant (OEDA)コマンドライン・インタフェース(oedacli)は、既存のes.xmlファイルを更新する際に使用できる新しいインタフェースです。これらの更新は、アクションと呼ばれます。アクションは、単一のアトミック・タスクです。アクションの例として、新しいゲストの作成があります。アクションは多数のサブ・コマンドを持つことができますが、ほとんどのアクションは単一のコマンドです。複数のコマンドの手順の例として、CLONE GUESTCLONE CELLがあります。

oedacliを使用して、次のような様々なExadataライフ・サイクル管理タスクで役立てることができます。

  • Oracle Exadata Database Machine上の仮想クラスタへのノードの追加またはノードの削除

  • 物理クラスタへのデータベース・ホームの追加または物理クラスタからのデータベース・ホームの削除

  • ストレージ・セルの追加または削除

  • Oracle ASMディスク・グループのサイズ変更

  • その他のデータベースの追加または削除

  • Oracle VMクラスタへのその他のデータベース・ホームの追加または削除

詳細は、Oracle Exadata Database Machineインストレーションおよび構成ガイドOEDAコマンドライン・インタフェースを参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata System Software 18c (18.1.0)

  • Oracle Exadata Deployment Assistant (OEDA) (2017年8月リリース)

A.2.10 Oracle Exadata Database Machine X7の新機能

次の新機能は、Oracle Exadata Database Machine X7で使用可能です。

A.2.10.1 ストレージ・サーバー上のDoNotService LED

冗長性の低いクラスタでOracle Exadata Storage Serverの電源をオフにすると、Oracle ASMディスク・グループの強制ディスマウントが発生したり、データの可用性が低下します。間違って異なるストレージ・サーバーの電源をオフにするなどのヒューマン・エラーを防止するために、Oracle Exadata Database Machine X7に新しいDoNotService LEDが付属しています。このLEDは、サービスのためにOracle Exadata Storage Serverの電源をオフにしてもよいかどうかを示します。Oracle Exadata System Softwareリリース18.1以降、冗長性が低くなったときに、DoNotService LEDはリアルタイムで自動的にオンになり、サービスのためにストレージ・サーバーの電源をオフにしないようにシステム管理者またはフィールド・エンジニアに通知します。

たとえば、ストレージ・サーバーまたはディスクがオフラインの場合、Oracle Exadata System Softwareでは、パートナ・ディスクが含まれるストレージ・サーバーのDoNotService LEDを自動的にオンにして、これらのサーバーをサービスのためにオフにしないように知らせます。冗長性が回復すると、Oracle Exadata System SoftwareDoNotService LEDを自動的にオフにして、ストレージ・サーバーの電源をサービスのためにオフにできることを知らせます。

詳細は、次を参照してください。

最小要件:

  • Oracle Exadata System Softwareリリース18.1.0.0.0

  • Oracle Grid Infrastructure:

    • リリース12.1.0.2 2017年7月BP (ARU 21405133を含む)

    • リリース12.1.0.2 2017年10月BP以降

    • リリース12.2.0.1 2017年7月BP (ARU 21405125を含む)

    • リリース12.2.0.1 2017年10月BP以降

  • Oracle Exadata Database Machine X7-2またはX7-8 (ストレージ・サーバーのみ)

A.2.10.2 Oracle Exadata Storage Server X7のオンライン・フラッシュ・ディスク交換

以前の世代のOracle Exadata Database MachineではOracle Exadata Storage Server X7-2 Extreme Flashでのオンラインのフラッシュ・ディスクの交換が可能でしたが、Oracle Exadata Storage Server X7-2 High Capacityでのフラッシュ・ディスクの交換はサーバーのダウンタイムが必要でした。Oracle Exadata Database Machine X7-2LおよびX7-8以降、Oracle Exadata Storage Server X7-2 High Capacityのフラッシュ・ディスクはオンラインでも交換でき、サーバーのダウンタイムがなくなりました。

Oracle Exadata System Softwareは、常にフラッシュ・ディスクの状態を監視しています。フラッシュ・ディスクに障害が発生したか、パフォーマンスが低下した場合、ディスクはすぐに交換できます。フラッシュ・ディスクに予測障害が発生した場合、冗長性を確保するには、次の状態になるまでフラッシュ・ディスクを交換しないでください。

  • デバイスをデータ・グリッド・ディスクとして使用している場合、Oracle ASMディスクのリバランスが完了

  • デバイスをフラッシュ・キャッシュに使用している場合、フラッシュ・キャッシュのフラッシュが完了

Oracle Exadata System Softwareは、冗長性を損なわずにフラッシュ・ディスクを安全に交換したら、自動的にOracle ASMディスクのリバランスおよびフラッシュ・キャッシュのフラッシュ操作の進行を監視し、ユーザーに通知を送信します。いずれの場合も、フラッシュ・ディスクを安全に交換できるようになると、Oracle Exadata System Softwareでは、自動的にオンライン交換用にフラッシュ・ディスクを準備し、そのフラッシュ・ディスクをdropped for replacementステータスに移行して、交換する準備が完了したことを示します。さらに、Oracle Exadata System Softwareは、フラッシュ・カードの注意用LEDを自動的にオンにし、カードの電源LEDをオフにして、交換するカードを示すことができます。

システム管理者またはフィールド・エンジニアはストレージ・サーバーを停止せずにシャーシを開き、LEDパターンでカードを容易に識別し、ディスクを交換できます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドフラッシュ・ディスクのホット・プラグ交換の実行を参照してください。

最小要件:

  • Oracle Exadata Storage Server X7-2 Extreme Flash

  • Oracle Exadata System Softwareリリース18.1.0.0.0およびOracle Exadata Storage Server X7-2 High CapacityまたはOracle Exadata Database Machine X7-8

A.2.10.3 ストレージ・サーバーのシステム・パーティションの新しい構成

以前の世代のOracle Exadata Database Machineでは、スロット0と1で2つのディスクの一部をシステム・パーティションとして使用していました。これは、オペレーティング・システムおよびOracle Exadata System Softwareがインストールされる場所です。Oracle Exadata Database Machine X7以降では、システム・パーティション専用に2つのM.2ディスクがあります。Oracle Exadata Storage Server X7-2 High Capacityのすべてのハード・ディスクおよびOracle Exadata Storage Server X7-2 Extreme Flashのすべてのフラッシュ・ディスクは、データ・ストレージ専用になっています。

この構成では、システムI/OとデータI/Oを分離して、スロット0と1のデータ・ディスク上のパフォーマンスを改善しました。ストレージ・サーバーのディスクはスロット0と1でディスク全体で作成でき、すべてのディスクでサイズは統一されています。

さらに、Oracle Exadata System Softwareでは、最新のインテル・ラピッド・ストレージ・テクノロジ・エンタープライズ(インテルRSTe) RAIDを使用して、M.2ディスク上にシステム・パーティションを作成し、従来のソフトウェアRAIDよりも高速なパフォーマンスを提供し、データ保護を強化しています。

Oracle Exadata System Softwareでは、M.2ディスクのオンライン交換もサポートしています。M.2ディスクは、サーバーのダウンタイムなしで交換できます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドExadata Storage ServerのM.2ディスクの保守を参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata System Software 18c (18.1.0)

  • Oracle Exadata Database Machine X7-2またはOracle Exadata Database Machine X7-8

A.2.10.4 セキュア・ブート

セキュア・ブートは、システムを起動する際に実行できるバイナリを制限するために使用する方法です。セキュア・ブートを使用すると、システムUEFIファームウェアでは、信頼できるエンティティの暗号署名を使用するブート・ローダーの実行のみを許可します。つまり、UEFIファームウェアで実行されるすべてのものは、システムが信頼できると認識する鍵で署名する必要があります。サーバーを再起動するたびに、実行されるすべてのコンポーネントが検証されます。これにより、マルウェアがブート・チェーンで組込みコードを隠せないようにします。

  • ブート・セクター・マルウェアまたはカーネル・コード・インジェクションの防止用

  • ハードウェアベースのコード署名

  • UEFIファームウェア・アーキテクチャの拡張

  • UEFIファームウェアによる有効化または無効化が可能

詳細は、Oracle Exadata Database Machineセキュリティ・ガイドシステムの起動に使用するバイナリの制限を参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata System Softwareリリース18c (18.1.0)

  • Oracle Exadata Database Machine X7-2またはX7-8

  • ベア・メタルのインストール

A.3 Oracle Exadata Database Machine 12.2.1.1.0の新機能

Oracle Exadata Database Machine 12.2.1.1.0の新機能は次のとおりです。

A.3.1 ストレージ・サーバーでのインメモリー列指向キャッシング

Oracle Exadata System Softwareリリース12.2.1.1.0では、ストレージ・フラッシュ・キャッシュ内のデータに対して高速ベクトル処理インメモリー・アルゴリズムを使用できます。この機能は、Oracle Database In-Memory (Database In-Memory)オプションのライセンスを所有している場合に使用可能です。

Database In-Memory形式のキャッシュにより、純粋な列指向のExadata Hybrid Columnar Compression形式で提供される以上に、Database In-Memory形式で保持されるデータの量が大幅に増加し、Smart Scanパフォーマンスが大幅に向上します。

Oracle Exadata System Softwareリリース12.1.2.1.0では、フラッシュ・キャッシュに純粋な列指向のExadata Hybrid Columnar Compression形式で自動的にExadata Hybrid Columnar Compressionデータを格納する、列指向のキャッシュ形式が追加されました。このリリースでは、Exadata Hybrid Columnar Compressionデータのサポートが拡張され、キャッシュしたデータをDatabase In-Memory形式で再書込みすることや、超高速な単一命令複数データ(SIMD)の述語をSmart Scanで使用することができるようになりました。この形式では、結合や集計など、ほとんどのインメモリー・パフォーマンス拡張がSmart Scanでサポートされています。

標準表領域(暗号化されていない)および暗号化表領域からのデータを、インメモリー列指向キャッシュ形式でキャッシュできます。

Oracle Database In-Memoryを使用する場合と同様に、新しいDatabase In-Memory形式は、問合せのパフォーマンスに悪影響を及ぼさないようバックグラウンド・プロセスで作成されます。

この機能は、INMEMORY_SIZEデータベース初期化パラメータが構成されている場合はデフォルトで有効になっており、ユーザーがこの拡張機能を取得するために行う必要がある操作はありません。INMEMORY_SIZEの詳細は、Oracle Databaseリファレンスを参照してください。INMEMORY_SIZEが構成されていない場合は、12.1.2.1.0と同様のExadata Hybrid Columnar Compression形式の列指向キャッシュが以降も使用されます。

この機能を無効にする必要がある場合、ALTER TABLEコマンドとともに新しいDDLキーワードCELLMEMORYを使用できます。Oracle Exadata System Softwareユーザーズ・ガイドストレージ・サーバーでのインメモリー列指向キャッシングの有効化または無効化を参照してください。

最小要件:

  • Oracle Database 12cリリース1 (12.1.0.2) (必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBP)または

  • Oracle Database 12cリリース2 (12.2.0.1)

  • バグ24521608のパッチ

A.3.2 暗号化表領域の列指向フラッシュ・キャッシュ

Oracle Exadata System Software 12.2.1.1.0では、列指向フラッシュ・キャッシュのサポートが暗号化表領域まで拡張されています。Oracle Database In-Memory (Database In-Memory)オプションのライセンスを所有している場合は、暗号化表領域データは、インメモリー列指向形式でストレージ・フラッシュ・キャッシュに格納されます。このオプションのライセンスがない場合、暗号化表領域データは、純粋な列指向Exadata Hybrid Columnar Compression形式でストレージ・サーバー・フラッシュ・キャッシュに格納されます。

最小要件:

  • Oracle Database 12cリリース1 (12.1.0.2) (必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBP)または

  • Oracle Database 12cリリース2 (12.2.0.1)

  • バグ24521608のパッチ

A.3.3 ストレージ索引でのセット・メンバーシップ

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では、通常のストレージ索引でこれらのディスク・リージョンをフィルタ処理できません。

最小要件:

  • Oracle Database 12cリリース1 (12.1.0.2) (必要な最小ソフトウェア・バージョンは12.1.0.2.161018DBBP)または

  • Oracle Database 12cリリース2 (12.2.0.1)

  • バグ24521608のパッチ

A.3.4 8列を超える列情報を格納するためのストレージ索引

12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、ストレージ索引で8列までの列情報を保持できます。Oracle Exadata System Softwareリリース12.2.1.1.0では、ストレージ索引が、24列までの列情報を格納するよう拡張されました。

8列の列情報を格納するための領域が保証されています。8列を超える場合、領域は、列のセット・メンバーシップ・サマリーと列の最小/最大サマリーとで共有されます。ワークロードのタイプによって、セット・メンバーシップ・サマリーがストレージ索引に格納されるかどうかが決定されます。

詳細は、ストレージ索引でのセット・メンバーシップを参照してください。

A.3.5 5倍高速なOracle Exadata System Softwareの更新

Oracle Exadata System Softwareの更新に要する時間がさらに短縮されました。Oracle Exadata System Softwareの更新処理が、12.1.2.3.0と比べて2倍、12.1.2.3.0より前のリリースと比べて5倍高速になりました。更新時間が短縮されることで、ソフトウェアの更新に必要なコストと労力が削減されます。

A.3.6 大量分析問合せおよび大量ロードのパフォーマンス高速化

大量の結合操作または集計操作がメモリーに適さず、ストレージにあふれさせる必要がある場合は、一時書込みおよび一時読取りを使用します。12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、一時書込みはフラッシュ・キャッシュでキャッシュされませんでした。一時書込みと後続の一時読取りは、どちらも、ハード・ディスクのみから行われていました。Oracle Exadata System Softwareリリース12.2.1.1.0では、一時書込みは、後続の一時読取りを同様にフラッシュ・キャッシュから実行できるよう、フラッシュ・キャッシュに送信されます。これにより、問合せが一時I/Oバウンドである場合に、一時にあふれる問合せが大幅に高速化されます。一定の問合せについて、パフォーマンスを最大で4倍高速化できます。これは、一時表領域全体をフラッシュに入れた場合に匹敵します。この機能を使用できるようにするためには、ライトバック・フラッシュ・キャッシュを有効にする必要があります。

Oracle Exadata System Softwareリリース12.2.1.1.0より前では、フラッシュ・キャッシュへの書込みにはサイズのしきい値がありました。128 KBを超えるほとんどの書込みは、ディスクに直接送られます。これは、これらの書込みがすぐに読み取られることが想定されていないためです。たとえば、直接ロード書込み、フラッシュバック・データベース書込み、アーカイブ済ログ書込みおよび増分バックアップ書込みは、フラッシュ・キャッシュを迂回します。Oracle Exadata System Softwareリリース12.2.1.1.0以降では、フラッシュ・キャッシュのアルゴリズムは、そのような大量の書込みによって優先度がより高いOLTPまたはスキャン・ワークロードが中断されない場合に、そのような大量の書込みをフラッシュ・キャッシュにリダイレクトするよう拡張されました。そのような書込みは、後でディスクがそれほどビジーでなくなったときにディスクにライトバックされます。この機能により、Oracle Exadata Storage Serverで、追加の予備フラッシュ容量およびI/O帯域幅を利用して全体的なパフォーマンスを向上させることができます。

この機能がV2およびX2ストレージ・サーバーを除くすべてのOracle Exadata Database Machineハードウェアでサポートされていることを覚えておいてください。X3およびX4ストレージ・サーバーでは、フラッシュ圧縮が有効になっている場合は、一時書込みおよび大量書込みのフラッシュ・キャッシングはサポートされません。

この機能に関連する新しい統計およびレポートに関するセクションが、12.1.0.2.0 2017年7月のDBBPおよび12.2.0.1.0 2017年10月のRURでも使用できるOracle Database 18c(18.1.0)自動ワークロード・リポジトリ(AWR)レポートに追加されました。

最小要件:

  • Oracle Exadata Database Machine X3-2以降

  • Oracle Exadata System Software 12.2.1.1.0

  • Oracle Database (次のいずれか):

    • Oracle Database 11gリリース2 (11.2) (バグ24944847の修正が適用済)

    • Oracle Database 12cリリース1 (12.1) — 12.1.0.2.0 2017年7月のDBBP

    • Oracle Database 12cリリース2 (12.2.0.1) — 12.2.0.1.0 2017年10月のRUR

    • Oracle Database 18c (18.1.0)

A.3.7 セキュア・イレイザー

Oracle Exadata System Softwareリリース12.2.1.1.0以降には、Oracle Exadata Database Machine内のすべてのコンポーネントに対してセキュア・イレイザと呼ばれる安全な消去のソリューションが用意されています。これは、2ソケット・サーバーと8ソケット・サーバーの両方を含めた、V2以上のすべてのExadata Database Machinesに対応する包括的なソリューションです。

Oracle Exadata Database Machineの以前のバージョンでは、DROP CELL ERASEDROP CELLDISK ERASEDROP GRIDDISK ERASEなどのCellCLIコマンドを使用してユーザー・データを安全に消去できます。ただし、これらのDROPコマンドは、ハード・ドライブとフラッシュ・デバイスのユーザー・データにのみ対応しています。セキュア・イレイザは、ユーザー・データのみでなく、オペレーティング・システム、Oracle Exadata System Software、ユーザー構成を含むすべてのコンテンツをサニタイズします。さらに、セキュア・イレイザーは、ハード・ドライブ、フラッシュ・デバイス、内部USB、ILOMを含む広範囲のハードウェア・コンポーネントに対応します。

セキュア・イレイザーは、データベース・サーバーとストレージ・サーバーのすべてのデータを消去し、InfiniBandスイッチ、イーサネット・スイッチおよび配電ユニットを出荷時のデフォルトにリセットします。Oracle Exadataマシンの使用を廃止するか目的を再設定する場合に、この機能を使用できます。セキュア・イレイザーは、マシンの各コンポーネント上のデータおよびメタデータのすべてのトレースを完全に消去します。

セキュア・イレイザー・ユーティリティの詳細は、Oracle Exadata Database Machineセキュリティ・ガイドを参照してください。

A.3.8 Oracle ASM範囲付セキュリティのセル間オフロード・サポート

セル間のオフロード操作を効率的に実行するには、ストレージ・サーバーが、データベース・サーバーを介するのではなく他のストレージ・サーバーに直接アクセスする必要があります。

ご使用のExadata環境でOracle ASM範囲付セキュリティを構成してある場合は、ストレージ・サーバーがそれ自体を他のストレージ・サーバーに対して認証することで相互に直接通信できるようにするために、セル・キーを設定する必要があります。これは、Oracle ASMの再同期、復元、再構築およびリバランスの操作、およびデータベースの高スループット書込み操作に適用されます。

A.3.9 Oracle Exadata Database Machine X6-2データベース・サーバーへの他のネットワーク・カードの追加

Oracle Exadata Database Machine X6-2データベース・サーバーでは、マザーボードで可用性の高い10 Gbps銅線ネットワークが提供され、スロット2のPCIカードを介して10 Gbps光ネットワークが提供されます。

Oracle Exadata System Softwareリリース12.2.1.1.0以降は、さらに接続性が必要な場合は、イーサネット・カードを追加できます。追加のカードにより、デュアルポート10 GbE光接続性(部品番号X1109A-Z)またはデュアルポート10 GbE銅線接続性(部品番号7100488)のどちらかを提供できます。この部品は、Oracle Exadata Database Machine X6-2データベース・サーバー上のPCIeスロット1に取り付けることができます。

ネットワーク・カードを取り付けてネットワークに接続すると、Oracle Exadata System Softwareリリース12.2.1.1.0は、自動的にその新しいカードを認識してデータベース・サーバー上で2つのポートをeth6およびeth7インタフェースとして構成します。これらの追加ポートを、追加でクライアント・ネットワークを提供するためや、別にバックアップまたは障害回復ネットワークを作成するために使用できます。仮想マシンを実行するデータベース・サーバーでは、このネットワーク・カードを使用して、トラフィックを2つの仮想マシンから分離できます。

A.3.10 Oracle ASRの自動Diagpackアップロード

Oracle Exadata System Software リリース12.2.1.1.0では、管理サーバー(MS)は、Oracle ASR Managerと通信し、Oracle ASRに関する情報を含む診断パッケージを自動的にアップロードします。以前のリリースでは、自動サービス・リクエスト(SR)が開かれた後、他の診断情報を手動でアップロードする必要がありました。この手順を自動化することで、この機能は、Oracle ASRの応答時間を大幅に短縮します。

この機能は、2つの新しい属性をAlertHistoryオブジェクトに追加します。

  • 新しいserviceRequestNumber属性は、関連付けられているサービス・リクエスト番号を示します。

  • 新しいserviceRequestLink属性は、関連付けられているサービス・リクエスト番号へのURLを示します。

その他の重要機能を次に示します。

  • 診断パッケージRESTfulページ(https://hostname/diagpack/download?name=diagpackname)には、対応するサービス・リクエストへのリンクを示す、新しい列があります。

  • Oracle ASRアラート電子メールに、SRリンクが含まれています。

Oracle ASRの自動Diagpackアップロードを有効にするには、Oracle ASR Managerhttp_receiverを有効にする必要があります。

  • http_receiverが有効になっているかどうかを確認するには、次のコマンドをOracle ASR Managerから実行します。

    asr show_http_receiver
  • http_receiverを有効にするには、次のコマンド(portは、http_receiverがリスニングするポート)を使用します。

    asr enable_http_receiver -p port

    注意:

    ここで指定したポートは、データベース・サーバーまたはストレージ・サーバーでサブスクライバに指定したasrmPortと同じである必要があります。次のコマンドは、データベース・サーバーおよびストレージサーバーでasrmPortを確認する方法を示します。

    DBMCLI> LIST DBSERVER ATTRIBUTES snmpSubscriber 
         ((host=test-engsys-asr1.example.com, port=162,community=public, 
    type=ASR,fromIP=10.242.0.55,asrmPort=16168))
    
    CellCLI> LIST CELL ATTRIBUTES snmpSubscriber
         ((host=test-engsys-asr1.example.com,port=162,community=public,
    type=ASR,asrmPort=16168))
    

診断データをサービス・リクエストに自動的にアップロードする必要がない場合は、ALTER CELL diagPackUploadEnabled=FALSEを実行して自動アップロードを無効にできます。

必要な最小ソフトウェア: Oracle ASR Managerリリース5.7

A.3.11 Oracle Exadata Database Serverで使用可能なCREATE DIAGPACKおよびLIST DIAGPACKコマンド

ストレージ・サーバーで使用可能な診断パッケージ機能が、データベース・サーバーでも使用可能になりました。データベース・サーバー上の管理サーバー(MS)は、データベース・サーバー・アラート生成時の関連するログおよびトレースを含む、カスタマイズされた診断パッケージを自動的に収集します。これは、重要なすべてのデータベース・サーバー・アラートに適用されます。診断情報の適時収集は、重要なログのロールオーバーを防ぎます。

データベース・サーバー上のMSは、重要なすべての電子メール・アラートで、診断パッケージを電子メール添付ファイルとして送信します。ユーザーは、新しいCREATE DIAGPACK DBMCLIコマンドを使用して開始時刻および継続時間を指定することで、毎時間カスタム診断パッケージを作成できます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドCREATE DIAGPACKおよびLIST DIAGPACKを参照してください。

A.3.12 レスキュー計画

12.2.1.1.0より前のリリースのOracle Exadata System Softwareでは、Oracle Exadata Database ServerまたはOracle Exadata Storage Serverのレスキューの後、複数のコマンドを再実行して、I/Oリソース管理(IORM)計画、しきい値、およびストレージ・サーバーおよびデータベース・サーバーの通知設定などの項目を構成する必要があります。

Oracle Exadata System Softwareリリース12.2.1.1.0では、cellおよびdbserverオブジェクトにはrescuePlanという新しい属性があります。この属性を使用してコマンドのリストを取得し、それをスクリプトとして格納できます。その後、セル・レスキューの後にそのスクリプトを実行して設定をリストアできます。

rescuePlan属性の詳細は、Oracle Exadata Database Machineメンテナンス・ガイドを参照してください。

A.3.13 IPv6 Oracle VMおよびタグ付きVLANのサポート

Oracle Exadata System Softwareリリース12.2.1.1.0では、Oracle Exadata Deployment Assistant (OEDA)を使用してIPv6 Oracle VMおよびタグ付き仮想LAN (VLAN)がサポートされています。

IPv6 VLANが、管理ネットワーク上でサポートされるようになりました。以前のリリースでは、これはサポートされていませんでした。

Oracle Exadata Database Machineインストレーションおよび構成ガイドを参照してください。

A.3.14 管理サーバーをNTP、DNSおよびILOMの変更中にオンラインのままにできる

NTP、DNSまたはILOMパラメータの変更中は、その操作の間、管理サーバー(MS)をオンラインのままにでき、再起動する必要はありません。

A.3.15 ExaWatcherでの新しいチャート

Oracle Exadata System Softwareリリース12.2.1.1.0では、GetExaWatcherResults.shは、IO、CPU使用率、セル・サーバー統計およびアラート履歴のチャートを含む、HTMLページを生成します。IOおよびCPU使用率のチャートではiostatからのデータが使用されますが、セル・サーバー統計ではcellsrvstatからのデータが使用されます。アラート履歴は、指定された時間枠の間に取得されます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドExaWatcherチャートを参照してください。

A.3.16 REDOログ書込みの新しいメトリック

REDOログ書込みパフォーマンスの分析に役立つ、新しいメトリックを使用可能です。

以前は、Automatic Workload Repository (AWR)でデータベース・サーバーのREDOログ書込み待機時間に関する問題がレポートされたときに、ストレージ・セルでREDOログ書込みパフォーマンスに問題がないと示されることがよくありました。新しいメトリックは、より詳細な全体像を得るために役立ちます。これらのメトリックは、次の懸念事項を理解する上での手掛かりとなります。

  • I/Oレイテンシが高いかどうか、または他の要因(たとえば、ネットワーク)であるかどうか。

  • フラッシュ・ログを迂回したREDOログ書込みの数。

  • フラッシュ・ログで処理されたREDOログ書込みのみでなく、すべてのREDOログ書込みを考慮に入れた、各セルでのREDOログ書込みの全体のレイテンシ。

Oracle Exadata System Softwareリリース12.2.1.1.0では、REDOログ書込みリクエストに関連する次のメトリックが導入されています。

  • FL_IO_TM_W: 累積的なREDOログ書込みレイテンシ。これには、Exadataスマート・フラッシュ・ログによって処理されないリクエストのレイテンシが含まれます。

  • FL_IO_TM_W_RQ: REDOログ書込みレイテンシの平均。書込みのI/Oレイテンシのみが含まれます。

  • FL_RQ_TM_W: 累積的なREDOログ書込みリクエスト・レイテンシ。ネットワーキングおよびその他のオーバーヘッドが含まれます。

    ネットワークおよび処理などの要因によるレイテンシ・オーバーヘッドを取得するには、(FL_RQ_TM_W - FL_IO_TM_W)を使用します。

  • FL_RQ_TM_W_RQ: REDOログ書込みリクエスト・レイテンシの平均。

  • FL_RQ_W: REDOログ書込みリクエストの合計数。これには、Exadataスマート・フラッシュ・ログによって処理されないリクエストが含まれます。

    Exadataスマート・フラッシュ・ログによって処理されないREDOログ書込みリクエスト数を取得するには、(FL_RQ_W - FL_IO_W)を使用します。

A.3.17 セル間のリバランス操作および高スループット書込み操作での隔離マネージャ・サポート

隔離マネージャのサポートは、セル間オフロード操作でのリバランスおよび高スループット書込みのために有効になっています。これらの操作の間にOracle Exadata System Softwareでクラッシュが検出された場合は、問題を起こす操作が隔離され、あまり最適化されていないパスを使用して操作が続行されます。

新しい隔離のための隔離タイプは、ASM_OFFLOAD_REBALANCEおよびHIGH_THROUGHPUT_WRITEです。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドセル間オフロード操作に対する隔離マネージャのサポートを参照してください。

A.3.18 管理サーバーで有効なExaCLIおよびREST API

ExaCLIとREST APIはいずれも、データベース・サーバー上の管理サーバー(MS)で使用できます。

MSコマンドのリモート実行ができるようになりました。WebブラウザのHTTPSを使用してインタフェース(curl)にアクセスできます。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

A.3.19 Oracle Grid Infrastructure 12.2.1.1.0の新機能

Oracle Grid Infrastructure 12.2.1.1.0における次の新機能は、Oracle Exadata Database Machineに影響します。

A.3.19.1 Oracle ASMフレックス・ディスク・グループ

Oracle ASMフレックス・ディスク・グループとは、Oracle ASMファイル・グループをサポートするディスク・グループ・タイプです。

Oracle ASMファイル・グループは、データベースに属するファイルのグループを表し、ファイル・グループまたはデータベースのレベルでストレージ管理の実行を可能にします。一般に、フレックス・ディスク・グループを使用すると、ユーザーはディスク・グループ・レベルに加えて、データベースの粒度でストレージを管理できるようになります。

Oracle Automatic Storage Management管理者ガイドフレックス・ディスク・グループの管理を参照してください。

A.3.19.2 Oracle Flex ASM

Oracle Flex ASMを使用すると、データベース・サーバーとは異なる物理サーバーでOracle ASMインスタンスを実行できます。

標準のOracle ASMクラスタ内のノードのOracle ASMインスタンスに障害が発生すると、そのノード上のすべてのデータベース・インスタンスでも障害が発生します。ただし、Oracle Flex ASM構成では、Oracle 12cデータベース・インスタンスは、別のノードの別のOracle ASMインスタンスにリモートでアクセスできるため、機能が停止することはありません。

Oracle Flex ASMを使用すると、すべての記憶域の要件を、ディスク・グループの単一のセットに統合できます。これらのすべてのディスク・グループを、単一のクラスタで実行中のOracle ASMインスタンスの小さいセットでマウントおよび管理します。カーディナリティ設定で、Oracle ASMインスタンスの数を指定できます。

Oracle Flex ASMは、Oracle Database 12cリリース2 (12.2)とともにデフォルトで有効になっています。Oracle Exadata Database Machineは、カーディナリティがALLに設定されて出荷されます。これは、Oracle ASMインスタンスが、使用可能なすべてのノード上で作成されるということです。詳細は、次の各項を参照してください。

A.3.19.3 ストレージ損失後の冗長性回復の高速化

Oracle Grid Infrastructure 12c リリース2 (12.2)の使用では、以前のリリースよりもストレージ損失の後の冗長性回復に時間がかかりません。

新しいREBUILDフェーズがリバランス操作に導入されました。REBUILDフェーズがストレージ障害後に最初に冗長性を回復するため、2番目の障害が発生するリスク期間が大幅に削減されます。後続のBALANCEフェーズが、バランスを回復します。

Oracle Grid Infrastructureリリース12.1.0.2 (DBBP 12.1.0.2.170718を含む)には、リバランスのOracle ASM REBUILDフェーズも含まれています。

注意:

Oracle Grid Infrastructure 12cリリース2 (12.2)では、再構築がGV$ASM_OPERATIONで別のバス(REBUILD)を介して追跡されます。Oracle Grid Infrastructure 12cリリース1 (12.1)では、再構築とリバランスの両方のフェーズが同じパス(REBALANCE)で追跡されます。
A.3.19.4 動的な電力変更

ASM_POWER_LIMITパラメータの値を動的に調整できます。

ALTER DISKGROUP文でPOWER句を指定しなかった場合や、ディスクの追加または削除によってリバランスが暗黙的に実行される場合は、リバランス指数はデフォルトでASM_POWER_LIMIT初期化パラメータの値になります。このパラメータの値は動的に調整できます。POWER句の値の範囲は、ASM_POWER_LIMIT初期化パラメータと同じです。

指数が大きくなるほど、リバランス操作の完了は早くなります。指数の値が小さいほどリバランスにかかる時間は長くなりますが、データベースなどの他のアプリケーションで共有される処理とI/Oの消費リソースは少なくなります。

Oracle Automatic Storage Management管理者ガイドリバランス操作の調整を参照してください。

A.3.19.5 Oracle Universal Installerでの定数ディスク・サポート

Oracle Grid Infrastructureのインストール中に、定数障害グループを指定できます。

Oracle Exadata Storage Serverでは、デプロイメント中に定数ディスク・グループが自動的に作成されます。定数障害グループは、Oracle Clusterware投票ファイルの格納に使用する特殊なタイプの障害グループです。定数障害グループは、指定した障害グループの定数が使用可能であることを確認するために使用されます。

Oracle Grid Infrastructure 12.2のインストーラは、定数ディスク・マネージャ・ユーティリティを使用してインストール後に定数障害グループを構成するかわりに、インストール中に定数障害グループを指定できるよう、更新されました。

Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイドfor LinuxOracle Automatic Storage Managementの記憶域要件の特定を参照してください。

A.3.20 Oracle Database 12cリリース2 (12.2.0.1)の新機能

Oracle Database 12cリリース2 (12.2.0.1)における次の新機能は、Oracle Exadataに影響します。

A.3.20.1 データベース・サーバーのI/Oレイテンシ制限

ごくたまに、ネットワーク・レイテンシの異常値、ストレージ・サーバーでのハードウェア問題、またはストレージ・サーバーに関するその他のシステム問題が原因で、データベース・サーバーとストレージ・サーバーとの間でI/Oレイテンシが高くなる場合があります。Oracle ASMおよびOracle Exadata Storage Serverソフトウェアは、読取りI/Oのレイテンシが予想より非常に長いときには、読取りI/O操作を他のストレージ・サーバーに自動的にリダイレクトします。データの最新の有効なミラー・コピーに対して実行されたI/Oは、リダイレクトされません。

この機能は、Exadata Storage Softwareのすべてのリリースで使用できます。この機能を使用するために構成を行う必要はありません。

必要な最小ソフトウェア: Oracle DatabaseおよびOracle Grid Infrastructure 12cリリース2 (12.2.0.1.0)

A.3.20.2 圧縮型索引スキャンのためのExadata Smart Scanオフロード

Oracle Exadata Storage Server Software 12.1.2.3.0以前のリリースでは、スマート・スキャン・オフロードで通常の圧縮されていない索引およびビットマップ索引がサポートされていました。

Oracle Exadata Storage Server Software 12.2.1.1.0では、スマート・スキャン・オフロードが圧縮型索引のために実装されました。Oracle Exadataでの圧縮型索引スキャンに関与する問合せには、この機能が役立つ可能性があります。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

A.3.20.3 インメモリー集計(IMA)のためのExadata Smart Scanオフロード機能拡張

Oracle Exadata Storage Serverソフトウェアでは、条件評価のために多数のSQL操作のオフロードがサポートされています。インメモリー集計機能は、ベクトル変換の最適化を実行しようとします。これは、スター型結合SQL問合せを特定の集計操作(たとえば、SUMMINMAXおよびCOUNT)とともに使用し、それをより効率的な処理のために再書込みします。ベクトル変換問合せは、結合にブルーム・フィルタを使用する問合せと似ていますが、より効率的です。ベクトル変換問合せをOracle Exadata Storage Serverリリース12.1.2.1.0とともに使用する場合は、集計に使用される行のフィルタ処理をオフロードできることにより、問合せでの結合のパフォーマンスが向上します。この最適化が始まると、問合せ計画にKEY VECTOR USEと表示されます。

Oracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0では、ベクトル変換された問合せは、Exadata Storage Indexに対するグループ化列(キー・ベクトル)の適用により、さらに処理が効率化されています。

また、ストレージ・サーバー上でインメモリー列指向形式でデータをスキャンする、ベクトル変換された問合せにより、集計作業の処理をオフロードできます。これらの最適化は自動であり、ユーザー設定に依存しません。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

A.3.20.4 XMLのためのExadata Smart Scanオフロード機能拡張

4 KB未満のSecureFiles LOBを使用してXMLデータが格納される場合は、Oracle SQL条件XMLExistsのSQL WHERE句内の評価、またはOracle SQL関数XMLQueryの戻り値に適用されたOracle SQL関数XMLCastを、Oracle Exadata Storage Serverにオフロードできる場合があります。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

A.3.20.5 LOBのためのExadata Smart Scanオフロード機能拡張

Oracle Exadata Storage Server 12.2.1.1.0では、LOB演算子LENGTHSUBSTRINSTRM CONCATLPADRPADLTRIMRTRIMLOWERUPPERNLS_LOWERNLS_UPPERNVLREPLACEREGEXP_INSTRTO_CHARのオフロード・サポートが拡張されました。

Exadataスマート・スキャン・オフロード評価は、圧縮されていないインライン化されたLOB(サイズは4 KB未満)でのみサポートされています。

必要な最小ソフトウェア: Oracle Database 12cリリース2 (12.2.0.1.0)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

A.3.20.6 Oracle Exadataスナップショットの新機能
  • 階層型スナップショット・データベース

    親(それ自体がスナップショット)から領域使用効率のよいスナップショット・データベースを作成できます。これにより、階層型スナップショット・データベースが可能になります。親スナップショットも、ベース・テスト・マスターにわたるまで、領域使用効率が優れています。複数のユーザーが、同じ親スナップショットから固有のスナップショットを作成できます。一連のスナップショットをツリーとして表現できます。この場合、ツリーのルートはベース・テスト・マスターです。ツリー内のすべての内接点は読取り専用データベースであり、ツリー内のすべてのリーフは読取り/書込みデータベースとなります。すべてのOracle Exadata機能が、階層型スナップショット・データベース上でサポートされています。階層型スナップショット・データベースでは、スナップショットの深度が深くなるほどパフォーマンスに不利になるため、スナップショット・ツリーの深度は最大でも10までにすることをお薦めします。

  • スペア・テスト・マスター・データベース

    スパース・テスト・マスターを作成および管理すると同時に、それからアクティブなスナップショットを持つこともできます。この機能では、スパース・テスト・マスターからスナップショットを直接作成している短い期間を除き、スパース・テスト・マスターをほぼ継続的にOracle Data Guardと同期できます。この機能では、読取り専用の非表示の親を作成することで、前述の階層型スナップショット機能が利用されます。Oracle Exadataスナップショット・データベースがテスト・データベースおよび開発データベースのみを対象としていることに注意してください。

  • スパース・バックアップおよびリカバリ

    DB0上でスパース・バックアップを実行する場合、その操作では、データベースの差分ストレージ領域、およびスパース・データ・ファイルの差分領域からのみデータがコピーされます。スパース・バックアップは、バックアップ・セット形式(デフォルト)、またはイメージ・コピー形式のどちらかにできます。RMANは、スパース・バックアップのスパース・データファイルをリストアし、次にそれらをアーカイブ・ログおよびREDOログからリカバリします。スパース・データファイルでは完全リカバリまたはPoint-in-Timeリカバリを実行できます。スパース・バックアップは、記憶領域の効率的な管理と、より高速なバックアップおよびリカバリを促進します。

    スパース・バックアップの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

最小ハードウェア: ストレージ・サーバーがX3以上である必要があります。

最小ソフトウェア: Oracle Database and Grid Infrastructure 12cリリース2 (12.2)およびOracle Exadata Storage Serverソフトウェア・リリース12.2.1.1.0

A.3.21 Unbreakable Enterprise Kernel 4にアップグレードされたOracle Linuxカーネルおよび3.4.2にアップグレードされたOracle VM

このリリースでは、Oracle LinuxがUnbreakable Enterprise Kernel (UEK) 4 (4.1.12-61.28.1.el6uek.x86_64)にアップグレードされます。仮想化を使用するシステムの場合は、DOM0がOracle VM 3.4.2にアップグレードされます。これにより、dom0上でOracle Linux 6を使用できるようになります。dom0およびdomU上で使用されるLinuxカーネルが統合されるようになりました。

以前に計算ノード上で仮想化を使用していたシステムの場合は、Oracle Exadata Storage Serverソフトウェアをリリース12.2.1.1.0にアップグレードする前に、すべてのdomUでOracle Grid Infrastructureホームをリリース12.1.0.2.161018DBBP以上にアップグレードする必要があります。Oracle Exadata Storage Serverソフトウェアをリリース12.2.1.1.0にアップグレードするには、dom0をアップグレードする前に、最初にすべてのdomU上のそれらをアップグレードする必要があります。この要件は、patchmgrソフトウェアによって強制されます。

Oracle ASM Cluster File System (Oracle ACFS)を使用する場合は、Oracle Grid InfrastructureホームをアップグレードしてOracle ACFSサポートをUEK4カーネルで有効にする前に、バグ22810422に対する修正を適用する必要があります。また、OLTPワークロードのパフォーマンスを向上させるために、バグ23642667に対する修正をOracle Grid Infrastructureホーム上とOracle Databaseホーム上の両方にインストールすることをお薦めします。

A.4 Oracle Exadata Database Machine 12cリリース1 (12.1.2.3.0)の新機能

Oracle Exadata Database Machine 12cリリース1 (12.1.2.3.0)の新機能は次のとおりです。

A.4.1 Oracle Exadata System Softwareの更新のパフォーマンス向上

Oracle Exadata System Softwareの更新に要する時間が大幅に短縮されました。内部処理をさらに最適化することで、セル更新プロセスが以前のリリースに比べて最大2.5倍高速化されました。

A.4.2 定数ディスク・マネージャ・ユーティリティ

以前のリリースでは、ストレージ・サーバーが5台未満のOracle Exadataシステムが高冗長性(HIGH)でデプロイされる場合、クラスタの投票ディスクは標準冗長性(NORMAL)を持つディスク・グループで作成されていました。こうしたシステムで2つのセルが停止した場合、高冗長性(HIGH)によってデータは引き続き保持されますが、投票ディスクは標準冗長性(NORMAL)を持つディスク・グループにあるため、クラスタ・ソフトウェアは停止します。

定数ディスクにより、ユーザーはデータベース・サーバー上にディスクをデプロイして利用し、クォータ・ラックまたは小規模構成で最高の冗長性を実現することができます。定数ディスクはデータベース・サーバー上に作成され、定数障害グループに追加されます。

高冗長性(HIGH)で構成する新規システムのストレージ・サーバーが5台未満の場合、Oracle Exadata Deployment Assistantを使用してこのような定数ディスクを自動的に作成できます。

こうしたシステムをデプロイする際、新しいquorumdiskmgrユーティリティを手動で使用できます。quorumdiskmgrによって、データベース・サーバー上の定数ディスクを管理できます。このユーティリティを使用して、定数ディスク構成、ターゲットおよびデバイスを作成、リスト、削除および変更できます。

詳細は、Oracle Exadata Database Machineメンテナンス・ガイドの高冗長性ディスク・グループのための定数ディスクの管理に関する項を参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Grid Infrastructureリリース12.1.0.2.160119(パッチ22722476および22682752を適用)またはGrid Infrastructureリリース12.1.0.2.160419以降

  • すべてのデータベース・ホームにパッチ23200778を適用

A.4.3 VLANサポート

OEDAでは現在、管理ネットワーク、ILOM、クライアントおよびバックアップ・アクセス・ネットワークのために、計算ノードおよびストレージ・サーバーでのVLANの作成をサポートしています。次の点に注意してください。

  • クライアント・ネットワークとバックアップVLANネットワーク・ネットワークが結合されている必要があります。管理ネットワークは結合しないでください。

  • バックアップ・ネットワークが、タグ付けされたVLANネットワーク上にある場合、クラスタ・ネットワークは、タグ付けされた異なるVLANネットワークにある必要があります。

  • バックアップおよびクライアント・ネットワークは、同一のネットワーク・ケーブルを共有できます。

  • OEDAは物理デプロイメントと仮想デプロイメントの両方でVLANタグ付けをサポートしています。

  • IPv6 VLANは、X2およびV2システムを除くすべてのOracle Exadataシステムのベア・メタルでサポートされています。

    現在、VMを使用したIPv6 VLANはサポートされていません。

注意:

システムがクラスタで10個のVIPアドレスを超えて使用し、Oracle Clusterwareクライアント・ネットワークにVLANを構成している場合、3桁のVLAN IDを使用する必要があります。VLAN名が15文字のオペレーティング・システム・インタフェースの名前制限を超える可能性があるため、4桁のVLAN IDを使用しないでください。

次の表に、管理ネットワーク、クライアント・ネットワークおよびバックアップ・ネットワークでの様々なExadataシステムおよびOracle Databaseバージョン向けのIPv4およびIPv6サポートを示します。

Oracle Databaseのリリース 管理ネットワークでのVLANタグ付け クライアントおよびバックアップ・ネットワーク

11.2.0.4

2ソケット・サーバー用のX3-2以上、および8ソケット・サーバー用のX4-8以上でのIPv4アドレスでのみサポートされています。

すべてのハードウェア・モデルでのIPv4およびIPv6でサポートされています。

12.1.0.2

2ソケット・サーバー用のX3-2以上、および8ソケット・サーバー用のX4-8以上でのIPv4アドレスでのみサポートされています。

すべてのハードウェア・モデルでのIPv4でサポートされています。

22289350が修正済であるすべてのハードウェア・モデルでのIPv6でサポートされています。

詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』Oracle Exadata Database MachineでのネットワークVLANタグ付けの使用に関する項を参照してください。

A.4.4 適応性のある修正スケジュール

Oracle Exadata System Softwareは、ハード・ディスクがアイドル状態のときに定期的にハード・ディスクを自動で検査して修復します。修正のデフォルト・スケジュールは2週間置きです。

ただし、ハード・ディスクで不良セクターが発生し始めるようになったら、より多くの不良セクターが発生する可能性があるため、ディスクをもっと頻繁に修正することが推奨されます。リリース12.1.2.3.0では、現在の修正ジョブでハード・ディスクに不良セクターが検出された場合、Oracle Exadata System Softwareはそのディスクに対して1週間以内にフォローアップ修正ジョブをスケジュールします。そのディスクの修正ジョブで不良セクターが検出されなかった場合、hardDiskScrubInterval属性で指定された修正スケジュールに戻ります。

hardDiskScrubIntervalを週次以下に変更した場合、不良セクターが検出された場合でも、Oracle Exadata System Softwareは週次フォローアップ・スケジュールではなくユーザーが構成した間隔を使用します。修正の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドALTER CELLを参照してください。

必要な最小ソフトウェア:

  • Oracle Exadata System Softwareリリース12.1.2.3.0

  • グリッド・インフラストラクチャ・ホーム:

    • 11.2.0.4.16 (2015年4月)以上

    • 12.1.0.2.4 (2015年1月)以上

A.4.5 ASRマネージャでのIPv6サポート

IPv6を使用するシステムで、ASR Manager 5.4を使用してAuto Service Request (ASR)に接続できるようになりました。

A.4.6 最大データベース・プロセス数の増加

表A-1に、データベース・ノード当たりサポートされる最大データベース・プロセス数を示します。これらの数は以前のリリースよりも高くなっています。ベスト・プラクティスは、プロセス数をこれらの値よりも低く抑えることです。ワークロードのサブセットがパラレル問合せを実行中の場合、最大データベース・プロセス数はパラレル問合せを含まない最大ロセス数列と実行中のすべてのパラレル問合せを含む最大プロセス数列の間になります。

表A-1 ノード当たりの最大データベース・プロセス数

マシン・タイプ InfiniBandボンディング・タイプ パラレル問合せを含まないプロセスの最大数 実行中のすべてのパラレル問合せを含むプロセスの最大数

8ソケット(X2-8、X3-8)

アクティブ・パッシブ

28,500

25,000

8ソケット(X4-8、X5-8)

アクティブ・ボンディング

100,000

44,000

2ソケット(X2-2、X3-2)

アクティブ・パッシブ

12,500

10,000

2ソケット(X4-2、X5-2、X6-2)

アクティブ・ボンディング

25,000

14,000

表A-2に、Oracle VMユーザー・ドメイン当たりのサポートされる最大データベース・プロセス数を示します。これらの数は以前のリリースよりも高くなっています。ベスト・プラクティスは、プロセス数をこれらの値よりも低く抑えることです。ワークロードのサブセットがパラレル問合せを実行中の場合、最大データベース・プロセス数はパラレル問合せを含まない最大プロセス数列と実行中のすべてのパラレル問合せを含む最大プロセス数列の間になります。

表A-2 Oracle VMユーザー・ドメイン当たりの最大データベース・プロセス数

マシン・タイプ InfiniBandボンディング・タイプ パラレル問合せを含まないプロセスの最大数 実行中のすべてのパラレル問合せを含むプロセスの最大数

2ソケット(X2-2、X3-2)

アクティブ・パッシブ

11,500

8,000

2ソケット(X4-2、X5-2、X6-2)

アクティブ・ボンディング

23,000

14,000

マシンは次のように構成されます。

  • アクティブ・ボンディングInfiniBand構成の8ソケット・データベース・ノード(X4-8およびX5-8)では、4つのInfiniBandカード(8つのInfinibandポート)全体で8つのIPアドレスがあります。

  • アクティブ-パッシブInfiniBand構成の8ソケット・データベース・ノード(X2-8およびX3-8)では、4つのInfiniBandカード(8つのInfinibandポート)全体で4つのIPアドレスがあります。

  • アクティブ・ボンディングInfiniBand構成の2ソケット・データベース・ノード(X4-2、X5-2およびX6-2)では、1つのInfiniBandカード(2つのInfinibandポート)上に2つのIPアドレスがあります。

  • アクティブ-パッシブInfiniBand構成の2ソケット・データベース・ノード(X2-2およびX3-2)では、1つのInfiniBandカード(2つのInfinibandポート)上に1つのIPアドレスがあります。

データベースの使用に対して、InfiniBand IPアドレス当たり50,000 RDSソケットが割り当てられます。IO対応の各データベース・プロセスは、複数のIPにまたがり均等なロード・バランスでRDSソケットを消費します。

Exadata 12.1.2.3.0以降、セル側の接続制限はありません。

ExadataイメージとOracleカーネルによってサポートされる最大プロセス数のほかに、次の関連製品も拡張されました。

  • Oracle Exadata Deployment Assistantによって、デプロイ時にGrid_home/crs/install/s_crsconfig_nodenameenv.txtで自動的に上限が構成されます。

  • Exadata Patch Manager (patchmgrdbnodeupdate.sh)によって、データベース・ノードのアップグレード時にGrid_home/crs/install/s_crsconfig_nodenameenv.txtで自動的に上限が構成されます。

最大プロセス数で最適なリソース使用率を実現するために、次のベスト・プラクティスに従う必要があります。

  • ローカルのBequeath接続を使用するのではなく、Exadataデータベースで実行されている一連のOracleリスナーを介して、アプリケーションが開始したOracleフォアグラウンドを確立する必要があります。

  • リスナー数はデータベース・ノードCPUソケット数と同じかそれ以上である必要があり、どのデータベース・ノードCPUソケットも同じ数のリスナーを実行する必要があります。たとえば、Oracle Exadata X5-8データベース・ノードでは8つのリスナーを構成できます(データベース・ノードCPUソケット当たり1つ)。

  • リスナーは、データベース・ノードCPUソケット間で均等にOracleプロセスを生成する必要があります。これは、起動時にこれらが実行されるソケットを指定することで実現できます。たとえば、リスナー0から7にlistener.oraファイルが適切に構成されていて、次のスクリプトを使用してX5-8データベース・ノードで8つのリスナーをそれぞれ別個のソケット上に生成するとします。

    #!/bin/bash
    export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1
    for socket in `seq 0 7`
    do
     numactl --cpunodebind=${socket} $ORACLE_HOME/bin/lsnrctl start LISTENER${socket}
    done
  • リスナー接続レート・スロットルを使用してログイン・ストームを制御し、最大プロセス数でシステムの安定性を実現します。

  • 過度のクライアント接続タイムアウトおよびサーバー側のエラーを防止するために、1秒当たりに確立される接続数合計、すなわちすべてのリスナーのrate_limitの合計は400以下にする必要があります。

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Oracle Database 12cリリース1 (12.1)リリース12.1.0.2.160119と次のパッチ: 22711561、22233968および22609314

A.4.7 セルからセルへのリバランスにおけるストレージ索引の保持

ストレージ索引を使用してスマート・スキャン時にI/Oをプルーニングすることで、パフォーマンスが著しく向上します。ディスクで予測障害または本当の障害が発生した場合、データを他のセルのディスクに移動してリバランスする必要があります。この機能により、失敗したディスクのデータ領域に作成されたストレージ索引エントリを、セルからセルへのオフロードによるリバランス時にデータとともに移動させて、アプリケーションのパフォーマンスを維持できます。

この機能により、前のリリースと比較して、ディスク障害によるリバランス時のアプリケーションのパフォーマンスが著しく向上します。

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Grid Infrastructureリリース12.1.0.2.160119(パッチ22682752適用)

A.4.8 グリッド・ディスク・サイズを減少させる際のASMディスク・サイズのチェック

12.1.2.3.0より前のリリースでは、ディスク・グループの一部であるASMディスクのサイズを減少させる前に、ユーザーが誤ってグリッド・ディスクのサイズを減少させる可能性がありました。リリース12.1.2.3.0では、グリッド・ディスクのサイズをASMディスクより小さくできないように、サイズ変更の順序がチェックされます。

ASMディスク・サイズ問合せをサポートするために、新しい属性asmDiskSizeがグリッド・ディスクに追加されます。ALTER GRIDDISKを実行してグリッド・ディスクのサイズを変更する際、ユーザーがグリッド・ディスクをASMディスクより小さくしないように、コマンドによってASMディスク・サイズがチェックされるようになりました。

このチェックは、通常のデータ・ディスクとスパース・ディスクの両方に対して機能します。スパース・グリッド・ディスクの場合、仮想サイズの変更時にチェックが実行されます。通常のグリッド・ディスクの場合は、サイズの変更時にチェックが実行されます。

たとえば、次のコマンドを考えてみます。

CellCLI> list griddisk DATAC1_CD_00_adczarcel04 attributes name,asmdisksize

次のような出力が返されます。

DATAC1_CD_00_adczarcel04     14880M

グリッド・ディスクのサイズをASMディスクより小さくしようとした場合:

CellCLI> alter griddisk DATAC1_CD_00_adczarcel04 size=10G

コマンドによってエラーが返されます。

CELL-02894: Requested grid disk size is smaller than ASM disk size. Please resize ASM disk DATAC1_CD_00_ADCZARCEL04 first.

必要な最小ソフトウェア:

  • Oracle Exadata Storage Server Softwareリリース12.1.2.3.0

  • Grid Infrastructureリリース12.1.0.2.160119(パッチ22347483適用)

A.4.9 CREATE DIAGPACKでのアラートのサポート

CREATE DIAGPACKコマンドで、alertNameパラメータを使用して指定したアラートの診断パッケージの作成がサポートされるようになりました。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドCREATE DIAGPACKを参照してください。

A.5 Oracle Exadata Database Machine 12cリリース1 (12.1.2.2.0)の新機能

Oracle Exadata Database Machine 12cリリース1 (12.1.2.2.0)の新機能は次のとおりです。

A.5.1 スマートFusionブロック転送

最小ソフトウェア要件: 12.1.0.2 BP13

多くのOLTPワークロードでは、Oracle Real Application Clusters (Oracle RAC)の複数のノードで頻繁に更新する必要があるホット・ブロックが発生することがあります。その一例がRight Growing Index (RGI)で、新しい行が複数のOracle RACノードからの索引付きで表に追加されます。索引のリーフ・ブロックが、すべてのノードで頻繁に更新する必要があるホット・ブロックになります。

ExadataのスマートFusionブロック転送機能がない場合、送信側ノードがREDOログで恒久的なREDOログ・バッファに変更を加えた後にのみ、ホット・ブロックを送信側ノードから受信側ノードに転送できます。スマートFusionブロック転送により、送信側ノードでの、このREDOログ書込みの待ち時間は解消されます。ブロックは、REDOログへのIOが送信側ノードで発行されると、その完了を待たずにただちに転送されます。スマートFusionブロック転送により、RGIワークロードのスループットが増加し(約40%増)、レスポンス時間が短縮されます(約33%減)。

スマートFusionブロック転送を有効にするには:

  • すべてのOracle RACノードで、非表示の静的パラメータ"_cache_fusion_pipelined_updates"をTRUEに設定します。これは静的パラメータであるため、この変更を反映させるにはデータベースを再起動する必要があります。

  • すべてのOracle RACインスタンスで、"exafusion_enabled"パラメータを1に設定します。

A.5.2 8TBのハード・ディスクのサポート

このソフトウェア・リリースで、Exadata Storage Serverは、8TBの大容量ディスクをサポートします。8TBの大容量ディスクのサポートには、次の利点があります。

  • 以前のExadataマシンのディスク容量を2倍にします(ラックごとに最大1344TB)

  • 既存のデータベースおよびデータ・ウェアハウスをスケール・アウトする追加の記憶域を提供します。

8TBの大容量ディスクを使用する要件

  • Exadata 12.1.2.1.2以上

  • グリッド・インフラストラクチャ・ホームには、次のいずれかが必要です。

    • 12.1.0.2.11以上のBP

    • 12.1.0.2.10以下のBPと次のパッチ: 21281532、21099555および20904530

    • 11.2.0.4.18以上のBP

    • 11.2.0.4.17以下のBPとパッチ21099555

    • 11.2.0.3とパッチ21099555

A.5.3 IPv6サポート

IPv6サポートはイーサネット向けです。

計算ノードとストレージ・サーバーでは、管理ネットワーク、ILOMおよびクライアント・アクセス・ネットワークでPv6を使用できるようになりました。これは、ベア・メタルおよび仮想化の両方のデプロイメントで有効です。次の表に、各種コンポーネントによるIPv6サポートの方法を示します。

コンポーネント IPv6サポートの説明

Oracle Exadata Deployment Assistant (OEDA)

OEDAでは、ユーザーが顧客ネットワークの定義画面(図A-1のスクリーンショットを参照)でIPv6アドレスを入力できます。IPv6アドレスが管理ネットワークで使用されている場合、DNSサーバー、NTPサーバー、SMTPサーバーおよびSNMPサーバーがIPv6ネットワーク上に配置されている必要があります。

顧客ネットワークの定義画面でIPv6アドレスを使用してゲートウェイを指定し、/64接尾辞を指定してマスクを表すと、「サブネット・マスク」フィールドがグレー表示されて使用できなくなります。

Ciscoスイッチ

Cisco 4948E-Fスイッチの最小ファームウェア・バージョン15.2(3)E2を使用すれば、CiscoスイッチでIPv6アドレスを有効にできます。

アップグレード手順と、SRを開いて最新のCiscoファームウェアをOracleサポートから入手する方法は、My Oracle Supportノート1415044.1を参照してください。

自動サービス・リクエスト(ASR)

ASRはIPv6アドレスでは機能しません。これは今後のリリースで対応します。ASRを有効にするには、IPv4ネットワークにブリッジします。

Enterprise Manager

Enterprise ManagerでInfiniBandスイッチ(IPv4ネットワーク上)と計算ノードやストレージ・ノード(IPv6ネットワーク上)の両方を監視できるようにするには、Enterprise Managerをブリッジ・ネットワーク上に配置する必要があります。

dbnodeupdate

dbnodeupdateには、IPv6アドレスが設定されたマシン上でホストされているリモート・リポジトリが必要です。あるいはISOファイルが使用されている必要があります。

リモート・リポジトリでIPv4を使用し、ホストにIPv6 IPのみが設定されている場合、(httpなどのプロトコルを使用して)リモート・リポジトリにアクセスすることはできません。ただし、ネットワーク・ルーターやデバイスで許可されていれば、顧客のIPv6ホストからIPv4 IPにアクセスできる場合があります。ほとんどの顧客がIPv6リポジトリ・サーバーを必要とするか、ISOファイルを使用することになります。

InfiniBandネットワーク

引き続きIPv4のみを使用するには、プライベートInfiniBandネットワークが必要です。InfiniBandネットワークではプライベート・アドレスのみが使用されるので、InfiniBandをIPv6に移行するメリットはほとんどありません。

SMTPとSNMP

顧客ネットワークにIPv4とIPv6間のルーティングを行うブリッジまたはゲートウェイがない場合、SMTPサーバーとSNMPサーバーは通常、IPv6 (またはIPv6 IPアドレスに解決される名前)になります。

Platinum Support

今後のPlatinum Gatewayソフトウェア・リリースが提供されるまで、Platinum SupportはIPv6デプロイメントでは使用できません。

図A-1 Oracle Exadata Deployment Assistantの顧客ネットワークの定義画面

図A-1の説明が続きます
「図A-1 Oracle Exadata Deployment Assistantの顧客ネットワークの定義画面」の説明

A.5.4 計算ノードからのCellCLIコマンドの実行

新しいExaCLIユーティリティでは、データベース・サーバーからCellCLIコマンドをストレージ・サーバーに対してリモート実行できます。これは、SSHアクセスを無効にしてストレージ・サーバーをロックした場合に役立ちます(ストレージ・サーバーでのSSHの無効化を参照)。

ExaCLIには、ストレージ・サーバーの管理に対応した使いやすいインタフェースも用意され、ストレージ・ユーザーの各種ロールをストレージ管理者から分離できます。

ExaCLIを実行するには、ストレージ・サーバー上でユーザーを作成し、そのユーザーにロールを付与する必要があります。ロールを付与するとユーザーに権限が割り当てられ、ユーザーの実行可能なCellCLIコマンドが指定されます。ストレージ・サーバーへの接続時に、ExaCLIは指定されたユーザー名を認証し、そのユーザーに指定されたコマンドを実行するための適切な権限があるかどうかを確認します。

新しいexadcliユーティリティはdcliユーティリティに似ています。exadcliを使用すると、複数のストレージ・サーバーにまたがってCellCLIコマンドを実行できます。

詳細は、次を参照してください。

ロールに権限を付与し、ユーザーにロールを付与することで、ユーザーが実行できるコマンドを制御できます。たとえば、ユーザーにLIST GRIDDISKコマンドを実行可能にしALTER GRIDDISKを実行不可にするよう指定できます。このレベルの制御は、システムへの完全なアクセスをごく少数のユーザーにのみ許可するOracle Cloud環境で役立ちます。

新しいExaCLIユーティリティを使用する場合は、ユーザーの作成も必要です。CREATE USERGRANT PRIVILEGEおよびGRANT ROLEコマンドを使用して、ユーザーの作成、ロールへの権限の指定、およびユーザーへのロールの付与を行います。詳細は、Oracle Exadata System Softwareユーザーズ・ガイドユーザーおよびロールの作成を参照してください。

A.5.5 ストレージ・サーバーでのSSHの無効化

デフォルトでは、ストレージ・サーバーでSSHが有効化されています。必要な場合は、ストレージ・サーバーをロックしてSSHアクセスを無効化できます。ExaCLIを使用すれば、引き続きセル上で各種操作を実行できます。ExaCLIは計算ノード上で実行され、httpsやREST APIを使用して、セル上で実行されているWebサービスと通信します。

セルへのログインを必要とする操作を実行するときは、一時的にセルのロックを解除できます。操作が完了したら、再びセルをロックできます。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドストレージ・サーバーでのSSHの無効化を参照してください。

A.5.6 フラッシュ・キャッシュ内でのデータベースへの割当ての固定

ALTER IORMPLANコマンドにはflashcachesizeと呼ばれる新しい属性が用意され、これによりフラッシュ・キャッシュ内の固定領域をデータベースに割り当てることができます。flashcachesizeに指定された値は強い制限であり、この指定値を超える領域をデータベースで使用することはできません。これは、弱い上限のflashcachelimit値とは異なります(フラッシュ・キャッシュがいっぱいでなければ、データベースはこのflashcachelimit値を超過できます)。

flashcachesizeは、クラウドや従量課金制などのデプロイメントでデータベースをそれぞれの割当て済領域に制限する必要がある環境において理想的です。

詳細は、次の項を参照してください。

A.5.7 AWRレポートのOracle Exadataストレージ統計情報

AWRレポートのExadataフラッシュ・キャッシュ・パフォーマンス統計情報セクションが、次のように強化されました。

  • 列フラッシュ・キャッシュとKEEPキャッシュのサポートの追加。

  • Exadataストレージ・セルの統計情報とデータベースの統計情報が要約されたフラッシュ・キャッシュ・パフォーマンス・サマリーに関するセクションの追加。

AWRレポートのExadataフラッシュ・ログ統計情報セクションに、ディスクおよびフラッシュへの最初の書込みの統計情報が含まれるようになりました。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2バンドル・パッチ11

A.5.8 最大データベース・プロセス数の増加

最小ソフトウェア要件: 12.1.0.2 BP11または11.2.0.4 BP18

次の表に、データベース・ノード当たりサポートされる最大データベース・プロセス数を示します。これらの数は以前のリリースよりも高くなっています。ベスト・プラクティスは、プロセス数をこれらの値よりも低く抑えることです。ワークロードのサブセットがパラレル問合せを実行中の場合、最大データベース・プロセス数はパラレル問合せを含まないプロセス数列と実行中のすべてのパラレル問合せを含むプロセス数列の間になります。

表A-3 ノード当たりの最大データベース・プロセス数

マシン・タイプ InfiniBandボンディング・タイプ パラレル問合せを含まないプロセスの最大数 実行中のすべてのパラレル問合せを含むプロセスの最大数

8ソケット(X2-8、X3-8)

アクティブ・パッシブ

28,500

25,000

8ソケット(X4-8、X5-8)

アクティブ・ボンディング

50,000

44,000

2ソケット(X2-2、X3-2)

アクティブ・パッシブ

12,500

10,000

2ソケット(X4-2、X5-2)

アクティブ・ボンディング

16,500

14,000

マシンは次のように構成されます。

  • アクティブ・ボンディングInfiniBand構成の8ソケット・データベース・ノード(X4-8およびX5-8)では、4枚のInfiniBandカード(8個のInfinibandポート)全体で8個のIPアドレスがあります。

  • アクティブ-パッシブInfiniBand構成の8ソケット・データベース・ノード(X2-8およびX3-8)では、4枚のInfiniBandカード(8個のInfinibandポート)全体で4個のIPアドレスがあります。

  • アクティブ・ボンディングInfiniBand構成の2ソケット・データベース・ノード(X4-2およびX5-2)では、1枚のInfiniBandカード(2個のInfinibandポート)上に2個のIPアドレスがあります。

  • アクティブ-パッシブInfiniBand構成の2ソケット・データベース・ノード(X2-2およびX3-2)では、1枚のInfiniBandカード(2個のInfinibandポート)上に1個のIPアドレスがあります。

データベースの使用に対して、IP当たり50,000 RDSソケットがプロビジョニングされます。IO対応の各データベース・プロセスは、複数のIPにまたがり均等なロード・バランスでRDSソケットを消費します。

セルには次の接続制限があります。

  • X4およびX5システムの場合、セルの接続制限は120,000プロセスです。

  • X2およびX3システムの場合、セルの接続制限は60,000プロセスです。

つまり、データベース・プロセスの合計数が前述のセル・ノードに対する制限を超えることはできません。たとえば、フル・ラックの8個のデータベースが最大プロセス数で実行されると、セルの接続制限を超過します。

A.5.9 ストレージ・サーバー・アラートのカスタム診断パッケージ

Oracle Exadata Storage Serverは、セル・アラートが生成されると、カスタマイズされた診断パッケージ(関連するログおよびトレースを含む)を自動的に収集します。これは、ハードウェア・アラートとソフトウェア・アラートの両方を含むすべてのセル・アラートに適用されます。診断情報を適切なタイミングで収集することにより、重要なログのロールオーバーが抑制されます。

管理サーバー(MS)は、電子メール・アラートごとに電子メール添付ファイルとして診断パッケージを送信します。次のURLにアクセスして、既存の診断パッケージをダウンロードすることも可能です(電子メールの添付ファイルがなかった場合)。次のURLで、hostnameはセルのホスト名のことです。

https://hostname/diagpack

ExaCLIを使用してパッケージをダウンロードすることもできます。

ユーザーは、新しいCREATE DIAGPACK CellCLIコマンドを使用して開始時間と期間を指定することにより、カスタム診断パッケージを毎時作成できます。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドCREATE DIAGPACKを参照してください。

A.5.10 patchmgrを使用したノードの更新

Exadataリリース12.1.2.2.0以降では、patchmgrを使用してOracle Exadataデータベース・ノード(リリース11.2.2.4.2以降)、Oracle Exadata仮想サーバー・ノード(dom0)およびOracle Exadata仮想マシン(domU)を更新、ロールバックおよびバックアップできます。スタンドアロン・モードでdbnodeupdate.shを実行することもできますが、patchmgrを使用すると、単一コマンドの実行で複数のノードを更新でき、各ノードで個別にdbnodeupdate.shを実行する必要はありません。patchmgrでは、ローリングまたは非ローリング方式でノードを更新できます。

更新されたpatchmgrとdbnodeupdate.shは、My Oracle Supportノート1553103.1からダウンロードできる、新しいdbserver.patch.zipファイルで利用できます。

詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』patchmgrによるデータベース・ノードの更新に関する項を参照してください。

A.5.11 8ソケット・データベース・ノードで機能するkdump

12.1.2.2.0より前のリリースでは、kdump (カーネル・クラッシュ・ダンプを作成して格納するサービス)は、vmcoreの生成に時間がかかりすぎ、領域の消費量も多すぎることから、Exadata 8ソケット・データベース・ノードで無効化されていました。Exadataリリース12.1.2.2.0以上では、次の最適化によって、kdumpは8ソケット・データベース・ノードで完全に機能します。

  • 共有メモリーのHugepagesや他の複数の領域がLinuxカーネルによってユーザー・スペースに公開され、カーネル・クラッシュ時にはmakedumpfileによって除外されるようになりました。これにより、vmcoreの時間と領域の両方が節約されます。

  • kexecカーネルのメモリー構成が最適化されました。

  • 不要なモジュールのブラックリスト化により、全体的な使用済メモリーが削減されました。

  • Snappy圧縮がデータベース・ノード上で有効化され、vmcoreの生成が高速化されています。

A.5.12 ストレージ・サーバーの電源切断時の冗長性チェック

前面の電源ボタンを押すか、ILOMを実行してストレージ・サーバーの正常な停止を試みると、ストレージ・サーバーはASMデータの冗長性チェックを実施します。ストレージ・サーバーを停止すると、データの冗長性が低下して、ASMディスク・グループの強制ディスマウントが生じる可能性がある場合は、停止が中止され、ストレージ・サーバーの停止は安全でないことをユーザーに警告するために、次のようにLEDが点滅します。

  • 大容量セルでは、すべてのハード・ドライブ上のすべての3つのLEDが10秒間点滅します。

  • エクストリーム・フラッシュ・セルでは、取外しOKの青色のLEDが10秒間点滅し、オレンジ色のLEDが点灯します。

ストレージ・サーバーではハード・リセットを実行しないでください。

冗長性の低下により、ストレージ・サーバーを安全に停止できない場合(コマンド"cellcli -e list griddisk attributes name, deactivationOutcome"を実行すると、オフライン・ディスクと異常なディスクがすべて表示されます)、先にデータ冗長性をリストアする必要があります。オフライン・ディスクが他にある場合は、そのディスクをオンラインに戻して再同期が終了するのを待機します。障害ディスクを強制削除するために実行中のリバランス、またはフラッシュ・キャッシュのエラーを書き戻した後でデータ・ブロックを復元するために実行中のミラー復元がある場合、リバランスまたはミラー復元が完了するまで待機する必要があります。データ冗長性がリストアされたら、ストレージ・サーバーの停止を続行できます。

A.5.13 SNMPトラップ用IPアドレスの指定

eth0に関連付けられているIPアドレスがOracle ASR Managerに登録されていない場合、ALTER CELLコマンド(ストレージ・サーバーの場合)またはALTER DBSERVERコマンド(データベース・サーバーの場合)の新しいfromIPフィールドを使用して、別のIPアドレスを指定できます。

詳細は、次の説明を参照してください。

  • Oracle Exadata System Softwareユーザーズ・ガイドALTER CELL
  • Oracle Exadata Database Machineメンテナンス・ガイドALTER DBSERVER

A.5.14 逆オフロードの改良

最小ソフトウェア要件: 12.1.0.2 BP11

逆オフロード機能を使用すると、ストレージ・セルのCPUが飽和状態の場合、ストレージ・セルにオフロードされた作業の一部をデータベース・ノードに戻すことができます。

ストレージ・サーバーからデータベース・ノードへの逆オフロードは、Exadata環境で利用可能なすべてのデータベースCPUリソースとストレージCPUリソースの使用率をより均一にするためには欠かせません。ほとんどの構成で、ストレージCPUよりもデータベースCPUの方が多くなっており、その比率はハードウェアの世代およびデータベース・ノードとセル・ノードの数によって異なる場合があります。

同時実行中の異なる問合せを経過時間に関して適切に実行するには、それぞれに異なる逆オフロード率が必要です。別々のインスタンスで同じ問合せを実行中の場合でも、それぞれに異なる逆オフロード率が必要な場合があります。

このリリースでは、ヒューリスティックの改良が多数追加されており、複数のデータベース・インスタンスと異なる問合せのパラレル実行にかかる経過時間が最大で15%向上しています。

A.5.15 セルからセルへのリバランスにおけるフラッシュ・キャッシュ移入の保持

最小ソフトウェア要件: 12.1.0.2 BP11

ハードディスクで予測される障害またはtrue障害が発生し、データをリバランスして障害から回復する必要がある場合に、このハードディスク上のデータの一部が、データへのレイテンシ・アクセスと帯域幅アクセスを向上させるために、フラッシュ・ディスクにキャッシュされていていることがあります。アプリケーションの現在のパフォーマンスSLAを維持するには、セルからセルへのオフロードによるリバランス時に、ハードディスク上の異なるリージョンのキャッシュ・ステータスを保持したまま、データをリバランスすることが重要です。

この機能により、ディスク障害またはディスク交換に伴うリバランス時のアプリケーションのパフォーマンスが以前のリリースと比較して大幅に向上します。

データが1つのセルから別のセルにリバランスされると、ソース・セルでキャッシュされていたデータはターゲット・セルでもキャッシュされます。

A.6 Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.2)の新機能

Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.2)の新機能は次のとおりです。

A.6.1 Exadata仮想環境用のInfiniBandパーティション化

InfiniBandパーティション化はExadata仮想環境で使用できるようになり、Oracle Exadata Deployment Assistant (OEDA)と組み合せて構成できます。

OEDAのグラフィカル・ユーザー・インタフェースを使用してInfiniBandパーティションをクラスタごとに定義し、OEDAのコマンドライン・インタフェースを使用し、適切なパーティション・キーとメンバーシップ要件を設定して、ゲストとInifniBandスイッチを構成し、InfiniBandパーティションを有効にします。

InfiniBandパーティションはクラスタごとに定義できます。ストレージ・サーバーが複数のクラスタ間で共有されている場合、すべてのクラスタで同じストレージ・パーティション・キーを使用します。

A.7 Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.1)の新機能

Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.1)の新機能は次のとおりです。

A.7.1 X5 Storage Serverでのフラッシュ・パフォーマンスの向上

NVMeフラッシュ・ファームウェアに変更が加えられ、バックグラウンドのリフレッシュ・アルゴリズムおよび操作に対してリソースや変更を処理するI/Oタスクが改善されています。このリリースでは、フラッシュのパフォーマンスが同じかわずかに向上しています。

A.7.2 Oracle Exadata仮想マシン

統合環境では、X5-2、X4-2、X3-2およびX2-2データベース・サーバー上で、ワークロード間をより高いレベルで分離するOracle Virtual Machine (Oracle VM)が使用されるようになりました。仮想マシンの分離は、信頼できないワークロードが共有環境でセキュリティ、CPUまたはメモリー使用状況を制限する場合に好都合です。

A.7.3 Infrastructure as a Service (IaaS)およびキャパシティ・オンデマンド(CoD)

Oracle Exadata Infrastructure as a Service (IaaS)のユーザーがキャパシティ・オンデマンド機能を使用して、データベース・サーバーのアクティブ・コア数を制限し、必要なデータベース・ソフトウェア・ライセンスの数を制限できるようになりました。Exadata 12.1.2.1.1 Softwareでは、CoDとIaaSを同じシステムに配置することができます。コアの予約済セットのオンとオフを切り替える機能(IaaS-CoD)はIaaSに含まれることに注意してください。

A.7.4 フラッシュ・キャッシュのメトリックの向上

このリリースには、統合ブロック・キャッシュと列キャッシュのメトリックが含まれ、フラッシュ・キャッシュ・パフォーマンスをさらに詳しく分析できるようになりました。

A.7.5 うるう秒の時刻調整

このリリースでは、2015年6月30日のうるう秒の調整に備えて、うるう秒がサポートされています。

A.7.6 ネットワーク・リソース管理

  • X5-2 Extreme Flash (EF) Storage Serverで、Oracle 1.6TB NVMe SSDファームウェアが8DV1RA12に更新されています

  • X5-2 High Capacity (HC) Storage Serverで、Oracle Flash Accelerator F160 PCIeカードのファームウェアが8DV1RA12に更新されています

A.7.7 DBMCLIでの/opt/oracle.cellos/compmon/exadata_mon_hw_asr.plスクリプトの置換

Oracle Exadata Storage Serverリリース12.1.2.1.0以降で、データベース・サーバーの構成、監視および管理のために、DBMCLIと呼ばれる新しいコマンドライン・インタフェースが導入されています。DBMCLIは、各データベース・サーバー上および仮想化マシンのDOM0上にプレインストールされています。DBMCLIでは、自動サービス・リクエスト、キャパシティ・オンデマンド、Infrastructure as a Serviceおよびデータベース・サーバー電子メール・アラートを構成できます。DBMCLIは、/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl Perlスクリプトにかわって使用されます。DBMCLIの使用方法の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

A.8 Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.0)の新機能

Oracle Exadata Database Machine 12cリリース1 (12.1.2.1.0)の新機能は次のとおりです。

A.8.1 Oracle Exadata Database Machineエラスティック構成

エラスティック構成を使用すると、Oracle Exadata Racksで、顧客が定義したデータベース・サーバーとExadata Storageサーバーの組合せを利用できます。少なくとも2台のデータベース・サーバーと3台のストレージ・サーバーをラックに設置する必要があります。ストレージ・サーバーは、すべて同タイプである必要があります。Oracle Exadata Database Machine X5-2エラスティック構成とOracle Exadata Database Machine X4-8エラスティック構成では、2台から19台のデータベース・サーバー、3台から20台のExadata Storageサーバーまたは1組のデータベース・サーバーとExadata Storageサーバーの組合せを使用できます。Oracle Exadata Storage Expansion Rack X5-2エラスティック構成では、4台から19台のストレージ・サーバーを使用できます。

エラスティック構成を使用すると、Oracle Exadata Racksで、顧客が定義したデータベース・サーバーとExadata Storageサーバーの組合せを利用できます。これにより、ハードウェア構成を、特定のワークロードに的確に適合させることができます(たとえばDatabase In-Memory、OLTP、Data WarehousingまたはData Retention)。

  • Oracle Exadata Database Machine X5-2エラスティック構成は、2台のデータベース・サーバーと3台のExadata Storageサーバーを含むクオータ・ラックから用意されています。ラックがいっぱいになるか、ラックの最大サーバー数の22台に達するまで、追加のデータベースとストレージ・サーバー(大容量(HC)またはExtreme Flash(EF))を追加できます。

  • Oracle Exadata Storage Expansion Rack X5-2エラスティック構成は、4台のExadata Storageサーバーを含むクオータ・ラックから用意されています。ラック当たり合計19台のストレージ・サーバーまで、追加のストレージ・サーバー(HCまたはEF)を追加できます。

  • Oracle Exadata Database Machine X4-8エラスティック構成は、2台のデータベース・サーバーX4-8 8ソケット・サーバーと3台のExadata Storageサーバーを含むハーフ・ラックから用意されています。ラック当たり最大2台の追加のX4-8 8ソケット・サーバーを追加できます。ラック当たり最大11台の追加のExadata Storageサーバー(HCまたはEF)を追加できます。

A.8.2 スパース・グリッド・ディスク

スパース・グリッド・ディスクは、新しいデータがディスクへ書き込まれるときに領域を割り当てるため、仮想サイズが実際の物理サイズよりはるかに大きくなることがあります。スパース・グリッド・ディスクは、スパース・ディスク・グループを作成して、割り当てられた領域の小部分を使用するデータベース・ファイルを格納するために使用されます。スパース・ディスク・グループは、短時間で効率的にデータベースのスナップショットをOracle Exadata上に作成するのに特に役立ちます。従来のデータベースを、スパース・ディスク・グループを使用して作成することもできます。

最小ハードウェア: ストレージ・ノードX3以上

最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 BP5以上。

A.8.3 テストおよび開発目的のデータベースのスナップショット

テストと開発目的のために、スペース効率のよいデータベース・スナップショットをすぐに作成できるようになりました。スナップショットは、機密情報を消去した本番データベース(またはプラガブル・データベース(PDB))の共有読取り専用コピーで開始します。各スナップショットは、変更がなされるたびに、変更されたブロックをスパース・ディスク・グループへ書き込みます。

複数のユーザーが、同じベース・データベースから別々のスナップショットを作成することもできます。このため、複数のテストおよび開発環境が、各タスク用のデータベースを別々に維持しつつ、領域を共有することができます。Exadata Storageサーバー上でスナップショットを使用すると、Smart Scanなど、Oracle Exadata Storage Server Softwareの機能を使用して、テストおよび開発をすることができます。

Exadataデータベース・スナップショットは、マルチテナント・データベース・オプションと統合されているため、きわめて簡素なインタフェースで新しいPDBスナップショットを作成することができます。

最小ハードウェア: ストレージ・ノードX3以上

最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 BP5以上。

A.8.4 列形式フラッシュ・キャッシング

Oracle Exadata System Softwareリリース12.1.2.1.0は、混合ワークロードを効率的にサポートしているため、OLTPと分析の両方でパフォーマンスを最適にできます。これは、トランザクショナル処理ではハイブリッド列形式で、分析処理ではそれに最適化された純粋な列形式で、データを格納することを可能にするExadata Smart Flash Cacheのデュアル・フォーマット・アーキテクチャにより実現されています。

さらに、Exadata Hybrid Columnar Compressionは、OLTPと分析のワークロードのニーズを均衡させます。Exadata Hybrid Columnar Compressionを使用すると最高レベルのデータ圧縮が可能になり、特に分析ワークロードでI/Oが削減されるためコストが大幅に節約されてパフォーマンスが向上します。

Oracle Exadata System Softwareリリース12.1.2.1.0では、フラッシュ・キャッシュ移入時に、分析処理を最適化するために、Exadata Smart Flash Cacheソフトウェアがハイブリッド列圧縮データを純粋な列形式に変換します。フラッシュ内の純粋な列データに対するフラッシュ・キャッシュは、選択された列のみを読み取るため、高速で実行され、フラッシュI/Oとストレージ・サーバーのCPU使用量が減ります。

Oracle Exadata System Softwareリリース12.1.2.1.0は、Exadata Hybrid Columnar Compression表データを純粋な列形式レイアウトでフラッシュ・キャッシュにキャッシュすることができます。Smart Scanを使用してExadata Hybrid Columnar Compression表にアクセスすると、Exadata Hybrid Columnar Compressionの圧縮されたデータがフラッシュ・キャッシュの記憶領域と同じ量で純粋な列形式レイアウトに再フォーマットされます。

大規模表の、圧縮ユニット(CU)内での所定の列のデータのパーセンテージは、小規模表と比較して小さくなります。これにより、列全体のデータを取得するために、ディスクとフラッシュからより多くのCUがフェッチされます。大規模なExadata Hybrid Columnar Compression表の少数の列のみを読み取る問合せは、ストレージから無関係な列も読み取るため、広いI/O帯域幅を使用します。データを列形式でフラッシュ・キャッシュに格納すると、無関係な列を読む必要が軽減され、パフォーマンスが大きく改善します。

ワークロードのタイプ(OLTPまたはデータ・ウェアハウス)によって異なりますが、同じリージョンのデータを、従来のブロック形式と列形式の両方でフラッシュ・キャッシュ上にキャッシュできます。

この機能はデフォルトで有効になっており、この機能を使用するためにユーザーによる構成を必要としません。

列形式のフラッシュ・キャッシュを使用すると、OLTPスタイルの単一列参照でも優れたパフォーマンスを維持しつつ、レポーティングと分析的問合せが高速化されます。

列形式フラッシュ・キャッシュは、よくスキャンされるExadata Hybrid Columnar Compressionの圧縮されたデータを、フラッシュ・キャッシュへのロード時に純粋な列形式に自動変換することによって、Oracle Exadata Database Machineフラッシュのデュアル・フォーマット・アーキテクチャを実装しています。フラッシュ内の純粋な列データに対して実行されるSmart Scanは、選択された列のみを読み取るため、高速で実行され、フラッシュI/Oとストレージ・サーバーのCPUが減ります。

データが頻繁にOLTP参照される場合、元のExadata Hybrid Columnar Compression形式データもフラッシュ・キャッシュにキャッシュできます。このため、Exadataスマート・フラッシュ・キャッシュは、よく使用されるあらゆるタイプの操作を高速化するために、キャッシュされたデータの形式を自動的に最適化します。

この機能はデフォルトで有効になっており、この機能を使用するためにユーザーによる構成を必要としません。

最小ソフトウェア: Oracle Database 12cリリース12.1.0.2.0を実行するOracle Exadata System Softwareリリース12.1.2.1.0

関連項目:

フラッシュ・キャッシュのメトリックの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.8.5 書込み操作のためのOracle Exadata System SoftwareのI/Oレイテンシ制限

この機能では、遅い読取りによって異常値を排除できます。それ以外ではアプリケーションに表示される読取りの異常値を防止します。

ディスク・ドライブ、ディスク・コントローラおよびフラッシュ・デバイスは、デバイスが内部メンテナンスまたはリカバリ操作を実行している間、場合により、待機時間が長くなることがある複雑なコンピュータです。また、障害が発生しかけているデバイスは、その発生前に待機時間が長くなる場合があります。以前は、高い待機時間を示すデバイスは、場合によりSQL応答時間が長くなることがありました。書込み操作のOracle Exadata System SoftwareのI/Oレイテンシ制限では、レイテンシが長いI/O動作をミラー・コピーに自動リダイレクトすることによって、Oracle Exadata Database Machine上でのSQL I/O応答時間を確実に改善します。

Oracle Exadata System Softwareリリース11.2.3.3.1および12.1.1.1.1では、Oracle Exadata Database Machineがフラッシュ・デバイスから読取りを試行し、読取りI/Oのレイテンシが適切な長さより長い場合に、Oracle Exadata System SoftwareがI/O読取り操作を自動的に別のストレージ・サーバー(セル)にリダイレクトします。I/O読取りを開始したデータベース・サーバーにメッセージが送信され、それによってデータベース・サーバーは、読取りI/Oをデータの別のミラー・コピーにリダイレクトします。データの最新の有効なミラー・コピーに対して実行された読取りI/Oは、リダイレクトされません。

Oracle Exadata System Softwareリリース12.1.2.1.0では、レイテンシの長い書込み操作を検出すると、Oracle Exadata System Softwareは、同じストレージ・サーバーの別の正常なフラッシュ・デバイスに自動的に書込み操作をリダイレクトします。書込みが正常に完了したら、データベース・サーバーで書込みI/Oが成功と認識され、それによって書込み異常値を除去します。

要件:

  • 最小ソフトウェア:

    • Oracle Database 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)

    • Oracle Grid Infrastructure 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)

  • ストレージ・サーバー(セル)のライトバック・フラッシュ・キャッシュの有効化

A.8.6 誤検知ドライブ障害の除去

ディスク・ドライブとフラッシュ・ドライブは、内部ソフトウェアがロックされるために、場合により、実際に物理的に故障していなくても故障しているように見えることがある複雑なコンピュータです。X5-2 High Capacityセル上のハード・ドライブ障害と見られる現象またはX5-2 Extreme Flashセル上のフラッシュ・ドライブ障害と見られる現象が発生した場合、Oracle Exadata System SoftwareはI/Oを他のドライブに自動的にリダイレクトし、ドライブをパワー・サイクルします。パワー・サイクルの後、ドライブが正常ステータスに戻ると、再び有効化され、再同期されます。パワー・サイクルの後もドライブの障害が継続する場合、それは削除されます。この機能により、Oracle Exadata System Softwareでは誤検知されたディスク障害を除去することが可能になるため、データ冗長度を維持しつつ管理負荷を減らすことができます。

A.8.7 フラッシュおよびディスクのライフ・サイクル管理アラート

Oracle Exadata Storage Server Softwareは、ディスクの障害と交換によるOracle ASMのリバランス操作を監視します。管理サーバーは、リバランス操作が正常に完了したか、エラーが発生したときにアラートを送信します。

以前のリリースでは、V$ASM_OPERATIONビューを問い合せることによって、ユーザーがリバランス操作の進捗を定期的に監視する必要がありました。ユーザーは管理サーバーからアラートをサブスクライブし、Oracle ASMリバランス操作に関する更新を受け取ることができるようになりました。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2 BP4以降、およびOracle Exadata Storage Server Softwareリリース12.1.2.1.0以降。

A.8.8 最小値または最大値機能を備えたSQL問合せのためのパフォーマンス最適化

最小値または最大値機能を使用するSQL問合せは、Exadata Storage Serverメモリーにキャッシュされたストレージ索引列サマリーを活用するように設計されています。問合せの処理時に、その際の最小値と最大値が追跡されます。I/Oを発行する前に、データ領域のストレージ索引にキャッシュされた最小/最大値がその時点の最小/最大値とともに確認され、そのI/Oを発行するか、プルーニングするかが決定されます。全体として、この最適化により問合せ時にかなりのI/Oプルーニングが発生することがあり、問合せのパフォーマンスを向上させます。この最適化がプラスに働く問合せの例は、次のとおりです。

Select max(Salary) from EMP where Department = 'sales';

各列の最小値または最大値を問い合せることによって表の形状を取得するビジネス・インテリジェンス・ツールでは、この最適化は有益です。

次のセッション統計情報は、ストレージ索引最適化によって節約されたI/Oの量を示します。

cell physical IO bytes saved by storage index

最小ソフトウェア: Oracle Databaseリリース12.1.0.2。

A.8.9 AWRレポートのOracle Exadata Storage Server Softwareパフォーマンス統計情報

Exadata Storage Serverの構成とパフォーマンスの統計情報は、自動ワークロード・リポジトリ(AWR)で収集され、そのデータをAWRレポートで表示できます。AWRレポートのOracle Exadataセクションは、HTMLまたはアクティブ・レポート形式で表示できます。

次のセクションが、AWRレポートの3つの主要なセクションです。

  • Exadata Server構成: ハードウェアモデル情報、ソフトウェア・バージョンおよびストレージ構成

  • Exadata Serverシステム状態レポート: オフラインのディスクとオープン・アラート

  • Exadataパフォーマンス統計情報: オペレーティング・システム統計情報、ストレージ・サーバー・ソフトウェア統計情報、スマート・スキャン統計情報およびデータベースごとの統計情報

AWRレポートは、特定のインスタンスまたはデータベースに制限されず、ストレージ・レベルでパフォーマンス統計を提供します。これは、あるデータベースが別のデータベースのパフォーマンスに影響を及ぼす場合の事例を解析するのに役立ちます。

特定の色を使用して構成の相違が強調表示されるため、分析が簡単です。たとえば、他のセルとソフトウェア・リリースが異なるセルや、他のセルとメモリー構成が異なるセルが強調表示されます。

異常値は自動的に解析、表示されるため、パフォーマンス分析が簡単です。異常値は、適切にカラー表示され、詳細な統計情報にリンクされます。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2、およびOracle Exadata Storage Server Softwareリリース12.1.2.1.0。

A.8.10 Exafusion Direct-to-Wireプロトコル

Exafusion Direct-to-Wireプロトコルを使用すると、データベース・プロセスが、OSカーネルに入るオーバーヘッドをバイパスし、通常のネットワーク・ソフトウェア・スタックを実行して、Oracle Real Applications Cluster(Oracle RAC)メッセージをInfinibandネットワーク経由で直接読み取ったり送信したりできます。これにより、Oracle Exadata Database Machine上でのOracle RAC環境の応答時間とスケーラビリティが改善されます。Exafusionは、特にOLTPアプリケーションで特に有効です。小さなOLTPメッセージではメッセージ当たりのオーバーヘッドが特に顕著だからです。

最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース12.1.2.1.0には、OS、ファームウェアおよびExafusionとOracle Databaseソフトウェア・リリース12.1.0.2.0 BP1のためのドライバ・サポートが含まれます。

A.8.11 データベース・サーバー上の管理サーバー

データベース・サーバー上の管理サーバー(MS)は、データベース・サーバー管理コマンド用にWebサービスを実装し、バックグラウンド監視スレッドを実行します。管理サービスは、次のものを提供します。

  • ハード・ディスク、CPUおよびInfiniBandポートの監視を含む、包括的なハードウェアおよびソフトウェアの監視。

  • 強化されたアラート機能。

  • 重要なシステム・メトリック・コレクションと監視。

  • データベース・サーバーの構成、監視および管理のための、DBMCLIと呼ばれるコマンドライン・インタフェース。DBMCLIは、各データベース・サーバー上および仮想化マシンのDOM0上にプレインストールされています。DBMCLIでは、自動サービス・リクエスト、キャパシティ・オンデマンド、Infrastructure as a Serviceおよびデータベース・サーバー電子メール・アラートを構成できます。

Oracle Exadata Database Machineコマンドライン・インタフェース(DBMCLI)ユーティリティは、データベース・サーバーを管理するためのコマンドライン管理ツールです。DBMCLIは各サーバー上で動作し、個々のデータベース・サーバーを管理できるようにします。DBMCLIは、仮想マシンでも動作します。DBMCLIを使用して、データベース・サーバーを構成、監視および管理します。このコマンドライン・ユーティリティは、Oracle Exadata Database Machineの出荷時にインストール済です。

DBMCLIは、自動サービス・リクエスト、キャパシティ・オンデマンド、Infrastructure as a Serviceおよびデータベース・サーバー電子メール・アラートを構成するための統合クライアント・インタフェースです。また、ハード・ディスク、CPU、InfiniBandポートおよびシステムのメトリックとしきい値を監視できます。

A.8.12 JSONおよびXML用のSQL演算子

Oracle Exadata System Softwareは、条件評価のために多数のSQL演算子のオフロードをサポートしています。次のSQL演算子のオフロードがOracle Exadata System Softwareでサポートされるようになりました。

  • JSON演算子

    • JSON_VALUE

    • JSON_EXISTS

    • JSON_QUERY

    • IS JSON

    • IS NOT JSON

  • XML演算子

    • XMLExists

    • XMLCast(XMLQuery())

最小ソフトウェア: JSONのオフロードの場合、Oracle Databaseリリース12.1.0.2。XML演算子オフロードの場合、Oracle Databaseリリース12.1.0.2 BP1。

A.8.13 フラッシュ用のI/Oリソース管理

I/Oリソース管理(IORM)は、ディスク・ドライブのI/Oに加えてフラッシュ・ドライブのI/Oを管理して、データベース、プラガブル・データベースおよびコンシューマ・グループ間のI/Oの競合を制御するようになりました。Oracle Exadata環境がOLTP I/Oによって制限されることは非常に珍しいため、IORMはOLTPフラッシュI/Oをスマート・スキャン・フラッシュI/Oより自動的に優先し、スマート・スキャン・スループットにほとんどコストをかけずに、OLTP応答時間を確実に高速化します。

最小ソフトウェア: Oracle Database 11gまたはOracle Database 12cリリースを実行するExadataセル・ソフトウェア・リリース12.1.2.1.0

最小ハードウェア: ExadataリリースX2-*

A.8.14 フラッシュ・キャッシュ領域のリソース管理

フラッシュ・キャッシュは、共有リソースです。フラッシュ・キャッシュ領域のリソース管理を使用すると、データベース間IORM計画を使用して、フラッシュ・キャッシュ内でデータベースが使用できる最小および最大サイズを指定できます。フラッシュ・キャッシュ領域のリソース管理を使用すると、データベース・リソース計画を使用して、フラッシュ・キャッシュ内でプラガブル・データベース(PDB)が使用できる最小および最大サイズを指定することもできます。

最小ソフトウェア: Oracle Database 11gまたはOracle Database 12cリリース1 (12.1)リリース12.1.0.2を実行するOracle Exadata System Softwareリリース12.1.2.1.0

最小ハードウェア: Oracle Exadata Database MachineモデルX2-*

A.8.15 I/Oリソース管理プロファイル

現在、IORMデータベース間計画は、多データベース環境でデータベース間計画の管理負荷を低下させるサポート・プロファイルを計画します。以前は、ストレージ管理者が、データベース間計画ですべてのデータベースに対してリソースを指定する必要がありました。この計画は、新しいデータベースが作成されるたびに更新する必要がありました。IORMプロファイルは、この管理負荷を大幅に低下させます。ストレージ管理者が、性能要件に基づいて様々なプロファイル・タイプを定義するプロファイル・ディレクティブを作成できるようになりました。次に、管理者は、データベース間計画内でデータベース・パラメータDB_PERFORMANCE_PROFILEを使用して、新規および既存のデータベースを定義済プロファイルのいずれかにマップします。各データベースは、指定されたプロファイル・ディレクティブから、属性すべてを自動的に継承します。

最小ソフトウェア: Oracle Database 12cリリース1(12.1)リリース12.1.0.2 Exadata Bundle Patch 4を実行するExadataセル・ソフトウェア・リリース12.1.2.1.0。

A.8.16 Extreme Flashセル上のライトバック・フラッシュ・キャッシュ

Extreme Flashセルでは、フラッシュ・キャッシュはデフォルトでライトバック・モードで動作し、フラッシュ領域の5パーセントを占有します。Extreme Flashセル上のフラッシュ・キャッシュはブロック・キャッシュとして使用されません。ユーザー・グリッド・ディスクがすでに作成されており、したがってフラッシュ・キャッシュが必要でないためです。ただし、それでもフラッシュ・キャッシュは、次の高度な操作に有効です。

  • 列キャッシュは、フラッシュ・キャッシュ上のExadataハイブリッド列圧縮(EHCC)表データを、Extreme Flashセル上に純粋な列形式レイアウトでキャッシュします。

  • 書込みI/Oレイテンシ制限は、一時的に停止したフラッシュへの書込みI/O動作をキャンセルし、Extreme Flashセル上の別の正常なフラッシュ・デバイスのライトバック・フラッシュ・キャッシュに記録するべき書込みをリダイレクトします。

  • 高速データ・ファイル作成は、Extreme Flashセル上で、ライトバック・フラッシュ・キャッシュのブロックに関するメタデータを維持し、ユーザー・グリッド・ディスクへの実際のフォーマッティング書込みを除去します。

管理者は、フラッシュ・キャッシュをExtreme Flashセル上でライトスルー・モードに構成するように選択できます。列キャッシングはライトスルー・フラッシュ・キャッシュ・モードで動作しますが、書込みI/Oレイテンシ制限と高速データ・ファイル作成には、ライトバック・フラッシュ・キャッシュが有効になっていることが必要です。

A.8.17 Extreme Flashおよび大容量システムにおける1.6TBフラッシュ・ドライブの安全な消去

このリリースでは、Oracle Exadata System Softwareは、Extreme Flashおよび大容量システムでの1.6 TBフラッシュ・ドライブの安全な消去をサポートしています。1.6TBのフラッシュ・ドライブを安全に消去するには、約5.5時間かかります。

A.8.18 Exadataセルの接続制限の向上

現在、Oracle Exadata X5-2およびX4-2セルは、アクティブ-アクティブ・ボンディングを使用して、1台以上のデータベース・サーバーから発信された最大120,000の同時接続をサポートできます。つまり、最大120,000のプロセスを1つのセルに同時に接続してI/O操作を実行することができます。

A.8.19 SNMP v3のサポート

Oracle Exadata Database Machineのデータベース・サーバーおよびストレージ・サーバーは、アラート送信に関してSNMP v3をサポートします。SNMP v3は、サーバーから管理者とOracle Auto Service Request (ASR)に送信されるアラートに、認証と暗号化を提供します。

A.8.20 米国連邦情報処理標準(FIPS) 140-2準拠のスマート・スキャン

米国連邦情報処理標準(FIPS)140-2は、暗号化モジュールのセキュリティ要件を指定しています。FIPS 140-2要件のある顧客をサポートするために、Oracle Exadataバージョン12.1.2.1.0では、FIPS 140-2検証済暗号モジュールを使用するように構成できます。これらのモジュールは、暗号化サービス(たとえばOracle Databaseパスワード・ハッシュと検証)、ネットワーク暗号化(SSL/TLSとネイティブの暗号化)および保存データの暗号化(透過的なデータ暗号化)を提供します。

透過的データ暗号化が使用され、Oracle DatabaseがFIPS 140モード用に構成されている場合、Oracle Exadata Smart Scanオフロードは、暗号化列と暗号化表領域の暗号化および復号のための同一のFIPS 140検証済モジュールを自動的に活用します。

Oracle Databaseリリース12.1.0.2.0では、データベース・パラメータDBFIPS_140が、Oracle DatabaseおよびExadata Storage Server内部でFIPS 140暗号処理モードのオンとオフを切り替える機能を提供します。

Oracle Databaseリリース11.2.0.4.0では、アンダースコア付きのパラメータ_use_fips_modeが、Oracle DatabaseおよびExadata Storage ServerでFIPS 140暗号処理のオンまたはオフを切り替える機能を提供します。

DBFIPS_140を使用した例を次に示します。

ALTER SYSTEM SET DBFIPS_140 = TRUE;

パラメータ・ファイルでの例:

DBFIPS_140=TRUE

次のハードウェア・コンポーネントは、指定したリリースのファームウェア・アップデートでFIPS準拠になりました。

  • Oracle Server X5-2以降のシステムは、FIPS 140–2に準拠するように設計されています

  • ILOMリリース3.2.4を使用したOracle Sun Server X4-8

  • SW1.2.0およびILOMリリース3.2.4.20/22を使用したSun Server X4-2およびX4-2L

  • SW1.4.0およびILOMリリース3.2.4.26/28を使用したSun Server X3-2およびX3-2L

  • SW1.8.0およびILOMリリース3.2.7.30.aを使用したSun Server X2-2

  • Cisco Catalyst 4948E-Fイーサネット・スイッチ

Exadata Database Machine ServersのV1、X2-*およびデータベース・ノードX3-8世代のFIPS準拠は計画されていません。

最小ソフトウェア: Oracle Databaseリリース12.1.0.2.0 BP3、MES Bundle on Top of Quarterly Database Patch For Exadata (APR2014 - 11.2.0.4.6)を適用したOracle Databaseリリース11.2.0.4、Oracle Exadata Storage Server Softwareリリース12.1.2.1.0、ILOM 3.2.4。

関連項目:

FIPSの詳細は、『Oracle Databaseセキュリティ・ガイド』

A.8.21 Oracle Exadata仮想マシン

統合環境では、X5-2、X4-2、X3-2およびX2-2データベース・サーバー上で、ワークロード間をより高いレベルで分離するOracle Virtual Machine (Oracle VM)が使用されるようになりました。仮想マシンの分離は、信頼できないワークロードが共有環境でセキュリティ、CPUまたはメモリー使用状況を制限する場合に好都合です。たとえば、ホスティングされている環境、クラウド環境、クロス部門統合、テストおよび開発環境、データベース・マシンで実行されている非データベースまたはサード・パーティのアプリケーションなどです。異なるバージョンのClusterwareを必要とするワークロード(たとえば特定のClusterwareパッチおよびバージョンを必要とするSAPアプリケーション)を統合するためにOracle VMを使用することもできます。

仮想マシンを使用すると高度な分離が提供されますが、各仮想マシンに別々のオペレーティング・システムOS、Clusterwareおよびデータベースをインストールする必要があるため、リソース使用、管理負荷およびパッチング負荷の増大が代償として伴います。このため、1つの仮想マシン内で複数の信頼できるデータベースを統合することにより、Oracle VMをデータベース固有の統合と混用することが望まれます。Oracle Resource Managerを使用して、1つの仮想マシン内でデータベース用のCPU、メモリーおよびI/O使用を制御することができます。Oracle Multitenant Optionを使用すると、統合Oracle Databaseに、高度な統合とアジリティを提供することができます。

Exadata Virtual Machinesは、高速InfiniBandネットワークをSingle Root I/O Virtualization (SR-IOV)とともに使用して、仮想マシン内のパフォーマンスを、Exadataの有名なrawハードウェア・パフォーマンスに類似したものにします。Exadata Smart Scansは、仮想マシンへのメッセージ・トラフィックを激減させることによって、仮想化オーバーヘッドを、他のプラットフォームと比較して大幅に減少させます。Exadata Virtual Machinesは、その仮想マシンで動作しているアプリケーションのワークロード要件に基づいて、CPUとメモリーを動的に拡大または縮小できます。

Exadata上の仮想マシンは信頼できるパーティションとみなされるため、ソフトウェアを物理プロセッサ・レベルでなく仮想マシン・レベルでライセンスすることができます。信頼できるパーティションがない場合、データベース・オプションおよびその他のOracleソフトウェアは、そのサーバーまたはクラスタ上で実行されているすべてのデータベースが特定のオプションを必要としていなくても、サーバーまたはクラスタ・レベルでライセンスする必要があります。

A.9 Oracle Exadata Database Machine 12cリリース1 (12.1.1.1.1)の新機能

Oracle Exadata Database Machine 12cリリース1 (12.1.1.1.1):の新機能は次のとおりです。

Oracle Exadata Database Machine 12cリリース1 (12.1.1.1.1)およびOracle Exadata Database Machine 11gリリース2 (11.2.3.3.1)の新機能は次のとおりです。

前のリリース11.2.3.3.1の機能は、「Oracle Exadata Database Machine 11gリリース2 (11.2.3.3.1)の新機能」を参照してください。

A.9.1 LOBおよびCLOBの追加のSQL演算子および条件

Oracle Exadata Storage Server Softwareは、条件評価のために多数のSQL演算子および条件のオフロードをサポートしています。現在、次のSQL演算子および条件のオフロードは、Oracle Exadata Storage Server Softwareでサポートされています。

  • LOBおよびCLOB条件

    • LIKE

    • REGEXP_LIKE

LOBがインライン(表の行に格納されている)場合のみ、LOBの演算子および条件がスマート・スキャンによって評価されます。また、スマート・スキャンでは、セキュア・ファイル圧縮が行われます。セキュア・ファイル圧縮を使用すると、LOBをインラインにできるようにサイズが縮小されます。

最小ソフトウェア: LOB/CLOBのオフロードの場合、Oracle Databaseリリース12.1.0.2.

関連項目:

インラインLOBの詳細は『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

A.10 Oracle Exadata Database Machine 12cリリース1 (12.1.1.1.0)の新機能

Oracle Exadata Database Machine 12cリリース1(12.1.1.1.0)の新機能は次のとおりです。

A.10.1 Oracle Databaseリリース12c リリース1 (12.1)および11g リリース2 (11.2)のサポート

Oracle Exadata Storage Server Software 12cリリース1 (12.1)は、単一のOracle Exadata Database Machine上で実行されるOracle Databaseリリース12cリリース1 (12.1)および11gリリース2 (11.2)をサポートしています。データベース・サーバーは、Oracle Exadata Storage Server Softwareリリース 12c リリース1 (12.1)がインストールされたすべてのExadata Storage Serverから、スマート・スキャン、高速ファイル作成および高速増分バックアップなど、最高のパフォーマンスを実現します。

Oracle Exadata Storage Server Software 12cリリース1 (12.1)では、オフロード・リクエストを処理するための適切なセル・オフロード・サーバーを実行することにより、複数のデータベース・リリースをサポートできます。Oracle Database 11gリリース2 (11.2)から生成されるオフロード・リクエストは、リリース11gオフロード・サーバーによって処理され、Oracle Database 12cリリース1 (12.1)データベースから生成されるオフロード・リクエストは、12cオフロード・サーバーによって処理されます。

Oracle Exadata Storage Server Software 12c リリース1 (12.1)は、主要な各データベース・リリースに個別のオフロード・サーバーを含むようになったため、すべてのオフロード操作を完全にサポートすることができます。Oracle Database 11g リリース2 (11.2)から生成されるオフロード・リクエストは、自動的にリリース11gオフロード・サーバーによって処理され、Oracle Database 12c リリース1 (12.1)データベースから生成されるオフロード・リクエストは、自動的に12cオフロード・サーバーによって処理されます。

Exadata Storage Server 12c リリース1 (12.1)は、次のリリースのOracle Databaseをサポートできます。

データベースのリリース 必要な最小リリース

11.2.0.2

バンドル・パッチ22

11.2.0.3

バンドル・パッチ20

11.2.0.4

現行のリリース

12.1.0.1

現行のリリース

A.10.2 CDBおよびPDBIORMサポート

Oracle Database 12cリリース1 (12.1)では、マルチテナント・アーキテクチャがサポートされています。マルチテナント・アーキテクチャにおいて、コンテナは、別個のデータベースとしてアプリケーションに論理的に表示されるOracle Multitenantコンテナ・データベース(CDB)の、スキーマ、オブジェクトおよび関連する構造体コレクションです。CDBにおいて、管理者は、ワークロードを実行するための複数のプラガブル・データベース(PDB)を作成できます。CDBでは、共有リソースを競合する複数のPDB内に、複数のワークロードがあります。

CDB計画およびPDB計画を使用することにより、I/Oリソース管理(IORM)では、異なるPDB間のI/Oリソース使用率を管理し、各PDBにおけるワークロードを管理できます。

Oracle Database 12cリリース1 (12.1)は、IORMの優先度付けをサポートしているため、異なるPDB間でのI/Oリソース使用率を管理したり、各PDB内のワークロードを管理することができます。

関連項目:

A.10.3 セルからセルへのデータ転送

以前のリリースでは、Exadataセルは、相互に直接通信しませんでした。セル間のデータの移動は、データベース・サーバー経由で行われていました。データは、ソース・セルからデータベース・サーバー・メモリーに読み取られ、次に宛先のセルに書き込まれていました。Oracle Exadata Storage Server Software 12c リリース1 (12.1)より、データベース・サーバー・プロセスは、セルへのデータ転送の負荷を軽減することができます。データベース・サーバーは、宛先のセルにソース・セルから直接データを読み取るよう指示し、データをそのローカル・ストレージに書き込みます。これにより、ファブリック間で転送されるデータの量が半分に削減され、InfiniBandバンド幅の消費とデータベース・サーバーのメモリー要件が削減されます。Oracle Automatic Storage Management (Oracle ASM)の再同期化、復元およびリバランスはこの機能を使用して、データ移動の負荷を軽減します。これにより、Oracle ASMインスタンスのInfiniBandファブリック・レベルでのバンド幅の使用率が向上します。この機能を利用するための構成は必要ありません。

ソフトウェアの最小要件: Oracle Database 12c リリース1 (12.1)以降およびOracle Exadata Storage Server Software 12c リリース(12.1)以降。

A.10.4 HP Oracle Database Machineハードウェアのサポート終了

Oracle Exadata System Software 12cリリース1 (12.1)は、HP Oracle Database Machineハードウェアではサポートされていません。Oracleは、引き続きOracle Exadata System Software 11gリリース2 (11.2)が実行されているHP Oracle Database Machinesをサポートしています。

A.11 Oracle Exadata Database Machine 11gリリース2 (11.2.3.3.1)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.3.3.1)の新機能は次のとおりです。

A.11.1 Oracleデータベース・サーバーのキャパシティ・オンデマンド

ユーザーは、データベース・サーバーのアクティブ・コア数を制限することにより、必要なデータベース・ソフトウェアのライセンス数を制限できます。プロセッサ・コアの削減は、Oracle Exadata Database Machine Deployment Assistant (OEDA)を使用したソフトウェア・インストール時に実装されます。アクティブ・コア数は、後でより大きな容量が必要になった場合に増やすことができますが、減らすことはできません。アクティブ・プロセッサ・コアは、データベースの各ソケットにおいて同数必要です。

キャパシティ・オンデマンドは、Oracle Exadata Infrastructure as a Service (IaaS)と次の点で異なります。

  • キャパシティ・オンデマンドでは、初期インストール後にアクティブ・コア数を減らせません。

  • キャパシティ・オンデマンドを使用する場合、必要なソフトウェア・ライセンスはアクティブ・コア用のみです。

注意:

アクティブ・コア数を削減することにより、ソフトウェア・ライセンスの初期コストを抑えられます。ハードウェアのコストは変わりません。

関連項目:

A.11.2 Exadata I/Oレイテンシ制限

ディスク・ドライブまたはフラッシュ・デバイスは、まれに、内部リカバリ操作の実行中、わずかな時間に対し待機時間が長くなる場合があります。また、障害が発生しかけているドライブは、その発生前に待機時間が長くなる場合があります。この機能によってI/O読込み操作がミラー・コピーにリダイレクトされるため、非常にまれに発生するこうしたレイテンシ・スパイクはマスクされます。

Oracle Exadata Storage Server Softwareでは、読取りI/Oのレイテンシが適切な長さよりはるかに長くなった場合に、I/O読取り操作が自動的に別のセルにリダイレクトされます。リダイレクトは、I/O読取りを開始したデータベースにメッセージが返されることによって実行されます。データベースによって、データの別のミラー・コピーにI/Oがリダイレクトされます。データの最新の有効なミラー・コピーに対して実行されたI/Oは、リダイレクトされません。

最小ソフトウェア: Oracle Database 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)。Grid Infrastructureにも、同じリリースが必要です。

A.11.3 Oracle Exadata Storage ServerのI/Oタイムアウトしきい値

Oracle Exadata Storage Serverに対して、I/Oタイムアウトしきい値を構成できます。ストレージ・サーバーのI/Oは、定義されたしきい値を超える時間がかかると取り消されます。I/Oは、Oracle Automatic Storage Management (Oracle ASM)によって、データの別のミラー・コピーにリダイレクトされます。データの最後の有効なミラー・コピーに対して発行された書込みI/Oは、タイムアウトしきい値を超えた場合でも取り消されません。

タイムアウトしきい値を低く設定しすぎると、システムのパフォーマンスに悪い影響を与えることがあります。ピークI/O負荷の自動ワークロード・リポジトリ(AWR)レポートを確認し、しきい値をピークI/Oレイテンシに十分な安全マージンを加えた、より長い値に設定することをお薦めします。

最小ソフトウェア: Oracle Database 11gリリース2 (11.2)、Monthly Database Patch For Exadata (2014年6月 - 11.2.0.4.8)。Oracle Grid Infrastructureにも、同じリリースが必要です。

関連項目:

I/Oしきい値タイムアウトのALTER CELL属性に関する詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.11.4 新しいハードウェアのサポート

このリリースには、次のハードウェアのサポートが含まれます。

  • Oracle Exadata Database Machine X4-8フル・ラック

  • Exadata Storage Server X4-2、Exadata Storage Server X3-2およびExadata Storage Server X2-2用の4TBの大容量ドライブ

最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3.1

A.12 Oracle Exadata Database Machine 11gリリース2 (11.2.3.3.0)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.3.3.0)の新機能は次のとおりです。

A.12.1 フラッシュ・キャッシュの圧縮

フラッシュ・キャッシュの圧縮では、ユーザー・データがフラッシュ・キャッシュにロードされる際にデータを透過的に圧縮することによって、フラッシュ・キャッシュの論理容量が大幅に増加します。そのため、より多くのデータをフラッシュに維持することができ、ディスク・ドライブのデータにアクセスする必要が減ります。フラッシュのデータへのI/Oは、ディスク上のデータへのI/Oよりも大幅に速くなります。圧縮操作および解凍操作は、アプリケーションおよびデータベースに対して完全に透過的で、1秒当たり何百万I/Oという速度で実行してもパフォーマンスのオーバーヘッドはありません。

ユーザー・データの圧縮率に応じて、Oracle Exadata Storage Server Softwareは、フラッシュ・キャッシュ・サイズを最大2倍に動的に拡張します。圧縮の効果はデータの冗長性に応じて変わります。圧縮されていない表および索引の場合は、削減される領域が最も多くなります。OLTP圧縮された表および索引の場合は、領域が大幅に削減されます。ハイブリッド列圧縮を使用する表の場合は、削除される領域が最も少なくなります。フラッシュ・キャッシュ圧縮を有効にするには、Oracle拡張圧縮オプションが必要です。

この機能は、CellCLI ALTER CELL flashCacheCompress=trueコマンドを使用して有効にします。

最小ハードウェア: Exadata Storage Server X4-2L Server

A.12.2 表スキャン・ワークロードの自動フラッシュ・キャッシュ

Oracle Exadata Storage Server Softwareは、オブジェクトが読み取られる頻度に基づいて、表およびパーティションのスキャン・ワークロードで読み取られたオブジェクトをフラッシュ・キャッシュに自動的にキャッシュします。アルゴリズムでは、オブジェクトのサイズ、オブジェクトのアクセス頻度、キャッシュから削除されたデータへのオブジェクトによるアクセス頻度、およびデータベースによって実行されているスキャンのタイプが考慮されます。フラッシュ・キャッシュ・サイズおよびその他の同時発生するワークロードに応じて、表またはパーティションのすべてまたは一部のみがキャッシュされます。フラッシュ・キャッシュのサイズに比べて大きいオブジェクトのキャッシュを試行したり、メンテナンス操作でアクセスされる表をキャッシュすることによって、フラッシュ・キャッシュをスラッシングするリスクはありません。

この新機能により、フラッシュ・キャッシュに表を手動で維持する必要性がほとんどなくなりますが、例外として、特定のオブジェクトの場合は、合計ディスクI/Oを潜在的に増やすことにより、応答時間が確実に長くなります。以前のリリースでは、データベース管理者が大きなオブジェクトをKEEPとマークして、表スキャン・ワークロード用のフラッシュ・キャッシュにキャッシュする必要がありました。

この機能は主に、データ・ウェアハウス、データ・マートなどの表スキャン集中型のワークロードに効果があります。オンライン・トランザクション処理(OLTP)に実行されるようなランダムI/Oは、以前のリリースと同じ方法で引き続きフラッシュ・キャッシュにキャッシュされます。

最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3

A.12.3 高速データ・ファイル作成

高速データファイル作成では、新規データファイルがフォーマットされる速度が2倍以上になります。フラッシュ・キャッシュでは、新しくフォーマットされたブロックをディスクまたはフラッシュに書き込むのではなく、単にブロックに関するメタデータをライトバック・フラッシュ・キャッシュに保持することにより、ディスクへの書込みの実際のフォーマットを排除します。たとえば、高速データファイル作成を使用すると、リリース11.2.3.3を実行しているOracle Exadataフル・ラックに1TBのデータファイルを作成する際に90秒かかります。以前のリリースで同じ1TBのデータファイルを作成すると、220秒かかります。この機能は、ライトバック・フラッシュ・キャッシュが有効であり、適切なソフトウェア・リリースが使用されている場合に自動的に機能します。

最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12cリリース1 (12.1)リリース12.1.0.1を実行するOracle Exadata Storage Server Softwareリリース11.2.3.3

A.12.4 ネットワーク・リソース管理

ネットワーク・リソース管理では、InfiniBandファブリックを使用して重要なデータベース・ネットワーク・メッセージに自動的かつ透過的に優先度を付け、レイテンシが重大な影響を及ぼす操作に関する高速の応答時間を実現します。優先度付けは、InfiniBandファブリック全体に適用されるように、データベース、データベースのInfiniBandアダプタ、Oracle Exadata Storage Server Software、ExadataストレージのInfiniBandアダプタおよびInfiniBandスイッチに実装されます。

Oracle RACキャッシュ・フュージョン・メッセージなど、レイテンシの影響を受けるメッセージには、バッチ、レポート作成およびバックアップ・メッセージよりも高い優先度が付けられます。ログ・ファイル書込み操作には、トランザクション処理時間のレイテンシを低下させるために最上位の優先度が付けられます。

この機能はCPUおよびI/Oリソース管理と連携し、統合環境での高パフォーマンスと予測可能性を実現します。たとえば、オンライン・トランザクション処理(OLTP)のワークロードがあると仮定した場合、コミット・レイテンシはログ書込みの待機時間によって決定されます。この機能により、ログ・ライター・プロセス(LGWR)のネットワーク転送に、バックアップ、レポート作成など、同一または他のデータベースにおける他のデータベース・トラフィックよりも高い優先度を付けることができます。

この機能はデフォルトで有効になっており、構成または管理は必要ありません。

最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12cリリース1 (12.1)リリース12.1.0.1、およびスイッチ・ファームウェア・リリース2.1.3-4を実行するOracle Exadata Storage Server Softwareリリース11.2.3.3

A.12.5 アクティブ・ボンディング・ネットワーク

Oracle Exadata Database Machine X4-2データベース・サーバーおよびストレージ・サーバーでは、InfiniBandカードの両方のポートのアクティブ・ボンディングのサポートが有効になります。ネットワーク・トラフィックの送信に両方のInfiniBandポートが同時に使用されるため、アクティブ・ボンディングでは以前のリリースのアクティブ・パッシブ・ボンディングに比べてネットワーク帯域幅がさらに高くなります。

アクティブ・ボンディング機能は、以前のInfiniBandカードよりもさらに高いスループットをサポートする新しいInfiniBandカードを特長としているため、Oracle Exadata Database Machine X4-2のネットワーク帯域幅を向上させます。以前のInfiniBandカードは最新世代のサーバーのPCIバスによって提供されるより高速な帯域幅を活用できるほど速くなかったため、アクティブ・ボンディングで古い世代のハードウェアの帯域幅は向上しません。

InfiniBandカードのアクティブ・ボンディングについて、次の点に注意してください。

  • Oracle Linuxを実行するデータベース・サーバーには、アクティブ・ボンディング機能があります。

  • Oracle Clusterwareでは、クラスタ内の各データベース・サーバーに同じインターコネクト名が必要です。既存のOracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2システムをOracle Exadata Database Machine X4-2システムで拡張する場合、データベース・サーバーにレガシー・ボンディングを保持することをお薦めします。

  • ネットワーク帯域幅を向上させるためには、InfiniBandカード1つ当たりに2つのIPアドレスが必要です。

次の表に、システムの構成方法のガイドラインを示します。

オペレーティング・システム Oracle Exadata Database Machine X4-2のデータベース・サーバー Oracle Exadata Database Machine X4-2のストレージ・サーバー Exadata Storage Server X4-2L Serverを使用したOracle Exadata Database Machine X3-8フル・ラックのデータベース・サーバー

Oracle Linux

アクティブ・ボンディング

アクティブ・ボンディング

従来のボンディング、HCAにつき1つのポートがアクティブ

Oracle Solaris

IPMP、1つのポートがアクティブ

アクティブ・ボンディング

IPMP、HCAにつき1つのポートがアクティブ

最小ハードウェア: Oracle Exadata Database Machine X4世代サーバー

最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.3

A.12.6 アプライアンス・モードのOracle ASMディスク・グループ

Oracle ASMappliance.mode属性を使用すると、1つ以上のOracle ASMディスクを削除するときにディスクのリバランス完了時間が改善されます。これは、障害後に冗長性がより高速にリストアされることを意味します。属性は、新しいディスク・グループの作成時に自動的に有効になります。既存のディスク・グループでは、ALTER DISKGROUPコマンドを使用して明示的に属性を設定する必要があります。

属性は、次の要件を満たすディスク・グループのみで有効にできます。

  • Oracle ASMディスク・グループ属性compatible.asmが、リリース11.2.0.4以降に設定されている。

  • cell.smart_scan_capable属性がTRUEに設定されている。

  • ディスク・グループ内のすべてのディスクが同じタイプである(すべてハード・ディスクまたはExtreme Flashディスクなど)。

  • ディスク・グループのすべてのディスクが同じサイズである。

  • ディスク・グループのすべての障害グループのディスク数が等しい。

  • ディスク・グループにオフラインのディスクがない。

最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12c リリース1 (12.1)リリース12.1.0.2を実行するOracle Exadata System Softwareリリース11.2.3.3

関連項目:

appliance.mode属性の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.12.7 ハード・ディスクの自動修正および修復

Oracle Exadata System Softwareは、ハード・ディスクがアイドル状態のときに定期的にハード・ディスクを自動で検査して修復します。ハード・ディスクで不良セクターが検出された場合、Oracle Exadata System Softwareは、別のミラー・コピーからデータを読み取ることによって不良セクターを修復するようOracle ASMに自動的にリクエストを送信します。デフォルトでは、ハード・ディスクの修正は2週間ごとに実行されます。

最小ソフトウェア: Oracle Database 11gリリース2 (11.2)リリース11.2.0.4またはOracle Database 12cリリース1 (12.1)リリース12.1.0.2を実行するOracle Exadata System Softwareリリース11.2.3.3

関連項目:

修正間隔の設定の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.12.8 交換のためのハード・ディスクの削除

障害ステータスではない正常なハード・ディスクを交換する場合、Oracle Exadata Database Machine管理者は事前にALTER PHYSICALDISK DROP FOR REPLACEMENTコマンドを実行して成功することを確認した後に、Oracle Exadata Storage Serverからハード・ディスクを削除する必要があります。このコマンドでは、ディスク・グループの強制ディスマウントを発生させずにそのハード・ディスクのグリッド・ディスクをOracle ASMから安全にオフラインにできることを確認します。ディスク・グループの強制ディスマウントを発生させずにすべてのグリッド・ディスクをオフラインにできる場合、このコマンドによってグリッド・ディスクがOracle ASMからオフラインにされ、ハード・ディスクが無効になり、ストレージ・サーバーのサービスLEDがオンになります。

最小ソフトウェア: Oracle Exadata System Softwareリリース11.2.3.3

関連項目:

ALTER PHYSICALDISKコマンドの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.12.9 交換のためのBBUの削除

Oracle Exadata Database Machineデータベース・サーバーまたはストレージ・サーバーでオンラインのBBU (バッテリ・バックアップ・ユニット)を交換する前に、Oracle Exadata Database Machine管理者はALTER CELL BBU DROP FOR REPLACEMENTコマンドを実行してこのコマンドが成功することを確認する必要があります。このコマンドによって、コントローラがライトスルー・キャッシングに変更され、停電時にBBUが交換される際にデータ損失が発生しなくなります。

最小ハードウェア: ディスクフォームファクタBBUを搭載したOracle Exadata Database Machine X3-2またはOracle Exadata Database Machine X3-8 フル・ラック

最小ソフトウェア: Oracle Exadata System Softwareリリース11.2.3.3

関連項目:

A.12.10 Oracle Exadata Database Machineエイス・ラックの構成

ストレージ・セルのOracle Exadata Database Machineエイス・ラックの構成は、ALTER CELL eighthRackコマンドを使用して有効または無効にできます。エイス・ラックの構成を使用すると、ハード・ディスクに6個以下のセル・ディスクが作成され、フラッシュ・ディスクに8個以下のセル・ディスクが作成されます。

最小ソフトウェア: Oracle Exadata Storage Server Softwareリリース11.2.3.2.1

関連項目:

Oracle Exadata Database Machineエイス・ラックの構成の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

A.12.11 セル・アラートのサマリー

Oracle Exadata System Softwareは、Oracle Exadata Storage Serverのすべてのオープン・アラートのサマリーを電子メールで定期的に送信します。オープン・アラート電子メール・メッセージには、セル上のすべてのオープン状態の問題の簡潔なサマリーが示されています。サマリーには次の内容が含まれます。

  • セル名

  • イベント時間

  • アラートの重大度

  • アラートの説明

  • アラート・サマリーの構成に関する情報

前のサマリー以降に作成されたアラートには、アスタリスクが付けられます。

最小ソフトウェア: Oracle Exadata System Softwareリリース11.2.3.3

関連項目:

アラート・サマリーの構成の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.12.12 大きいドライブの安全な消去

このリリースでは、Oracle Exadata Storage Server Softwareは、大きいハード・ドライブおよびフラッシュ・ドライブの安全な消去をサポートしています。次に、サポートされているアルゴリズムを使用してドライブを安全に消去するための所要時間を示します。

ドライブのタイプ 1パス(1pass) 3パス(3pass) 7パス(7pass)

1.2 TBドライブ

1.67時間

5時間

11.67時間

4 TBドライブ

8時間

24時間

56時間

186 GBフラッシュ・ドライブ

該当なし

該当なし

36分

関連項目:

Exadata安全消去

A.12.13 ILOMの定期的なリセット

Integrated Lights Out Manager (ILOM)は、管理サーバー(MS)ILOMハング検出モジュールにより、未然防止策として定期的にリセットされます。これは、ILOMが長期間稼働した後に、不安的な状態に陥るのを防ぐためです。リセット間隔は、90日です。

最小ソフトウェア: Oracle Exadata System Softwareリリース11.2.3.3.0

A.12.14 Oracle OSwatcherからOracle Exawatcherへの置換え

このリリースから、Oracle OSwatcherはOracle Exawatcherに置き換わりました。Oracle Exawatcherには、Oracle OSwatcherより高度なコレクションおよびレポート機能が備わっています。

関連項目:

Oracle Exawatcherの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.12.15 ハードウェアおよびソフトウェアの拡張

ハードウェアおよびソフトウェアに次の拡張が追加されています。

  • Sun Datacenter InfiniBand Switch 36スイッチの拡張

    • Oracle Exadata Database MachineのSun Datacenter InfiniBand Switch 36スイッチは、patchmgrユーティリティを使用してローリング方式でアップグレードされます。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

    • スイッチ・ソフトウェア・リリース2.1.3-4には、断続的なリンクを自動的に無効にする機能があります。InfiniBandの仕様には、リンクのビット・エラー率は1012よりも小さい必要があると規定されています。シンボル・エラーの数が1日当たり3546ビット・エラーまたは1時間当たり144ビット・エラーよりも多い場合、リンクは無効になります。InfiniBandスイッチのソフトウェアにはautodisableコマンドがあり、スイッチがリリース2.1.3-4にアップグレードされる場合、この機能はpatchmgrユーティリティによって自動的に有効になります。

    • 新しいスイッチのソフトウェア・リリース2.1.3-4では、2台のスイッチ、またはファブリック内の複数のスパイン・スイッチ間に不均衡な数のリンクがあるファットツリー・トポロジを作成できます。

    • サブネット・マネージャのフェイルオーバーの実行にかかる時間は、複数ラック構成でも1秒未満に削減されます。

  • パッチ・アプリケーションの拡張

    • patchmgrユーティリティには、パッチ適用の完了時の電子メール・メッセージと、ローリングおよび非ローリング・パッチ・アプリケーションのステータスを送信する機能があります。詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』およびパッチ・セットを参照してください。

    • ILOM/BIOS、InfiniBand HCAおよびディスク・コントローラのデータベース・サーバーのファームウェア・アップグレードは、Oracle LinuxおよびOracle Solarisを実行するラックでコンポーネントを交換する際に自動的に実行されます。

  • ハードウェアの堅牢性の強化

    • ハード・ディスクの不良セクターからリカバリする時間は、12倍に削減されています。

    • ハード・ドライブまたはフラッシュ・ドライブの障害状態はまれにしかブールになりません。ほとんどのドライブでは、障害が発生する前に大幅に速度が低下します。遅くて断続的なドライブがより早期に検出され、ドライブがpredictive failureまたはハード障害状態になる前にOracle Exadata Storage Server Softwareにより機能が停止されます。

    • ストレージ・サーバーのILOMが応答を停止すると、管理ソフトウェアはILOMを自動的にリセットできます。

  • Oracle Solaris 11.1 (SRU 9.5.1)のサポート

    このリリースでは、データベース・サーバーでOracle Solaris 11.1 SRU 9.5.1をサポートしています。

A.13 Oracle Exadata Database Machine 11gリリース2 (11.2.3.2)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.3.2)の新機能は次のとおりです。

A.13.1 Exadata Smart Flash Cacheを使用したライトバック・フラッシュ・キャッシュ

Exadata Smart Flash Cacheは、頻繁にアクセスされるデータを高速なソリッド状態の記憶装置に透過的にキャッシュし、問合せの応答時間とスループットを向上させます。ディスクではなくフラッシュによって処理される書込み操作は、ライトバック・フラッシュ・キャッシュと呼ばれます。ライトバック・フラッシュ・キャッシュでは、1秒当たりの書込みI/OをX3システムで20倍、X2システムで10倍多く実行できます。X3システムではフラッシュ容量がより大きいため、ほぼすべての書込みがフラッシュによって処理されます。

アクティブなデータ・ブロックを、ライトバック・フラッシュ・キャッシュに数か月または数年間保持できます。最近読取りが実行されていないブロックの場合、主要なコピーのみがキャッシュに保持されます。必要に応じて、すべてのデータはディスクにコピーされます。これにより、性能のよいフラッシュ領域を効率よく使用できます。

フラッシュ・キャッシュに問題がある場合、操作はフラッシュのミラー・コピーに透過的にフェイルオーバーされます。ユーザーが介入する必要はありません。フラッシュのデータは、割当て単位に基づいてミラー化されます。これは、書き込まれるデータ量がディスク・サイズではなく損失したキャッシュ・サイズに比例することを示します。

関連項目:

ライトバック・フラッシュ・キャッシュおよびライトスルー・フラッシュ・キャッシュの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください
A.13.1.1 セルの再起動後のExadataスマート・フラッシュ・キャッシュの持続性

Exadataスマート・フラッシュ・キャッシュは、停電、停止操作、セルの再起動などを行っても持続します。フラッシュ・キャッシュのデータは、セルの再起動後にディスクから読み取ることで、再移入されることはありません。サーバーからの書込み操作はフラッシュ・キャッシュに直接実行されます。これにより、ディスクでのI/O操作の数が減少します。フラッシュ・ディスクでのデータのキャッシュは管理者が設定します。

A.13.2 CELLSRVサービスの正常シャットダウン

セルまたはディスクがオフラインになり、管理者がCELLSRVサービスを再起動または停止しようとすると、冗長性が低下しているために、セルを停止できないというメッセージが管理者に通知されます。

A.13.3 ストレージ・サーバー・ディスクの取外しのLED通知

ストレージ・サーバー・ディスクを取り外す必要がある場合は、青色のLEDライトがサーバーに表示されます。青色のライトにより、保守が必要なサーバー・ディスクを簡単に確認できます。

A.13.4 パフォーマンスが低下しているディスクの識別

ディスクのパフォーマンスが低下すると、作業がすべてのディスクに均等に分散されるため、すべてのディスクのパフォーマンスが影響を受けます。たとえば、あるディスクのパフォーマンスが他のディスクよりも30%低下すると、システム全体のI/O容量が30%低下します。

パフォーマンスが低下しているディスクが検出されると、そのディスクはアクティブな構成から削除されます。次に、Oracle Exadata Database Machineが一連のパフォーマンス・テストを実行します。ディスクの問題が一時的な場合は、テストに合格すると、そのディスクは構成に戻ります。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ディスクを交換するための自動サービス・リクエスト(ASR)のサービス・リクエストが開きます。この機能は、ハード・ディスクとフラッシュ・ディスクの両方に適用されます。

A.13.5 Oracle SolarisでのOracle Database File Systemのサポート

Oracle Database File System(DBFS)では、Oracleデータベースの非構造化データを管理します。DBFSのファイルはSecureFilesのデータベースに格納され、パフォーマンス、スケーラビリティ、セキュリティ、可用性、および圧縮、重複除外、暗号化、テキスト検索、XQueryなどの豊富な機能の利点のすべてを継承します。

以前のリリースでは、DBFSはLinuxを実行するOracle Exadata Database Machineでしか利用できませんでした。このリリースでは、DBFSは、Oracle Solarisを実行するOracle Exadata Database Machineでもサポートされます。

関連項目:

DBFSの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

A.13.6 予測障害ディスク・ドロップの状態要因

ハード・ディスクがOracle Exadata Storage Serverで予測障害になると、Oracle Exadata System SoftwareOracle Automatic Storage Management (Oracle ASM)リバランスを自動的にトリガーし、ディスクからデータを移動します。Oracle ASMリバランスでは、最初に正常なミラーから読み取り、冗長性をリストアします。他すべてのミラーが利用できない場合、Oracle ASMリバランスは予測障害ディスクからデータを読み取ります。最適なリバランスを進めることができる場合は、これにより予測障害ディスクからのリバランス読取りが回避され、リバランス・プロセスで最大限のデータ冗長性を維持できます。

ディスク・グループ内の正常な他のディスクにデータを完全に移動する前に、Oracle Exadata System Softwareは、予測障害ディスクの悪い状態をデータベース・インスタンスに通知し、そのディスクのデータに対する問合せとスマート・スキャンを他のミラーに迂回して、応答時間を改善します。

A.13.7 サーバーのハード・ディスク・ドライブの番号付け

Exadata Storage Server X3-2 Serverのドライブは、各行で左から右に番号付けされます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図A-2 Exadata Storage Server X3-2 Serverのディスク・レイアウト

図A-2の説明が続きます
「図A-2 Exadata Storage Server X3-2 Serverのディスク・レイアウト」の説明

Sun Fire X4270 M2サーバーおよび以前のサーバーを使用したExadata Storage Serverのドライブは左下から上へと番号が付けられ、左端の列のドライブが0、1および2となっていました。次の列のドライブは3、4および5になりました。その次の列のドライブは6、7および8になりました。右端の列のドライブは9、10および11になりました。

図A-3 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのディスク・レイアウト

図A-3の説明が続きます
「図A-3 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのディスク・レイアウト」の説明

A.14 Oracle Exadata Database Machine 11gリリース2 (11.2.3.1)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.3.1)の新機能は次のとおりです。

A.14.1 Oracle Solaris 11(SRU2a)のサポート

このリリースでは、データベース・サーバーでOracle Solaris 11(SRU2a)をサポートしています。

A.14.2 Unbreakable Linuxネットワークを使用したLinuxデータベース・サーバーの更新

Oracle Exadata Storage Server Software 11gリリース2(11.2)リリース11.2.3.1以降は、最小パックが非推奨になりました。データベース・サーバーの更新手順では、更新の配信にUnbreakable Linuxネットワーク(ULN)を使用し、yumユーティリティを使用して更新を適用します。

関連項目:

データベース・サーバーの更新に関する詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

A.14.3 Oracle Exadata Database Machine向けOracle Enterprise Manager Cloud Control

Oracle Exadata Database Machineは、Oracle Enterprise Manager Cloud Controlを使用して管理できます。Oracle Enterprise Manager Cloud Controlでは、サーバー、オペレーティング・システム、ファームウェア、仮想マシン、ストレージおよびネットワーク・ファブリックの管理を単一のコンソールに結合します。

A.14.4 32個を超えるデータベースでのI/Oリソース管理のサポート

I/Oリソース管理(IORM)では、共有ベースのプランがサポートされるようになり、データベース間のプランで最大1024のデータベースと1024のディレクティブをサポートできます。共有ベースのプランでは、割合ではなく、共有に基づいてリソースを割り当てます。共有とは、I/Oリソースの相対分布です。また、新しいdefault指令で、データベース・プランで明示的に指定されていないすべてのデータベースのデフォルト値を指定します。

関連項目:

IORMの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.14.5 Oracle Database 11 gリリース2 (11.2.0.3)

Oracle Exadata System Software 11gリリース2 (11.2)リリース11.2.3.nのスマート・スキャンは、Oracle Databaseソフトウェア11gリリース2 (11.2)リリース11.2.0.3に存在しているテクノロジに基づいており、11.2.0.nリリースのデータベースと下位互換性があります。

A.14.6 Exadataセルの接続制限

Oracle Database、Oracle ASM、Oracle ClusterwareおよびOracleユーティリティは、ExadataセルでI/O操作を実行します。ExadataセルでI/O操作のプロセスを実行するには、プロセスでセルとの接続を最初に確立する必要があります。プロセスがExadataセルと接続されると、プロセス終了まで接続は維持されます。

このリリースでは、各Exadataセルで1台以上のデータベース・サーバーから最大60,000の同時接続をサポートできます。つまり、60,000を超えるプロセスを1つのセルに同時に接続してI/O操作を実行することはできません。リリース112.2.4での接続数の上限は32,000でした。リリース11.2.2.4より前は、接続数の上限は20,000でした。

A.15 Oracle Exadata Database Machine 11gリリース2 (11.2.2.4)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.2.4)の新機能は次のとおりです。

A.15.1 Oracle Exadataスマート・フラッシュ・ログ

ユーザー・トランザクションをコミットする時間は、ログ書込みのレイテンシにより大きく影響を受けます。また、領域管理や索引分割などのパフォーマンス・クリティカルな多くのデータベース・アルゴリズムも、ログ書込みのレイテンシにより影響を受けます。Oracle Exadata Storage Server Softwareでは、バッテリバックアップ式のDRAMキャッシュをディスク・コントローラで使用して、ログ書込みの速度を上げています。ディスク・コントローラ・キャッシュへの書込みは、通常は非常に高速ですが、ディスクI/Oが高い間は遅くなる場合があります。Oracle Exadataスマート・フラッシュ・ログでは、Exadata Storage Serverのフラッシュ・メモリーを利用することで、ログの書込みを高速化しています。

フラッシュ・メモリーの書込みレイテンシは平均して非常に少ないですが、平均より1から2等級遅くなるような異常値を示す場合もあります。Oracle Exadataスマート・フラッシュ・ログでは、フラッシュ・メモリーとディスク・コントローラ・キャッシュの両方に同時にREDO書込みを実行し、2つのうち最初の書込みが完了すると、書込みを完了します。これにより、ユーザー・トランザクションの応答時間が短縮し、I/Oが集中するワークロードで全体のデータベース・スループットを向上します。

Oracle Exadataスマート・フラッシュ・ログでは、REDOログ・データの一時的な格納にExadataフラッシュ・ストレージのみを使用します。Oracle Exadataスマート・フラッシュ・ログでは、デフォルトでフラッシュ・ディスクごとに32MB、各Exadataセル全体で合計512MBを使用します。自動的に構成および有効化されます。追加の構成は不要です。

A.16 Oracle Exadata Database Machine 11gリリース2 (11.2.2.3)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.2.3)の新機能は次のとおりです。

A.16.1 データベース・サーバー用Oracle Solarisオペレーティング・システム

Oracle Exadata Database Machineのデータベース・サーバーには、Linuxオペレーティング・システムおよびOracle Solarisオペレーティング・システムがあります。初期構成時に、各自の環境のオペレーティング・システムを選択します。オペレーティング・システムを選択したら、もう一方のオペレーティング・システムが使用しているディスク領域を再利用できます。

A.16.2 Exadata安全消去

Oracle Exadata System Softwareには、再デプロイする前に物理ディスクを安全に消去してクリーン・アップする方法が用意されています。ERASEオプションでは、1パス、3パスまたは7パスでディスク上の既存の内容を上書きします。1パス・オプションでは内容を0(ゼロ)で上書きします。3パス・オプションはNNSA(米国国家核安全保障局)の勧告に準拠し、7パス・オプションはDOD(米国国防総省)の勧告に準拠します。

次の表に、サポートされているアルゴリズムを使用してドライブを安全に消去するための所要時間を示します。

ドライブのタイプ 1パス 3パス 7パス

600 GBドライブ

1時間

3時間

7時間

2 TBドライブ

5時間

15時間

35時間

3 TBドライブ

7時間

21時間

49時間

22.875 GBフラッシュ・ドライブ

該当なし

該当なし

21分

93 GBフラッシュ・ドライブ

該当なし

該当なし

32分

注意:

  • Oracle Exadata System Softwareの安全なデータ消去では、アクセス可能なすべてのデータの複数回上書き方式を使用します。上書き方式では、データ文字の様々な組合せを使用します。このデータ消去方式は、周知のアルゴリズムに基づきます。まれな条件下で、7パスによる消去でもデータ形跡を完全に削除できないことがあります。たとえば、ディスクに内部的なリマップ・セクターがあると、ディスク上に一部のデータが物理的に残ってしまう場合があります。通常のI/Oインタフェースでは、そのデータにアクセスできません。

  • データの保護に使用できる別の方法として、表領域暗号化があります。

A.16.3 最適化されたスマート・スキャン

Oracle Exadata Storage Server Softwareでは、CPU使用率を監視することにより、Exadata Storage Serverのリソースのボトルネックを検出します。ボトルネックが見つかると、処理の再割当てを行い、パフォーマンスを改善します。各Exadataセルでは、次の統計情報を保持します。

  • 直前の30分間を対象とするExadataセルのCPU使用率とプッシュバック(戻り)率のスナップショット。

  • プッシュバック(戻り)が決定された1MBのブロックの合計数。

  • データベース・サーバーに戻されたブロックの数。

  • Total cpu passthru output IO sizeの統計(KB)

A.17 Oracle Exadata Database Machine 11gリリース2 (11.2.1.2)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2.1.2)の新機能は次のとおりです。

A.17.1 Exadataスマート・フラッシュ・キャッシュ

Exadataスマート・フラッシュキャッシュにより、各Exadataセル上で頻繁にアクセスされるデータ用にキャッシュ・メカニズムが提供されます。このキャッシュは、ランダムな反復読取りを処理するのに役立つライトスルー・キャッシュであり、オンライン・トランザクション処理(OLTP)に非常に適しています。これにより、表または索引レベルでデータベース側のSTORAGE句のヒントを使用して、KEEPモードでデータをキャッシュするメカニズムが提供されます。フラッシュ・ディスクのExadataスマート・フラッシュキャッシュ領域は、起動時にExadataセルに自動的に作成されます。

Oracle Exadata Storage Serverには、従来の回転型のハード・ディスクに加え、高性能なフラッシュ・ディスクが搭載されています。これらの高性能なフラッシュ・ディスクを使用して、Exadataグリッド・ディスクを作成し、頻繁にアクセスされるデータを格納できます。この場合、ユーザーは、正確な領域プランを作成して、性能のよいディスクに最もアクティブな表領域を配置する必要があります。推奨オプションとして、Exadataスマート・フラッシュキャッシュ用にフラッシュ・ディスク領域の一部または全部を提供できます。この場合、回転ディスク上で最も頻繁にアクセスされるデータは、高性能なフラッシュ・ディスクのExadataスマート・フラッシュキャッシュ領域に自動的にキャッシュされます。データベースがこのようなデータにアクセスする必要がある場合、Oracle Exadata Storage Serverでは、データを遅い回転ディスクから取得するかわりに、Exadataスマート・フラッシュキャッシュからフェッチします。

パーティションや表がデータベースによってスキャンされる場合、オブジェクトにCELL_FLASH_CACHE属性が設定されていれば、Exadata Storage Serverでは、Exadataスマート・フラッシュキャッシュからスキャン対象のデータをフェッチできます。また、Exadata Storage Serverでは、Exadataフラッシュキャッシュからデータを提供する以外に、ハード・ディスクからスキャン対象のオブジェクトをフェッチすることもできます。

Exadata Storage ServerによってExadataスマート・フラッシュキャッシュおよびハード・ディスクからスキャン・データをフェッチする場合、そのパフォーマンスは加算的です。Exadata Storage Serverでは、Exadataスマート・フラッシュキャッシュの最大帯域幅とハード・ディスクの最大帯域幅を使用してオブジェクトをスキャンできるため、双方からの同時スキャン中は最大帯域幅が加算されます。

Oracle DatabaseとExadataスマート・フラッシュキャッシュ・ソフトウェアは、相互に緊密に連携して動作します。データベースでは、Oracle Exadata Storage Serverに読取りまたは書込みリクエストを送信する際に、そのデータが再度アクセスされる可能性があるかどうかと、そのデータをキャッシュする必要があるかどうかに関する追加情報をリクエストに含めます。たとえば、ログ・ファイルやミラー・コピーにデータを書き込む場合、データベースではキャッシュを省略するようヒントを送信します。表の索引を読み取る場合、データベースではそのデータをキャッシュするようヒントを送信します。この連携動作により、最も頻繁にアクセスされるデータのみが格納されるようにExadataスマート・フラッシュキャッシュ領域の使用が最適化されます。

ユーザーは、他のデータベース・オブジェクトよりも優先的にキャッシュするオブジェクト(表領域や表など)と、まったくキャッシュしないオブジェクトについてより詳細に制御できます。この制御を行うには、データベース・オブジェクトに割当て可能な、STORAGE句の新規属性であるCELL_FLASH_CACHEを使用します。

たとえば、Exadataスマート・フラッシュキャッシュにCALLDETAIL表を確保する場合、次のコマンドを使用します。

ALTER TABLE calldetail STORAGE (CELL_FLASH_CACHE KEEP)

Exadata Storage Serverでは、CALLDETAIL表のデータを優先的にキャッシュし、そのデータを他の表のキャッシュ・データよりも長い間Exadataスマート・フラッシュキャッシュに保持するよう試みます。CALLDETAIL表が複数のOracle Exadata Storage Serverに分散されている場合、それぞれ独自のExadataスマート・フラッシュキャッシュに表の一部がキャッシュされます。キャッシュのサイズが十分であれば、多くの場合、CALLDETAIL表は一定期間にわたり完全にキャッシュされます。

A.17.2 ハイブリッド列圧縮

Exadata Hybrid Columnar Compressionにより、ダイレクト・パス・ロードが行われるデータに高度な圧縮レベルが提供されます。この新しい圧縮機能は、更新頻度の低いデータに推奨されます。ハイブリッド列圧縮は、パーティション、表および表領域のレベルで指定できます。また、希望の圧縮レベルを指定して、ディスク使用量とCPUオーバーヘッドの間のトレードオフ関係を適切に調整することもできます。さらに、現在のアプリケーションにとって適切な圧縮レベルを決定するのに役立つ圧縮アドバイザも付属しています。

この機能によって、データベースでは表をスキャンするI/Oの回数を減らすことができます。たとえば、データを10分の1に圧縮すれば、I/Oも10分の1に減少します。また、ハイブリッド列圧縮により、同じ容量分のディスク領域を節約できます。

同様に、この機能によって、データベースでは列圧縮表のスマート・スキャンをOracle Exadata Storage Serverにオフロードできます。圧縮表でスキャンが行われる場合、Oracle Exadata Storage Serverはスキャンのためにディスクから圧縮ブロックを読み取ります。次に、Oracle Exadata System Softwareが参照列を解凍し、データの条件評価を実行して、フィルタを適用します。その後、ストレージ・サーバーは、修飾データを非圧縮形式で返します。このオフロードがなければ、データ解凍はデータベース・サーバーで発生することになります。Oracle Exadata Storage Serverにデータを解凍させることで、データベース・サーバーのCPUを大幅に節約できます。

関連項目:

ハイブリッド列圧縮の詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.17.3 ストレージ索引

ストレージ索引は、I/O操作の回避に役立つ、Oracle Exadata System Softwareで提供される非常に優れた機能です。Oracle Exadata System Softwareでは、Exadataメモリーにストレージ索引を作成して管理します。ストレージ索引により、そのセルに格納されている表の列の最小値と最大値がストレージ・リージョン単位で追跡されます。この機能は透過的に実行されるため、ユーザーによる管理操作は必要ありません。

問合せでWHERE句が指定されると、Oracle Exadata System Softwareでは、ストレージ索引を調査して、指定された列値を含む行がセル内ディスクのリージョンに存在しないかどうかを判断します(この処理は、ストレージ索引に保持されている最小値および最大値と列値を比較することで行われます)。列値が最小値と最大値の範囲外の場合、その問合せのためのスキャンI/Oはそのリージョンで回避されます。多数のI/O操作が少数のインメモリー検索に自動的に置き換えられるため、多くのSQL操作の実行速度が大幅に向上します。操作上のオーバーヘッドを最小限に抑えるため、Oracle Exadata System Softwareによってストレージ索引が透過的かつ自動的に作成されて管理されます。

ストレージ索引は、暗号化された表領域で効果を発揮します。ただし、ストレージ索引では、暗号化された列の最小値と最大値は保持されません。

A.17.4 暗号化データのスマート・スキャン

Oracle Exadata System Softwareでは、復号化処理をオフロードし、暗号化された表領域や暗号化された列に対してスマート・スキャンを実行できます。以前のリリースのOracle Exadata System Softwareでも、暗号化された表領域と暗号化された列は完全にサポートされていましたが、Exadataオフロード処理によるメリットはありませんでした。暗号化された表領域の場合、Oracle Exadata System Softwareでは、ブロックを復号化してその復号化ブロックをOracle Databaseに返すか、または行および列を返すスマート・スキャンを実行できます。Oracle Exadata System Softwareがデータベースのかわりに復号化を実行すると、CPUの使用がExadataセルにオフロードされるため、CPU処理を大幅に節約できます。

A.17.5 インターリーブ・グリッド・ディスク

この機能は、Oracle Exadata System Softwareリリース19.1.0で非推奨となりました。

グリッド・ディスクの領域は、インターリーブ形式で割り当てることができます。このタイプの領域割当てを使用するグリッド・ディスクは、インターリーブ・グリッド・ディスクと呼ばれます。この方法では、内側のトラックのグリッド・ディスクを犠牲にして外側のトラックを占有するグリッド・ディスクに優れたパフォーマンスを発揮させるのではなく、同じセル・ディスク上に存在する各グリッド・ディスクのパフォーマンスを均等化するよう試みます。

セル・ディスクは、外側半分(上部)と内側半分(下部)の2つの等しい部分に分割されます。新規グリッド・ディスクが作成されると、そのグリッド・ディスク領域の半分はセル・ディスクの外側半分に割り当てられ、グリッド・ディスク領域の残りの半分はセル・ディスクの内側半分に割り当てられます。グリッド・ディスクの上部は、外側半分の空き領域または使用済領域に応じて、外側半分で最初に使用できる最も外側のオフセットから開始します。グリッド・ディスクの下部は、内側半分で最初に使用できる最も外側のオフセットから開始します。

たとえば、100GBの領域を持つセル・ディスクCD_01_cell01が完全に空で、そのセル・ディスクに50GBのサイズのグリッド・ディスクdata_CD_01_cell01を作成する場合、セル・ディスクのレイアウトは次のようになります。

- Outer portion of data_CD_01_cell01 - 25GB
- Free space - 25GB
------------ Middle Point ------------------
- Inner portion of data_CD_cell01 - 25GB
- Free space - 25GB

関連項目:

グリッド・ディスクの詳細は、Oracle Exadata System Softwareユーザーズ・ガイドを参照してください

A.17.6 データ・マイニング・スコアリングのオフロード

Oracle Exadata System Softwareでは、データ・マイニング・モデル・スコアリングがオフロードされるようになりました。これにより、Oracle Exadata Storage Server上のデータ・ウェアハウスのデプロイメントが、より優れた高性能なデータ分析プラットフォームになります。PREDICTION_PROBABILITYなどのすべてのデータ・マイニング・スコアリング関数は、Oracle Exadata Storage Serverにオフロードされて処理されます。これにより、データベース・サーバーのCPU使用量を抑制し、Oracle Exadata Database ServerOracle Exadata Storage Server間のI/O負荷を軽減しながら、ウェアハウス分析を高速化できます。

A.17.7 管理性機能の拡張

Oracle Exadata Storage Server Softwareには、現在、次の管理性機能が含まれます。

  • ディスク・グループに対する置換ディスクの自動追加: 物理ディスクの障害後に置換ディスクが追加された場合、ディスク・グループを再作成して元のディスク・グループに各グリッド・ディスクを追加するのに必要なすべてのExadata操作は、現在、自動的に実行されます。

  • セルの自動再起動: セルが障害から回復するか、再起動すると、各グリッド・ディスクは自動的にオンラインに変更されます。

  • ASMディスク・グループでのOCRおよび投票ディスクのサポート: Oracle Database 11gリリース2(11.2)では、ASMディスク・グループでOracle Cluster Registry(OCR)および投票ディスクがサポートされます(iSCSIパーティションは必要なくなりました)。

  • データベース・サーバーにおける最大4つのデュアルポートInfiniBandホスト・チャネル・アダプタのサポート。この機能により、Oracle Exadata Storage Server Softwareを使用するデータベース・サーバーとして、より大規模なOracle Exadata Database Machine X2-8フル・ラックを使用できます。

A.18 Oracle Exadata Database Machine 11gリリース2 (11.2)の新機能

Oracle Exadata Database Machine 11gリリース2(11.2)の新機能は次のとおりです。

A.18.1 このガイドの拡張コンテンツ

このリリースの『Oracle Exadata Database Machineシステム概要』には、保守手順、配線情報、サイト計画のチェックリストなどが含まれます。このガイドは、Oracle Exadata Database Machineの主要な参考資料です。